What do people find so appealing about dynamic languages? [closed]

Question

It seems that everybody is jumping on the dynamic, non-compiled bandwagon lately. I've mostly only worked in compiled, static typed languages (C, Java, .Net). The experience I have with dynamic languages is stuff like ASP (Vb Script), JavaScript, and PHP. Using these technologies has left a bad taste in my mouth when thinking about dynamic languages. Things that usually would have been caught by the compiler such as misspelled variable names and assigning an value of the wrong type to a variable don't occur until runtime. And even then, you may not notice an error, as it just creates a new variable, and assigns some default value. I've also never seen intellisense work well in a dynamic language, since, well, variables don't have any explicit type.

What I want to know is, what people find so appealing about dynamic languages? What are the main advantages in terms of things that dynamic languages allow you to do that can't be done, or are difficult to do in compiled languages. It seems to me that we decided a long time ago, that things like uncompiled asp pages throwing runtime exceptions was a bad idea. Why is there is a resurgence of this type of code? And why does it seem to me at least, that Ruby on Rails doesn't really look like anything you couldn't have done with ASP 10 years ago?

Carcassonne

Kinda sad (and odd) to see so few defending dynamic languages. – Mediatory

Since this is the only way to get somoething in above all the dynamic-haters below, i'll answer here: Dynamic languages let you write code faster, no two ways about it. I don't have to worry about the type of any of my variables, and i don't have to fire up a big heavy IDE to write code. Thus, it's much better for doing quick tasks that would take longer with static type systems due to the cumbersomeness of type systems making you tell the comiler EVERYTHING. – Magruder

What's with C# programmers parochial myopia? – Explication

First, what's parochial myopia? – Magruder

@RCIX: Then do that kind of quick throw-away stuff in a script language that is inherently dynamic. I'd rather have strict type safety - but with generics and a smart compiler with type inference like in most functional languages - in the language(s) that I use. – Cecil

I take it you haven't read steve.yegge.googlepages.com/is-weak-typing-strong-enough then? – Magruder

What you want is a blend between static and dynamic, simply because you would hate oprating in a strict type system with no generics, no lambdas, no implicit variables, etc. – Magruder

Misspelled variable names being a problem comes from implicit variable declaration, not static/dynamic. Dynamic languages that require explicit variable declaration (like Smalltalk) don't have this problem. – Creedon

With the right IDE (e.g. Zend Studio, netbeans, eclipse etc) you can catch a bunch of errors before runtime. – Redpoll

Answer 1

I think the reason is that people are used to statically typed languages that have very limited and inexpressive type systems. These are languages like Java, C++, Pascal, etc. Instead of going in the direction of more expressive type systems and better type inference, (as in Haskell, for example, and even SQL to some extent), some people like to just keep all the "type" information in their head (and in their tests) and do away with static typechecking altogether.

What this buys you in the end is unclear. There are many misconceived notions about typechecking, the ones I most commonly come across are these two.

