To me this guy sounds like he could do anything, just see if he's easy to work with and see if he likes your domain. He's certainly said enough about programming over the years that he shouldn't need a leetcode grilling.

Anyway my point was it can get quite narrow what we look for in a coder when in fact some broad experience might be just what is necessary. For instance I've coded apps for iPhone and Android despite being ostensibly a back end financial trader. I'd think a lot of coders wouldn't want to be siloed into the first thing they get a job in.

Increased job liquidity means employers seek increasingly specific fit above all other considerations.

People vastly overestimate how long it takes a decent programmer to learn new tech.

A lot of the speed a junior, or new person has, is in not considering the things they do not know. If the system is incredibly robust it will just absorb their bad decisions. But in most decisions it means they planted ticking bombs. Often 5 minutes today costs 5 hours in 6+ months time.

If someone were to ask me to sit down and write something in React/Vue.js/whatever on the first interview, I don't think I could without the docs or a tutorial available. I can write JS just fine, I can't write any specific framework, even though I have the mental model and concepts behind how they work and how to use them. So when I see a job that specifically asks for e.g. React, I just don't apply. Same story with companies that ask for Django rather than the more generic "Python web development experience". I could pick up Django within two weeks if you hired me. I know what it is and what MV(C) is. Isn't that enough?

Understandably, this only works at large and established corporations who have enough spare revenue to invest in a dedicated training team.

Something like CSS would be much harder to fake.

And of course if you tried making a short demo as part of the learning, you can show that to the boss/the UI team, and be able to tell more in React terms how (not) far it got, though your current boss might also say "Ok" and now you have a chance to learn it more professionally. Like, that's how a lot of us learn new things -- I wanted to learn property testing, fortunately I didn't have to ask any managers (just a legal/security workflow and pom changes signed off by another team member) to add Java's QuickTheories to my team's test code. After that I used it in a few places, did a casual lunch-and-learn demo on it for the team, used it in various other places over time. I'd put property testing on my resume if a job app needed it, and just be honest that I haven't written nearly as many property tests as unit tests. It's a mindset change to write them, too, and maybe my lack of years and years and thousands of tests would be clear to someone needing such deep expertise. Or not.

What do you mean by this?

This style of react can be pretty weird to “normal” programmers, intolerable even.

Fortunately there are many full stack programmers writing sensible react, I have worked on such teams and had no problems.

I've been in the web development doing all "ends" since I-lost-count-how-many years and even with a library which has rather a small API surface like React, I also need to search things every once in a while. If they don't allow you to do that in an interview, they have unrealistic expectations.

> I could pick up Django within two weeks if you hired me. I know what it is and what MV(C) is. Isn't that enough?

Most of the time, it is enough. There is also an unlikely chance that they have a lot of complexity and need someone who knows the internals and can fix obscure bugs. That probably wouldn't be you for Django/React. I sometimes was that person in the past and it's very stressful so, it's not something a developer would seek to become anyway.

My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program".

I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form.

Even the smartest person on this planet still needs time to learn things.

Someone just starting to use a new environment won't have the months and years of practical experience with the many frameworks and libraries out there. They won't have the battle scars to know out why one library is better than the other one for this specific use case. They won't have the experience to know why structuring the code in this specific way is better than the other way.

And thing about the other myriad gotchas every environment has, that someone only picks up over time, as they try to use all the corners of a specific software stack.

I mean, yeah, sure, a smart dev will look up best practices and carry over some of their existing experience, but unless they're a true polyglot (and that takes many years as you probably need at least 1 super intense year with each or more like 2-3 years with several), they will still be a solid mid level dev, but not a true senior dev using the new framework.

Personally I've never had problem doing project in new languages and had never have client making a point out of it. They just look at the references and products I've completed personally or as the lead. But those clients are business with real needs and problems to solve. Not architecture astronauts who would go to holy wars over things that do not matter much in real world.

