Hacker News new | past | comments | ask | show | jobs | submit login
I would like a job writing Haskell (plover.com)
405 points by Rerarom 3 months ago | hide | past | favorite | 492 comments



The interesting thing this brings up is whether programming hiring is too specific. Why do we hire reactjs programmers with e-commerce experience instead of react programmers, e-commerce programmers, or programmers?

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.


If the average tenure is 20 years and person A takes 1 month to become effective and person B takes 6 months, then person B has to be 2.1% more productive to be greater ROI. If the average tenure is 1 year then person B has to be 83% more productive for greater ROI.

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


There is no programming job in the world that would take me six months full-time to become effective. Maybe a month, if it's an awful setup in an awful, unfamiliar programming language with unhelpful colleagues. It sounds like you're assuming if you hired a React programmer to work on your React app, it would take that programmer 1 month to get up to speed, while it would take a Haskell programmer 6 months. I claim: if your codebase is complex enough and your situation unusual enough that it would take a React programmer 1 month to write productive React code, the Haskell programmer will take 2 weeks. This is because the vast majority of the learning curve is in your domain and setup, not in how React components work. (Assuming for sake of argument they are actually smarter.)

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


in my experience people should be contributing _something_ within a month, hit a reasonable stride by 6 months, and asymptotically approach full speed extending out to 36 months.

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.


That's my experience as well. If someone is "productive" at their job in a month, then the job is either trivial, or they have a senior dev holding their hand.


I've had a very hard time finding a new job given that my current job doesn't use any kind of "tooling" or outside libraries to get things done, other than rather obscure and domain specific ones (e.g. libgps). Ideally I'd like to pivot to web development given that I have some hobbyist experience with it, but I'm not very good at "specific frameworks".

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?


This is also the reason many companies rewrite code to new framework because they cannot find developers that know how to program in the old framework. Really narrow-minded if you ask me. You just need a good programmer than can easily learn new languages/frameworks. It might take a good programmer a week to learn a new language/framework.


An old job of mine put new employees through two months of bootcamp. The first month was mostly learning the industry idiosyncrasies and the second was role-specific training on the tech stack.

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


I got my current job because I was able to learn a new framework overnight


For an experienced programmer with some frontend experience it only takes a couple of days of studying to learn React well enough to pass an interview. It really isn’t very complicated.

Something like CSS would be much harder to fake.


The problem isn’t Reacts API. It’s the absurd extreme declarative beginner mindset and code style you will be evaluated against. If you have any real experience without React you have to really lie about who you are.


Learn React on your own, put React on your resume, don't claim mastery over it but a vague 'know' or 'learned'. What's to lie about? But sure, it might look better in a professional context instead of just being in the keyword soup. Add at your present place a blurb: 'worked on migrating frontend to React'. You can make this true enough by simply talking to your boss "Hey, why don't we move [our native UI/command line/custom JS] to React?" and getting a "No." If it comes up in an interview, you didn't get very far and it wasn't completed. Your lack of expertise may show up in a test of ability, but then again it may not, interviews are about both sides resolving what's true enough about the resumes and the job description/requirements into what they actually care about.

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.


> extreme declarative beginner mindset

What do you mean by this?


Perhaps they are referring to the fact that unfortunately many “React programmers” don’t have much experience of programming in other contexts, and fall into classic beginner programmer traps of overengineering, overabstraction, etc. It’s similar to the “jquery programmers” of yore.

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.


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


I guess their point is "why don't you go ahead and learn django in 2 weeks, sacrifice a few weekends and nights so you can blow away the easy pitches we're tossing at you during the interview". Pick a web framework and learn it and then you at least have a basis for your claims.


I'm currently working with a C++ dev who has exactly zero previous experience with the web, but because he essentially finished his part of the system, he picked up web-related tasks.

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.


I don't agree with this assumption because of a hidden variable: time.

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.


On any decent size project real senior programmer / architect with years of active product design and development under the belt would beat the crap out of the person who learned to screw size 8 bolt into size 8 nut and been doing this and nothing else for years. And seniority does not come from knowing every last function/class of some 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.


You're arguing against a strawman.

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


Ask someone more experienced to suggest a framework.

Read documentation and implement.


And that takes time.

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.


Have to agree with you there. I started a job using the exact same stack I was using in a hobby project. I had my dev environment fully up in less than two hours and had production ready PRs by noon. On my first day. Then someone got it in their head to rewrite everything in react (2014) and we slowed to an absolute crawl. We never saw the momentum we had pre-react, at least before I moved on two years later.


I'm not so sure. I'm saying they can be efficient with it.

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


