Hacker News Reader

Comment by benreesman | Hacker News Reader

We don’t like to talk about this: but modulo all the usual turf wars around libraries and attribution and where the braces go: serious Haskell people skew smart and capable.

This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming).

But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.

Source: worked on one of the biggest production Haskell code bases on Earth, was involved in early design discussions on both React and Ember, and wrote big pieces of an ECMA-262 compiler/VM.

Haskell people skew smarter than most other languages.

Sorry for saying it out loud.

View on HN

One issue is if smart people are more trouble than they're worth. I've seen too many 'smart people' drop in and do a bunch of fancy stuff that no one understands before leaving again because they're 'smarter' than everyone else. I'm still not sure if they were smart or just thought they were.

Effectiveness at work from what I have observed is mostly about pragmatism and willpower to do what needs to be done in that context. You need some baseline amount of mental horsepower but in most pursuits it's not that high.

Really smart people can be some combination of idealistic, lazy or simply in a context that diminishes their willpower. Therefore their smarts don't really "manifest" in that particular context. I've worked with lots of people who I thought were bozos because they sucked at their programming job but they were clearly smart about other things.

This has been my exclusive experience with all the "smart" FP developers who just couldn't help themselves into dropping FP libraries or concepts all over our node.js serverless backend every chance they could. One even quit because he couldn't use purescript on the frontend.

Had to show another the door because he was so disgruntled that we were coding in a paradigm so beneath his intelligence that his toxicity and moping permeated across the entire team.

Like dude do you realize what we are doing here...

If they were that smart I don't think they would have ended up here next to me programming CRUD backends for a mobile app.

A smart dev is someone that learns new paradigms and concepts and the applies them only where they make things easier to understand/maintain.

It's not enough to learn about higher kinded types, you've got to know when forcing them into a place is a bad idea.

I've seen a bunch of devs that can't help but write unmaintainable code because they learn a new programming concept and decide to shoehorn it in everywhere. This happens even with basic concepts like generics.

The same thing happens to devs that aren't curious. If they never learn newer programming concepts then every problem looks like a nail and inheritance is the hammer. Those systems equally become unmaintainable because clearer programming paradigms would make the code more readable and maintainable.

Contrast that with walking into a codebase in a statically typed language that uses String as the predominant type with little to no effort spent on sanitizing the data in those Strings.

It’s understandable in pieces… but also really hard to scale/refactor/replace after it has grown enough.

I think I covered that case in the end of my comment.

> The same thing happens to devs that aren't curious. If they never learn newer programming concepts then every problem looks like a nail and inheritance is the hammer.

Stringly types or the overuse of Dictionary/maps in a statically typed language are extensions of this concept.

> A smart dev is someone that learns new paradigms and concepts and the applies them only where they make things easier to understand/maintain.

I think we put a little to much stock in "smart" developers. What you describe sounds more like a "wise" developer - as in "a clever developer knows how to map-reduce, a wise developer knows not to put it in a fruit salad"...

IMO, there's no difference. There are few concepts in programming that are really unknowable or ungraspable. Anyone that can program can misunderstand and misuse programming concepts.

The only wisdom is asking "should I"? And that, to me, is being smart and cleaver. Cleaver people don't write hard to understand/maintain code. Cleaver people write code that anyone can come to and understand. They write elegant code.

Flexibility + smart is the ultimate smart.