Fallacy: Dynamic languages are less verbose. The misconception is that type information equals type annotation. This is totally untrue. We all know that type annotation is annoying. The machine should be able to figure that stuff out. And in fact, it does in modern compilers. Here is a statically typed QuickSort in two lines of Haskell (from haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

And here is a dynamically typed QuickSort in LISP (from swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

The Haskell example falsifies the hypothesis statically typed, therefore verbose. The LISP example falsifies the hypothesis verbose, therefore statically typed. There is no implication in either direction between typing and verbosity. You can safely put that out of your mind.

Fallacy: Statically typed languages have to be compiled, not interpreted. Again, not true. Many statically typed languages have interpreters. There's the Scala interpreter, The GHCi and Hugs interpreters for Haskell, and of course SQL has been both statically typed and interpreted for longer than I've been alive.

You know, maybe the dynamic crowd just wants freedom to not have to think as carefully about what they're doing. The software might not be correct or robust, but maybe it doesn't have to be.

Personally, I think that those who would give up type safety to purchase a little temporary liberty, deserve neither liberty nor type safety.

Histamine

Yeah, and if you're talking about Java there's Groovy...it's dynamically typed Java. – Uriniferous

Well it's going to be more verbose if you choose longer names for everything! (Does LISP forbid the name "qsort" ?) – Outspoken

Give up type safe for liberty deserve neither.. Oh yeah man.. Excellent close to the post – Gastropod

lisp is quite verbose by itself, it has nothing to do with it being dynamically typed... try it in python. def qsort(l): return qsort([x for x in l[1:] if x < l[0]]) + l[0] + qsort([x for x in l[1:] if x >= l[0]]) if l else l – Met

That's precisely the point. It has nothing to do with being dynamically or statically typed. – Histamine

Haskell is a great language. But, I suspect most people who are on the statically-typed bandwagon are not using Haskell, Scala, Ocaml, or f#. – Energetic

great point with the algorithm - dynamic language are write only, how many programmers that dont know lisp/haskell can understand that? not many. i prefer badly written java code. – Bobstay

I think part of the reason people are not big on statically-typed languages like C, C++ and Java is all the casting involved. Fortunately, I think that type-inference in C# and Scala (and others) has mostly solved this problem. You get the expressiveness of a dynamic language with the safety and error-checking of a typed language. To me, it's a good trade-off. – Uncharted

I would argue that your examples are rather poor. The people praising dynamic languages are not likely choosing Lisp of Haskell. They are likely choosing Python or Ruby over Java or C#. – Quilting

People. The examples were picked to be one very terse statically typed language and one very verbose dynamic language. Haskell and LISP fit those categories well. – Histamine

I must now use the Steve Yegge power to stage a Dynamic Languages Strike Back, or read this: steve-yegge.blogspot.com/2008/05/… – Magruder

In short, compilers should be able to infer a lot more than wheat they do now, dynamic languages could be waaaaaay faster, and (i think) dynamic type systems aren't pure evil like everyone thinks! – Magruder

Well, you made an argument, and then cherry-picked two languages atypical of their class to prove that point. No one is arguing that all dynamic languages are less verbose than all static languages. The argument would be that most commonly-used static languages (C, C++, Java, C#) are more verbose than most commonly-used dynamic languages (Python, PHP, Ruby). – Mediatory

The argument goes that there's a link between verbosity and typefulness. As you can see, any such coincidence is pure accident. Atypical is precisely why I picked these languages. Haskell is more strongly typed than most anything else, so it's a good representative of the statically typed languages. LISP is the quintessential dynamic language which all others necessarily imitate but never duplicate. – Histamine

Hypothesis: Statically typed implies verbose. Falsification: Haskell is statically typed. Haskell is one of the least verbose languages in existence. True (statically typed) => False (verbose) == False. Ergo, the hypothesis of implication is falsified. Q.E.D. – Histamine

RCIX: It's perhaps ironic that Steve Yegge is extremely verbose. – Histamine

Not all static languages are verbose, and not all dynamic languages are concise. However, in general, dynamic languages are more concise than static ones. – Magruder

Fallacy: a series of carefully crafted examples ("anecdotes") proves anything in the general case. – Angelus

If you picked two languages more typical (say c# and Python), i don't think that you would be saying the same thing... – Magruder

A good quote from Steve Yegge (who was a diehard java fan till he saw Perl outperforming it at amazon: – Magruder

"But after watching the new Hitchhiker's Guide movie this weekend, and seeing the hilarious caricature of British governmental bureacracy in the Vogons, I thought: hey, I hate bureacracy. And static type systems are basically just bureacracy. I want them to get out of my way and let me get stuff done without needing to fill out a bunch of forms. If the price of getting static type-safety is working with a brain-dead compiler and a restrictive type system, well, then I can handle my own type errors, thanks very much. " – Magruder

I'm sorry I didn't pick the languages you know/like/approve. Tough cookies, really. – Histamine

hobbs: But a carefully crafted example can disprove a poorly crafted induction. – Histamine

Ok then let's do an example to prove that dynamically typed languages are faster than static type ones let's pit lua gainst....say...COBOL(or insert slow static language here). Whaddya know! lua is faster! Wait, i didn't use your favorite languages? sor-ry..... My point is that you can't cherry-pick languages to prove your point or you can prove anything you want. You need to use some reasonably objective measure to select the language (like popularity) – Magruder

RCIX: I'm not cherry-picking. The accusation is that statically typed languages are verbose. This accusation implies a causal connection between verbosity and typefulness. Going straight to the most typeful language for which I could find an example of anything useful. As strongly typed as you might think C# or Java are, they aren't half as strongly typed as Haskell. Yet Haskell is more terse. Could that be because there is no link whatsoever between verbosity and typefulness? I don't aim to prove anything here. Only to disprove. What's your aim? – Histamine

RCIX: Is all you're saying that most of the popular dynamic languages are more terse than languages with piss-poor type systems such as Java and C#? In that case, I agree. But this is only because Java and C# are poorly designed, not because they are statically typed. – Histamine

Ok first of all i disagree that C# is poorly designed, but that's another argument altogether. I get the point you're making now but i don't see it's relevance to the question; you've proved that not ALL dynamic languages are less verbose than ALL static ones, so what? It seems to give the impression that the main reason for using dynamic languages (conciseness) is nulled out, and that's not what yourre really saying.The case for most popular dynamic languages is that they are more concise while being easier to read, and that holds true for them. – Magruder

That is indeed what I'm saying: dynamic buys you metaprogramming, but not much else. Many of them have other qualities, but these qualities are orthogonal to types or lack thereof. Static languages that have very poor type systems but very good marketing are not going to be terse. But that's no reason to throw out types. – Histamine

I think that it's quite possible that something like a mix of F# and something like Python will become the norm at some point: sufficient type safety to aid in maintainability, while offering many of the features and flexibilities of a dynamic language. Ultimately i suspect, this is what it's going to take to quell all of the "Static is better! no dynamic is better!" talk... Anyway, back to static bashing ;) – Magruder

A crippled, "sufficiently typed" language might become the "norm" at some point, but if I'm going to have a dynamic language, then I'd rather have un(i)typed all the way down, i.e. some dialect of LISP. Dynamic was already perfected by the Lambda Papers in the 1970s, so that's done and done. Meanwhile, technology marches on with dependently typed languages like Agda and Epigram. The future of programming lies in new research such as that. – Histamine

But that's the thing, LISP allows you to define static types as necessary and i think it does type checking for them.... – Magruder

+1 for the great deliberately mangled quote, tho I totally love Ruby. QUESTION: if the verbosity conventional wisdom is so false, how come perl, python, and ruby totally dominate the top code-golf scores on SO? – Pascale

Re interpreters for compiled languages: There's even an interpreter for C++, cint from the ROOT project. And I'm pretty sure the clang project will eventually do one too. – Crick

Answer 2

Don't forget that you need to write 10x code coverage in unit tests to replace what your compiler does :D

I've been there, done that with dynamic languages, and I see absolutely no advantage.

Hundredth

Glad I'm not the only one. Makes me sleep better at night. – Availability

This is indeed the big advantage of static over dynamic typing. I can't tell how many times I've missed a typesafe typedef in C++, just to enable the compiler to find me some more bugs. (Go compiler, go! Fetch me some more bugs! :-) – Serendipity

Nonsense. If you're testing the method, and you're testing the methods that call the method, you know the parameter passing is fine. By definition, well tested code will gain precisely no additional benefit from static typing. – Pentatomic

@Garth: weird definition. Not one many people would agree with. OTOH, most people would agree that the compiler’s type checker implements a lot of (sometimes very complex) tests. – Defrayal

@Garth Roxburgh-Kidd, you're assuming that you test all paths through all code at all times. Then who maintains your test code? – Agama

@yar, if you're not testing your code, you're vulnerable to logic bugs. I've worked in Python for a decade, now. I don't think I've ever had a TypeError in production. I've had plenty of logic bugs, though. Conclusion: I don't need static type checking much, but I definitely need unit tests. – Pentatomic

@Garth T Kidd, that's cool. I'm getting into testing now with Ruby, so hopefully it will restore and even go beyond the confidence I have in, say, Java code thanks to compile-time checks. An open mind is not very scientific, but it is very objective :) – Agama

Answer 3

When reading other people's responses, it seems that there are more or less three arguments for dynamic languages:

1) The code is less verbose. I don't find this valid. Some dynamic languages are less verbose than some static ones. But F# is statically typed, but the static typing there does not add much, if any, code. It is implicitly typed, though, but that is a different thing.

2) "My favorite dynamic language X has my favorite functional feature Y, so therefore dynamic is better". Don't mix up functional and dynamic (I can't understand why this has to be said).