I don't agree with the assumption that it takes months and years of practical experience with a framework to be productive within it's codebase. I also don't think the claim was that our candidate would perform at the level of a senior dev.

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


It's not just a framework.

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


Many of the concepts listed above overlap significantly between languages/frameworks/etc. Of course there are always idiosyncrasies, but having experience with one approach will significantly reduce friction when learning the next one.

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.


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

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.


> It seems that they hadn't encountered async programming before and really struggled to get their head around it.

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


This is interesting. Personally I did not need to "encounter" async. At some point I realized that I needed it in my project (it did not have that official name back then) and had written an implementation in a few days. I also written preemptive multithreading library in ancient DOS based product with having zero prior experience. Again took me few days.


And why wasn't someone there to ease him over the culture hurdle? I've taken people who had no idea about Async and baby sat them till it clicked. But left alone it would never have happened. 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.


A combination of bad management (nobody set up that mentoring relationship), and insecurity on their part (I tried to do just that, but they wouldn't accept the help).

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


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

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.


Ok. That's a bit different. Somebody who has been at the company for 7 years should also have the sense to ask around. But you are also right. I've worked with mathematicians and PHD's much smarter in the domain than me who wrote spaghetti code and often couldn't see the point in good code hygiene.


Can confirm, async programming - whether done with callbacks/promises/sugar is tangential here - is a conceptual stumbling block for some at first, and that includes smart programmers who haven't done much in terms of Web or GUI programming. Add the concept of static scoping and closures and you have a few things to absorb first, before you get comfortable. It has to click.

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.


I won’t say someone is good at programming if he/she cannot learn JavaScript in two weeks


I agree, you'd have to be a pretty bad programmer if you can't wrap your head around JavaScript in a couple of weeks. TypeScript even. Also, React. Babel. Grunt. Gulp. NPM. Node. Cobertura. Comfey. JQuery. Angular. Vue. Bootstrap. Flutter. Mocha. Minior. Yarn. Leftpad. Webpack. Npx. JSON. Rest. CORS. XMLHttpRequest. WebSockets. Web Storage. IndexDB.

Actually, I think some of those might be Pokemon.


I've never had the experience that learning a language is harder than learning the culture and (usually bad) tools around it. Stuff like "oh no, I know the official docs say that, but no one does it that way" or "this tool is a 'hip, faster, drop-in replacement' and you'll see it recommended everywhere but the last part is actaully a lie" or "the platform says it supports this language but actually the tools are so broken that it effectively does not" et c.

[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 :-)


Perhaps not in a general sense. But that they were certainly good enough at C++ that my employer was quite happy with their performance at those tasks. They just weren't very good at translating that to areas they were less familiar with.


I've worked with numerous people with PhDs in Physics (and Math and other heavy science fields) and they tend to be pretty awful at production software while at the same time having very strong opinions that the field is "broken". I mean, think about it, 99.99% (at least) of physics and math is learning what has already been solved. It is heavy, complicated learning, but is far from the type of learning you do in a new field like software development.


Non-CS people tend to be completely pragmatic in my experience. They aren't the ones having arguments over the 'art' side of software engineering like everyone else.


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

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.


Alternatively, one could go with a one-person framework [1]. In addition to Rails, I think Phoenix is pushing in that direction. On the JavaScript side, Remix and Blitz are interesting, though I generally don't like the SPA approach. I don't see frameworks in other mainstream languages, such as Django, Spring, or ASP.NET Core, trying to unify front-end and back-end like Rails and Phoenix are.

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


But is it efficient? I would say web programming takes about a decade to become proficient in, after you learned to program. There are so many (perhaps accidental) things to know about the DOM, CSS, HTTP, web standards and practices, interactivity, hosting models, database tech, caching & CDNs, integrations & APIs, and god forbid, any "connect the dots" design and ux work that lands on your table.


Let's just say that we're in a large corporation and the bar is set appropriately.

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


My feeling is a lot of that is driven by recruiters. It's probably a lot easier to sift through dozens of resumes by looking for keywords. It's a bit shit though. There's plenty of jobs I'd like to apply for specifically because they advertise that they use technologies I haven't worked with. I could spend the time trying to convince them I can learn quickly and my other skills make me an asset, but I'm afraid of it being a waste to do so if a lack of "X years experience in Y" trips some red flag.

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 spent my entire job hunt last year, neglecting to apply for positions that interested me, because whether I thought I was capable or performing or not, I know that my resume, basically just a projection of my past experience, would never get me through the resume screening step. Actually in fact, the first few applications I put in never made it past screening and I couldn’t even be mad. It made perfect sense why on paper I’m not qualified.

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.


He's easy to work with. I was a technical reviewer on his book, and not only was he extremely good at communication, he gracefully handled stupid bullshit from me that nobody could reasonably be expected to handle. In terms of interpersonal ability, I think he's head and shoulders above the crowd.


I have looked back at Kragen's review comments from 2002 and they were (as I remembered) unusually thoughtful, detailed, and helpful.

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.


Aw, thanks! I was thinking of the review comments where I was unusually aggressive, detailed, and impatient, and, I should add unreasonably so. I think the fact that to you they only seemed thoughtful, detailed, and helpful speaks volumes about your character.


We tend to get hired for what we've done before, rather than for what we want to do in the future. Although it wasn't always like that for me. For a long time I felt it was totally normal to learn a completely new language for a new job.

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.


Hiring for a particular language/framework/ecosystem combination almost always limits the prospects for the employer. Any seasoned programmer with some C, Python, Java and JavaScript experience can get up to speed with your shiny UI or cloud framework and won't brag about it. The opposite is rarely true. That AWS, Node.js or Blockchain expert can hardly write a Python module in C.


> He's certainly said enough about programming over the years that he shouldn't need a leetcode grilling.

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.


Good programmer can switch niches and will still be a good programmer, there's no doubt about it. Problem is that it still takes some time. You can't just pick up a new language (or even just a new framework) and immediately start producing your best code. It takes time to pick up the style and best practices, and to learn all the nuances. Also very importantly to embrace that new mindset, which can be sometimes hard when you've been doing something in a particular way for long time. There's always that warming up period where you instinctively still try to stick to your habits from the previous language, and you end up with Frankenstein looking code for a while.


There are certainly Haskell jobs in the Bay area. No idea about Philadelphia. MJD doesn't seem to have embarked on a Haskell job search so far, beyond the blog posting announcing his availability. So my bet is that he gets plenty of takers.


The Philadelphia tech job market exists, but...it's not like New York/Boston/SF. The major players are Comcast(...), Vanguard and a smattering of Big Pharma companies. There is a startup scene (most notable success likely being Gopuff), but not a huge one.

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


It really depends on the size and resources of your company. I used to work for a large French ecommerce company where most of the stack was in Clojure and most of the people we hired were totally new to this language and/or were Clojure fans but were new to the ecommerce world. It didn’t really matter as long as they were motivated because we had the resources to train them and give them time to learn.

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 :) ]