It’s hard enough to figure out who has smarts, let alone real flexibility:(

> If they were that smart I don't think they would have ended up here next to me programming CRUD backends for a mobile app.

Good for him.

I have had a hard time figuring out how to phrase this, but I think the problem is that everyone wants to be smart, and sometimes that subconsciously gets turned into "smart people are better," but what we really want other people to be is aligned with us. How capable they are is just the length of the vector, which could even point in the opposite direction making intelligence detrimental.

Agreed. You might be interested in reading about AI alignment which is this concept applied to non-human intelligence, and like you said the same principle holds among people too. https://en.wikipedia.org/wiki/AI_alignment

Then is the goal of "preventing bad AI outcomes" at any level just a bit absurd? Or at least as absurd as "eliminating alignment issues among humans", or maybe even "bug-free code" if you apply the principle towards relatively simple programs?

It is equally challenging as both of those examples, but it's very very important so it's worth working on despite the intractability.

In terms of alignment among humans, most (but not all) human governments agree on certain principles, which are encoded in international law and negotiated within the United Nations.

E.g., most (not all) people agree that torture and slavery are unacceptable.

Thus, it is possible and important to get AGI to abide by these high-level human values. E.g. if an AGI system is put in charge of maximizing the GDP of a nation, it should do so in accordance with generally recognized principles of human rights and human dignity.

There's certainly a lack of agreement among nations but at least we mostly agree on some things and getting AI to agree with us on the things we agree on is important.

If you like podcasts, here's a great podcast episode which explores a philosopher's perspective on how to make moral decisions (e.g. should abortion be legal) in a situation of moral uncertainty:

https://futureoflife.org/2018/09/17/moral-uncertainty-and-th...

I don't think everyone wants to be smart. I don't give a shit about feeling smart or being smart if I get paid well and I'm happy.

I think many folks in eng are used to being told they were smart either in high school or college or an early job and it became part of their self image. They might be smart but they are tossed into a field of people who come from similar backgrounds and now they are average which just doesnt fit with their self image.

Nothing you value can be obtained without your brain, although you might use words other than "smart" to describe the abilities involved.

Being hardworking is also an ability of the brain, but distinct from being smart.

"Smart" also can have a lot of different meanings/outlets/vectors.

First 10 years of my career, I felt bearded Unix Sysadmins were the smartest people I knew :->, whereas I was fully Dilbertian in view of The Evil Pointy Haired Management.

I've been trying to develop "PeopleSmarts" or "Soft Skills" or "Emotional Intelligence" or whatever we call it last 5+ years, and it's... just as much harder and more challenging than technical skillset, as my mentors always told me and I never believed. It's a far fuzzier, squishier, less certain set of problems, and there just isn't O'Reilly-quality literature out there :P.

I have confidence that given time I can learn technical concepts or figure out technical issues.

I think path in front of me to be soft-skill-savvy, emotionally intelligent, is going to be long and hard.

So, how to properly setup LUNs on AIX or optimize a SQL statement or design an ERP architecture is one kind of smart; how to work with your own team to figure out productive way forward is another kind of smart; how to work with client and business and management stakeholders to satisfy their actual needs is another important kind of smart.

Sounds like a type of Bikeshedding: providing contribution (that's more noise than value) just to prove you're contributing.

https://en.wikipedia.org/wiki/Law_of_triviality

As someone who was a little misguided in my early programming career, I think what attracted to me about the FP community is the general enthusiasm that they have in their craft. I don't think it's about the axis on whether if someone is "smart" or not, but if the problem space is interesting enough to devote a whole career to.

That's the difference between understanding the machine and understanding people (and understanding that most people do not (really want to) understand the machine).

In order to get real value out of a "smart person", I think you need a sufficiently challenging problem for them to work on.

Yes, giving them a CRUD app where they build their own frameworks because they're bored and something about the existing frameworks is sub-optimal probably will end up adding net negative value as they introduce complexity all the other developers now need to understand.

But if you have a ton of PHP code and running at such scale that you need to create a new PHP engine to optimize all of your existing code and save millions of dollars on your infrastructure costs, a "smart person" just might fit the bill.

The original HHVM team were in fact… legends. :)

> I think you need a sufficiently challenging problem for them to work on.

One important thing to realize is that the challenge doesn't have to be in the obvious place.

Having a smart person who is really interested in solving the business problem you are trying to solve will make things better all over the place.

Having a smart person who is uninterested in the business problem you are trying to solve and looking for intellectual stimulation in the technical stack - well, if you aren't doing something "interesting" it's probably going to go poorly.

In my experience there's a difference between smart and clever, at least when it comes to writing code.

Clever people implement solutions nobody else can - they know the tools they're using inside and out and can do amazing things.

Smart people realize the things they build must last longer than themselves. They implement solutions those that come after them can understand and maintain. Sometimes those solutions are clever. If the problem domain is hard, then the solution is necessarily clever.

People can be smart and selfish at the same time. I've worked with some extremely smart people who realized that what made work satisfying to them was getting paid to be clever all day. Being smart, they found ways to do that, at the expense of their employers and coworkers. I wasted an hour of my afternoon writing a long and angry screed about my professional experience with functional programming (in Scala) but at the end of the day, sadly, it can be summed up as that, smart people scamming companies for the opportunity to be clever all day. I see mainstream programming benefiting more and more from the influence of functional ideas, so I still think that FP might become the default for professional programmers at some point in the future, at least for some kinds of work, and I think the work I've invested in it has made me a better programmer, but I'm fed up with the kinds of people I've found myself working with along the way.

IMHO when someone looks at a problem and sees some outlines of mathematical structure and thinks “C++ is overkill performance-wise and I don’t want to take the incremental maintenance burden, but Python is so friggin slow that it matters for even this”, they’ve got a few options. If you’ve already got a JVM in your stack, that’s probably the call. If you’ve already got Cargo in your stack, also reasonable. But if you don’t and are unlikely to, well you kinda go the Haskell/ML route or the Go/Node route.

And as much as my personal spiritual home is the MEAN stack, the Haskell/ML route seems to attract more people who know heavier CS than I do.

"Python is so friggin slow that it matters for even this"

Why wouldn't they use Cython, any of the scipy/numpy ecosystem, or Numba?

"the Haskell/ML route seems to attract more people who know heavier CS than I do"

Why is someone else knowing heavier CS than you do a good heuristic for a tool being the right long-term solution for a job to be done?

Because I want to work with people more capable than myself for at least two reasons:

1. I’m likely to learn a lot from them.

2. The harder the problem is that the team can realistically tackle the more likely the team is to do something novel/interesting/beneficial/profitable, ideally all at once.

I didn't ask you why or whether you want to work with people more capable than yourself (on that, I'd agree with you, striving to work with people more capable than oneself is generally desirable).

Would you mind answering the question I asked rather than an unrelated one? Maybe I can be even more clear than in my original question:

What does someone else (who knows heavier CS than you) liking some tool have to do with that tool being the right long-term solution for any particular use case?

The smart people I know write simple solutions to hard problems.

But if you stick a smart person on a boring problem they'll probably write clever solutions for the boring problem.

This reminds me of Dan Abramov's post about identifying when not to be smart. https://overreacted.io/goodbye-clean-code/

On the flipside, the usual argument around "simplicity" and "readability" is just code for "familiarity". A Haskeller used to composing a bunch of folds has no obligation to transform their program into something readable by Python programmer, unless of course, they were the only Haskeller.

But I agree, there's a difference between code that veers towards obfuscation and code that employs techniques someone just hasn't learned yet.

Haskell is much more than folds, maps and monads.

I agree. I'm just presenting an example where patterns that one camp deems as "too clever" are normal to another.

> On the flipside, the usual argument around "simplicity" and "readability" is just code for "familiarity"

I found this resonating with my own thoughts towards LeetCode questions, which are at odds with most on HN. Unfamiliarity makes people dismiss them as requiring rote memorization, where's most of them are a matter of figuring out the nature of the problem space, and choosing the right data structure and algorithms

Yeah, I totally acknowledge that most of the people I know that like Haskell are probably a lot smarter than me from an IQ perspective and yet if I was running a company I wouldn't hire a majority of them. Most of them seem to lack pragmatism.

I think intelligence is as much a choice as it is a built in trait in many ways and the people who like Haskell are the ones who enjoy solving very difficult abstract problems over just getting stuff done. The world needs some people like that but most projects don't.

> . I've seen too many 'smart people' drop in and do a bunch of fancy stuff that no one understands before leaving again because they're 'smarter' than everyone else.

Eh, they are not really 'smart' now, are they?

Sure, they may be mathematically gifted or what have you. But if your definition of 'smart' includes the individual's performance when responding to their world around they, they definitely were not :)

The 'smartest' (according to my own definitions and biases) developer I know also happened to write the most beautiful and easy to understand code. He could write clever one-liners. He knew better not to.

“But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.”

I think that’s going to be true for most people who have both the skill to contribute to anything like GHC and the drive to do so, I’m not convinced it’s specific to Haskell no matter how much you’d like that to be true.