3) In dynamic languages you can see your results immediately. News: You can do that with C# in Visual Studio (since 2005) too. Just set a breakpoint, run the program in the debugger and modify the program while debbuging. I do this all the time and it works perfectly.

Myself, I'm a strong advocate for static typing, for one primary reason: maintainability. I have a system with a couple 10k lines of JavaScript in it, and any refactoring I want to do will take like half a day since the (non-existent) compiler will not tell me what that variable renaming messed up. And that's code I wrote myself, IMO well structured, too. I wouldn't want the task of being put in charge of an equivalent dynamic system that someone else wrote.

I guess I will be massively downvoted for this, but I'll take the chance.

Availability

quote: In dynamic languages you can see your results immediately. News: You can do that with C# in Visual Studio (since 2005) too. Just set a breakpoint, run the program in the debugger and modify the program while debbuging. I do this all the time and it works perfectly. This has been in Delphi since day one (1995?) and probably in Turbo Pascal before that (I don't remember exactly). – Presentment

10k lines of javascript? I think thats around 9,000 lines too many and I love scripting languages... – Antirachitic

@No'am: I know. You could do it in Visual C++ 6 as well (which was actually the main point for me not to switch to C# until VS2k5 came out). If anything, this only adds to the point. @Oz: How do you know how much work my JS has to do? – Availability

I think people who like seeing their changes take effect immediately like using a plain text editor too, and not VS. To each his own. You might consider using something like JSLint. – Etherege

@dlamblin: Why is it preferable to use a text editor over an IDE? Btw, I just tested Eclipse for Java, and that supports edit and continue, too. Jslint, no thanks, I switched to Script# instead. – Availability

Good point with the refactoring. I'm really starting to enjoy Ruby for rapid prototyping and small scripts, but I would never try to maintain a large product across several developers without static typing. – Koziol

Answer 4

I am a full-time .Net programmer fully entrenched in the throes of statically-typed C#. However, I love modern JavaScript.

Generally speaking, I think dynamic languages allow you to express your intent more succinctly than statically typed languages as you spend less time and space defining what the building blocks are of what you are trying to express when in many cases they are self evident.

