6 ms·

Just in case anyone is reading the blogs in a hurry, keep in mind that neither the Dmitri Sotnikov nor the post he mentioned by Maxime Chevalier-Boisvert actual

by jasode 11y ago

Just in case anyone is reading the blogs in a hurry, keep in mind that neither the Dmitri Sotnikov nor the post he mentioned by Maxime Chevalier-Boisvert actually try to refute Elben Shira's carefully worded prediction: "This is my bet: the age of dynamic languages is over. There will be no new successful ones." Instead of making a case for "new successful dynamic languages" and why such new ones would emerge, both authors are defending the existing benefits of today's dynamic languages. Elben Shira is saying that he predicts the next wave of successful languages will have static checking but also look & feel like a "dynamic" one made possible by smarter compiler technologies such as type inferencing. (Maxime Chevalier-Boisvert also mentions the new Crystal language as an example of this.) If one is itemizing all the great points of Python/Ruby/Javascript, that's orthogonal to what Shira is betting on.

adamors 11y ago
Elixir is a new dynamic language that is quite successful already.
- Avshalom 11y ago
  If I may be pithy here: Erlang is reliable because it's fault tolerant. The Strong Static Typing camp wants software that is reliable because it is faultless. Elixir has Erlang's philosophy on the problem. I think most of the wailing and gnashing of teeth is because most languages (even most statically typed ones historically) have just completely punted on the notion of language support for writing software that doesn't fall over in a stiff breeze. The more we build layers of software between humans and their actual goals the more this is going to come to a head.
  - yogthos 11y ago
    The Strong Static Typing camp appears to be blissfully oblivious of Gödel's incompleteness theorems. :)
    - marcosdumay 11y ago
      No point on citing this or the Halting Problem. Of course your compiler will never be able to proof the correctness (or lack of it) of all programs. The relevant question is, what share of useful programs can our compilers help us creating? This is not answered yet, and you seem to have never even thought about it.
      - Avshalom 11y ago
        fun fact: the Busy Beaver function applied to the universe yields a finite number and seeing as we need to leave some space to actually run the program we can conclude that in fact any program that can be written can be proven to halt. Granted that in case of "for(;;){printf("hello");}" that halt is the heat death of the universe but it's still theoretically tractable.
    - incepted 11y ago
      And you are falling prey to the Nirvana fallacy [1]. Yes, we will never be able to prove that a program is 100% correct but that doesn't mean we shouldn't prefer solutions that bring that number up (statically typed languages) over solutions that don't (dynamically typed languages). Just because you can't do something perfectly doesn't mean you shouldn't try to do it as best you can. [1] https://en.wikipedia.org/wiki/Nirvana_fallacy https://en.wikipedia.org/wiki/Nirvana_fallacy
      - yogthos 11y ago
        I'm saying that you have to actually demonstrate that additional formalism adds value before you start claiming that it does.
        Turing_Machine 11y ago
        Yes. Real-world programming is an entirely different thing from academic research. In the real world, it may well be the case that while you're screwing around with a baroque type system, your competition has iterated three or four times and your milkshake has been drunk.
- jerf 11y ago
  I'd rate Elixir right now only as "up-and-coming". It is not yet an acceptable second-tier choice. Even in an environment where Ruby or Python (or the several other similar second-tier languages) are accepted without a second thought (as opposed to an environment where only first-tiers like Java or C(#/++/) are acceptable), Elixir will still result in some questions being asked that you better have a good answer for. This is not a criticism of the language, simply descriptive of its current position. Go, which is substantially larger at the moment from what I can see, is just barely cracking that boundary that I described, and probably still has a good year or two before it's quite there. Elixir is currently on a good trajectory, but I would definitely be concerned that trying to be a Ruby on top of the Erlang VM is going to make it a non-trivial challenge to get to the next level of usage, precisely because the Ruby space is covered, covered, and covered again with mature, existing languages. This is, again, not a promise from me it can't succeed, indeed I wish it all the best, just a description of its challenges. It is growing rapidly in its little niche but it may have a serious challenge getting to the next level. And, back on topic, when this came up on Reddit, I'd observe that Elixir is the only dynamically-typed "up-and-coming" language I can think of. Nim is statically-typed. Rust is static. Go is probably on the way out of "up-and-coming" but it's static. I also observe that all the dynamic languages are all adding static type support, even when the static type support is inevitably compromised by the dynamic portion of the language. In the meantime, I don't see any static language trying to move in a dynamic direction... in fact, many of the static languages are moving to be even more static! The net flow of feature work right now is strongly in the static direction.
  - sanxiyn 11y ago
    > I don't see any static language trying to move in a dynamic direction. C# added "dynamic" keyword in 4.0.
    - jerf 11y ago
      Point. And it's a non-trivial implementation, from the look of it. A lot of static languages have "a thing that can be passed around as a 'dynamic' value but has to be cast back to a static type to do anything", but the C# feature is much more than that. https://msdn.microsoft.com/en-us/library/dd264736.aspx https://msdn.microsoft.com/en-us/library/dd264736.aspx
