Under what circumstances are dynamic languages not appropriate? [closed]

Question

What factors indicate that a project's solution should not be coded in a dynamic language?

Intercommunion

Answer 1

Speed is typically the primary answer. Though this is becoming less of an issue these days.

Cutlor

Speed is largely dependent on the quality of the implementation and has very little to do with whether the language is dynamically or statically typed. Good Common Lisp compilers can certainly compete with C, bad C compilers can be much slower than, say, CPython. – Madison

Answer 2

Familiarity and willingness of the programmers to work with the language.

Your dynamic language is probably my static language.

Metagalaxy

Answer 3

System level development is a key group of software that typically shouldn't be in dynamic languages. (drivers, kernel level stuff, etc).

Basically anything that needs to have every ounce of performance or low level hardware access, should be in a lower level language.

Another indicator is if it is highly number crunching, like scientific data number crunching. That is, if it needs to run fast and do number crunching.

I think a common theme is processor intensive problems... in which case you will easily see the performance differences, and you will find that the dynamic language just can't give you the power to use the hardware effectively.

That said, if you are doing processor intensive work and you don't mind the hit in performance, then you could still potentially use a dynamic language.

---

Update:

Note that for number crunching, I mean really long running number crunching in scientific arena where the process is running for hours or days... in this case a 2x performance gain is GINORMOUS... if it is on a much smaller scale, then dynamic languages could still be of use.

Herriot

Well, number crunching and dynamic languages are not orthogonal, given the right libraries. Think Python and Numpy, or Star*P, etc. – Jamesy

Answer 4

To a large degree, programming language is a style choice. Use the language you want to use and you'll be maximally productive and happy. If for some reason that's not possible, then hopefully your ultimate decision will be based on something meaningful, like a platform you have to run against or real, empirical performance numbers, rather than someone else's arbitrary style choice.

Stratiform

Answer 5

Video card device drivers

Congresswoman

although... with proper libs even that's possible. just look at numpy. – Walrath

Answer 6

when speed is crucial. Dynamic languages are getting faster, but still not close to the performance of what a compiled language is.

Drawbridge

Answer 7

Interop is absolutely possible with dynamic languages. (remember classic visual basic, which has "lazy binding"?) It requires the COM component to be compiled with some extras though for helping their callers to call by name.

I don't think that number crunching has to be statically compiled, most often it is a matter of how you solve. Matlab is a good example made for number crunching, and it has a non-compiled language. Matlab, however, has a very specific runtime for numbers and matrices.

Mccandless

Answer 8

I believe you should always opt for statically-typed language where possible. I'm not saying C# or Java have good static systems but C# is getting close. Good type inference is the key because it will give you benefits seen in dynamic languages while still giving you security and features of statically-typed ones. Problem solved - no more flamewars.

Lydie

this is highly subjective... even type inference can't always do things that a very dynamic language can do, at least not without a lot of big changes to the type system... – Herriot

(haskell was a fun language btw with strong type inference, but I still prefer more flexible, dynamic, object oriented languages like Ruby) – Herriot

Of course dynamic languages will be always more flexible but at cost of certain guarantees. I think flexibility of dynamic languages is overrated. Ruby is great language, really is, but most of its innovative features are now possible even in C# 3.0 without loosing static-checking during compilation – Lydie

Answer 9

System level code for embedded systems. A possible problem is that dynamic languages sometimes hide the performance implications of a single easy looking statement.

Like say this Perl statement:

@contents = <FILE>;

If FILE is a few megabytes, then that is one resource-consuming statement - you might exhaust your heap, or cause a watchdog timeout, or generally slow down the response of the embedded system.

If you want to "program closer to the metal", you probably want to be using a statically typed and "middle level" language.

Ruthi

Answer 10

How about interop? Is it possible to call a COM component from Ruby or Python?

Lissettelissi

Almost painlessly. Ruby and as far as I remember Python both have Win32Ole modules for this purpose. .Net interop is also possible, though I think it works better with the IronRuby/IronPython implementations. – Lablab

Dynamic languages are often served under the tag "glue languages", so interoperability is in the job description :) – Jamesy