I think there are multiple classes of dynamic languages, too. I have no desire to go back to writing classic ASP pages in VBScript. To be useful, I think a dynamic language needs to support some sort of collection, list or associative construct at its core so that objects (or what pass for objects) can be expressed and allow you to build more complex constructs. (Maybe we should all just code in LISP ... it's a joke ...)

I think in .Net circles, dynamic languages get a bad rap because they are associated with VBScript and/or JavaScript. VBScript is just a recalled as a nightmare for many of the reasons Kibbee stated -- anybody remember enforcing type in VBScript using CLng to make sure you got enough bits for a 32-bit integer. Also, I think JavaScript is still viewed as the browser language for drop-down menus that is written a different way for all browsers. In that case, the issue is not language, but the various browser object models. What's interesting is that the more C# matures, the more dynamic it starts to look. I love Lambda expressions, anonymous objects and type inference. It feels more like JavaScript everyday.

Decoction

I wish someone would add file-handling, sockets, and a GUI library to JavaScript, then build a compiler... JS on the desktop....... – Dive

code.google.com/p/jslibs – Siebert

Also, it's always been possible to write a windows gui app using jscript. Well, for a very very long time anyway. see "windows hta" for more info- You get some extra apis running in an hta you don't get in a browser. Dashboard widgets get a lot of power. Webapps on the iphone are a lot more powerful than most people give them credit for. Apple has made a lot of powerful apis available to brower JS in mobile safari. – Siebert

commonjs.org – Revocation

+1 for intent here. Though your code might be translated to a static lang one day, dynamics (Python particularly) are great for one-offs and prototypes. – Hemimorphite

@Unkwntech take a look at Adobe AIR – Zetta

Answer 5

VBScript sucks, unless you're comparing it to another flavor of VB. PHP is ok, so long as you keep in mind that it's an overgrown templating language. Modern Javascript is great. Really. Tons of fun. Just stay away from any scripts tagged "DHTML".

I've never used a language that didn't allow runtime errors. IMHO, that's largely a red-herring: compilers don't catch all typos, nor do they validate intent. Explicit typing is great when you need explicit types, but most of the time, you don't. Search for the questions here on generics or the one about whether or not using unsigned types was a good choice for index variables - much of the time, this stuff just gets in the way, and gives folks knobs to twiddle when they have time on their hands.

But, i haven't really answered your question. Why are dynamic languages appealing? Because after a while, writing code gets dull and you just want to implement the algorithm. You've already sat and worked it all out in pen, diagrammed potential problem scenarios and proved them solvable, and the only thing left to do is code up the twenty lines of implementation... and two hundred lines of boilerplate to make it compile. Then you realize that the type system you work with doesn't reflect what you're actually doing, but someone else's ultra-abstract idea of what you might be doing, and you've long ago abandoned programming for a life of knicknack tweaking so obsessive-compulsive that it would shame even fictional detective Adrian Monk.

That's when you go get plastered start looking seriously at dynamic languages.

Substantiate

Interesting stuff... I'll see if Ruby convinces me. PHP has not, but I feel that a lot of that is because it's OO stuff is an afterthought. – Agama

"twenty lines of implementation... and two hundred lines of boilerplate to make it compile": I disagree with this statement. Sure, it was true in the Java days, but C# 3 and Scala have vastly reduced the amount of boilerplate required. – Uncharted

The Java days are over? cracks a beer and prepares to celebrate Oh... wait... C++. – Substantiate

"VBScript sucks, unless you're comparing it to another flavor of VB" Huh? Are you saying VBScript is the best variant of Visual Basic? I must have misunderestimated you. – Serrato

Answer 6

Here is a statically typed QuickSort in two lines of Haskell (from haskell.org):

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

And here is a dynamically typed QuickSort in LISP (from swisspig.net):

(defun quicksort (lis) (if (null lis) nil
  (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
    (append (quicksort (remove-if-not fn r)) (list x)
      (quicksort (remove-if fn r))))))

I think you're biasing things with your choice of language here. Lisp is notoriously paren-heavy. A closer equivelent to Haskell would be Python.

if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

Python code from here

Tyndall

That's not a retort, but a supporting argument. It goes to show that a language's type system (or lack thereof) tells us very little about whether it will be verbose or concise. – Histamine

I agree with Apocalisp, verbosity is not dependant in either dynamic or static languages. I would even say that static/dynamic typing has little to no effect on verbosity of a language. So yes this is no static typing camp destroying retort. – Magical

or perl! sort(@array); – Pickpocket

Apocalisp's whole comparison was bullshit. Firstly, quicksort (as defined in the original paper by Tony Hoare) is an in-place algorithm specifically designed to use minimal extra space but Apocalisp used the Haskell community's bastardized out-of-place version that wastes asymptotically more memory and runs hundreds of times slower than a real quicksort. Haskell struggles to express a real quicksort algorithm because it relies upon mutation (!). Check out these Haskell attempts and get back to me on Haskell's alleged brevity: haskell.org/haskellwiki/Introduction/Direct_Translation – Cavernous

Secondly, you cannot make any strong statements about verbosity on the basis of two implementations of an algorithm that has been bastardized specifically for one of the languages. Look at APL or J or K or Mathematica or any other concise (= modern) dynamically typed language. They should be more concise than any statically typed language. Type inference shrinks the gap but there should still be a gap. – Cavernous

Answer 7

For me, the advantage of dynamic languages is how much more readable the code becomes due to less code and functional techniques like Ruby's block and Python's list comprehension.

But then I kind of miss the compile time checking (typo does happen) and IDE auto complete. Overall, the lesser amount of code and readability pays off for me.

Another advantage is the usually interpreted/non compiled nature of the language. Change some code and see the result immediately. It's really a time saver during development.

Last but not least, I like the fact that you can fire up a console and try out something you're not sure of, like a class or method that you've never used before and see how it behaves. There are many uses for the console and I'll just leave that for you to figure out.

Find

At least one Python IDE I know of (namely, IDLE, the one that happens to come with the usual build of the Python interpreter) does indeed have auto-completion capabilities, though declared variables only have it in the interpreter window. – Semple

readable? have you seen the quicksort example? i have no idea whats going up there. u can argue that its badly written to show how fast can u write something, but its not readable. – Bobstay

@01: its using common constructs of the language. Its fairly readable if you do know the basics of the language. – Evocator

I write PHP, and there are many IDEs which provide autocomplete features (Netbeans, Zend Studio, Eclipse, Komodo, for example). – Mediatory

Readability has nothing to do with dynamic typing. E.g. Scala's lambdas are typically shorter (and arguably more expressive) then Ruby's blocks, the same comparing Haskell's and Python's list complehensions. REPL console exists e.g. for F#, Scala, Haskell. Quick loading of changed code to running application is the strong point of dynamic languages. Though there are some technologies that allow it for static languages (JavaRebel e.g.). – Sabec

Interestingly I find the code LESS readable. Number one because I often can't use my IDE to zip around to find declarations and embedded documentation etc., and number two because the syntax is so compact quite often I forget what on earth it means! I would also put FAR greater weighting on the loss of IDE autocompletion. Not only is it a godsend, I think it absolutely increases maintainability. – Carchemish

I think the biggest drawback of dynamic languages is the lack of proper IDE support. Visual Studio and Eclipse increase productivity by at least 5x compared to hacking away in Text Mate. – Boustrophedon

Answer 8

Your arguments against dynamic languages are perfectly valid. However, consider the following:

1. Dynamic languages don't need to be compiled: just run them. You can even reload the files at run time without restarting the application in most cases.
2. Dynamic languages are generally less verbose and more readable: have you ever looked at a given algorithm or program implemented in a static language, then compared it to the Ruby or Python equivalent? In general, you're looking at a reduction in lines of code by a factor of 3. A lot of scaffolding code is unnecessary in dynamic languages, and that means the end result is more readable and more focused on the actual problem at hand.
3. Don't worry about typing issues: the general approach when programming in dynamic languages is not to worry about typing: most of the time, the right kind of argument will be passed to your methods. And once in a while, someone may use a different kind of argument that just happens to work as well. When things go wrong, your program may be stopped, but this rarely happens if you've done a few tests.

I too found it a bit scary to step away from the safe world of static typing at first, but for me the advantages by far outweigh the disadvantages, and I've never looked back.

Surly

If you don't see it, it doesn't bother you. This is like saying functional languages are not deterministic because you don't know how instructions between threads are interleaved. It's true, but it is not noticable to users or programmers, so it just doesn't matter. – Surly

-1: I would say reasons one and two are plain incorrect and reason three is a sloppy bad practice, one: dynamic languages have nothing to do with when the code is compiled, it's about typing (Scala interpreter). Two: just take a look at Haskell, Erlang, Scala etc. Three: replace the words "not to worry about" with "assume correct" and you'll see why I find the final point unsettling. – Magical

@wvdschel: By your logic, I could argue compiled languages like C# and Java don't need to be compiled then, since all I have to do is click the "Play" button on my IDE and they just run. Since I don't notice that the IDE is compiling for me, it "just doesn't matter". – Uncharted

@cdmckay: And can you connect to your running C#/Java program and run commands against it, modifying or querying it as it's running. Interpreted (which many Dynamic languages are) languages allow runtime introspection that compiled languages just don't. – Amidase

@Amidase - Um, yes, you can do all of that with Visual Studio. Edit-and-continue isn't restricted to dynamic languages. – Pumpkin

@RHSeeger: Erm, yes, the Visual Studio debugger does exactly that. Why shouldn't that be possible for a compiled language? – Dotty

@Greg Beech, @nikie: C# isn't turned into machine code directly. It runs on a Virtual Machine. That's why you can do those things. – Evocator

@baash05, I think you've thoroughly missed hte point of this answer, 1.means you can run code as you right it faster no need to wait for a compiler to see the effects of every small change. 2. weather you agree with the effect of it or not there will be less code to write and to read no arguing this fact. – Deason

Thank you fire crow, we need more people like you on our side. I wrote a rather large lua script just a few weeks ago and i shudder to think what it would look like in C#, simply because it's waaaaaaaaay easier to learn and understand dynamic languages like lua. You don't have to wrap your head around half of the idiosynacricies of C#. "Why are arrays zero based?" "why do i have to cast that darn number? its just a stupid number!" "Why do we need half a dozen different data structures? i just want to store my data..." What's the differentce between a class and struct?" Etc. – Magruder

@Magruder "Why do we need half a dozen different data structures? I just want to store my data..." - I'm glad I'm not on your team! FYI the Interpreted vs Compiled debate is unrelated to the Static vs Dynamic debate. Keep on topic. – Waverly

Well said. Dynamic languages are generally just more expressive! if a = b rather than if aVeryLongObject->obscureMethod.equals(anotherLongObjectName->obscureMethod) – Pickpocket

2. That's not an issue of static vs. dynamic but of procedural vs. functional. True: Python (and many other dynamic languages) are more functional than Java. False: This has anything to do with dynamic typing. – Availability

Answer 9

I believe that the "new found love" for dynamically-typed languages have less to do with whether statically-typed languages are better or worst - in the absolute sense - than the rise in popularity of certain dynamic languages. Ruby on Rails was obviously a big phenomenon that cause the resurgence of dynamic languages. The thing that made rails so popular and created so many converts from the static camp was mainly: very terse and DRY code and configuration. This is especially true when compared to Java web frameworks which required mountains of XML configuration. Many Java programmers - smart ones too - converted over, and some even evangelized ruby and other dynamic languages. For me, three distinct features allow dynamic languages like Ruby or Python to be more terse:

1. Minimalist syntax - the big one is that type annotations are not required, but also the the language designer designed the language from the start to be terse
2. inline function syntax(or the lambda) - the ability to write inline functions and pass them around as variables makes many kinds of code more brief. In particular this is true for list/array operations. The roots of this ideas was obviously - LISP.
3. Metaprogramming - metaprogramming is a big part of what makes rails tick. It gave rise to a new way of refactoring code that allowed the client code of your library to be much more succinct. This also originate from LISP.

All three of these features are not exclusive to dynamic languages, but they certainly are not present in the popular static languages of today: Java and C#. You might argue C# has #2 in delegates, but I would argue that it's not widely used at all - such as with list operations.

As for more advanced static languages... Haskell is a wonderful language, it has #1 and #2, and although it doesn't have #3, it's type system is so flexible that you will probably not find the lack of meta to be limiting. I believe you can do metaprogramming in OCaml at compile time with a language extension. Scala is a very recent addition and is very promising. F# for the .NET camp. But, users of these languages are in the minority, and so they didn't really contribute to this change in the programming languages landscape. In fact, I very much believe the popularity of Ruby affected the popularity of languages like Haskell, OCaml, Scala, and F# in a positive way, in addition to the other dynamic languages.

Energetic

Answer 10

Personally, I think it's just that most of the "dynamic" languages you have used just happen to be poor examples of languages in general.

I am way more productive in Python than in C or Java, and not just because you have to do the edit-compile-link-run dance. I'm getting more productive in Objective-C, but that's probably more due to the framework.

Needless to say, I am more productive in any of these languages than PHP. Hell, I'd rather code in Scheme or Prolog than PHP. (But lately I've actually been doing more Prolog than anything else, so take that with a grain of salt!)

