Comment by yogthos | Hacker News Reader

Comment by yogthos | Hacker News Reader

Parent Full thread

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 and this kind workflow will be difficult to match for static languages.

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).

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.

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.

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.

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.

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

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.

Well, are you aware that the same Haskell you cite has a REPL environment, with on the fly code patching, and that does not require all expressions to "go throught main" anyway, right?

I simply have no idea how anyone would use a REPL to do main development (I never liked the idea anyway). I use it just for early stage testing and debugging assistance, just like I do in Python, Lisp, Prolog... and certainly not Perl - this one has a useless REPL.

see here https://news.ycombinator.com/item?id=10645106

> 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.

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.

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?

In case of Haskell it's due to the fact that you can't just evaluate any top level form without going through the main. I'm sure it would be possible to design a statically typed language that's REPL development friendly, but none exist currently.

Ok, I either don't get what you are saying, or you never really tried Haskell's REPL for real.

I've probably run most of the modules I've written in Haskell on the REPL, normally without importing the main one, because I use it for early-stage testing. I've run DB interfaces, network abstractions, and, of course, lots and lots of pure stuff. Just like you describe doing for Clojure.

Ok, I don't use an IDE that run stuff automatically at the REPL. On Haskell I import the interesting module, and run it. There is at least one IDE that connects with ghci, but I don't like it, and don't know how far it takes debuging (at a minimum, it evaluates your code and tells you the type of anything - I've tried this).

This is simply misinformed. GHCI can evaluate/run the IO monad. Syntax: to run and throw away the result, simply type an expression with type IO a: it will be evaluated to IO a, then executed. If GHCI can show values in a, it will (unless a=()). To get the value, say var <- expr.

Reply on news.ycombinator.com