They didn't say it was specific to Haskell, the wording was "than most other languages".

My intuition is that they are right. More powerful and fitting tools with a higher learning curve attract different kinds of people than stuff that is tailored for the mainstream.

There are also pragmatists who are extremely smart and capable and choose to deepen their expertise in Java (for example). But at _first glance_ it says more about a person if they are proficient in a specialized language than a mainstream one.

Maybe what I’m saying is that I give better odds for the typical senior Haskell hacker to get a useful diff into GHC than I do for the typical senior JS developer to get a useful diff into v8.

I actually think this is what is holding back the Haskell community from broader adoption. The senior Haskell hackers are much more interested in building compilers and runtimes and the like so the things that most developers really benefit from are missing.

The IDE support, dependency management, performance monitoring and application frameworks are all just plain worse in the Haskell ecosystem than others.

Smarter maybe holding the language back because it doesn’t correlate with shipping useful application software as well as other traits such as being customer oriented or empathetic to other workflows.

Reason #9143346356 why I’m so grateful for VSCode even though I’d never use it: haskell-language-server —-lsp is pretty good.

It’s kinda sad it can’t precise go to definition on libraries, but otherwise it’s really sweet.

it's sweet but can't do basic go to definition?

Go to definition in libraries is different than basic go to definition

But something solved for 20 or more years in IDEs for mainstream languages.

With the possible exception of Visual Studio, the only thing that mainstream IDEs have been “go to”-ing in the presence of an NP-hard dependency resolution graph for 20 years is the wrong place with a UI that simply exudes confidence.

You are sort of making my point for me. In theory dependency graph traversal is NP hard but in practice you can use heuristics to get to really good accuracy.

This really good accuracy is almost always better than the system not working at all. Very frequently (not always) the Haskell community let’s the perfect get in the way of the good on issues like this and I end up with tooling that is worse than 20 year old IDEs.

Oh I also agree that haskell-language-server makes the wrong precision/usefulness tradeoff. Codex for example can usually get you somewhere at least useful.

I was just pointing out that “solved” is a strong word for anything Eclipse or JetBrains did 5-10 years ago :) It’s easy to forget how shitty all the IDE stuff was before VSCode forced LSP through the clogged artery of language tooling.

I was personally using “go to definition” for Java with whatever IDEA’s tool was called in 2001-2002 (renamer?) and had the full suite of modern refactors in C# with Resharper by 2005.

I honestly haven’t seen much of an improvement in IDE productivity in the last 5-10 years compared to Resharper circa 2008 but if Haskell could get to parity with that it would be a huge win.

I once inherited a medium size python service and small front end at work that was primarily developed by someone that was super into Haskell. He chose to use mongodb and built a lot of functionality around the constraint that he didn't know what an index was.

I'm very thankful his manager didn't let him write it in Haskell. Now he's where he belongs back in academia doing NLP research.

In fairness, enthusiasts from lots of language communities got duped into using MongoDB.

Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be aware of.

> Is there some major problem with mongoDB?

Yes, plenty. It's mostly useless for relational data.

Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.

By relational data do you mean data that has no nesting or arrays? Or data that you always want to query with a join? Something else?

That that you would want to query with a join and have invariants that spread through those places you would want to join.

Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.

I see so reference data that you want included in an object for which you're willing to pay the performance overhead of a join rather than denormalize across many object representions in your database. This model has some downsides when it comes to reasoning about scale and denormalization isn't necessarily a consistency quagmire when you can use transactions to keep multiple objects in sync. More generally you can absolutely do this types of queries in modern data systems whether or not they are "relational".

Yeah, I guess I should retract my claim that people aren't claiming it's useful for relational data anymore.

Anyway, I was focusing on invariants. But yes, destroying your performance every time you need an atomic change or joining values also makes it bad for relational data.

That doesn't mean it's useless, just that it should not be used on the most common problem people have with their data.

Postgres literally beats MongoDB at JSON in benchmarks. Y'know, the thing that's supposed to be Mongo's bread and butter?

Which benchmark is that?

https://www.enterprisedb.com/news/new-benchmarks-show-postgr...

Unfortunately that benchmark was very inaccurate. They tuned the postgres configuration and didn't tune MongoDB. They also used an unsupported, experimental driver without connection pooling on MongoDB.

For example: they measured Query B execution time on postgres: 41m3s, mongodb: 1h13m3s. When MongoDB measured Query B with a supported driver, the execution time was only 3m30s more than 10x faster than postgres!

You'll find details here: https://www.mongodb.com/blog/post/benchmarking-do-it-right-o...

Thanks for that info. Statistics, misunderstandings, lies, benchmarks, database benchmarks...

Mongodb was a lot easier to manipulate json in for a while vs postgres, but once postgres got json path support it evened out a bit imo.

Say you have some json and nested in it somewhere is an array of objects, and you want to just map over that and update those objects. I was writing a migration to do that in Postgres <11 once and it was not fun to try and figure out how to do it.

I haven't worked with Mongo in years though, so no clue how it has evolved since like 2015.

> He chose to use mongodb [...]

I find it rather surprising that somebody who uses Haskell, i.e. clearly sees the value of types as an aid for reasoning about programs, would default to using a schemaless database which gives you essentially zero ways to reason about your data.

It makes much more sense coming from someone who doesn't really like static typing and so prefers run-time, informal reasoning.

He was using python 2.7 so he would have lost the type safety after he fetched the data anyway

That's not the same thing. There's value in a schema even in a dynamically typed language.

For example, if you have a bug in your codebase due to e.g. a runtime type error, you can generally troubleshoot and fix it, but if your data is in an inconsistent state, it may be impossible to fully recover.

I worked in a Haskell shop for a while. What I found was perhaps not precisely that they skewed smarter, but they definitely skewed more experienced. There were quite a few engineers who had been at it for two or more decades and very few whose first language was modern JavaScript. They were all very happy to be working in Haskell, so the morale benefit was substantial.

This did not, perhaps, always result in better code. It did at times result in an excessive faith in the power of types to solve all problems easily and neatly. This sometimes got awkward, such as when the team had to learn what XSS was and how to prevent it.

FWIW that ties out closely with my anecdotal experience.

> This did not, perhaps, always result in better code.

Personally, I make no effort to write good code when I'm programming in Haskell.