Antimicrobial

Answer 11

My main reason for liking dynamic (typed, since that seems to be the focus of the thread) languages is that the ones I've used (in a work environment) are far superior to the non-dynamic languages I've used. C, C++, Java, etc... they're all horrible languages for getting actual work done in. I'd love to see an implicitly typed language that's as natural to program in as many of the dynamically typed ones.

That being said, there's certain constructs that are just amazing in dynamically typed languages. For example, in Tcl

 lindex $mylist end-2

The fact that you pass in "end-2" to indicate the index you want is incredibly concise and obvious to the reader. I have yet to see a statically typed language that accomplishes such.

Amidase

In what way is this better than $mylist.length-2? To me, it seems that kind of syntax only adds extra keywords with no real benefit, meaning the language harder to learn. – Availability

I'll be a slight bit pedantic and point out that it doesn't add any keywords to the language itself, it adds that to that command. That being said, it's a matter of being clearer. The term "end" expresses the intent/meaning rather than how to get there; it says "the last element". – Amidase

If I understand you correct, that case it's even worse. You have to learn new syntax for each command. what does the keyword bar mean when used in the command foo? – Availability

@erikkallen: Its the same as learning what the different inputs to a standard library are for any other language. In fact, every command in core Tcl is, more or less, just part of the standard library. In theory, there are no commands that couldn't be removed and re-implemented as pure Tcl code. That being said, the inputs and what they mean are fairly consistent across that library (ie, end means the same thing across all the commands) – Amidase

Answer 12

Ah, I didn't see this topic when I posted similar question

Aside from good features the rest of the folks mentioned here about dynamic languages, I think everybody forget one, the most basic thing: metaprogramming.

Programming the program.

Its pretty hard to do in compiled languages, generally, take for example .Net. To make it work you have to make all kind of mambo jumbo and it usualy ends with code that runs around 100 times slower.

Most dynamic languages have a way to do metaprogramming and that is something that keeps me there - ability to create any kind of code in memory and perfectly integrate it into my applicaiton.

For instance to create calculator in Lua, all I have to do is:

print( loadstring( "return " .. io.read() )() )

Now, try to do that in .Net.

Quechua

Do you often create calculators? I find arguments of the type "I can create the hello world application in 20 characters" having no value whatsoever. – Availability

You just showed how extremely low imagination you have. Bad thing for programming m8. GL. – Quechua

No need to get personal. I think the point is valid. It is very easy (and very common) to come up with arguments of the type 'look how much code you have to write to print a line to the console in C#, in lua I can just say print("Hello, world")'. But the ratio real code to boilerplate doesn't stay like that when the projects grow into realistic size. – Availability

Bullshit. Here's some statically-typed F# that runs on .NET: Linq.QuotationEvaluator.Evaluate <@ 2 + 3 @> – Cavernous

Answer 13

