5 ms·
No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use cas
by IfOnlyYouKnew 6y ago
No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference.[0]
The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits.
There's absolutely nothing wrong with that. It's a bit emotional, but those exist for a reason. If you consider that idea libellous, you can always cite PR motives for plausible deniability and point at this HN story as evidence.
[0]: Elm, by the way, strikes me as borderline with regards to the bounds of reasonableness, considering the state that community is in. As such, it's more evidence your left (right?) metaphorical hemisphere may have had a finger on the scale.
- FlyingSnake 6y ago> The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?
- oblio 6y agoI think his point is that there are N languages that are performant and they could have probably chosen any of them to achieve their goal, so the choice is primarily aesthetic.
- thedmstdmstdmst 6y agoThe article doesn't say they have exhausted all languages, just that it is their first choice. Not their only choice but first choice.
- IfOnlyYouKnew 6y agoI really don't have a problem with their choice–I wasn't being ironic. It's perfectly acceptable to make "I like it" or "it works for us" choices. I do believe, very very mildly, that there's a strain of thinking among the tech crowd that glorifies this Spock-like emotional detachment and I'm-so-rational mindset. Two issues, actually: First, such a mindset is neither possible nor would do much good. There are stroke victims that survive with full mental capabilities with regards to logical reasoning but entirely devoid of emotions. These patients can still ace the SAT, but they fail spectacularly at daily life. As it turns out, you just cannot decide on a doctor's appointment without emotions. They'll spent hours vacillating between two good choices. Emotions are incredibly well-tuned heuristics that cut down your mental load to manageable levels. As any part of being human, they are sometimes ill-fitting for modern times: there's absolutely no reason to make me flinch when I spill hot coffee over my hand. But mostly they just work. Second, it's slightly annoying when people deny that they are subject to emotions, and it gets up to Ryanair-levels of discomfort when they announce that it makes them superior to all those emotional social science majors, illogical politicians, women "throwing a fit", superficial designers etc. If I got a KDE theme every time someone accused Apple users of being blinded by eye candy, I'd still be left with only half of what Kubuntu ships. But Rust is cool.
- arcturus17 6y agoI think these are very keen observations of reality, and they're very well put. I've long-admitted that my heuristics for choosing a tech stack are very similar to what you describe. I analyze the requirements and give each technology a pass/fail grade. Then, amongst those that pass, I simply choose the one that I find the coolest.
- thedmstdmstdmst 6y agoI completely agree about your thought about emotions and the Spock-like emotional detachment and the importance of emotions in decision making and every day life. I disagree that this is related to the original posted article about a company that has chosen as their first language Haskell. I do wonder how your responses would differ if they had chosen Elm originally and perhaps it is both you and I that should evaluate our emotions are why we even commented...
- willtim 6y ago> There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference. It's about quality of life and picking the right tool for the job. There are some problems I can solve in Haskell, that I simply could not solve in Java, it would be too hard and too much work. Java is a simple language and therefore it's much easier to reason about the performance and space usage. There are thus many problems where Java would be a better fit.
- sesm 6y agoJava is much easier to reason about the performance and space usage because it's a language with strict evaluation. Most programming languages use strict evaluation, including OCaml, F# and Scala.
- willtim 6y ago> because it's a language with strict evaluation But that is not the only reason. Haskell does much more aggressive optimisations than Java (and Scala, OCaml, F#). A large part of Haskell's space-usage reasoning issues come from the combination of lazy evaluation and these aggressive optimisations. Java and Scala code can contain plenty of deferred evaluation too, for example iterators, but the compilers simply don't do (and cannot do) such aggressive optimisations. Of course, this also means that much pure functional Scala/Java code can be poorly performing.
- Albert_Camus 6y agoAuthor here. Having written a lot of Haskell, I don't find lazy evaluation to be an issue nearly as often as it is a benefit. Yes, it can be difficult to reason about at times, but more often it ends up leading to simpler code. I would say that if you're consistently highly concerned with evaluation order, then yes, Haskell might not be the language for you. But I would also say that you shouldn't be concerned with evaluation order when writing Haskell, in the same way you usually shouldn't be concerned with what the query optimizer is doing when writing SQL.
- boomlinde 6y agoWhy don't you argue against the points made in favor of Haskell in the article? You can probably tell more about why they use Haskell that way. It's certainly a better indication than your ridiculous TLD divination.
- thedmstdmstdmst 6y agoI have no horse in this race. Reading the posted article I have a hard time understanding why you posted this comment. The article has reasoned arguments related to software development. Your comment is pure emotion which seems to be your main claim against the article.
- slow_donkey 6y agoI had the same feelings as the parent - this article did not make good arguments for using Haskell specifically in building production systems, it instead argues that Haskell is a good programming language yet many of the benefits listed can be found in other languages. Even if Haskell was objectively the 'best' language, it'd likely be a poor choice for most teams simply due to familiarity and developer speed. I'd be extremely hesitant to hire the services of this company entirely because they use Haskell and it'd be a nightmare to maintain after their contract.
- thedmstdmstdmst 6y agoI think the article was easy enough to pass by as I agree it didn't make GOOD arguments specifically in building production systems. I also give the author some slack because that article would be quite heavy to address the entire development cycle up to production systems. From my reading the article makes no claim that Haskell is the best language. The purpose as I read it is to explain why Haskell is their first choice while addressing an audience that has a passing knowledge of Haskell. You being extremely hesitant to hire the services because of their technology stack is great and fine. There are many stacks and services I completely avoid in dealing with so I agree there. "It'd be a nightmare to maintain after their contract" is something someone would likely say to any language that is not their preference.
- mcosta 6y ago> fmap renderPost postList for(var post: postList) renderPost(post); Or postList.stream().map(renderPost)