It was in fact a hard to get paradigm change, because I am a careful developer that makes quite an effort to avoid future problems when programming. But Haskell code can change at any time, so the optimal path is to go from the proof of concept into the fully featured software redesigning as you go.

> Haskell people skew smarter than most other languages.

As someone who is working on broadening Haskell adoption I'm trying to stop this being true! I'd like programmers of a wide variety of intelligence levels to be able to find a comfortable home in Haskell.

This is a similar challenge to e.g. C++. Can it be done with SFINAE? Yeah, probably.

Does Servant need pseudo-dependent types and does Wren need lenses?

Maybe we could both make and respond to an HTTP request without getting into some pretty heavy shit?

I think there is a tension between the power of the type system which anyone in userland can use, and wanting to make things easy for the everyday programmer.

What might help is a complete standard library framework akin to what C# provides out of the box that everyone agrees to use unless there is good reason not to.

Also allow imperative syntax.

> But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.

In my experience when exposed to dynamically typed languages, they will argue endlessly on "how bad they are". Also proponents of strongly type systems are often incapable of recognizing the drawbacks of such systems.

See for example https://github.com/fsharp/fslang-suggestions/issues/243#issu... for a critique that is never expressed by Haskellers.

Getting a bit precious about typing is IMHO a weakness of the Haskell community/mindset.

It’s not my favorite language, I’m a Lisp guy, but I stand by my assertion that a random sample from the Haskell population is a better bet on a hard problem than a random sample from the GraphQL population.

It seems fair. I have an hypothesis beyond the fact that it's a niche so self-motivated people are pre-selected: what somebody needs to learn Haskell are in good part applicable to computer science and programming languages whereas for JavaScript you need to learn the quirks and the specificity of the ecosystem first. The second experience does not translate very well to solving hard problems.

Sure thats like saying a random sample of 18 gear manual semi drivers are better drivers than an average suburban suburu dad driver, and … that makes sense!

I've worked with Haskell, OCaml and Erlang professionally. The other half of my career was spent mostly with some variants of C and Python. (I haven't contributed to GHC, though.)

I can get work done in dynamically typed languages without arguing all the time.

And from the point of view of eg Agda, Haskell itself is rather dynamically typed. It's all a continuum.

Of course, some languages are still better than others. And even the same language can get better or worse over time. For example, modern Python is much more palatable than Python used to be in the bad old days.

> for a critic that is never expressed

critique?

Thanks, corrected.

> See for example https://github.com/fsharp/fslang-suggestions/issues/243#issu...

See Rust traits to get an idea what happens if you 'just' implement type classes without proper support for higher kinded types ;)

I'm not that familiar with Rust at the moment, could you expand?

GP is referring to a Rust language feature called “traits” that is a quirky subset of a Haskell language feature called “type classes”.

Type classes are based on firmer theoretical footing (I think the original paper is called “Making Ad-Hoc Polymorphism Less Ad-Hoc”) and therefore run into fewer weird corner cases.

That’s not to say that Rust traits are “bad”, they’re useful and arguably cleaner than the C++ version of the idea (“concepts”), but a Haskell hacker writing Rust is liable to grumble now and again at the weird edge cases.

To use traits like you would type classes in Haskell, for example to define functors or monads in a general way, you need higher kinded types. Which can kind[oh, what a pun] of be implemented in Rust.

   So yes! You can use higher kinded types in rust. Whether you should I will
   leave up to you. But it certainly doesn't seem like a very attractive option 
   for most projects considering the syntactic noise of the implementation, a 
   typechecker that gets often confused and requires help, as well as error 
   messages that don't make much sense. Especially the last is a shame since 
   extremely helpful error messages is what rust is known for, and I 
   wholeheartedly agree (under normal circumstances).

https://hugopeters.me/posts/14/

   Yes, But Why, Really?
   Because sometimes one just gets homesick for Haskell and wants to implement
   the Functor hierarchy. You'll find this in the higher-cat crate. It's not 
   really very suited for writing good Rust code, but it makes Haskell 
   programmers feel happy and it has a lot of funny words.

https://docs.rs/higher/latest/higher/

A proposal for an addition to Rust, to get generic monads and (Haskell-like) do-notation for them:

https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in...

That link is very insightful and those reasons are why I stopped haskelling in my spare time.

Unfortunately pure FPs without typeclasses like Elm seem to be too boilerplatey for me.

F# may get around it by offering imperative and OO capabilities?

Overall I wanted to love pure FPs but I really appreciate Typescript and C# these days even though I tried with Haskell.

With Haskell you want to use a web library there are loads of programming language concepts that framework uses that you need to grok. With C# etc. you learn the language much quicker and libraries are way more “uniform” with nothing too fancy going on.

In my book this doesn’t seem controversial.

(As for me, I haven’t written one line of Haskell. Might never do.)

Another thing I believe: Most (but probably not all) projects are better off not using Haskell.

Totally agree that most software is probably better off without Haskell.

Most software is better off without C++, or Haskell, or Julia, or Nix for that matter.

But when every edge matters: one would be foolish not to reach for the sharpest knife that one can handle properly.

Indeed!

>This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming).

Those people dicking around with C++ templates make the whole project slower to compile and more difficult to understand though. I don't really know anybody that can easily read the finished template magic that you need to achieve anything meaningful in C++. Something which I think is not so much the case with using a good type system fully.

Agreed. I don’t have anything near your experience, but I have done Haskell in production for two years, and other things for longer. And yet I always say I’m not smart enough to use a language like JavaScript, I need a dumb language like Haskell :-)

I’d like an actual citation for this assertion.

Anecdotally, and counter to yours: I’ve generally found that people who focus on a language for the intelligence attributes it supposedly implies of users are often simply deep experts in that language and it’s application mistaking that expertise for general intelligence.

That’s a fair critique. Not anticipating the interest that this comment would produce I didn’t do some basic hygiene.

I should have said: “In my anecdotal experience: X.”

I said “X.”

I screwed that up.

I think serious $language people for any $language skew smart and capable. I'm not sure that the top 10% in any language (by whatever metric you choose to measure overall quality) are going to be significant more or less smart and capable than in any other language.