I somewhat agree with your point, but the I think software developers underestimate the difficulty in getting someone up to speed when the "tech stack delta" is significant. Every piece of technology you need to learn isn't a linear increase in time, but rather more quadratic. Learning just k8s might take N weeks, and learning Go might take M weeks, but learning k8s and Go at the same time takes more than N+M weeks, and might take something more like N X M weeks (or really 0.1N X 0.1M or something). Learning one tech while also learning another tech makes each more difficult. I push employers to understand this and instead of throwing people into the tech pile, have them hit each tech bit one at a time, but the sink-or-swim belief is strong.


Personality in my opinion and humility are the biggest two things when I care about who my team mates are. If you have more than one hot head you are not going to be happy, they will eventually clash and one or both or more will try to leave. Programming can get frustrating and stressful on its own, why add to the fire?

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.


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

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.


I wonder if it’s a signal of how much their are willing to Invest in people. I’ve been interviewing recently and have seen many companies are explicitly “we don’t care about language exp we will teach you, we want good ppl”.


I've been in the industry for ten years, and this is the first time I hear about asking for things like "e-commerce experience". My CV consists of telecom, e-commerce, fintech, mobility and music industry.

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


I've had an interviewer literally stop the interview to give me career advice when I told him I was a generalist. His advice was that whenever he hears about someone who's a full stack generalist he knows they aren't that good. His advice was to specialize and get really really good at something.

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


Fully agree, the only reason I have some stuff on Github it isn't even for the joy of doing FOSS and contributing to a better world, rather to keep HR happy that I am actually proficient on stuff done as hobby coding.

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.


I cannot answer either the more broad or more specific questions in these threads. But my 2 cents as to:

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


>In my neck of the woods, we generally hire specifically PeopleSoft Programmers, ideally with Payroll experience.

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


I can understand that perspective. There's always a personal and professional decision and tradeoff, ideally done in a conscious and informed manner, of specialization vs generalization.

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.


Why React at all? Is JavaScript really that horrific or does nobody know what they are doing?

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.


