Hacker News Reader

Comment by s4vi0r | Hacker News Reader

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 candidates than a react position might draw but the candidates are going to be people who've played around with Elm and enjoyed it and want to get a job writing Elm.

I'm kinda surprised more companies don't take the risk - its not like these are bad languages, either. There's still a huge chunk people (in terms of absolute number, not portion of total devs of course) out there playing around with languages like Elm or Haskell or a Lisp/Scheme, or OcaML, F#, etc. who'd be super excited to use those languages professionally.

View on HN

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.

That's what a good manager is for, they're there to turn a powerful engine into a productive one.

> 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 that you can just import in other languages.

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.

...or Node.js nowadays, so three, I guess.

Elm nicely abstracts over JS interoperability with a mechanism called ports: https://guide.elm-lang.org/interop/javascript.html

Most niche languages have an FFI escape hatch for when you really need a library and don't want to re-invent a wheel. Elm, Purescript, Bucklescript, and ghcjs can all interoperate with javascript; Scala and Clojure work with most (all?) native java libraries; F# has access to most (all?) .NET libraries. Haskell, Idris, ATS, Erlang, and SBCL Common Lisp all allow you to access native system libraries.

FFIs can have warts, but in the general case library support isn't the obstacle people make it out to be.

I don't agree. I find that the impedance mismatch of an FFI is an incredibly fertile breeding ground for nasty and obscure bugs and deployment problems.

> 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

Interviewing costs money—good tech interviewing particularly so. The less of the people you have applying to start with, the more money you save on culling then by way of tech interviews.

True, I'd much rather someone who spends their time learning Elm than Cracking The Code Interview.

Aren't you just as likely to get people who excel at hyping and hello-worlding new languages but can't actually make applications? Or people who just read the python paradox (with python scribbled out and Elm written over it) who think they can look like a great developer who understands the value of Elm but really don't?

You'll get those, yes. I know because I was one of them... But I think you unerestimate how bad the average interviewee can be.

Someone who hello worlds new languages may not know the syntax or idioms to write fizzbuzz in any specific language, but they will be able to characterise the rough shape of the problem, and not just sit in silence...

> bluffing the interview

"bluffer overflow vulnerability". :)

I have noticed a lot of language / framework collectors where every new project is in a new framework or language on their CV. While it will expose you to a lot of different ideas I doubt you will code very well in any of them if you are swapping every year. I have seen plenty of Python written like its Java and its just less elegant code. And Django code that doesn't follow best practices seems to be the norm. If you take the time to master a few things you can produce some quite elegant solutions. If you only know the basics, you reinvent the wheel in a crappy way usually.

Python written like Java would be a huge improvement over what most people produce.

I don't think so. I've seen Java written like Java.

The best ideas are those that you can share between languages. When you get hung up on idioms, or when you recreate idioms that don't matter in another language, that's where the problems are. Exposure to a lot of languages allow a person to figure out that union of computation that benefits all languages.

Like I say when I see python written in a Java style its verbose, and doesn't take advantage of much of the expressive syntax that Python provides over Java. You have given up the speed benefit of Java and have kept code that is nearly as verbose.

And don't get me started on the way people misuse Django.

In my experience they're quite correlated (but not 100%). It seems to be a strong signal for passion about development, which I'd say is important for hiring someone who really cares about doing their job well (which I also find is an important and rare attribute in a good dev).

They're a great way to seed your recruiting pipeline. Enough of them ought to be good hires to make this useful. After that, you just have to trust your hiring process, just like you would for any other source of candidates.

I think this depends on what you mean by “actual value”. A working product powered by a tangled yarn of hastily-assembled spaghetticode has a highly dubious long-term value, and what’s worse, your “average-Joe” coders might not even realize/see the value of what that “one overly-careful coder” brings to the table

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.

datomic has both soft delete (retraction) and hard delete (excision).

He was working in a health startup and this was something like a couple of years ago. He said that datomic was immutable so actually deleting things to HIPPA standards was not possible I think. They might of fixed it by now.

Having installed a medical records system for live-fire use by an optometry practice, I can say that it's exceedingly rare that you ever want to delete anything that is logged in a medical records environment. It's so rare that it's never been done on the four or so years I've been maintaining the system.

Datomic is an immutable database, so if you need ephemeral (deleteable) data you could just set up another non-Datomic store.

You're correct that Datomic considers immutability a feature. That said, Datomic on-prem supports excision which completely removes data for exceptional cases. I suspect Datomic Cloud will sometime in the future.

With EU's GDPR (General Data Protection Regulation) looming on the horizon I think Cognitect would do themselves a disservice should they not include excision in their Datomic Cloud platform sooner rather than later.

F# is a bit surprising, since it’s already on top of a mainstream platform. If all else fails you can glue in C# if you ever find that you really can’t do something with F#.

Isn't Elm built on top of maybe the most mainstream "platform"? JavaScript? If all else fails you can glue in some JavaScript via its ports system[1].

[1]Languages like PureScript provide a much more convenient FFI for this glue, but the glue and escape hatch is still there with Elm.

That's an apples to oranges comparison...

F# and C# compile to the same intermediate language, are interpreted on the same runtime, and are produced by the same organization for the same IDE... Their libraries are compatible and they rely on shared access to the common .net ecosystem.

Your absolute worst case scenario would involve decompiling your F# source as C#. More realistically you would use dependency management to gracefully transition out of one of the languages.

Transitioning piecemeal works exceptionally well: it's exactly how I've transitioned numerous projects away from C# onto F# ;)

Ummm Purescript compiles to JS and shares the same runtimes. Both languages have support from popular text editors, and their libraries are compatible and rely on shared access to the common JS ecosystem. In what way is it an apples-to-oranges comparison?

React was small at one time even if backed by Facebook. I was passionate about it even before it became popular and still am.

Reply on news.ycombinator.com