Disclaimer: I have minimal exposure to Haskell or Haskell programmers, so this opinion is predicated upon my experience with programmers of many other languages, not Haskell in particular, so I could be completely wrong.

Yeah I have no particular axe to grind on Haskell’s behalf. I’m a Lisp guy who has to write C++ all day like everyone else.

Lazy is a ridiculous default, the combinatorial explosion created by GHC extensions makes C compiler quirks look like a gentle massage in comparison, and building Haskell is a friggin migraine on wheels.

But for whatever reason, those folks are on average in my experience, serious as a heart attack.

I'll take your word for it then, since I have seen similar opinions expressed before, but when you say "serious" what particular qualities are you thinking about?

See a problem, realize it’s a graph, realize it’s traveling salesman, reduce it to 3SAT, and start grinding it out in MiniSAT before I can type “jupyter lab”.

That's not particularly Haskell specific.

What's more Haskell specific is recognizing many problems can be solved easier when seen through the lens of parsers, interpreters and/or compilers.

Haskell's and the whole ML family of languages are great at writing parsers etc. In fact they were originally invented for implementing other languages.

I have always figured the appeal of Haskell, Clojure, et al., is to transpile your task and turn any software problem into your language of choice.

Yes, though that's related, but not really want I wanted to say.

I meant that solving a problem in Haskell can often mean eg writing something a bit like a parser.

Lazy made historical sense as a default: it forced them to deal with side-effects properly.

For a new language I would suggest that without annotation, only pure, total functions are allowed.

Haskell makes you annotate side-effecting functions with a tag (like IO). But it allows divergent and partial functions just fine. That's why they can't just remove the laziness.

I propose that the latter would also need a tag.

The nice thing about total functions is that the choice between evaluation orders becomes purely a matter of optimization, and won't change anything about semantics.

Some languages like Agda already do something a bit like this.

(Also note that total functions are not Turing complete. But that's a feature, not a bug.)

ever check this out? https://github.com/Kindelia/HVM

> I'm not sure that the top 10% in any language (by whatever metric you choose to measure overall quality) are going to be significant more or less smart and capable than in any other language.

Eh, I'm fairly sure the top 10% of people who liked the bad old PHP were still fairly moronic. (Facebook gave PHP a nice revamp, so it's a much nicer language these days.)

For another example, have a look at newLISP. Especially http://www.newlisp.org/MemoryManagement.html

However, I agree with your point on average in general for most languages.

>liked

That's not really the issue though. I said top 10% by some measure of quality. Whether not the top 10% of PHP programmers liked the language is a separate variable from their levels of competence & intelligence as compared to some other language.

My formulation was a bit sloppy. Just assume I wrote about the top 10% of people using bad old PHP.

Yes, there were some smart people forced to use it. But they were perhaps enough to drive up the top 2%, not so much the top 10%.

>Haskell people skew smarter than most other languages.

But are they more productive, get shit that we care about done, or do they go down monadic rabbit holes?

By all means Haskell away in your pet projects, but having a company invest into a team to deliver things customers want, I'd like to see some evidence this makes sense outside specific niche areas (Cardarno possibly being a good example where it makes sense).

There is a lot of “I wish this was Agfa so I could really flex” jerk-off stuff in Haskell.

But I’ve seen way more useful software fall down the show off well in C++ than in Haskell.

I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.”

That quote is something I had in mind when I wrote that message :)

And your spot on with the C++ reference, but there its more the case the language was adopted in industry then it expanded into intellectual twiddling, Haskell has that as its starting point.

Don't get me wrong I like programming in Haskell, C++ and others, I enjoy going beyond what I need to get the job done and amusing myself in doing things 'clever' ways. But no longer being paid to write the code and having different concerns to manage, its hard to qualify Haskell as a good choice.