you have to fit into the company's software ecosystem, if everyone uses php or python there and you do Haskell it does not matter if you're a MIT PhD that happens to be a Haskell core developer that can rewrite chrome in Haskell in a month, it just does not fit.

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


Unfortunately, a lot falls on networking (the human kind).


The prominent example of gatekeeping is game industry.


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.


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.


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.


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.


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.


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


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


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.


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


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.


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.


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.


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


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


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.


> 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


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.


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.


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


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?


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.


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


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


“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?


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.


Which benchmark is that?



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


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


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


FWIW that ties out closely with my anecdotal experience.


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


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


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


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.


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.


> for a critic that is never expressed

critique?


Thanks, corrected.


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.


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


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.


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


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


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.


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.


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


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


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


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.


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.


> 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


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


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?


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


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


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


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


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.


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


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.


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.


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


Meanwhile, I left a Haskell job for a Go job.

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.


Yep. I wanted a job writing haskell. Got a job writing haskell. It was one of the worst jobs I ever hard (for non-haskell reasons). Team dynamics, culture, how good is a manager, how overengineered is a code base, how easy it is to feel valued and given responsibility. There's so many more important things than the language that now I actively don't care at all. Plus, I think these elitist programming languages attract more jerks so I'd rather avoid anything too niche and go for a Go job or something.


I'm not that sure about "for non-haskell reasons".

Haskell seems to select for people who enjoy going off on puzzling tangents, and it seems like it takes so much learning that for many, meta skills such as good engineering and communication practices fall by the wayside.


> Language isn’t the be-all end-all of a software project.

Certainly not, but at some point you make a move to scratch an itch. Sick of doing typeless python with runtime issues everywhere? A typed language may be a good break from that. Annoyed of Haskell in a company where people care more about their exceptions than about the business? Maybe you'll do the opposite move.

It's not so much about doing things the one right way as experimenting with what makes you productive and happy. And if people find they're comfortable doing that one thing only, good for them.


Same. Left it for job that doesn’t involve Haskell and far happier. Turns out picking jobs based on technology misses other important factors like what the technology is used for and how a workplace treats its people. Now I use technology I’d rather not, but in a super positive environment, and I’m happier than I ever was before.


> Now I use technology I’d rather not, but in a super positive environment, and I’m happier than I ever was before.

I tried that, but knowing the issue your whole team faces or that is putting you in a crunch would have or likely been avoided with a better language was too grating for me.


Agreed on most points there. On the flip side, I was running away from That One Language (Java). I was put off by its verbal diarrhea (when it came to naming classes - blame it on Spring perhaps). And the gratuitous use of OOPs concepts (which I attribute to being a scripter for much of my working life). Perhaps it was more to do with the organization I worked for, it might have been a very (toxic) culture thing that they encouraged - 1) If you didn't know Java you weren't cool. 2) If you didn't know Java you didn't understand OOPs. Lots of companies have such culture issues over languages. Its managers/leadership's job to ensure the tool doesn't become the master, to the detriment of goals.

I've been deliberately been a slow-poke when it came to absorbing languages, far from the bleeding edge within the ecosystem I was in. Hasn't hurt at all. Pushing back on trends (once you're 'inside' a language) means you are looking around, and absorbing more of the problem (business domain).

If you emerge from an old-job into a new-job, and the only take away is bleeding-edge language/platform features, there's some richness of experience that's been missed IMO, maybe its useful at early career stage, but you need to see the whole picture, not just uber details about a language.


I went from Go to Haskell so I could sleep at night.

map[string]interface{}, pervasive null, and lack of sum types kept pager duty ringing.


Agree 100%. I worked in Haskell project too, which overall was fun but it came with many drawbacks.

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

Indeed, I understand personal preferences, but it's hard to work with people who are religious about languages.


> I’ll take a well maintained and well documented Java codebase

I get your point but at some point the boilerplate becomes depression inducing for me, I can't see myself being motivated to work on a Java codebase, the language and the patterns that arise from it just get in the way of solving the problem too much. It's like having to do a relatively easy job but only being allowed to use one hand, it becomes frustrating that you can't use both hands when you see it would take 1/2 effort and then I become even less motivated to work and it's a bad spiral :)


Something similar happened to me. I worked at a job where someone proposed using a purely functional React framework. Ironically I ended up implementing most code and everyone else left eventually so I worked on it alone. People underestimate how non-standard that stuff is. Nowadays I rather avoid using a Functional programming language although I've seen also other companies using or considering pure FP but it's usually a one man army...


Yeah, I recently took a job with a language I don't really know and don't really like. I'm doing it because it's for a beneficial and positive product that I'm happy to improve for customers.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: