Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm changed my mind about unpopular languages

blog.realkinetic.com

Post reply on HN
Print view View original

111–120 of 321 posts

Re: Elm changed my mind about unpopular languages

#111

Post by crdoconnor »

kqr wrote: post #92
boubiyeah wrote: post #56

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.

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

Re: Elm changed my mind about unpopular languages

#112

Post by collyw »

boubiyeah wrote: post #56
s4vi0r wrote: post #38

Earlier quoted context omitted.

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…

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

Re: Elm changed my mind about unpopular languages

#113

Post by switchbak »

boubiyeah wrote: post #56
s4vi0r wrote: post #38

Earlier quoted context omitted.

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…

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.

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

Re: Elm changed my mind about unpopular languages

#114

Post by thaumasiotes »

shaki-dora wrote: post #101
thaumasiotes wrote: post #49

Earlier quoted context omitted.

> It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where 1 + "1" "1" + 1 1 + 1 "1" + "1" are all 2, and 1 . "1" "1" . 1 "1" . "1" 1 . 1 are all 11. Letting you specify the result you want by the function you call basically solves that whole problem.

That's just a "type system by obscurity". Extending it to provide the same sort safety, you'd need specific function for all combinations of types: sum_two_integers(), sum_integer_and_float() etc... Which would be both extremely ugly and a terrible waste of memory.

You seem to have missed the whole point of my comment. sum_integer_and_float() is the opposite of what I'm talking about. If you wanted to extend this system within numeric operations, you'd have e.g. divide_and_return_integer() vs divide_and_return_float() (funnily enough, this is also a very popular distinction for languages to draw); sum_and_return_integer() vs sum_and_return_float(); etc.

This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result.

That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2).

Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.

Re: Elm changed my mind about unpopular languages

#115

Post by woolvalley »

Jeff_Brown wrote: post #16

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…

How much of it was haskell, and how much of it was just working with a statically typed language?

Re: Elm changed my mind about unpopular languages

#116

Post by woolvalley »

ken wrote: post #44

> "I don’t want to be the guy that finds a bug in the compiler." When I'm wearing by "be productive" hat, I don't, either, but how realistic is that? Unless you've memorized the bug database for your compiler, running into a known bug is just as frustrating as discovering a new one, and I'm pretty sure I've run into at least a few bugs in every compiler I've ever used. According to my comments, my current flagship pr…

At least you save a few hours when you look up the known bug

Re: Elm changed my mind about unpopular languages

#117

Post by mrweasel »

isostatic wrote: post #79

I used to use Elm, then I moved to Pine, then Mutt (which is still going strong) I guess there's only so many names in the world, and they're bound to be reused.

True, I still think article with ML in the title are all about ML the programming language.

Re: Elm changed my mind about unpopular languages

#118

Post by switchbak »

onebot wrote: post #62
rtfeldman wrote: post #33

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…

Don't you want people that care about your product instead of the technology behind it? I do. Because there may come a time when another technology is a better fit for your product and ultimately your customer's experiences. Then what? Now your not using elm and your team leaves or is disgruntled. I hire on passion for what we are trying to accomplish, not the technology stack.

Seems like a false dichotomy to me. It's plenty possible to choose (and recruit based on) a suitable language at the time you start a project, and to have people psyched about making a great product.

If down the line you find language XYZ is a much better fit, well you still have choices about migration/etc. I wouldn't expect the devs to revolt against this, if it really is a better fit.

Time and technology marches on, that doesn't mean we can't try to make the best tool choices we can while still accepting that change is a fact of life and adapting the best we can.

Re: Elm changed my mind about unpopular languages

#119

Post by woolvalley »

rboyd wrote: post #103
woolvalley wrote: post #90

Earlier quoted context omitted.

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…

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.

Re: Elm changed my mind about unpopular languages

#120

Post by ujal »

woolvalley wrote: post #115
Jeff_Brown wrote: post #16

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…

How much of it was haskell, and how much of it was just working with a statically typed language?

In my case the verbosity of Typescript or Flow stops me from adopting it. Still waiting for Elm/Haskell-style type signatures for Javascript.
Post reply on HN