Live data from Hacker News

Elm changed my mind about unpopular languages

blog.realkinetic.com

131–140 of 321 posts

Re: Elm changed my mind about unpopular languages

#131

Earlier quoted context omitted.

The Python paradox is interesting in 2018. At time he wrote this, Java was the go-to language to teach in university and Python was reserved for hobbyists. It seems that has almost completely flipped now, and everywhere wants to teach Python first. Evidently, there's an awful lot of no-so-smart python programmers available on top of the smart ones now. It looks just like Java looked in 2004.

I definitely disagree that java is looking like - or even starting to - python did in 2004, it still has a huge market share, even compared to python. Yes python is definitely more popular now, enough so that the python paradox doesn't even apply, but it will probably never apply to java, or at least not in the current computing paradigm.

Maybe I read GP wrong, but what I took it to mean was that the market/talent position of python in 2018 is similar to java in 2004, not that java in 2018 is similar in any way to "2004 python".

Elm, Haskell, Clojure, etc, seem like they fulfill the role of "2004 python" in 2018.

Re: Elm changed my mind about unpopular languages

#132
post #74
post #7

Earlier quoted context omitted.

> This is always a risk with new tools and techs. Absolutely. Whenever I see a new project, I look at business risk and technology risk. Either one is OK, but both are not. (I picked that up from someone, don't remember who). I think that there's real value to being a Tom Bombadill (and really learning a language/framework/problem space deeply) as opposed to being a Gandalf. However, one fundamental issue is it's eas…

I have pondered about this depth vs breadth approach for some time. My path has made me a generalist who learns and does whatever I think is necessary in a given situation. This is great because I can do anything. But I envy the domain experts who do one (or a related few) things VERY well. Perhaps it depends much on the mind of the person; I don't think I could just focus on one thing forever. But while the new shin…

I think it's also a risk tolerance thing.

To analogize, if you are a general carpenter, you can always find work, but it will be at a lower rate. However, it will be varied.

If you are a fine cabinet carpenter, your work will likely be more focused, possibly more repetitive, more lucrative, and harder to find (you'll have to seek out the folks who need really really nice cabinets).

Re: Elm changed my mind about unpopular languages

#133
post #127

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…

Strangely, if you switch Elm for Scala, you get the exact opposite result (at least where I work). We got mostly inexperienced candidates and the ones able to understand the codebase can get more interesting offers elsewhere.

So you know that experienced Scala devs won't like your offers, but you aren't interested in the less experienced devs who apply.

What are you looking for, exactly? As an "inexperienced" Scala dev, I'm genuinely interested.

Re: Elm changed my mind about unpopular languages

#134

Earlier quoted context omitted.

I'm not the quoted person, but we hire Elm devs (or people who want to become Elm devs - no prior Elm experience necessary; you can pick it up after joining!) all over the world. Most of our team is remote, including one from Copenhagen! http://noredink.com/jobs

Damn you Richard, you hired all the best Elm devs and cornered the market :)

Oh man, if only! There are soooo many amazing Elm devs out there.

I'm excited for Elm Europe in large part so I can finally meet more of them in person!

Re: Elm changed my mind about unpopular languages

#135
post #43

Earlier quoted context omitted.

I saw the same at CircleCI with clojure. People want to use functional langs in real systems - we had a lot of Haskell lovers apply because "close enough". Way easier than hiring rails devs. One of the reasons I'm using OCaml/Elm in my new startup :)

> One of the reasons I'm using OCaml/Elm in my new startup Where do I apply? ;-) (To prove the point: yes, I'm one of those passion people, moving to Denmark to work in OCaml full-time, before working in Clojure full-time. Now someone give me an Idris job, heh!)

I’m curius, who’s using OCaml in Denmark? (If you don’t mind me asking, of course)

Re: Elm changed my mind about unpopular languages

#136

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

The author does emphasise how complete and well-built the official Elm tools are, which kind of mitigates this concern. But I agree, the article doesn’t really spell out its reasoning.

Re: Elm changed my mind about unpopular languages

#137
post #92

Earlier quoted context omitted.

> But are language enthusiasts really better hires in general? I've known many of them who loved the theory and toying with a language but were not any better at producing actual value than the average joe. I think they may be safer hires, anyway. They will be able to program themselves out of a wet cardboard box, which is more than you can say about the average Joe who may just be good at bluffing the interview.

Provided you dangle enough money and have a good interview process you can easily cull those people who can't code themselves out of a wet paper bag. The thing that would worry me about niche languages is the amount of wheel reinvention you'd have to do. Not sure the cost/benefit calculation starts to look so great any more when you realize that your enthused elm developers will have to build a whole lot of stuff tha…

Not sure how Elm interacts with Javascript libraries, but JVM languages can generally use any existing Java libraries. So a language built on a popular run time (JVM, .Net VM, guess there's exactly two), can still have excellent library support.

Re: Elm changed my mind about unpopular languages

#138

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.

Erlang is dynamically typed. It's certainly not untyped - it's assembly and Forth that are untyped.

Re: Elm changed my mind about unpopular languages

#139

Earlier quoted context omitted.

> One of the reasons I'm using OCaml/Elm in my new startup Where do I apply? ;-) (To prove the point: yes, I'm one of those passion people, moving to Denmark to work in OCaml full-time, before working in Clojure full-time. Now someone give me an Idris job, heh!)

You could go do reason @ facebook messenger (I dont work at facebook): https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

Wait, Facebook is rewriting one of the most used applications on Earth with an ML -> Javascript compiler?

Not sure how I missed that, seems like it was under reported.

Re: Elm changed my mind about unpopular languages

#140
>I made it a hard and fast rule: if I found two technologies that could solve a problem, I would choose the one more people were using. I didn’t want to include an obscure graphics API and then discover that no one had ever called set_color() followed by resize_window() (resizing is hard) and somehow those two functions in sequence cause a segfault. I don’t want to be the guy that finds a bug in the compiler. I just need to ship the product.

Then he links to issues for Qt and Go. They're certainly not obscure. What kind of weird argument is this? If anything, the argument there is that it doesn't matter how popular something is, as even extremely popular things like Qt and Go will still have bugs.

Post reply on HN