Live data from Hacker News

Elm changed my mind about unpopular languages

blog.realkinetic.com

81–90 of 321 posts

Re: Elm changed my mind about unpopular languages

#81

I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here: >You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.

I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly. If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those. Elm helps significantly with the latter.

So elm gives you plenty of time to sit around being completely blocked by conceptual/technical bugs that no one can solve.

Re: Elm changed my mind about unpopular languages

#82

Earlier quoted context omitted.

I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly. If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those. Elm helps significantly with the latter.

That's one of the points he raised, and I see the value now. However, the author also talks about the dangers that come from using lesser-known, using unstable languages (he mentions finding bugs in the compiler, segfaults, and so on), and he doesn't say how Elm solves them

Good point. I suspect to some degree it's mitigated by the fact that anyone attempting to re-implement (most of) Haskell must care about correctness a great deal, and having Haskell already in place limits the number of conceptual bugs.

Anyway, this is pure speculation on my part, I have yet to dive into either language.

Re: Elm changed my mind about unpopular languages

#83

I see that the current version is 0.18. Curious if the language has become more stable with fewer breaking changes than when I looked at it two years ago.

It actually has... due to not having any major release in 2 years.

So it's abandoned?

Re: Elm changed my mind about unpopular languages

#84

Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining and refactoring a big Python program had become really painful. Haskell lets me keep the codebase smaller, it's easier to be pretty sure things are working, it's easier to refactor, and I'm sure the language will only keep getting better. Those are all unders…

That's been the story of Haskell for over 10 years. The world and other language ecosystems are changing faster than Haskell is growing. Clojure and Scala give you an alternative to Python that have the power of the Java ecosystem to take your programming out of academic and toy projects. And Python finally has static typing, 10 years after it was announced.

What changes do you think Haskell can't keep up with?

If you want to approximate the cool things in Haskell with a Python-compatible* language, there's Coconut. In addition to static typing, it offers algebraic data types (how I lived without sum types, I don't know) and pattern matching.

* every valid Python program is valid Coconut

Re: Elm changed my mind about unpopular languages

#85

I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here: >You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.

I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly. If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those. Elm helps significantly with the latter.

If that also has the consequence of significantly less bugs in Elm libraries, you will also encounter much less of the former when using third-party libraries.

Re: Elm changed my mind about unpopular languages

#86
post #73

This is common reaction to Elm and especially to Elm. I also use Elixir and it has great community and everything, but somehow Elm is even more. All the concerns about 'unpopular' languages, lack of tooling, I feel it is quite the opposite. Elm formatter changed how I work and now I started using it in other languages, Elixir and JS are using it more, or maybe I just started paying more attention. There are other sma…

When you say smarter programmer I understand what you mean. But the way I look at it, Elm allows me to relax and be a dumber programmer. I commit my smarts up front to the type design and interfaces between types and then I can relax as the project grows from there because the compiler will enforce the invariants I've encoded into the types. Pure Bliss.

Big Design Up Front is back in style now? Agile is dead?

Re: Elm changed my mind about unpopular languages

#87

My first thought: The author would probably be equally satisfied if they had used JavaScript with flowtype and react. It sounds like they're comparing JQuery + Bootstrap (and similar "old" frontend frameworks) to Elm. I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.

Not the author, but I've used React + Redux and Flowtype and played a little bit with Elm. Elm felt so much cleaner, the typing was great and it was a breeze to learn. I'm certain I'll go with Elm on my next web project.

Re: Elm changed my mind about unpopular languages

#88
post #2

My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should? The problem with unpopular languages is twofold: * lack of talent that can step right in and be effective * lack of resources to push the language forward The first can be remediated by planning to bring new hires up to speed, and just making that i…

In the worst case, you just adopt the runtime yourself. I don't understand why people draw boundaries around certain frameworks, runtimes, and languages and say "I'm hiring that kind of engineer". A good developer can go up and down the stack as needed and fix any part of it --- including the language runtime.

Re: Elm changed my mind about unpopular languages

#89

Earlier quoted context omitted.

With the huge exception being Lisp-based languages (closure, scheme, etc....). Heck, Lisp was the first functional language and first one that made full use of dynamic typing.

There is also Erlang and Elixir which while functional aren't typed. There are some static analysis tools though.

I'm just getting into Elixir now but even without it being statically typed, it does catch a ton of errors and present warnings at compile time.

It's remarkably useful so far. I feel like I have an extra level of protection compared to Ruby or Python.

Re: Elm changed my mind about unpopular languages

#90
post #38

Earlier quoted context omitted.

Worth noting that in our experience, hiring has gotten way easier for us since we became an Elm shop. We really struggled to hire React engineers (who have a zillion positions to choose among - why would they pick ours?), whereas there seem to be a lot more great programmers who want to use Elm than there are companies hiring for Elm positions. Here's a verbatim quote from a cover letter (one I happened to be reading…

The communities for languages like Elm are definitely smaller, but they're also "passion languages", if that makes sense. Nobody is learning elm because they've been or feel forced to (like you might with React, eg) or because they needed to maintain a legacy codebase at an old job or something. They're learning it because they're interested/like it, etc. So when it comes time to hire you have a small(er) pool of can…

Because you get all of the problems that you get mentioned in the article. And on top of that javascript land is fad heavy, and whats cool today might not be cool 2 years from now.

I personally know of a story where a startup started with datomic and clojure, and it was a bad idea because datomic could not effectively delete things. Eventually they went the standard java and standard cassandra / postgres / redis type route.

Post reply on HN