On one side you pit a "real senior programmer /architect with years of active product design and development under the belt" and on the other side "person who learned to screw size 8 bolt into size 8 nut and been doing this and nothing else for years".

My point is that for this situation:

* person A (truly senior polyglot developer just now starting to use a specific stack)

* person B (truly senior developer with experience primarily in that specific stack, all other things being equal)

Person B will smoke person A at the start of the project, since they're already ramped up. Person A will have to learn, that's why we call it "ramping up".

Read documentation and implement.

If you're telling me that anyone can be as good as someone else who is equally smart but with 2-3 years of experience with that specific tech stack, I'd say that can't be true, almost by definition.

More efficient than a jr with 1-2 experience in it for example. ( If the implementer that is new knows multiple languages and there isn't a fundamental big difference ( eg. the new language is functional))

But to your point. Yes, experience is critical for mastering a skill.

It's a new language. Syntax, semantics, common patterns, high level approaches to things (you could call this culture).

It's a new VM (possibly) or compiler.

It's a myriad of libraries.

It's operational tools around the main tech stack (debugger, tracing/performance tools, deployment tools, logging tools/frameworks, etc).

To truly master a mature software stack takes years. Yes, a smart and experienced dev can hack their way around with the help of an experienced team, but the real test will be when the same dev looks at their own code from the start.

Though even that's not a sure thing, because if it's one thing developers have plenty of, it's hubris. Sometimes it helps, but many times it doesn't.

> I also don't think the claim was that our candidate would perform at the level of a senior dev.

No, the claim was even funnier, that the candidate will be a competent developer because he has a PhD in physics (a field somewhat related to software engineering, if you squint really hard, but not really).

But more importantly, you also don't need to very much about the above if your goal is just to reach competency. My understanding is the OP was claiming the candidate will be competent because "he knows how to program". Now that may mean anything from "candidate has written a python script to display a graph once" to "candidate is the lead dev of our game engine".

If the former, then of course, yes, they would likely struggle a little bit at first (though I would expect competency within hours -- many frameworks, as part of their core design, aim to reduce time-to-competency). If the latter, give them a brief overview of the system architecture, point them at the docs, hand them a ticket, pat them on the back and walk away.

I don't doubt that they guy you work with is excellent and is able to seamlessly make this switch, but I have previously worked with someone who was excellent at C++, and had a PhD in something maths related (can't remember what exactly), and completely failed to get anywhere with JavaScript. As in: took 2 weeks to write a script that would take me a couple of hours, and it was still in a pretty bad state at that point.

It seems that they hadn't encountered async programming before and really struggled to get their head around it. The silly thing is their program didn't actually require any concurrency so they could just have stuck an `await` on each async function call and treated it like synchronous code, but they were convinced that async-await was too complicated to learn up front so they had a complete mess tracking everything with callbacks.

Seems totally normal. And most likely, after a few weeks this person would get the concept.

> New hires should not just be thrown a task, left alone and then be slandered two weeks later on hacker News when they get it wrong.

They were certainly not a new hire (they'd been at the company 7 years - if anything I was the new hire!), but I generally agree. My point was merely that while some people will easily transfer their skills to different languages and domains, this won't be true of everyone.

That tends to make it harder. I've experienced quite a few people more "senior" than me (either age-wise or company-tenure-wise or both) who had trouble having the less-senior guy telling them things like suggesting different designs or code refactors. Some things were just not obvious why my suggestions were better, but they were based on experience with this particular technology. So they preferred to ignore the advice and run into the issues I and other colleagues had run into 3 years prior cause they didn't want to listen. Sadly, they didn't always have to live with the consequences since some of them moved on before the consequences became obvious, so we had to clean up the mess we were suggesting against in the first place.

Reminds me of stochastics in school, which was a subject that wasn't immediately natural for some who were otherwise very good at math in general.

For me it's bit fiddling for example: I bought Hacker's Delight some months ago and first had to really work through even the most basic things on paper until it stopped to feel like magical hieroglyphs.

Actually, I think some of those might be Pokemon.

[EDIT] I had in mind Android, Yarn, and AWS Lambda + Java (as of a couple years ago, anyway), in order, for those examples, for the curious :-)

