3 ms·

As much as I try to remain objective, it's really hard to see any future for dynamically typed languages (and by that, I mean languages verified at compile time

As much as I try to remain objective, it's really hard to see any future for dynamically typed languages (and by that, I mean languages verified at compile time in order to avoid the silly pedantic distracting argument between statically and weakly typed languages). The bottom line is that statically typed languages (STL) have been much better at getting good at what dynamically typed languages (DTL) shine than the other way around to the point that there is hardly any good reason left to use a DTL. These days, STL are terse, fast, expressive, are supported by tremendous tool chains including amazing IDE's and DTL pretty much suck in all these areas.

taeric 11y ago
Your bottom line reads more to indicate the resources that have gone into the statically typed languages than it does anything else. Also ignores the ocean that is javascript. Seriously, think about that example for a minute. During a time when statically typed languages were getting more and more tooling than you can shake a stick at, browsers take off and prove that the ultimate tool for any language is a widely distributed runtime. So, where is the difficulty in seeing that dynamic runtimes that can adapt to changes in the system have a very valid place in the future? I realize I'm an emacs person, so biased as can be. But there is something inspiring about finding a problem in my editor/runtime, popping over to the function, fixing it, reevaluating it, and then continuing without a restart. Is ridiculously nice.
- zak_mc_kracken 11y ago
  Couldn't agree more with your last point, it's just that we've been able to do this with statically typed languages for years now. Javascript still reigns supreme, no argument there, but the contenders that are trying to replace it all have something in common: they add types to Javascript. All of them. I think the trend is pretty clear.
  - taeric 11y ago
    Sadly, if there is a trend, it is that none of them have succeeded. So, if that is the path to success, it will only be after it was forced through more effort than really makes sense. And, correct me if I'm wrong, but Haskel and vanilla Java, along with many other common statically typed languages, can not hotswap. Well, to be fair, vanilla Java can, under limited conditions.
    - zak_mc_kracken 11y ago
      The fact that none of them have succeeded is more due to inertia than anything else. Again, this doesn't take anything away from the fact that that statically typed languages are the future and even Javascript won't be dodging this evolution for much longer. Ruby and Python were the latest victims of this trend, Javascript will clearly be next, even if it might take years.
      - taeric 11y ago
        Isn't javascript younger than all of the poster static languages? Why didn't inertia help any of them beat it? (It is amusing that it was called JavaScript to capitalize the popularity of Java.) I mean, ultimately, I think I agree with you. But at the rate things are moving, I expect my children will still learn JavaScript. And probably C.
        the_why_of_y 11y ago
        The reason why JavaScript has succeeded where many other languages, whether statically typed or not, have failed, is that it was bundled with a runtime platform - the web browser - that became ubiquitous. Millions of people want to write programs that runs in a web browser, and it's easiest to do that in JavaScript. JavaScript is a textbook example of "worse-is-better", and you are right, for compatibility reasons we are going to be stuck with it until long past its best-before date, just like C.
        taeric 11y ago
        That was the point I meant when I said the the ultimate tooling a language needs is a runtime that is widely distributed.
  - obsurveyor 11y ago
    You're ignoring all the people that aren't trying to replace Javascript because they're... using Javascript. It's has a lot of warts but with some mindfulness it's entirely usable. No one can argue that people aren't getting things done with it and being successful.
    - Roboprog 11y ago
      Thank you. All of these BlahBlahScript wrappers don't change the fact that I still have to debug (and thus read, anyway) Javascript in the browser. Javascript isn't assembler, it's actually mostly OK to read - I kind of like it. I only recently discovered JSDoc, and it goes a long way towards documenting types when they matter, especially if your IDE/editor (e.g. - WebStorm) recognizes the annotations and displays them when you click on a symbol.

taeric 11y ago

Your bottom line reads more to indicate the resources that have gone into the statically typed languages than it does anything else. Also ignores the ocean that is javascript. Seriously, think about that example for a minute. During a time when statically typed languages were getting more and more tooling than you can shake a stick at, browsers take off and prove that the ultimate tool for any language is a widely distributed runtime. So, where is the difficulty in seeing that dynamic runtimes that can adapt to changes in the system have a very valid place in the future? I realize I'm an emacs person, so biased as can be. But there is something inspiring about finding a problem in my editor/runtime, popping over to the function, fixing it, reevaluating it, and then continuing without a restart. Is ridiculously nice.

zak_mc_kracken 11y ago
Couldn't agree more with your last point, it's just that we've been able to do this with statically typed languages for years now. Javascript still reigns supreme, no argument there, but the contenders that are trying to replace it all have something in common: they add types to Javascript. All of them. I think the trend is pretty clear.
- taeric 11y ago
  Sadly, if there is a trend, it is that none of them have succeeded. So, if that is the path to success, it will only be after it was forced through more effort than really makes sense. And, correct me if I'm wrong, but Haskel and vanilla Java, along with many other common statically typed languages, can not hotswap. Well, to be fair, vanilla Java can, under limited conditions.
  - zak_mc_kracken 11y ago
    The fact that none of them have succeeded is more due to inertia than anything else. Again, this doesn't take anything away from the fact that that statically typed languages are the future and even Javascript won't be dodging this evolution for much longer. Ruby and Python were the latest victims of this trend, Javascript will clearly be next, even if it might take years.
    - taeric 11y ago
      Isn't javascript younger than all of the poster static languages? Why didn't inertia help any of them beat it? (It is amusing that it was called JavaScript to capitalize the popularity of Java.) I mean, ultimately, I think I agree with you. But at the rate things are moving, I expect my children will still learn JavaScript. And probably C.
      - the_why_of_y 11y ago
        The reason why JavaScript has succeeded where many other languages, whether statically typed or not, have failed, is that it was bundled with a runtime platform - the web browser - that became ubiquitous. Millions of people want to write programs that runs in a web browser, and it's easiest to do that in JavaScript. JavaScript is a textbook example of "worse-is-better", and you are right, for compatibility reasons we are going to be stuck with it until long past its best-before date, just like C.
        taeric 11y ago
        That was the point I meant when I said the the ultimate tooling a language needs is a runtime that is widely distributed.
- obsurveyor 11y ago
  You're ignoring all the people that aren't trying to replace Javascript because they're... using Javascript. It's has a lot of warts but with some mindfulness it's entirely usable. No one can argue that people aren't getting things done with it and being successful.
  - Roboprog 11y ago
    Thank you. All of these BlahBlahScript wrappers don't change the fact that I still have to debug (and thus read, anyway) Javascript in the browser. Javascript isn't assembler, it's actually mostly OK to read - I kind of like it. I only recently discovered JSDoc, and it goes a long way towards documenting types when they matter, especially if your IDE/editor (e.g. - WebStorm) recognizes the annotations and displays them when you click on a symbol.