What factors indicate that a project's solution should not be coded in a dynamic language?
+1
A:
Speed is typically the primary answer. Though this is becoming less of an issue these days.
swilliams
2008-09-26 21:57:15
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.
Jörg W Mittag
2008-09-28 08:08:39
A:
when speed is crucial. Dynamic languages are getting faster, but still not close to the performance of what a compiled language is.
Darren Kopp
2008-09-26 21:57:52
+2
A:
Familiarity and willingness of the programmers to work with the language.
Your dynamic language is probably my static language.
ddaa
2008-09-26 22:00:09
+3
A:
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.
Mike Stone
2008-09-26 22:00:16
Well, number crunching and dynamic languages are not orthogonal, given the right libraries. Think Python and Numpy, or Star*P, etc.
ΤΖΩΤΖΙΟΥ
2008-09-26 23:58:45
A:
How about interop? Is it possible to call a COM component from Ruby or Python?
FlySwat
2008-09-26 22:01:04
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.
JasonTrue
2008-09-26 22:51:26
Dynamic languages are often served under the tag "glue languages", so interoperability is in the job description :)
ΤΖΩΤΖΙΟΥ
2008-09-27 00:00:19
+1
A:
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.
Hugo
2008-09-26 22:06:07
A:
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.
lubos hasko
2008-09-26 22:06:40
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...
Mike Stone
2008-09-26 22:10:32
(haskell was a fun language btw with strong type inference, but I still prefer more flexible, dynamic, object oriented languages like Ruby)
Mike Stone
2008-09-26 22:12:00
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
lubos hasko
2008-09-29 00:11:42
A:
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.
alps123
2008-09-26 22:49:22
+2
A:
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.
Logan
2008-09-27 00:28:44