Having said all that, I probably would be biased towards someone that has Haskell on their CV (doesn't need to be commercial) as it would indicate intellectual curiosity (and probably some capability) in their profession!

> I think it was Thompson or Ritchie who said: “debugging code is twice as hard as writing it, so be half as fancy when writing as you could be.”

I never agreed with the conclusion. Clearly the observation implies that you should use all your brain power to write your code in such a way that it is easy to read, understand and debug.

That often means using eg the right abstraction for the job. Not the dumbest one.

My bonafides for the comment I’m about to make: 5 years of professional Scala development at a serious Scala house. I have never done Haskell, but many of my co-workers have, and I had at least one interviewee do all his coding in it (he got hired, not because Haskell).

The problem really nice abstractions have is that they encode too much into too little code. They are very concise, and people who aren’t as knowledgeable (avoiding the word “smart” here as I think it’s wrong) will treat it as “magic”. Magic in code is a really bad idea when you need to debug it. The ML type system can create these magic moments that make someone who actually wants to understand how the hell that works have to go down a multi-hour rabbit hole just to figure it out. The best example of this that I’ve directly worked with is Finagle. If you look at the code for it, you’re very often left scratching your head trying to understand how it manages to get so much done with so little code. Having been there while it was developed, I will say it didn’t start off that “pretty”, it got there over 3 fairly major revisions to the underlying type abstractions. The result is beautiful, but opaque to most of the mere mortals that use it.

I would argue that Go has been successful largely because everything that’s happening is “out in the open”, where the average developer can see it. It’s a very different philosophy, one that I think the quote-creator aligns with better than your typical Haskell devotee.

I tend to believe in the value of those magic moments and think we should raise expectations in terms of training and practice to appreciate and understand them (I've never used Finagle so I don't know the specifics of it, maybe it is beyond any reasonable standard of comprehensibility).

The problem is when the magic isn't happening. How do you convince yourself or someone you work with to take off the wizard hat, come down out of the clouds and implement the naive/verbose/ugly solution because the elegant stroke of genius hasn't come and the feature is taking forever?

This is where Go and PHP shine, less temptation to guild the lily.

Stupid nitpick, but I'd prefer to have someone correct me:

s/guild/gild/

Better than gelding it I guess.

> I would argue that Go has been successful largely because everything that’s happening is “out in the open”, where the average developer can see it. It’s a very different philosophy, one that I think the quote-creator aligns with better than your typical Haskell devotee.

This is why I like Go. It makes it difficult to write code that doesn't take basically the same approach any other, similar code would. When you start trying to get abstract or do anything cute, it hurts just enough that you won't do it unless there's an actual need, not just some aesthetic preference.

Consequently, I can hop in to just about any of my dependencies and read them immediately. No, "huh, I haven't seen that language feature before" or "WTF is that symbol even?" or "... but where does it actually do anything?" or "oh great they've imported a library that basically turns it into an entirely different language".

The community's also been really good at avoiding adding abstractions through libraries, so you don't end up with the mess that Javascript had for years with multiple competing Promise libraries in wide use or a dozen competing module systems or any of that crap. There's some experimentation but it rarely gets out of hand.

Well, on the other flip side, with Go you have to type out the same crap over and over again and again.

Scala is not necessarily a detour in this discussion. It's arguably the most functional language among mainstream ones. And for better or worse its ecosystem seems to be influenced by old Haskell hands much more than one would expect. So what we have seen in the last ten years is probably a good proxy for using a real functional language in the industry.

Akka comes to mind as another example of what you said about Finagle. It works great and even has voluminous documentation. But every time I try to click through it in Idea to see how it works I kind of don't see it. This contrast with most other libraries is very real. From speaking to other people I know that I'm not the only one who feels this way. Broadening horizons aside, I'd rather not have production issues with such a codebase.

Personally I don't doubt that Haskell developers are smarter than me. Though I strongly suspect that they come from a hard to reproduce background (PL theory majors? CS postgrads? theoretical physicists?). And not that many companies require this level of sophistication.

There's a huge disconnect I see in the real world. Intellectual bottom scrapers such as JS/golang are increasingly popular. Yes, we see golang catching up with Java ten years later than was necessary but it only confirms the observation. Scala and even Kotlin (F# too?) are not that widely used for how practical they are. In this world I see no place to be found without a looking glass for something as esoteric as Haskell, lazy evaluation and all. And we've had this exact conversation for a decade already.

> The problem really nice abstractions have is that they encode too much into too little code.

Sorry, I don't think I made myself very clear. I wasn't talking about concise code. I was talking about designing your system right, and deciding where you want to set boundaries and what you want to keep flexible. And sometimes: what do you want to encode in types, and what do you want to check at runtime?

Also what properties and invariants do you want your system to have? (See also property based testing.)

Calling all of this a design of abstractions was not the most clear word choice on my part. Sorry for that.

However, to defend a point I didn't make:

Sometimes it does make sense to shorten your code a lot. If you can express your solution in 10% of the lines, it might be worthwhile, even if each line is twice as hard to understand now.

That code might benefit from some explanation, and generous annotations, though. And plenty of properties tested.

> But are they more productive, get shit that we care about done [...]

I think there's a balance to be struck between "getting shit done" and "write something that will be maintainable in the future".

It might be true that (some?) Haskellers overdo it, but I've definitely seen enough of the "let's just get shit done" people who create messes that are completely unmaintainable and full of bugs after just a year or two.

And IMHO, the software industry is in a really sorry state, considering how bug-riddled most software is, how most software projects fail or are considerably above budget, etc. [1]

I've seen quite a number of failed projects in the companies I've been so far, a number of them involving quite a lot of resources. I've seen companies trying to rewrite hopeless messes and failing at it, grinding everything to a halt, because the code base is full of implicit assumptions that nobody bothered to properly specify anywhere. I've read about Shopify spending a whole year to upgrade to a newer version of Ruby on Rails.[2]

Probably the industry doesn't yet know how best to find this balance but I don't think that the Haskellers are solely to blame for this.

[1]: https://danluu.com/everything-is-broken/

[2]: https://shopify.engineering/upgrading-shopify-to-rails-5-0

> This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming)

doing this my whole career has completely, 100% percent been an upside. This removes literally entire classes of bugs. Every time I've moved some check from run-time to compile-time I ended up finding so many cases that were subtly broken and that the compiler will now catch perfectly, until the end of time. I don't understand how it is sane to accept bugs that are automatically preventable.

Yeah I mean there’s definitely a guns and butter curve here: hoisting stuff into templates and using either old-school traits or concepts gets you more compile-time checking (though I’d argue you’re still going to get more from a good static analyzer, which clang-tidy-13 is).

But at some point build times matter. At some point L1i spills matter. At some point TLB spills matter.

I don’t think it’s a knob we should always crank to 11.

> Haskell people skew smarter than most other languages.

In my experience this has nothing to do specifically with Haskell, but more a somewhat-time-varying collection of niche languages. e.g. Haskell roughly equivalent to lisp programmers roughly equivalent to [a few others], but not equally likely to find them 1998/2008/2018 or whatever.

There is a flip side though, which is that a subset of them are not actually good team members. Depending on your project and team scale and role for them this can either not really matter or be deadly.

That's true of any medium-small language, though. I'd argue it isn't true for the smallest of languages, because there's a genre of small languages that are made largely to trap nontechnical people into bad decisions, but it's true for all of the medium-small languages.

Languages that are niche enough to require passion to find and get running average a much better quality programmer, because why wouldn't they? Tesla drivers are, on average, better drivers, because fewer teenagers drive expensive cars. Conlangs have the highest intelligence per speaker, on average, because they require intention to learn. Subscription MMORPGs have the smartest players, because a $15/mo subscription filters out most children. Nearly two decades ago, the guy who made this forum wrote a post about this exact phenomenon with Python, before Python was actually relevant in the industry or had a million resources to learn. Filters work.

You aren't saying something controversial; you're just saying a more limited version of something that everyone already knows because you have tunnel vision. Filter the worst half out, and shockingly, the average looks better. This is a novel idea and you are a genius for coming up with it.

Doesn't Haskell have a bit of an aura that languages of similar size don't? Kinda like how people think you're smart/educated if you study Latin, rather than Old Norse?

Old Norse seems way more linguist-hipster than latin?

However, reading about Haskell makes me feel like sitting in front of a bad university math book throwing hard to pronounce words and proofs at me, when I just want to pass the exam.

Haskell has a reputation because a subset of the community chooses to push a reputation. This is how it works with almost every language.

It actually, to an extent, works to its disadvantage. If a metric becomes a target, it stops being a useful metric, and some of the worst programmers I know have made their way over to Haskell to take advantage of this reputation in the last five years.