That’s seems an off-axis question to me. “These devs are expensive and a constraint on our growth. I want to hear more tappy-tappy…”

What’s the alternative if you have a good backend programmer and an excess of front-end work at the moment? Have the backend plow further ahead? Move items that “belong” in the front-end to the backend just for dev capacity reasons? Decide your architecture based on which devs are free in a given sprint?

That backend dev might be 50% as efficient and still result in more total value delivered.

[1]: https://world.hey.com/dhh/the-one-person-framework-711e6318

His tasks are currently backend-ish(still TypeScript though). I wouldn't throw anyone into the deep waters of frontend unprepared.

As an aside, advertisements for developer positions need some sort of intervention. I'm tired of not knowing who the company is ("Exciting opportunity with growing startup in the whatever space!"). I also see things like "experience with object-oriented programming required". These days that's like saying "we're looking for a driver who has experience with steering wheels" and really puts me off.

I could probably find a way to make myself look qualified, but it’s be a lot of work and frankly, I haven’t had the drive or passion for programming required to do that for years. Probably just easier to quit and find some new career at this point.

I sent him a more detailed message about this but I wanted to have it on the record here.

Kragen: Thanks for your kind words. I am happy to know that you found me easy to work with.

My first job was Visual C++, my second job was Java and XSLT, my third job was Ruby, my fourth was Groovy with some Java and Ruby. Then after some more Java and Ruby, I ended up in Javascript + Angular, then Typescript + Vue, now Typescript + React.

I feel like I'm fairly lucky in that I at least still get to hop frameworks; there are tons of people who've been doing Java+Spring for 20 years now. I wouldn't mind moving to Kotlin or Scala, but that's hard to find. At least for me; most recruiters still look at what I did in the past, and they see a lot of Java, so they assume that's what I do.

If the purpose of the test were to evaluate the applicant’s technical ability, then this would be true.

I’ll lay odds that is not the purpose of the testing, though.

Thankfully, the remote situation has improved dramatically, so I agree, they should be ok :)

I left ~1 year ago to join a very early-stage startup where we’re currently 5, and while I would love to hire people that don’t master at least most of the stack we use, I just can’t because we really don’t have the resources to afford to have someone spending time (their time and also other people time) learning everything. This probably an extreme example but it illustrates the point: even if you’d like to hire people in a broader spectrum, you can’t always afford to. [ I hope that at one point we’ll be able to do it :) ]

People learn to program over time. You want to resolve bugs the sooner the better, if you spend all day arguing or you’re working with one of those “its not my code my code is perfect” types you’re going to have to do more work to get things moving. People who think they know it all can hold you back, some devs are great at some things at the same time some at others. Find a nicely balanced team that can work together.

We do hire less specialized programmers, we just don't pay them at the scale that someone with 30 years of experience might expect. If the job really needs someone that knows a specific tech immediately then the expectation is that a candidate has at least pursued a decent amount self-learning, which for someone with 30 years of experience should be easy to do in a couple of weeks. (The author here has done that*) All else being equal we still wouldn't pay them the same as someone with 5-10 in that specific tech though.

Is it really like that somewhere? In the US, or in particular domains, or in particular technology space? If it matters, I've mostly been working with JVM, but two quite different paradigms - Java (OOP) and Scala (pure FP; I understand everything the haskell guy talks about).

Keep in mind I'm super senior. Much older than most people in this industry.

However that is something that most families cannot manage, and one cannot be expected to create portfolios on SCM of the year just to prove their skillset.

"Why do we hire reactjs programmers with e-commerce experience instead of react programmers, e-commerce programmers, or programmers?"