One of the advantages pointed out for dynamic languages is to just be able to change the code and continue running. No need to recompile. In VS.Net 2008, when debugging, you can actually change the code, and continue running, without a recompile. With advances in compilers and IDEs, is it possible that this and other advantages of using dynamic languages will go away.

Memphis

You're correct that there's nothing inherent in dynamically typed languages that lets you change code in a running system. It's a lot easier with interpreted languages (not to be confused with dynamic), but it can be accomplished even with compiled code. Just as one example, Oracle's PL/SQL is a statically typed compiled language, and Oracle has had the feature for decades now where you can modify PL/SQL procedures in a running system. – Histamine

There's a C# repl in Mono now -- mono-project.com/CsharpRepl – Gytle

Dynamic languages can do that kind of things outside a debugger, and from within your application. Also, the possibility of doing monkey patching to classes when unittesting, is a time saver. – Evocator

Answer 14

My appreciation for dynamic languages is very much tied to how functional they are. Python's list comprehensions, Ruby's closures, and JavaScript's prototyped objects are all very appealing facets of those languages. All also feature first-class functions--something I can't see living without ever again.

I wouldn't categorize PHP and VB (script) in the same way. To me, those are mostly imperative languages with all of the dynamic-typing drawbacks that you suggest.

Sure, you don't get the same level of compile-time checks (since there ain't a compile time), but I would expect static syntax-checking tools to evolve over time to at least partially address that issue.

Ingrate

I've never before heared anyone even suggesting that he likes the JavaScript prototyped objects. – Availability

Answer 15

I think this kind of argument is a bit stupid: "Things that usually would have been caught by the compiler such as misspelled variable names and assigning an value of the wrong type to a variable don't occur until runtime" yes thats right as a PHP developer I don't see things like mistyped variables until runtime, BUT runtime is step 2 for me, in C++ (Which is the only compiled language I have any experience) it is step 3, after linking, and compiling.

Not to mention that it takes all of a few seconds after I hit save to when my code is ready to run, unlike in compiled languages where it can take literally hours. I'm sorry if this sounds a bit angry, but I'm kind of tired of people treating me as a second rate programmer because I don't have to compile my code.

Dive

Oh my, in practice... well, maybe I'm just incompetent, but in PHP the gottcha's from misspelling variables are huge time wasters. Especially when you inherit a huge code base which doesn't allow you to turn strict warnings on. – Agama

You can ALWAY turn on strict error_reporting() and any good IDE will prevent 99% of the variable misspellings. – Dive

Not to mention one can misspell anything in any language, however it is easier(possibly faster) to find these mistakes because my interpreter is at the same step at the linking/compile so again your rebutle is irrelivent. – Dive

-1: The compiling argument is distracting from the real argument, which is about typing, static or dynamic. Both dynamic and static languages can be compiled and interpreted. The complaints about spelling and compile time are outside of these issues. – Magical

Literally hours? What are you compiling on, an original IBM PC? – Nephritic

months later... you cannot "always turn on strict error_reporting" because in some cases thousands of lines of code DEPEND on it being off. – Agama

@yar can you give an example? – Dive

Answer 16

The argument is more complex than this (read Yegge's article "Is Weak Typing Strong Enough" for an interesting overview).

Dynamic languages don't necessarily lack error checking either - C#'s type inference is possibly one example. In the same way, C and C++ have terrible compile checks and they are statically typed.

The main advantages of dynamic languages are a) capability (which doesn't necessarily have to be used all the time) and b) Boyd's Law of Iteration.

The latter reason is massive.

Ovid

Type inference isn't the same as dynamic typing, because an inferred type still needs to be known unambiguously at compile time. – Voe

-1: C# is statically typed, not dynamically typed. – Nocturne

Answer 17

I think that we need the different types of languages depending on what we are trying to achieve, or solve with them. If we want an application that creates, retrieves, updates and deletes records from the database over the internet, we are better off doing it with one line of ROR code (using the scaffold) than writing it from scratch in a statically typed language. Using dynamic languages frees up the minds from wondering about

• which variable has which type
• how to grow a string dynamically as needs be
• how to write code so that if i change type of one variable, i dont have to rewrite all the function that interact with it

to problems that are closer to business needs like

• data is saving/updating etc in the database, how do i use it to drive traffic to my site

Anyway, one advantage of loosely typed languages is that we dont really care what type it is, if it behaves like what it is supposed to. That is the reason we have duck-typing in dynamically typed languages. it is a great feature and i can use the same variable names to store different types of data as the need arises. also, statically typed languages force you to think like a machine (how does the compiler interact with your code, etc etc) whereas dynamically typed languages, especially ruby/ror, force the machine to think like a human.

These are some of the arguments i use to justify my job and experience in dynamic languages!

Nernst

Your point 1 and 3 are identical, and IMO is the reason to prefer static typing. What if you change the type to something that is not compatible? If you change a variable from an int to a string you probably do it for a reason. And if not, just rebuild the project until all build errors are gone. It usually doesn't take that long, and sometimes in the process you discover a real problem that you are glad the compiler pointed out to you. Point 2 is invalid, growing a string is performed automatically in all languages (I guess, at least all I've encountered the last 15 years) except C. – Availability

i agree that depending on the application, you may have reason to prefer either type of language over the other, and static languages that are faster may deliver beter performance. But i was saying that if you have to make a like-every-other web application, you might be better off delivering functionality faster by using a dynamic language than a static one. also, suppose you need to use a variable x in such a way that x.func="yes", and x.func_="no". u dont care which type it is, it is a duck as long as it swims like a duck. that is proly why dynamic typing is also called duck typing. 0 left! – Nernst

Answer 18

Although I'm not a big fan of Ruby yet, I find dynamic languages to be really wonderful and powerful tools.

The idea that there is no type checking and variable declaration is not too big an issue really. Admittedly, you can't catch these errors until run time, but for experienced developers this is not really an issue, and when you do make mistakes, they're usually easily fixed.

It also forces novices to read what they're writing more carefully. I know learning PHP taught me to be more attentive to what I was actually typing, which has improved my programming even in compiled languages.

Good IDEs will give enough intellisense for you to know whether a variable has been "declared" and they also try to do some type inference for you so that you can tell what a variable is.

