3 ms·

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 additio

by 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.
  - sanderjd 11y ago
    I liked your article and generally think you have lots of good thoughts, so I want to give you some color on why I think you're getting downvoted here (though I didn't downvote you), so that you don't just think it is because of "bible thumpers". You seem to be missing that jasod's claim was that the "main claim of the article" is "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." You haven't said anything in this thread about "the next wave of successful languages" one way or the other. > 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. That's true, but has nothing to do with the claim about "the next wave of successful languages" because javascript is clearly part of the last wave (or really, the one before). You seem to be arguing (in an increasingly heated tone) a broader point (which may be right or wrong) in a thread attempting to focus on a more narrow one.
- ane 11y ago
  Elixir isn't that old and it'll be interesting to see if it caches on. It's basically Erlang with a nicer syntax and some new ideas.
  - sanderjd 11y ago
    Elixir (and Erlang itself, actually) are definitely the vanguard of dynamically typed languages at the moment. I think this is because they aren't just convenient to write "normal" code in (like Ruby, Python, JS, etc.), they also come with major advantages in writing concurrent and distributed code, which is increasingly important. BEAM is also a particularly good runtime with better performance (especially memory) characteristics than many of its dynamically typed competitors. I think this is the counter-argument to the original claim; new dynamically typed languages can be successful by offering convenience for important functionality. Even so, I think type annotations to aid static analysis (which Elixir has and JS will likely have in the future) will be an important feature. I think the bar has simply been raised for new languages with both static and dynamic type systems. The former can no longer be boilerplate-y, inflexible, and inconvenient, and the latter can no longer be statically uncertain and hard to reason about. This is a good thing.
marcosdumay 11y ago
Well, there are static languages with great REPLs and live code patching. Those are not exclusive to dynamic typing in any way.
- yogthos 11y ago
  I'm certainly not aware of any. Pretty much all statically typed languages use the REPL as a toy on the side. It's not part of the actual development process. You're not running the REPL in the actual app you're working on and its usefulness is extremely marginal at that point. A language like Haskell pretty much precludes having REPL integration as you can't just run any top level expression without going through the main.
  - wtetzner 11y ago
    > A language like Haskell pretty much precludes having REPL integration as you can't just run any top level expression without going through the main. What? Why not? I know people who pretty much use the REPL (GHCi) as their primary method of developing in Haskell.
    - yogthos 11y ago
      Let me give you an example of my typical day working with Clojure. I will start the app then connect my IDE to its instance. When I work on any code I write it in the context of the running application. I have access to all the state that's been built up, I can leverage user sessions, database connections etc. Let's say I'm writing an endpoint to serve some data to the client. I would go to my db namespace, write the function to query the db, run the code and see what it's doing. I'll modify and run it until it does what I want. Then I might go write a controller and do the same thing, and so on. At each point I have my code running within the context of the app, anything I write in the editor can be evaluated modified, and inspected. This workflow simply doesn't exist in Haskell last I checked.
      - tome 11y ago
        I'm not aware of any simple way to get up and running like you are describing in Haskell, no. But it's unclear whether you are saying that such a thing cannot exist in a statically typed language, or whether it just does not at the moment. Can you clarify?

by yogthos 11y ago

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.
- sanderjd 11y ago
  I liked your article and generally think you have lots of good thoughts, so I want to give you some color on why I think you're getting downvoted here (though I didn't downvote you), so that you don't just think it is because of "bible thumpers". You seem to be missing that jasod's claim was that the "main claim of the article" is "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." You haven't said anything in this thread about "the next wave of successful languages" one way or the other. > 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. That's true, but has nothing to do with the claim about "the next wave of successful languages" because javascript is clearly part of the last wave (or really, the one before). You seem to be arguing (in an increasingly heated tone) a broader point (which may be right or wrong) in a thread attempting to focus on a more narrow one.
ane 11y ago
Elixir isn't that old and it'll be interesting to see if it caches on. It's basically Erlang with a nicer syntax and some new ideas.
- sanderjd 11y ago
  Elixir (and Erlang itself, actually) are definitely the vanguard of dynamically typed languages at the moment. I think this is because they aren't just convenient to write "normal" code in (like Ruby, Python, JS, etc.), they also come with major advantages in writing concurrent and distributed code, which is increasingly important. BEAM is also a particularly good runtime with better performance (especially memory) characteristics than many of its dynamically typed competitors. I think this is the counter-argument to the original claim; new dynamically typed languages can be successful by offering convenience for important functionality. Even so, I think type annotations to aid static analysis (which Elixir has and JS will likely have in the future) will be an important feature. I think the bar has simply been raised for new languages with both static and dynamic type systems. The former can no longer be boilerplate-y, inflexible, and inconvenient, and the latter can no longer be statically uncertain and hard to reason about. This is a good thing.

marcosdumay 11y ago

Well, there are static languages with great REPLs and live code patching. Those are not exclusive to dynamic typing in any way.

yogthos 11y ago
I'm certainly not aware of any. Pretty much all statically typed languages use the REPL as a toy on the side. It's not part of the actual development process. You're not running the REPL in the actual app you're working on and its usefulness is extremely marginal at that point. A language like Haskell pretty much precludes having REPL integration as you can't just run any top level expression without going through the main.
- wtetzner 11y ago
  > A language like Haskell pretty much precludes having REPL integration as you can't just run any top level expression without going through the main. What? Why not? I know people who pretty much use the REPL (GHCi) as their primary method of developing in Haskell.
  - yogthos 11y ago
    Let me give you an example of my typical day working with Clojure. I will start the app then connect my IDE to its instance. When I work on any code I write it in the context of the running application. I have access to all the state that's been built up, I can leverage user sessions, database connections etc. Let's say I'm writing an endpoint to serve some data to the client. I would go to my db namespace, write the function to query the db, run the code and see what it's doing. I'll modify and run it until it does what I want. Then I might go write a controller and do the same thing, and so on. At each point I have my code running within the context of the app, anything I write in the editor can be evaluated modified, and inspected. This workflow simply doesn't exist in Haskell last I checked.
    - tome 11y ago
      I'm not aware of any simple way to get up and running like you are describing in Haskell, no. But it's unclear whether you are saying that such a thing cannot exist in a statically typed language, or whether it just does not at the moment. Can you clarify?