In my neck of the woods, we generally hire specifically PeopleSoft Programmers, ideally with Payroll experience. Here's why:

1. First and foremost, developers need to do more than spit out code. They need to thoroughly understand business problems, work with business analysts and product owners to hash out requirements, be able to meaningfully discuss these requirements, create design that they can independently sanity-check meets these requirements, and then work on translating it into code. 2. They need PeopleSoft experience and knowledge - it's a specific ecosystem and language with specific requirements and constraints and capabilities. Programmer needs to fully understand these early on when they discuss requirements and solution with business.

3. Payroll experience helps, again for them to be able to discuss things meaningfully with the business.

I know that this ("Dev needs to be able to gather requirements") is self-evidently true across development world, but I want to underline that our developers can meaningfully discuss intricacies of Canadian and Provincial tax code, payroll processes and regulations, time and labour, benefits, pension, and other adjustments with their functional counterparts; while also having meaningful discussions with our DBA & Infra teams on indexes, stats, etc. All in the specific world of PeopleSoft where code resides in database, with specific component processor which offers about 30 different ways to trigger code on a page, while ensuring data integrity etc.

With that in mind, historically, it's just as easy and perhaps easier/faster/cheaper, to train a new grad (and we do, a lot!), rather than get somebody experienced in a completely different ecosystem and try to retrain them.

Now, PeopleSoft is a very specific (quirky, legacy, idiosyncratic, crazy, etc) ecosystem, but I think using it as an extreme example may show some of the core reasons why even in less extreme environments, requirements are fairly specific. Yes, a good programmer with wide experience has a lot of skills. But by numbers, I think most devs work in business areas with specific set of common industry/sector problems and solutions, which reward specialization.

I can see why that works for the employer but as an employee I would be terrified of that becoming a career dead end.

My world is drastically different than the mean HN poster I think; but I'm fairly convinced that by number of people it employs, it may be the more common one. There's just a lot of boring but eternal business applications out there.

FWIW, I've been a "PeopleSoft person" for 25 years now. So from that perspective I'm specialized, but I would not call it a dead end. In that time I've also worked with Windows Linux AIX HP-UP; with DB2 on mainframe and unix, Oracle on Unix and Windows, even MS-SQL once. On premise, hosted, and now even cloudy. Done development, database administration, system administration, upgrades, performance testing and tuning, data disaster recovery, infrastructure architecture, etc. So I've led a wonderfully diverse, interesting, challenging and satisfying career - inside a very specific niche ecosystem :) . Around me are respected professionals with DEEP and profound understanding of that ecosystem, who do their job exceptionally well, consistently deliver client value, and most of us find our own kind of variety. None of us feel "exploited by the employer", for what it's worth (I have fair control of my career and direction), and are generally satisfied with our chosen lot in life.

I suspect the goal is to widen candidate availability to the maximum, cast the widest net. I find this odd because compensation is now absurd competence, experience, and product quality be damned.

That been said, there are definitely companies need Haskell developers, it just has less positions for a smaller pool of developers.

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.

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.

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.

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.

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

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.

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

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

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

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.

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

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

Good for him.

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.

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.

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.

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.

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

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

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

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.

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.

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?

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.

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?

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

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.

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.

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

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.

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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

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

   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.

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

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.

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.

critique?

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

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.

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.

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.

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

I said “X.”

I screwed that up.

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.

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.

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

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 meant that solving a problem in Haskell can often mean eg writing something a bit like a parser.

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.

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

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

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

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.

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.

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.

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.

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.

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.

s/guild/gild/

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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?

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

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!

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

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?

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.

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

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.

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

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.

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.

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

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.

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?

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.

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

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.

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

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

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.

Language isn’t the be-all end-all of a software project. I’ll take a well maintained and well documented Java codebase over a write-only Haskell codebase with more lines of language extension imports than lines of comments.

Software developers who only look for jobs always in That One Language freak me out.