The power of what can be done with dynamic languages is really what makes them so much fun to work with in my opinion. Sure, you could do the same things in a compiled language, but it would take more code. Languages like Python and PHP let you develop in less time and get a functional codebase faster most of the time.

And for the record, I'm a full-time .NET developer, and I love compiled languages. I only use dynamic languages in my free time to learn more about them and better myself as a developer..

Theaterintheround

I find any argument which uses "for experienced developers this is not really an issue" usually a little dangerous. As in, I could say that OOP/memory management etc in C++ is no problem for an experienced developer. Why with something so simple as variable declaration and basic type checking do I need to be so cautious and experienced? I would much rather that the language helps me program rather than lets me make errors that can be easily prevented using a static approach. And I think that verbosity is very very little to do with dynamic or static typing check out Haskell or Scala. – Magical

I agree, I find the argument a little dangerous also. My point is that the issue of type checking at coding time isn't too bad. You'll see the error right away in 90% of cases. It is a problem for the 10% of cases where an implicit type conversion can cause stress, however when you know what you're doing, you won't let that happen. JavaScipt is a great example of the 10% where that can be dangerous, but I've never been bitten by it in all my time developing for it. – Theaterintheround

@Brian Heylin: then you must hate C! So many ways to shoot yourself in the foot, yet so used and (in some cases) loved. – Evocator

Answer 19

Nice blog post on the same topic: Python Makes Me Nervous

Method signatures are virtually useless in Python. In Java, static typing makes the method signature into a recipe: it's all the shit you need to make this method work. Not so in Python. Here, a method signature will only tell you one thing: how many arguments you need to make it work. Sometimes, it won't even do that, if you start fucking around with **kwargs.

Transaction

Answer 20

I don't have much experience with dynamic languages in general, but the one dynamic language I do know, JavaScript(aka ECMAScript), I absolutely love.

Well, wait, what's the discussion here? Dynamic compilation? Or dynamic typing? JavaScript covers both bases so I guess I'll talk about both:

Dynamic compilation:

To begin, dynamic languages are compiled, the compilation is simply put off until later. And Java and .NET really are compiled twice. Once to their respective intermediate languages, and again, dynamically, to machine code.

But when compilation is put off you can see results faster. That's one advantage. I do enjoy simply saving the file and seeing my program in action fairly quick.

Another advantage is that you can write and compile code at runtime. Whether this is possible in statically compiled code, I don't know. I imagine it must be, since whatever compiles JavaScript is ultimately machine code and statically compiled. But in a dynamic language this is a trivial thing to do. Code can write and run itself. (And I'm pretty sure .NET can do this, but the CIL that .NET compiles to is dynamically compiled on the fly anyways, and it's not so trivial in C#)

Dynamic typing:

I think dynamic typing is more expressive than static typing. Note that I'm using the term expressive informally to say that dynamic typing can say more with less. Here's some JavaScript code:

var Person = {};

Do you know what Person is now? It's a generic dictionary. I can do this:

Person["First_Name"] = "John";
Person["Last_Name"] = "Smith";

But it's also an object. I could refer to any of those "keys" like this:

Person.First_Name

And add any methods I deem necessary:

Person.changeFirstName = function(newName) {
  this.First_Name = newName;
};

Sure, there might be problems if newName isn't a string. It won't be caught right away, if ever, but you can check yourself. It's a matter of trading expressive power and flexibility for safety. I don't mind adding code to check types, etc, myself, and I've yet to run into a type bug that gave me much grief (and I know that isn't saying much. It could be a matter of time :) ). I very much enjoy, however, that ability to adapt on the fly.

Carbonaceous

Answer 21

I have love for both static and dynamic languages. Every project that I've been involved in since about 2002 has been a C/C++ application with an embedded Python interpret. This gives me the best of both worlds:

1. The components and frameworks that make up the application are, for a given release of an application, immutable. They must also be very stable, and hence, well tested. A Statically typed language is the right choice for building these parts.
2. The wiring up of components, loading of component DLLs, artwork, most of the GUI, etc... can vary greatly (say, to customise the application for a client) with no need to change any framework or components code. A dynamic language is perfect for this.

I find that the mix of a statically typed language to build the system and a dynamically type language to configure it gives me flexibility, stability and productivity.

To answer the question of "What's with the love of dynamic languages?" For me it's the ability to completely re-wire a system at runtime in any way imaginable. I see the scripting language as "running the show", therefore the executing application may do anything you desire.

Balbur

Answer 22

This all comes down to partially what's appropriate for the particular goals and what's a common personal preference. (E.G. Is this going to be a huge code base maintained by more people than can conduct a reasonable meeting together? You want type checking.)

The personal part is about trading off some checks and other steps for development and testing speed (while likely giving up some cpu performance). There's some people for which this is liberating and a performance boost, and there's some for which this is quite the opposite, and yes it does sort of depend on the particular flavor of your language too. I mean no one here is saying Java rocks for speedy, terse development, or that PHP is a solid language where you'll rarely make a hard to spot typo.

Etherege

Answer 23

Because I consider stupid having to declare the type of the box. The type stays with the entity, not with the container. Static typing had a sense when the type of the box had a direct consequence on how the bits in memory were interpreted.

If you take a look at the design patterns in the GoF, you will realize that a good part of them are there just to fight with the static nature of the language, and they have no reason whatsoever to exist in a dynamic language.

Also, I'm tired of having to write stuff like MyFancyObjectInterface f = new MyFancyObject(). DRY principle anyone ?

Loyalist

Answer 24

Put yourself in the place of a brand new programmer selecting a language to start out with, who doesn't care about dynamic versus staic versus lambdas versus this versus that etc.; which language would YOU choose?

C#

using System;
class MyProgram
{
    public static void Main(string[] args)
    {
        foreach (string s in args)
        {
            Console.WriteLine(s);
        }
    }
}

Lua:

function printStuff(args)
    for key,value in pairs(args) do
       print value .. " "
    end
end
strings = {
    "hello",
    "world",
    "from lua"
}
printStuff(strings)

Magruder

That's non-argument, really. We're not brand new programmers; this debate rages most fiercely between non-brand-new programmers. – Cecil

It's just one reason why programmers may have come to prefer dynamic languages; they're generally more easy to understand than others and thus attract more new programmers to them. – Magruder

