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

141–150 of 321 posts

Re: Elm changed my mind about unpopular languages

#141

Post by nogridbag »

matte_black wrote: post #70

I feel unpopular languages are best relegated for niche use cases the language is well suited for. If you are going to build something mundane like a CRUD App or a game, or an ERP, why wouldn't you just use some mundane blue-collar language like Javascript or its equivalent? What you are doing isn't new or groundbreaking, so why bother bringing in extra drama and ceremony by using a language very few people use to ac…

I find this line of reasoning a bit strange. I've only dabbled a bit with some unpopular languages, but I don't think their limited popularity implies they're only suitable for niche use cases. In fact after using some languages (most recently Clojure) I find programming in other mundane languages like JS a huge step backwards.

People are probably the biggest determining factor in achieving a quality result. But I don't think that means we should forget about trying to improve our tools.

Re: Elm changed my mind about unpopular languages

#142

Post by seanmcdirmid »

MaxBarraclough wrote: post #138
LeonidasXIV wrote: post #59

Earlier quoted context omitted.

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.

Dynamic typing (like static typing) is a spectrum, actually. You can flag method missing errors at a minimum, but in a nominally dynamically typed system, you could flag class mismatches before you ever got to a dispatch error.

Re: Elm changed my mind about unpopular languages

#143

Post by woolvalley »

Jeff_Brown wrote: post #123
woolvalley wrote: post #115

Earlier quoted context omitted.

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

I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on…

That complicated type system w/ type inference does come with it's own costs, usually bad compile speed issues. It's what I've noticed when looking at languages like swift, rust, scala & haskell.

I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point.

But that was insightful, thank you!

Re: Elm changed my mind about unpopular languages

#144

Post by woolvalley »

jimbokun wrote: post #139
woolvalley wrote: post #94

Earlier quoted context omitted.

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.

Yes and they use haskell too

Re: Elm changed my mind about unpopular languages

#145

Post by Jeff_Brown »

woolvalley wrote: post #143
Jeff_Brown wrote: post #123

Earlier quoted context omitted.

I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type system is complete -- even a function of functions can specify exactly what kinds of functions it uses for inputs and outputs. That makes higher order programming much safer -- and higher-order programming might be the best way to move fast. Haskell is also astoundingly terse. In Java and C my data type declarations were too long to fit on…

That complicated type system w/ type inference does come with it's own costs, usually bad compile speed issues. It's what I've noticed when looking at languages like swift, rust, scala & haskell. I'm currently dealing with it in a large swift project, and I would much rather go back to the extra verbosity of objective-c than have type inference at this point. But that was insightful, thank you!

Have you noticed slow compiling with Haskell specifically?

Re: Elm changed my mind about unpopular languages

#146

Post by keithnz »

mooreds wrote: 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 general sense (not talking about elm) It's a risk going off the beaten path to leverage some new way of doing things that makes life easier, sometimes that risk pays off, sometimes it doesn't. Sometimes it pays off bigtime early and then starts costing big time later ( I experienced this using Meteor from early on in its life ). I went with C# when it was still beta, that paid off real well. I went with embedding lua into a embedded system very early in luas life, that was a great choice. I tried with moving to F# from C# and it was just too painful for the devs to switch (though I really like F#, it's advantages weren't huge over C# that made it compelling ). Considering trying again with converting C programmers to Rust for an embedded system where we are refreshing to a more modern chipset.

So mixed results, but just because it might not work out isn't reason to not take a risk, just have to work out how appropriate that risk is.

Re: Elm changed my mind about unpopular languages

#147

Post by blunte »

mooreds wrote: post #132
blunte wrote: post #74

Earlier quoted context omitted.

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

Exactly. And maybe the grass is always greener, but sometimes I envy the COBOL guy who earns a small fortune doing something that doesn't involve learning a new language and framework every two years.

Re: Elm changed my mind about unpopular languages

#148

Post by z5h »

mooreds wrote: 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…

Your interested in solving problems you might have in 3 years, and Elm solves problems you definitely have now and will continue to have in 3 years. In 20 years of development I've never been happier, more productive, and more error-free.

Re: Elm changed my mind about unpopular languages

#150

Post by matte_black »

nogridbag wrote: post #141
matte_black wrote: post #70

I feel unpopular languages are best relegated for niche use cases the language is well suited for. If you are going to build something mundane like a CRUD App or a game, or an ERP, why wouldn't you just use some mundane blue-collar language like Javascript or its equivalent? What you are doing isn't new or groundbreaking, so why bother bringing in extra drama and ceremony by using a language very few people use to ac…

I find this line of reasoning a bit strange. I've only dabbled a bit with some unpopular languages, but I don't think their limited popularity implies they're only suitable for niche use cases. In fact after using some languages (most recently Clojure) I find programming in other mundane languages like JS a huge step backwards. People are probably the biggest determining factor in achieving a quality result. But I do…

It’s not just about the language itself.

You might think Japanese is an awesome language and decide to learn it, but then what use is speaking Japanese outside of Japan? Around the world people still just use boring ol’ English, even though English is actually a pretty shitty language and full of hacks to make up for weird edge cases (read and read, goose and geese, mice and meese?, Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo)

Likewise, if you write something in Clojure, you have far less people and libraries and platforms that can help you accomplish whatever you are doing. If what you are doing is not something new or groundbreaking that could only be done well with Clojure, then the extra effort you have to spend to get up and running is not worth it.

Post reply on HN