Under what circumstances are dynamic languages appropriate?

Question

I have used static languages such as C#, Java, C and some done some work in Javascript which is a dynamic language.

Contrary to the popular belief, I find myself writing code faster in C# than in Javascript (and that could be because I have more experience in C# compared to javascript)

So, what I want to understand is that what are the places where the dynamic language is appropriate and can be favored over the static languages.

Can a dynamic language be used for the Enterprise system which needs to be maintained for years to come or, its mostly used for use and throw codes?

Answer 1

One sitauation that is showing usefulness of C# 4.0 dynamics. Lets say you have a control that can contain one for two controls. Both od them have DataSource property, but this common superclass don't. In order to make this clear, you can use dynamics to check if the property exists at the runtime level.

Other scenario involves class modification durring runtime based on conditional. Let's say you want function A() to be in class B if only function C() would return true. It can be done in JavaScript, but C# can't do this.

Answer 2

I don't think you can generalize like this. Dynamic/non-dynamic languages can both be useful in the same domain, which is comprised of pretty much everything.

Answer 3

JavaScript is not the best example. You should take a look at Python, Ruby or Groovy.

Answer 4

I'd use a dynamic language anytime simplicity and flexibility count more than performance and explicitness. Static typing gives the compiler a lot of information that can be used to write really fast assembly code. It also makes contracts explicit, possibly making sections of code easier to reason about in isolation. However, because these contracts are so explicit and have ripple effects through so much code they're somewhat hard to change. In systems that need a high degree of flexibility, this can lead to a lot of complexity being created to get around the rigidity of static typing.

Personally, I don't see the lack of static type checking to be that big a deal. Of course, failing at compile time is the ideal fast failure. However, the dynamic language paradigm isn't really bad. When a type error occurs at runtime in a dynamic language, things fail immediately and with explicit error messages. You don't just get weird undefined behavior and a failure in some completely different place.

On the other hand, I find that a good template system (not C++) and static type inference can be an absolute godsend. This allows you to have the best of both worlds, as it's basically compile time dynamic typing. Everything still gets statically checked at compile time. Errors are caught early and efficient assembly code is generated. Nonetheless, you retain the flexibility of not having to make contracts explicit at design time. My understanding is that Haskell, OCaml, etc. do this quite well. If you're interested in a language with a more mainstream look and feel that does this, try D.

Answer 5

Take a look at: http://stackoverflow.com/questions/493973/uses-for-dynamic-languages/667275#667275

Answer 6

I would point out that dynamic languages can have their types implicitly defined by the programmer, the same as a static language.

One nice thing about dynamic languages is that you can write method stubs that call objects and methods that do not actually exist. This can be nice for designing the code first and filling in the details later. Good when you are working in teams. Don't worry though, if you do this the compiler will usually give you a warning that the method call probably won't work. The compiler will let you code and run that code though.

Dynamic languages are powerful, although the power can make them harder to debug at times.