Answer 25

Dynamic Languages Strike Back

http://www.youtube.com/watch?v=tz-Bb-D6teE

A talk discussing Dynamic Languages, what some of the positives are, and how many of the negatives aren't really true.

Amidase

Answer 26

Productivity in a certain context. But that is just one environment I know, compared to some others I know or have seen used.

Smalltalk on Squeak/Pharo with Seaside is a much more effective and efficient web platform than ASP.Net(/MVC), RoR or Wicket, for complex applications. Until you need to interface with something that has libraries in one of those but not smalltalk.

Misspelled variable names are red in the IDE, IntelliSense works but is not as specific. Run-time errors on webpages are not an issue but a feature, one click to bring up the debugger, one click to my IDE, fix the bug in the debugger, save, continue. For simple bugs, the round-trip time for this cycle is less than 20 seconds.

Swoon

Answer 27

FWIW, Compiling on most applications shouldn't take hours. I have worked with applications that are between 200-500k lines that take minutes to compile. Certainly not hours.

I prefer compiled languages myself. I feel as though the debugging tools (in my experience, which might not be true for everything) are better and the IDE tools are better.

I like being able to attach my Visual Studio to a running process. Can other IDEs do that? Maybe, but I don't know about them. I have been doing some PHP development work lately and to be honest it isn't all that bad. However, I much prefer C# and the VS IDE. I feel like I work faster and debug problems faster.

So maybe it is more a toolset thing for me than the dynamic/static language issue?

One last comment... if you are developing with a local server saving is faster than compiling, but often times I don't have access to everything on my local machine. Databases and fileshares live elsewhere. It is easier to FTP to the web server and then run my PHP code only to find the error and have to fix and re-ftp.

Rodenticide

I would say that compiling time really depends on the language being used. In .Net, a project of that size may take only a couple minutes to compile. If it's done it C, then I could see it taking a while to compile everything. – Memphis

Okay I will give you that. But when you think about it how many projects that you would think to write in C would be feasible to write in PHP with significant compile times? I think there is a certain point interpreted languages aren't the right tool for the job and vice versa. I am a big fan of going with the right tool for the job and using what you work best in. I don't see a reason to try and make one language do everything when another can do it easier. No reason to re-learn what you know. – Rodenticide

BTW, there is a php plugin for VS jcxsoftware.com/vs.php I havn't tried it yet as it's not free but from what I've heard it is as good with php as Zend (5.5 as 6 sucks) with all the goodness of VS – Dive

You just hit on what is one of the biggest reasons no one uses dynamic languages as much. No one has built a big fancy 2m lines of code IDE that can do almost anything for you around any one of them, so everyone whines about "they're not type safe so it's too easy to make mistakes" – Magruder

I don't care about the type safe non-sense. That doesn't so much bother me. My biggest complaint is that it just physically takes longer and is often times much harder to track problems down. For me I think the style of development is counter to how I like to work. – Rodenticide

Answer 28

I think both styles have their strengths. This either/or thinking is kind of crippling to our community in my opinion. I've worked in architectures that were statically-typed from top to bottom and it was fine. My favorite architecture is for dynamically-typed at the UI level and statically-typed at the functional level. This also encourages a language barrier that enforces the separation of UI and function.

To be a cynic, it may be simply that dynamic languages allow the developer to be lazier and to get things done knowing less about the fundamentals of computing. Whether this is a good or bad thing is up to the reader :)

Grandiloquence

Answer 29

To me it is a matter of situation. I spend a lot of time writing Perl code for websites and C++ for graphics engines. Two completely different realms of programming with two very different languages.

Dynamic languages, for me anyways, are faster to work out as I spend less time making sure the framework is in place and more on the actual problem at hand.

However static languages offer more fine-tuned control which can be necessary in some application such as real-time graphics rendering. I can do things in C++ that run far more efficiently and faster than what I would write for Perl, but for the size of most Perl scripts the loss in efficiency is negligible.

In the end it really comes down to the problem statement and what your target goals are. If you have a lot of simple things to do where speed and memory efficiency aren't a big deal, use a dynamic language. If you have a megalithic project that needs to squeeze every last cycle out of your system, go static.

Antirachitic

Answer 30

Theoretically it's possible for a statically typed languages to have the benefits of dynamic languages, and theoretically it's also possible for dynamic languages to suck and cause more headache than pleasure.

However, in practice, dynamic languages allow you to write code quickly, without too much boilerplate, without worrying about low level details.

Yes, in theory a c-style language can provide similar features (D tries, with auto type discovery and dmdr which compiles modules and runs them on the fly as if they were scripts),

So yes, the naysayers are right, in that being dynamic doesn't necessarily mean easier/cleaner code.

but, in practice, Python > Java

Try w = "my string here".split()[1] in C, or even Java.

Trappist

What's the problem with w = "my string here".split()[1] in Java? In C#, it would've been OK. – Availability

Oh is it? well my bad, wrong example, haven't used Java in a long time. – Trappist

Answer 31

Weakly typed languages allow flexibility in how you manage your data.

I used VHDL last spring for several classes, and I like their method of representing bits/bytes, and how the compiler catches errors if you try to assign a 6-bit bus to a 9-bit bus. I tried to recreate it in C++, and I'm having a fair struggle to neatly get the typing to work smoothly with existing types. Steve Yegge does a very nice job of describing the issues involved with strong type systems, I think.

Regarding verbosity: I find Java and C# to be quite verbose in the large(let's not cherry-pick small algorithms to "prove" a point). And, yes, I've written in both. C++ struggles in the same area as well; VHDL succumbs here.

Parsimony appears to be a virtue of the dynamic languages in general(I present Perl and F# as examples).

Compendious

The equivalent of assigning a 9-bit bus to a 6-bit one is to try to assign an int to a short or something like that. This is an error in C# (and Java, I think), and any C or C++ compiler should be able to issue a warning about it. – Availability

-1. Weakly typed language != Dynamically typed language. – Torchwood

Answer 32

Because it's fun fun fun. It's fun to not worry about memory allocation, for one. It's fun not waiting for compilation. etc etc etc

Abell

Garbage collection is orthogonal to static/dynamic type-checking. – Cabbagehead