deleted 11y ago
[deleted]
jack9 11y ago
> why such new ones would emerge, People create languages all the time. Some languages (like PHP) were just created for problems that the creators had, not for some overriding empirical reason. Dynamic languages also tend to be easier to make. There's nothing to suggest people will stop creating languages and then adopting them, when they are tailored toward specific problems. Any reasoning as to why they might not appear is hand waving for attention.
- incepted 11y ago
  Reread the article. It doesn't say such language will not emerge (I certainly hope people keep creating languages all the time), it says they will not be successful.
  - yogthos 11y ago
    It's a very strong and largely baseless claim.
yogthos 11y ago
Oh definitely think the prediction is absurd. I didn't realize it wasn't obvious from my post. The problem I outline is not that static typing involves additional boilerplate. It's the inherent additional cognitive load it introduces. A smarter compiler isn't going to help you there. The fallacy of Elben's argument is in the assumption that there will be only advances in the field of static typing. Meanwhile, people working with dynamic languages are improving their tools at an astonishing pace. For example, working with an editor like Cursive provides many refactoring options you could only expect from a static language a few years ago. The biggest benefit though comes from interactivity though. Dynamic languages lend themselves extremely well to providing live coding environments. This allows for tools like the REPL and things like Figwheel https://github.com/bhauman/lein-figwheel https://github.com/bhauman/lein-figwheel and this kind workflow will be difficult to match for static languages.
- incepted 11y ago
  It's obvious you think it's absurd and given your heavy involvement in Clojure, your reaction is not unexpected. But you are still not addressing the main claim of the articles (that no new dynamically typed language will ever emerge again and be successful) and also missing why statically typed languages have won (it's not just correctness guarantees, it's also the automatic refactorings they enable, which are impossible to achieve with dynamically typed languages, and performance). Clojure and its family of language will be a thing of the past in a few years from now (Clojure is not even a thing of the present actually, given its minuscule mind share on the JVM).
  - yogthos 11y ago
    I am addressing the main claim of the article quite clearly. Static typing adds complexity and there's no evidence that the added complexity results in any tangible benefits. Therefore, my prediction is that dynamic typing isn't going anywhere unless some empirical evidence appears that clearly demonstrates the advantages of static typing. Seeing how long static typing has been around I wouldn't hold my breath on that. If you think that static languages have won then you must live in a very special bubble seeing how pretty much all of the web runs on JavaScript. Having such strong convictions in absence of any empirical evidence is simply faith and static typing seems to just be a religious experience for some people. Many advocates are like bible thumpers coming to your door and telling you to accept monads into your heart. Naturally these are the loudest elements of the community who live in their own little echo chamber.

by jasode 11y ago

adamors 11y ago

Elixir is a new dynamic language that is quite successful already.

Avshalom 11y ago
If I may be pithy here: Erlang is reliable because it's fault tolerant. The Strong Static Typing camp wants software that is reliable because it is faultless. Elixir has Erlang's philosophy on the problem. I think most of the wailing and gnashing of teeth is because most languages (even most statically typed ones historically) have just completely punted on the notion of language support for writing software that doesn't fall over in a stiff breeze. The more we build layers of software between humans and their actual goals the more this is going to come to a head.
- yogthos 11y ago
  The Strong Static Typing camp appears to be blissfully oblivious of Gödel's incompleteness theorems. :)
  - marcosdumay 11y ago
    No point on citing this or the Halting Problem. Of course your compiler will never be able to proof the correctness (or lack of it) of all programs. The relevant question is, what share of useful programs can our compilers help us creating? This is not answered yet, and you seem to have never even thought about it.
    - Avshalom 11y ago
      fun fact: the Busy Beaver function applied to the universe yields a finite number and seeing as we need to leave some space to actually run the program we can conclude that in fact any program that can be written can be proven to halt. Granted that in case of "for(;;){printf("hello");}" that halt is the heat death of the universe but it's still theoretically tractable.
  - incepted 11y ago
    And you are falling prey to the Nirvana fallacy [1]. Yes, we will never be able to prove that a program is 100% correct but that doesn't mean we shouldn't prefer solutions that bring that number up (statically typed languages) over solutions that don't (dynamically typed languages). Just because you can't do something perfectly doesn't mean you shouldn't try to do it as best you can. [1] https://en.wikipedia.org/wiki/Nirvana_fallacy https://en.wikipedia.org/wiki/Nirvana_fallacy
    - yogthos 11y ago
      I'm saying that you have to actually demonstrate that additional formalism adds value before you start claiming that it does.
      - Turing_Machine 11y ago
        Yes. Real-world programming is an entirely different thing from academic research. In the real world, it may well be the case that while you're screwing around with a baroque type system, your competition has iterated three or four times and your milkshake has been drunk.
