The advantage of dynamic languages is not in succinctness; the advantage is being able to defer the concrete definitions of the objects you're dealing with, or to ignore them entirely: it's what lets you pass arbitrary objects around in your middleware stack, or do things like ActiveRecord, click.py or sh.py which do crazy things with the object and module system, etc. There are things that are really hard in a statically typed language, or that you simply can't do, that dynamic languages let you do effortlessly. Of course, all of this freedom comes with cost. But gaining succinctness is hardly the major win of dynamic languages.
Well, succinctness is an advantage, and I'll claim with no data to support me that it is the reason, combined with the lack of compilation, that most developers choose dynamic languages, without necessarily realizing what they are giving up.
As someone who works for a company that uses python, but mostly uses Haskell in his spare time, my python code is often far more verbose than my Haskell (for a similar degree of complexity). I suppose if your yardstick is Java or something than you'll probably be more concise in a dynamic language, but that's really besides the point. The amount of characters you type in a language is one of the least important factors in choosing whether to use it or not. It's certainly not the reason that we use it.
I'm thinking about the golden age of PHP. Lower amount of typing, and typing weak enough that whatever junk you type ends up in something actually displayed. The no-compilation part also lowers the barrier to entry and makes deployment easier. Also features the fantastic ability to break your production code by debugging it on the server!
I agree, although there are also other benefits of dynamic typing.
With modern type systems employing structural subtyping, row polymorphism, proper variance and covariance handling and other advanced techniques static typing becomes a very powerful tool.
On the other hand, there are correct programs which we still don't know how to type. This means that there are programs we just can't write in statically typed languages, at least not yet.
Anyway, I'm not arguing against or in favour of static or dynamic typing. I'm simply stating the fact that choosing one over the other is still just a matter of preference and personal decision about which set of tradeoffs you like better.
It's exactly the same as with Vim vs. Emacs debate. I can't believe I got downvoted because of pointing this out. I believe that there is a place and a good way of discussing relative merits of static and dynamic type systems, but simply stating your preference in a thread about something unrelated is most definitely not a good way.
> On the other hand, there are correct programs which we still don't know how to type. This means that there are programs we just can't write in statically typed languages, at least not yet.
I don't think that's right. If something can't be type-checked then you just add an "assert" and do the check dynamically.
For example, in 0install I need to ask the SAT solver which version of a program I should use. I pass it a load of SAT variables, each containing a user data field with the attached program details, run the solver, and get back the selected variable. The SAT problem also contains other variables, with other kinds of data.
I know the user data field for the selected result will be of type program details, but I couldn't figure out how to let the compiler check this statically. It's not a problem; I just check the type and "assert false" if it's wrong. I still get the benefit of static checking almost everywhere else in the code.
> On the other hand, there are correct programs which we still don't know how to type. This means that there are programs we just can't write in statically typed languages, at least not yet.
I know this is true, but is it common? What would be a realistic case for this? Realistic as in, "code most people who are fans of dynamic typing find themselves writing". Contrived examples can always be found, but if someone told me they don't use static typing because there are programs that cannot be typed, I'd ask them "how often do you write that kind of programs?".
Well, the parent post is not exactly an example of objectivity too. I agree that dynamic typing can be a useful tool. I am likely to use both in any n-tier project and benefit from that.
Common Lisp guy gonna chime in here...having a REPL that integrates with your editor (vim/slimv in my case) is an intense improvement on any other language I've ever used. With C you edit, leave, `make`, run. With PHP you edit, open browser, F5, run...same with JS.
With lisp, I edit, eval (simple command in my editor), see result. If I'm building a game or a long-running app, I can redefine functions while it's running without doing a full recompile and having to try and get back to the state the app was in when I wanted to test my change.
So you get the ability to live-code while the app is running. Once you get used to being able to do this, leaving your editor and opening to shell to test your app seems like a barbaric exercise.
So a good REPL (lisp or not, doesn't matter) can make the experience a lot more interactive and experimental that your average write -> save -> compile -> run cycle.
I'm no Javascript advocate, but I just found out that you can use Chrome like that for JS, where I can edit a function, press Ctrl+S, the Chrome REPL will say something like "functions recompiled in 80ms," and then your running app will use that function. I have to say that developing like that is pretty great.
Unfortunately the OCaml toplevel pales in comparison to CL environments like slime in terms of visibility and debuggability. Redefinition is also off the table, as OCaml is a very static language. (You can rebind the same name, which can be helpful in exploratory programming but is not at all the same thing.)