The closest "real" languages in TIOBE are ML (a few positions under Haskell) and Scheme (a few above), and both have a pretty similar reputation.

In fairness, the semi-official motto of Haskell is: “Avoid success at all costs.” :)

Every time I see an SPJ quote I always remember that he's working one step removed from video games now and start laughing.

I’m generally a fan of lulz for any reason, and I’ve long since lost track of where SPJ was working (I thought he was still at MSR).

But what’s wrong with video games? That shit is creeping up on the NFL right?

Well, games have a complex reputation.

Are they works of staggering complexity, pushing the limits of what hardware can do, and one of the few examples of software people will actually pay for?

Or are they gigantic mountains of poorly tested hacks, laden with bugs at release, developed under abusive conditions and riddled with DRM, microtransactions and gambling mechanics?

There's lots of different games. Some are both, some are neither. Some are one of the two.

Don't get me wrong, I love video games! Half of my posts on Hacker News are about video games! It's just funny to me to think about how one of the most esteemed members of the FP community is working one step removed from the least-prestigious video game, and was employed directly because of that video game.

I have an absolutely baseless suspicion that "the worst programmers [you] know" are significantly better than the worst ones I've worked with.

The worst ones I've worked with have probably never heard of Haskell, and I would be pretty surprised if they actually managed to write and run a Haskell program that did anything not entirely trivial without someone else helping.

You're probably correct. I've been very lucky to have mostly been around smart people, and so it's likely that the average middling person I come across is, well, just that. Middling status-climbers are still dangerous, though, and still work to ruin averages.

That said, Haskell actually has a lot of great resources available, and I think it is learnable by just about anyone these days. It usually only takes one good book for a language to become available to average people, and Haskell has a great volume of beginner-friendly books. It can be debated as to whether this is a good thing or not, but I think it's always nice to see new pathways into programming become available, even if I'm not necessarily in love with a language.

I might be biased by having worked with Bryan O’Sullivan, but I personally think that RWH has aged fantastically well in the “get practical shit done in Haskell” genre.

“Haskell people skew smarter”.

Well that’s me out. I’ll stick to JavaScript and C#.

Ah that’s not at all what I hoped for with my post.

JS is at its core a Lisp/Smalltalk hybrid, and if you write serious JS you know what “currying” is, whether you call it that or not.

LINQ maps onto a lot of the same math that gets used in Haskell.

I hope I haven’t done some elitist gatekeeping bullshit that discourages people from trying new things.

I’d I did: don’t listen to me, keep trying new things!

Learn some Haskel or Ocaml, and Javascript / C# will seem way more complicated all of a sudden.

> I hope I haven’t done some elitist gatekeeping bullshit that discourages people from trying new things.

Sorry for "saying it out loud", but that's exactly what you did.

This sort of post obviously irks many people. I think the reason is that pros have seen many many dimensions of what "being smarter" means. You can't claim that there is a correlation until you specify on what dimension of 'being smart' you're attempting to correlate against.

Further, it perpetuates this super annoying egotistical myth for a collection of folks: they think that they themselves are much better programmers than everyone around them. When they write crappy code that can't be maintained, it's the team's fault. The team is obviously not up to their level of genius. Etc.

Edit: removed an unnecessary bit for something hopefully more constructive.

Here's a comment in another part of the thread, I see now what the phrase "skewing smarter" means to you: https://news.ycombinator.com/item?id=30258409

I no longer have a horse in the race. I wonder why categorical claims really get the blood moving :)

If anyone blames you for getting fired up by my original phrasing it won’t be me! I thought I was making a drive-by anecdotal observation about a signal I’ve used to work with smarter people than myself, by the time I had read it over once or twice there were like 100 child comments and it was too late to choose more temperate language.

It wasn’t my intention to imply that I was smart personally, rather that of the crazy effective people I’ve had the privilege of working with, Haskell hackers are wildly over-represented in that group.

It's funny that PG's "Blub Paradox"[1] is very close to your post, but harsher and stronger, but rarely draws much push-back when it comes up here, while your post is drawing flames like crazy.

I think PG's post is kinda shitty and is exactly the kind of thing you'd expect to see from someone who's very sure they've got things figured out, but aren't quite as far along their journey as they think they are, while yours is a simple correlational observation that probably has some truth to it (if there's an intellectually-challenging thing that's low-reward, probably the people involved will tend to be pretty smart, since they're just doing it as a hobby or for fun). Yet here we are, in the middle of a fire storm.

I think he's also dispensed exactly the advice you (basically) are, which is that you should choose some nerdy niche language if you want it to be easy to hire smart people cheaply, though I can't find it in a skim of that post and may be imagining it.

[1] http://www.paulgraham.com/avg.html

You’ve just made the original point I hoped to make far better than I made it.

I think I used fairly intemperate language because I feel (rightly or wrongly) this dogma that all engineering problems and all engineers are just k-equivalent and am sort of frustrated by that feeling.

If some shit isn’t so hard that it’s inaccessible to me, then why should I work and study and sweat to be able to solve the N-1 hard problem?

    > worked on one of the biggest production
    > Haskell code bases on Earth

Which one was that?

As he also mentioned he was involved in early React, so maybe Facebook? They are known to use it for spam filtering, amongst other things.

Sigma/Haxl.

Nah this rings true. There's a reason Haskell's killer app is a mobile astrology reader.

Do you put Mensa on your resume?

While I think there's probably some low-range filtering going on with Haskell, I think that only shows that Haskell isn't that fit for writing much production software, since, for all the "smart people" very little has been done with Haskell.

What I think Haskell does attract are people that like to develop overwrought, abstract, and ornate systems. Another reason it hasn't proven to be terribly useful for production software.

I do like the experimental space languages like Haskell play in, and think there is strong net benefit to our field as a whole, by finding ideas that work when brought into that field. So I like people out there mucking around with different programming idioms/domains/approaches.

If I see significant Haskell or Lisp experience on a resume, I tend to be wary.

Come on man, Mensa? I’ve never taken an IQ test and the only pedigree I have is the school (UCSD) that I flunked out of.

I didn’t say that I’m personally a smarty-pants Haskell hacker. I said that those people skew smart and capable.

How come @dang is always there like the Batman spotlight when I stray into ad hominem but I always get smashed with this stuff?