jerf 11y ago
I'd rate Elixir right now only as "up-and-coming". It is not yet an acceptable second-tier choice. Even in an environment where Ruby or Python (or the several other similar second-tier languages) are accepted without a second thought (as opposed to an environment where only first-tiers like Java or C(#/++/) are acceptable), Elixir will still result in some questions being asked that you better have a good answer for. This is not a criticism of the language, simply descriptive of its current position. Go, which is substantially larger at the moment from what I can see, is just barely cracking that boundary that I described, and probably still has a good year or two before it's quite there. Elixir is currently on a good trajectory, but I would definitely be concerned that trying to be a Ruby on top of the Erlang VM is going to make it a non-trivial challenge to get to the next level of usage, precisely because the Ruby space is covered, covered, and covered again with mature, existing languages. This is, again, not a promise from me it can't succeed, indeed I wish it all the best, just a description of its challenges. It is growing rapidly in its little niche but it may have a serious challenge getting to the next level. And, back on topic, when this came up on Reddit, I'd observe that Elixir is the only dynamically-typed "up-and-coming" language I can think of. Nim is statically-typed. Rust is static. Go is probably on the way out of "up-and-coming" but it's static. I also observe that all the dynamic languages are all adding static type support, even when the static type support is inevitably compromised by the dynamic portion of the language. In the meantime, I don't see any static language trying to move in a dynamic direction... in fact, many of the static languages are moving to be even more static! The net flow of feature work right now is strongly in the static direction.
- sanxiyn 11y ago
  > I don't see any static language trying to move in a dynamic direction. C# added "dynamic" keyword in 4.0.
  - jerf 11y ago
    Point. And it's a non-trivial implementation, from the look of it. A lot of static languages have "a thing that can be passed around as a 'dynamic' value but has to be cast back to a static type to do anything", but the C# feature is much more than that. https://msdn.microsoft.com/en-us/library/dd264736.aspx https://msdn.microsoft.com/en-us/library/dd264736.aspx

deleted 11y ago

[deleted]

jack9 11y ago

> why such new ones would emerge, People create languages all the time. Some languages (like PHP) were just created for problems that the creators had, not for some overriding empirical reason. Dynamic languages also tend to be easier to make. There's nothing to suggest people will stop creating languages and then adopting them, when they are tailored toward specific problems. Any reasoning as to why they might not appear is hand waving for attention.

incepted 11y ago
Reread the article. It doesn't say such language will not emerge (I certainly hope people keep creating languages all the time), it says they will not be successful.
- yogthos 11y ago
  It's a very strong and largely baseless claim.

yogthos 11y ago

Oh definitely think the prediction is absurd. I didn't realize it wasn't obvious from my post. The problem I outline is not that static typing involves additional boilerplate. It's the inherent additional cognitive load it introduces. A smarter compiler isn't going to help you there. The fallacy of Elben's argument is in the assumption that there will be only advances in the field of static typing. Meanwhile, people working with dynamic languages are improving their tools at an astonishing pace. For example, working with an editor like Cursive provides many refactoring options you could only expect from a static language a few years ago. The biggest benefit though comes from interactivity though. Dynamic languages lend themselves extremely well to providing live coding environments. This allows for tools like the REPL and things like Figwheel https://github.com/bhauman/lein-figwheel https://github.com/bhauman/lein-figwheel and this kind workflow will be difficult to match for static languages.

incepted 11y ago
It's obvious you think it's absurd and given your heavy involvement in Clojure, your reaction is not unexpected. But you are still not addressing the main claim of the articles (that no new dynamically typed language will ever emerge again and be successful) and also missing why statically typed languages have won (it's not just correctness guarantees, it's also the automatic refactorings they enable, which are impossible to achieve with dynamically typed languages, and performance). Clojure and its family of language will be a thing of the past in a few years from now (Clojure is not even a thing of the present actually, given its minuscule mind share on the JVM).
- yogthos 11y ago
  I am addressing the main claim of the article quite clearly. Static typing adds complexity and there's no evidence that the added complexity results in any tangible benefits. Therefore, my prediction is that dynamic typing isn't going anywhere unless some empirical evidence appears that clearly demonstrates the advantages of static typing. Seeing how long static typing has been around I wouldn't hold my breath on that. If you think that static languages have won then you must live in a very special bubble seeing how pretty much all of the web runs on JavaScript. Having such strong convictions in absence of any empirical evidence is simply faith and static typing seems to just be a religious experience for some people. Many advocates are like bible thumpers coming to your door and telling you to accept monads into your heart. Naturally these are the loudest elements of the community who live in their own little echo chamber.