I'm bemused that you think Mensa is such an ad hominem :)

“Do you put Mensa on your resume?” is clearly a personal attack in this context. At least own up to your words.

> "I didn’t say that I’m personally a smarty-pants Haskell hacker."

You didn't? You said serious Haskell programmers are smart and then pointed out that you worked on the largest Haskell codebase on the planet; we were supposed to not conclude that you are smart, but rather that people working on said codebase are non-serious Haskell programmers?

"Nobody likes to talk about it, but we Haskell programmers are smarter than everyone else, especially bickering Javascript plebs" is kinda surprising it hasn't been flagged as flamebait.

I’m a fairly intermediate Haskell programmer at best.

My point about working in a serious industrial setting was that I’ve seen the real deal, up close, and over time.

> What I think Haskell does attract are people that like to develop overwrought, abstract, and ornate systems.

Haha. I'm laughing in move semantics.

C++, Perl, Python, Go, Java -- literally any programming language that some group of people somewhere has grown to a large enough scale is full of complexity. Go is supposed to be "simple" but there is nothing simple about k8s by virtue of being written in Go.

Don't mistake Haskell's jargon, idioms, and ideas for your wilful ignorance. There are a lot of good ideas in Haskell that could benefit most programmers if they took the time to learn them. There's a fast concurrent run-time and great primitives for working with software transactional memory, a fast and advanced type system to help you get feedback on your program interactively and reject more poorly formed programs, immutable data structures and rules for composing them that enable distributing computations safely while making code much easier to manage. There is a lot going on here and it has been slowly adopted into other language ecosystems for decades for a reason.

I understand it's often more work than folks are willing to invest but that's no reason to be so dismissive.

An abstraction in a pragmatic field like engineering is only as good as its utility.

Haskell is unapproachable, and its abstractions are complex. More complex than most engineers actually need. From a utility perspective, these abstractions are bad.

Honestly I spent enough time to dig into Haskell to learn it well enough to make an informed criticism of the language. I ended up sticking around.

I understand there's plenty of jargon and terms that are unfamiliar to a lot of folks but they're not unapproachable or complex (usually). People commonly point to weird words like, "Functor," or, "Monad." It seems insurmountable and complex but if you really dig in and learn what they mean it's infuriatingly simple and practical. I hardly even notice when I'm using them but I can see the pattern in software everywhere (or where they leak because they don't use them).

Our job is abstraction. And good abstractions matter. There's a reason most software these days isn't written in machine language or assembly. And there's a reason why it's incredibly difficult to verify, say the security properties, of software systems in assembly; we use higher-level languages for that work.

Update: The kind of complexity that is bad in my opinion is the incidental kind that is beyond your control. Move semantics and object initializers are an example of a language abstraction that leaks a lot. It's incredibly hard to write a class that works well in all cases and you have to know a lot about what's happening under the abstraction layer in order to avoid the pitfalls of using them. This kind of complexity is everywhere in software, even Haskell in some places. The blast radius for this kind of complexity has been well managed in Haskell though. So it often comes down to what you need.

In my experience using Haskell has let me spend less time working on errors/bugs (no use after free, off-by-ones, no unhandled cases, I can even avoid a lot of threading and shared state issues) and more time focusing on the problems I"m trying to solve.

> Haskell people skew smarter than most other languages. > Sorry for saying it out loud.

You can write good code in any language and likewise with bad code. What does it say about a speaker who makes such surface level and broad sweeping statements about a user based on the tool rather than the user's experience?

At least to me, it smells of unrigorous thinking. It's an unprincipled stereotype that conflates cause and effect.

But how are they able to get anything done when they're spending all their time telling everyone how smart they are? ;-)

> This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming).

I'm not sure why you say this is dicking around as the payoffs for moving things higher up are usually orders of magnitude better

I'd tend to agree. Every time I do any functional programming (which is rare), it leaves me with a 'better way to do this' feeling and a different view on things when I go back to writing a regular OOP language.

On the other hand, I've worked with a lot of C++ programmers, that tend to be a bit smarter than the Java/C# programmers I've worked with. But, and it's a big but, some C++ programmers I've worked with really do have the Dunning Kruger effect. They write what they think is "smart code", but it's really horrifically complex code, that others have mentioned here as too complex for the next guy to easily debug. "If I had more time I'd have written less".

(disclaimer, I clearly suffer from DK based on what I've just written...)

Smart enough to write Haskell.

Not smart enough to realize it’s not pragmatic in most cases.

Or smart enough to figure out how to get a job writing Haskell without publicly begging for one online.

He's smart enough to get one.

He's also smart enough to know he'll get a better one by giving his quest visibility.

> He's also smart enough to know he'll get a better one by giving his quest visibility.

The popularity of a blog post on HN rarely translates into any material gains. At best only serves to boost one’s ego for a day. The next day everything remains the same. Such is the life of someone who seeks validation over the internet.

Parent has a minimum of one serious interview if they want it.

Haskel. For when you have an IQ of 187 but act like it’s 293.

Haskel. Perfect code for a perfect world.

I might put those numbers at like 125 and 140, but your point is taken that there’s a fine line between reality and elitism, and I possibly strayed across it.

There is in fact a difference between chasing the latest fad in serving HTTP requests and trying to do serious computation, but it’s also so much masturbation if nothing useful is getting built.

I was leaning a little heavily into one side of the argument because the other side doesn’t seem to lack for advocates.

It's understandable being anti-intellectual when spelling the thing you're deriding is out of reach.

I think the spelling was on purpose

It is Haskell, not Haskel.

While it is possible to have an intelligence higher that an IQ score of 200 would indicate, the highest IQ score you can get is 200.

The value of Hacker News is proportional to the time and thought contributors put into their contributions, including comments. Please take more time and thought before you comment, or refrain.

for the viewers at home, an IQ of 187 is a one-in-300-million intelligence.

If you, or someone you know, has an IQ of 187, please reach out. I'll let you write whatever language you want, once I spin up a consultancy to rent out your monstrous services.

This/my comment goes against the guidelines by not adding much to the discussion, but as a guy who just stuck my hand in the garbage grinder:

Funniest comment on the thread. :)

Reply on news.ycombinator.com