I would like a job writing Haskell(blog.plover.com)
blog.plover.com
I would like a job writing Haskell
https://blog.plover.com/2022/02/07/
506 comments
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.
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.
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.
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?
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.
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.
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.
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?
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.
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'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.
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.
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.
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".
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.
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.
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))
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.
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).
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.
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.
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.
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.
> 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.
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.
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.
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 :-)
[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.
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
[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.
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.
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.
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.
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.
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.
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 :)
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 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.
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.
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).
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.
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.
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.
"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 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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
> 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"...
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.
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:(
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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?
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.
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?
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.
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.
[deleted]
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.
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.
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.
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 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.
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 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 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.
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.
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.
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.
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.
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...
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.
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.
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. 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.
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.
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?
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.
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.
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’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.
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 ;)
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.
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...
So yes! You can use higher kinded types in rust. Whether you should I will
leave up to you. But it certainly doesn't seem like a very attractive option
for most projects considering the syntactic noise of the implementation, a
typechecker that gets often confused and requires help, as well as error
messages that don't make much sense. Especially the last is a shame since
extremely helpful error messages is what rust is known for, and I
wholeheartedly agree (under normal circumstances).
Yes, But Why, Really?
Because sometimes one just gets homesick for Haskell and wants to implement
the Functor hierarchy. You'll find this in the higher-cat crate. It's not
really very suited for writing good Rust code, but it makes Haskell
programmers feel happy and it has a lot of funny words.
A proposal for an addition to Rust, to get generic monads and (Haskell-like) do-notation for them:
https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in...
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.
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.
Unfortunately pure FPs without typeclasses like Elm seem to be too boilerplatey for me.
F# may get around it by offering imperative and OO capabilities?
Overall I wanted to love pure FPs but I really appreciate Typescript and C# these days even though I tried with Haskell.
With Haskell you want to use a web library there are loads of programming language concepts that framework uses that you need to grok. With C# etc. you learn the language much quicker and libraries are way more “uniform” with nothing too fancy going on.
In my book this doesn’t seem controversial.
(As for me, I haven’t written one line of Haskell. Might never do.)
Another thing I believe: Most (but probably not all) projects are better off not using Haskell.
(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.
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.
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.
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 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.
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 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.)
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.
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.
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.
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.
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%.
Yes, there were some smart people forced to use it. But they were perhaps enough to drive up the top 2%, not so much the top 10%.
>Haskell people skew smarter than most other languages.
But are they more productive, get shit that we care about done, or do they go down monadic rabbit holes?
By all means Haskell away in your pet projects, but having a company invest into a team to deliver things customers want, I'd like to see some evidence this makes sense outside specific niche areas (Cardarno possibly being a good example where it makes sense).
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.”
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.
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.
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. 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.
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.
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.
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.
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.
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
I think there's a balance to be struck between "getting shit done" and "write something that will be maintainable in the future".
It might be true that (some?) Haskellers overdo it, but I've definitely seen enough of the "let's just get shit done" people who create messes that are completely unmaintainable and full of bugs after just a year or two.
And IMHO, the software industry is in a really sorry state, considering how bug-riddled most software is, how most software projects fail or are considerably above budget, etc. [1]
I've seen quite a number of failed projects in the companies I've been so far, a number of them involving quite a lot of resources. I've seen companies trying to rewrite hopeless messes and failing at it, grinding everything to a halt, because the code base is full of implicit assumptions that nobody bothered to properly specify anywhere. I've read about Shopify spending a whole year to upgrade to a newer version of Ruby on Rails.[2]
Probably the industry doesn't yet know how best to find this balance but I don't think that the Haskellers are solely to blame for this.
[1]: https://danluu.com/everything-is-broken/
[2]: https://shopify.engineering/upgrading-shopify-to-rails-5-0
> This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming)
doing this my whole career has completely, 100% percent been an upside. This removes literally entire classes of bugs. Every time I've moved some check from run-time to compile-time I ended up finding so many cases that were subtly broken and that the compiler will now catch perfectly, until the end of time. I don't understand how it is sane to accept bugs that are automatically preventable.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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”.
Well that’s me out. I’ll stick to JavaScript and C#.
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!
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
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 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.
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 :)
I no longer have a horse in the race. I wonder why categorical claims really get the blood moving :)
If anyone blames you for getting fired up by my original phrasing it won’t be me! I thought I was making a drive-by anecdotal observation about a signal I’ve used to work with smarter people than myself, by the time I had read it over once or twice there were like 100 child comments and it was too late to choose more temperate language.
It wasn’t my intention to imply that I was smart personally, rather that of the crazy effective people I’ve had the privilege of working with, Haskell hackers are wildly over-represented in that group.
It 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
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.
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.
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.
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.
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. 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.
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.
My point about working in a serious industrial setting was that I’ve seen the real deal, up close, and over time.
0des(1)
> 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.
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'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...)
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.
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.
> 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.
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.
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.
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.
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.
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. :)
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.
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.
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.
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.
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'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.
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.
> 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 :)
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.
I was once in the position of Mark Dominus. I had spent years of using Haskell for recreational programming and wrote a book using the subset of Haskell that I personally use (you can get a free copy at https://leanpub.com/u/markwatson by setting the price to free).
About six years ago I decided to apply for Haskell jobs at Standard Charter and Facebook on Haskell teams with well known people in the field. Both groups said that I was an interesting candidate and suggested getting another Haskell job for a while, and then reapplying. I did end up consulting remotely for a startup in India writing Haskell but that job was short (about 6 weeks) because I was in the process of getting hired at Capital One to manage a deep learning team.
About six years ago I decided to apply for Haskell jobs at Standard Charter and Facebook on Haskell teams with well known people in the field. Both groups said that I was an interesting candidate and suggested getting another Haskell job for a while, and then reapplying. I did end up consulting remotely for a startup in India writing Haskell but that job was short (about 6 weeks) because I was in the process of getting hired at Capital One to manage a deep learning team.
Wow, this thread really exploded! My 2 cents on Haskell, since we're building https://wasp-lang.dev/ in it and also just hired several founding engineers:
- we're sticking with the "Boring Haskell" manifesto(https://www.snoyman.com/blog/2019/11/boring-haskell-manifest...) - using only the widely adopted compiler plugins and not going too crazy with the monad transformer stack, which keeps the code easy for others to contribute to.
- we've hired 2 founding engineers so far - none of them knew Haskell beforehand! But they were both senior engs well versed in different languages and I was surprised with how quickly they picked it up - within the first month they are at 90% productivity.
- we're sticking with the "Boring Haskell" manifesto(https://www.snoyman.com/blog/2019/11/boring-haskell-manifest...) - using only the widely adopted compiler plugins and not going too crazy with the monad transformer stack, which keeps the code easy for others to contribute to.
- we've hired 2 founding engineers so far - none of them knew Haskell beforehand! But they were both senior engs well versed in different languages and I was surprised with how quickly they picked it up - within the first month they are at 90% productivity.
That doesn't bode well for the rest of us if someone this accomplished can't land a Haskell job. This makes me wonder if it's been worth learning functional programming. I've put hours and hours of my free time into F#. I'm not sure that it was a wise move. That said I love F#.
> I've put hours and hours of my free time into F#
It can't be worse than playing video games or watching tv shows.
Seriously, this is never lost. The more languages/paradigms we know, the easier it gets to learn new languages. I think it's a good investment.
It can't be worse than playing video games or watching tv shows.
Seriously, this is never lost. The more languages/paradigms we know, the easier it gets to learn new languages. I think it's a good investment.
Pro gamers and TV critics are rolling their eyes. =D
I feel like in this day and age, you can be successful at anything if you put in enough hours. Key is probably in being active and critical instead of being mindless.
I feel like in this day and age, you can be successful at anything if you put in enough hours. Key is probably in being active and critical instead of being mindless.
You could argue that if you see an activity as an investment, by definition it is NOT free time?
The counter argument could be that this defines free time as measured by its opportunity cost against something else, and not as just what you enjoy. I tell people all the time that what I'm doing isn't procrastination, it's sacrifice.
I think getting to grips with Haskell and the like is worth it even if you are not going to end up using it day to day.
In the pst I have been running a program where I was introducing devs to Haskell (immutable data, purism and quickcheck lostly) and then watching how their code evolved in their classical language projects. Over all it always was a great benefit.
Still, I think our industry is seriously behind in the adoption curve of pure force languages. It is mindblowing really that important software is still mainly written in Java C and the likes…
Still, I think our industry is seriously behind in the adoption curve of pure force languages. It is mindblowing really that important software is still mainly written in Java C and the likes…
Haskell makes you think about code composition.
My Java skills (and object composition) has changed drastically after reading about Haskell.
[java8+, of course]
> That doesn't bode well for the rest of us if someone this accomplished can't land a Haskell job.
As an opposite experience, we're currently hiring someone with no experience to do haskell and purescript. The key here is that there are few haskell companies, but also few haskellers: companies have trouble finding haskellers just like haskellers have trouble finding companies. While most of the work in a traditional tech company receives lots of CVs, we typically experience the opposite, where it's hard to find many people to apply.
As an opposite experience, we're currently hiring someone with no experience to do haskell and purescript. The key here is that there are few haskell companies, but also few haskellers: companies have trouble finding haskellers just like haskellers have trouble finding companies. While most of the work in a traditional tech company receives lots of CVs, we typically experience the opposite, where it's hard to find many people to apply.
I learned Haskell because I love programming and it was fun. If you enjoyed learning F# then your time was not wasted :)
Yeah you're not wrong it's loads of fun
Finding "F# jobs" is a lot easier in my experience, due to easy interop with C#. Many places using .Net or C# are willing to let you use F# in places if you can convince them it makes sense.
As to the question of it being "worth it". I learnt more about becoming a better programmer by learning Haskell than probably any other single thing I've done. And while I've never written Haskell professionally and haven't used Haskell in probably a decade, I use many of the concepts and principles I discovered via Haskell almost every day.
As to the question of it being "worth it". I learnt more about becoming a better programmer by learning Haskell than probably any other single thing I've done. And while I've never written Haskell professionally and haven't used Haskell in probably a decade, I use many of the concepts and principles I discovered via Haskell almost every day.
Only if other people at the company can maintain F#, though - interoperability is importnnt, yes, but experienced managers will want to plan for the time after you are gone.
[deleted]
F# means Windows right? That is a pretty big turn off for some of us. Ocaml seems perfectly nice though.
F# means Windows right?
In theory no, as F# runs perfectly fine on Linux. In practice all real world uses of F# in paying jobs I've seen has been Windows. The big advantage however is that there are probably at least an order of magnitude more F# jobs than Ocaml jobs.
In theory no, as F# runs perfectly fine on Linux. In practice all real world uses of F# in paying jobs I've seen has been Windows. The big advantage however is that there are probably at least an order of magnitude more F# jobs than Ocaml jobs.
F# runs on .Net Core, which in turn runs near perfectly on Linux (incl Alpine). The runtime is about 50MB these days, so coupled with alpine or a minimal ubuntu server, you can squeeze a lot out of .net. F# is slightly slower than C# in some ways but in most cases you won't notice it and it brings a lot more to the table. I honestly wish most C# devs would start using F# for everything by default except the GUI layer, which C# makes more sense. If you are doing purely api/backend stuff, F# can be sharp knife you are looking for on linux.
Yup, and even on Linux setup is faster / easier than say Ocaml.
With decent (neo)vim support!
With decent (neo)vim support!
We hire F# dev. You can work on whatever OS suits you need as long as you can maintain it. If most of my colleagues are windows users, more and more are switching to tux. (mandatory, I use arch btw). Thank you dotnet core.
https://news.ycombinator.com/item?id=30165023
https://news.ycombinator.com/item?id=30165023
As for my company, we use F# in many platforms (iOS, macOS, Android, Linux, Windows), and in the server only in Linux (ubuntu).
It's fine/great on dotnet core.
Actually it's the old .NET was windows only, new .NET is cross platform, since June 2017.
So F# is cross-platform.
So F# is cross-platform.
Thanks everyone, I might give F# a try.
Loads of F# jobs advertise as “.NET” or “C# with an interest in functional programming” since they want to encourage strong C# developers to apply.
Seriously, F# is used a lot more than you might think in the financial world!
Seriously, F# is used a lot more than you might think in the financial world!
There's a big difference between Haskell and F#. I like F# because I can get messy and impure if I want to. I've only written a little Haskell but it seems very much the opposite - its has to be perfect or else it doesn't even compile.
Businesses generally aren't looking for perfect code. They want code that does the job well enough, that others can maintain, and they want it done fast. Haskell doesn't seem great for that, the people who can actually crank it out fast/well enough seem quite few in number. In most cases, as a business, you don't want to have an IQ minimum of 140 for people to be able to maintain and extend your code (exception for safety critical software of course).
F# has the potential to be suitable for more businesses, the skill floor is lower, and when the going gets tough you can just take on the technical debut and f**ing hack it - and someone else will be able to understand the hacks.
Businesses generally aren't looking for perfect code. They want code that does the job well enough, that others can maintain, and they want it done fast. Haskell doesn't seem great for that, the people who can actually crank it out fast/well enough seem quite few in number. In most cases, as a business, you don't want to have an IQ minimum of 140 for people to be able to maintain and extend your code (exception for safety critical software of course).
F# has the potential to be suitable for more businesses, the skill floor is lower, and when the going gets tough you can just take on the technical debut and f**ing hack it - and someone else will be able to understand the hacks.
I would disagree, but only a bit.
>Businesses generally aren't looking for perfect code.
Mostly you don't want that, but there are a few industries where its jackpot. For instance building some state control engine for rockets etc. Also Haskell does not force you to write perfect code, but forces you to write code that is considering all the possible outcomes, so even if you handwave some stuff it will be pretty clear to everyone reading you handwaved some stuff.
>Businesses generally aren't looking for perfect code.
Mostly you don't want that, but there are a few industries where its jackpot. For instance building some state control engine for rockets etc. Also Haskell does not force you to write perfect code, but forces you to write code that is considering all the possible outcomes, so even if you handwave some stuff it will be pretty clear to everyone reading you handwaved some stuff.
> For instance building some state control engine for rockets etc.
Just out of curiosity: are there companies actually writing mission-critical code in a Haskell? My impression is that those normally tend to get written in C++ and the like.
Just out of curiosity: are there companies actually writing mission-critical code in a Haskell? My impression is that those normally tend to get written in C++ and the like.
> Ogma, a new open-source NASA tool, written in Haskell, to generate hard-realtime C runtime monitoring applications from high-level specifications
https://www.reddit.com/r/haskell/comments/r80djm/ann_nasas_o...
https://www.reddit.com/r/haskell/comments/r80djm/ann_nasas_o...
Even if you don't use F# directly, you might apply something you learned when reasoning about any problem, or coming up with more elegant solutions.
Also, having the discipline to study to improve your skills, will most definitely be beneficial in other spheres of your life.
Also, having the discipline to study to improve your skills, will most definitely be beneficial in other spheres of your life.
We are hiring F# developers: https://news.ycombinator.com/item?id=30165023
Is it because they might be overqualified, so any company that happens to do haskell (which I can imagine aren't many) are intimidated?
I mean how many people here, currently working in language X, would want to hire someone that is better than they are? I mean rationally it makes sense - bette for the company, learning opportunities, etc, but emotionally it would seriously piss me off if someone came swooping in and basically made me obsolete and look stupid. (I'm not saying the author of the article would do so, I'm just speaking in general and thinking up hypothetical scenarios)
I mean how many people here, currently working in language X, would want to hire someone that is better than they are? I mean rationally it makes sense - bette for the company, learning opportunities, etc, but emotionally it would seriously piss me off if someone came swooping in and basically made me obsolete and look stupid. (I'm not saying the author of the article would do so, I'm just speaking in general and thinking up hypothetical scenarios)
That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success.
But the main reason, at least in my 20+ year career in my industry, is that it simply doesn't have a track record of success. Haskell isn't remotely new. It was mainstream in academia when I was at university and since then I've seen multiple attempts at adopting it in a large scale commercial setting. I've seen a couple of successes, on small, well defined projects that were relatively "academic" in nature (i.e. the challenges were in the comp-sci type aspects rather than the engineering, and the interactions with other systems were minimal). I've seen more failures, projects with lofty goals that went nowhere. F# has been more successful, and I've seen some significant infrastructure built with it, but it's certainly not proven itself superior to the alternatives (in an industry where successful solutions always get mimicked).
Basically, it's 2022. People have tried it and it hasn't worked out.
But the main reason, at least in my 20+ year career in my industry, is that it simply doesn't have a track record of success. Haskell isn't remotely new. It was mainstream in academia when I was at university and since then I've seen multiple attempts at adopting it in a large scale commercial setting. I've seen a couple of successes, on small, well defined projects that were relatively "academic" in nature (i.e. the challenges were in the comp-sci type aspects rather than the engineering, and the interactions with other systems were minimal). I've seen more failures, projects with lofty goals that went nowhere. F# has been more successful, and I've seen some significant infrastructure built with it, but it's certainly not proven itself superior to the alternatives (in an industry where successful solutions always get mimicked).
Basically, it's 2022. People have tried it and it hasn't worked out.
> That attitude among Haskell devs is one of the problems. The conviction that it is a fundamentally better way of programming and that anybody who chooses anything else for anything is a worse programmer certainly hampers its success.
This is not true in my experience; and I have been professionally writing Haskell for over a decade. It is well understood that Haskell is excellent for reasoning about program correctness, but rather poor for reasoning about program performance/efficiency, especially memory usage. What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?). There are many domains for which correctness and productivity are important, but performance/efficiency less so. Haskell is still much more performant than many dynamic languages are.
OCaml is a nice middle ground, lots of functional goodness and type safety with a much more predictable runtime.
This is not true in my experience; and I have been professionally writing Haskell for over a decade. It is well understood that Haskell is excellent for reasoning about program correctness, but rather poor for reasoning about program performance/efficiency, especially memory usage. What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?). There are many domains for which correctness and productivity are important, but performance/efficiency less so. Haskell is still much more performant than many dynamic languages are.
OCaml is a nice middle ground, lots of functional goodness and type safety with a much more predictable runtime.
> What Haskell programmers might get frustrated about is less suitable tools used for domains for which Haskell would be an excellent fit (smart contracts?)
Haskell actually is used for smart contracts on Cardano (which is also written in Haskell): https://github.com/input-output-hk
They haven't been very "successful" yet in the sense of mass adoption (even as far as smart contracts go, EVM-based dapps have multiples more users), but I think this is because of design choices in how the blockchain works moreso than using Haskell for implementation, which limit the usability right now.
Haskell actually is used for smart contracts on Cardano (which is also written in Haskell): https://github.com/input-output-hk
They haven't been very "successful" yet in the sense of mass adoption (even as far as smart contracts go, EVM-based dapps have multiples more users), but I think this is because of design choices in how the blockchain works moreso than using Haskell for implementation, which limit the usability right now.
According to Messari Cardano oscillates between 2nd/3rd most active crypto
https://messari.io/screener/most-active-chains-DB01F96B
Given the head start for Ethereum I would call this very successful in terms of adoption.
https://messari.io/screener/most-active-chains-DB01F96B
Given the head start for Ethereum I would call this very successful in terms of adoption.
Ethereum and EVM compatible chains are at least 4 years ahead in terms of smart contract activity. Cardano just enabled smart contracts in September of last year, and there's been very little success in terms of usability so far; network scaling upgrades are slated to roll out over the next few years, and the dapps that have deployed don't really work without them. For context, Sundaeswap, a long-awaited DEX just deployed roughly 1 week ago, but people trying to make swaps may have to wait days for their swap to execute, which isn't very ergonomic.
The increased activity from people trying to make transactions with Sundaeswap has resulted in sluggishness all-around on the chain as well, because Cardano doesn't have the concept of gas bidding for priority
The increased activity from people trying to make transactions with Sundaeswap has resulted in sluggishness all-around on the chain as well, because Cardano doesn't have the concept of gas bidding for priority
I was replying to a comment that explicitly described Haskell programmers as "better" than other programmers and implied they make them "look stupid". I'd certainly expect anyone with some maturity and common sense to have a more nuanced view, but this attitude is expressed commonly enough that I think it does have an impact on perceptions.
I have similar opinions on Scala, lots of theory that it makes things better, but the only measurable difference is that its a nightmare to hire for, more expensive and we often have to invest time training people ... who then leave to become contractors.
I'm not anti functional or Scala, but I'm yet to see any reports etc that actually indicate there is a pay off.
I'm not anti functional or Scala, but I'm yet to see any reports etc that actually indicate there is a pay off.
There are two flavors of Scala and only one of them is about cats/scalaz. I feel intellectually inferior to people who use the latter in production. But I don't think anymore it's a reasonable aspiration to become one of them. And maven builds Scala projects equally well (with half a screen of XML) and without any SBT complexity.
I have not seen Bay Area companies where previous Scala experience counts for more than inviting me to an interview. In my current team I know multiple developers who'd like to have more Scala and Java developers who don't know Scala or even Kotlin.
I have not seen Bay Area companies where previous Scala experience counts for more than inviting me to an interview. In my current team I know multiple developers who'd like to have more Scala and Java developers who don't know Scala or even Kotlin.
I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java.
The underlying issue is that it's a complex language with many experimental and interacting features, which can and do cause a lot of distraction. This is not the fault of functional programming. Have a go at OCaml or F#, which are nice practical sweet spots.
The underlying issue is that it's a complex language with many experimental and interacting features, which can and do cause a lot of distraction. This is not the fault of functional programming. Have a go at OCaml or F#, which are nice practical sweet spots.
The JVM has had specialized bytecode for SAM types for a long time now, you cannot really get more "first-class" than that. And really it's just an implementation detail than doesn't make the language more or less functional.
Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml. The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
> it's just an implementation detail than doesn't make the language more or less functional.
It affects the language very much, awkward currying and tupling, needing to wrap methods in objects. Subtyping also has many complex consequences. There is limited type inference and tail call optimisation versus functional-first languages.
> Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml.
It offers higher-kinded types, but F# has units of measure, OCaml has polymorphic variants. Each has advanced features not offered by the other.
> The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
It was not designed as a functional programming language first and foremost, that is my point.
It affects the language very much, awkward currying and tupling, needing to wrap methods in objects. Subtyping also has many complex consequences. There is limited type inference and tail call optimisation versus functional-first languages.
> Scala isn't simply an evolution of Java. It offers a type system that goes beyond what you can do in F# or OCaml.
It offers higher-kinded types, but F# has units of measure, OCaml has polymorphic variants. Each has advanced features not offered by the other.
> The fact it's multi-paradigm and plays nice with Java's OO model doesn't make it less functional than these two.
It was not designed as a functional programming language first and foremost, that is my point.
> It affects the language very much, awkward currying and tupling, needing to wrap methods in objects.
That is a lot less true since Scala 3.
> Subtyping also has many complex consequences.
Sure. But it also means I can use any library from the Java ecosystem, and that's a huge reason behind the big number of Scala jobs compared to other FP languages.
> There is limited type inference and tail call optimisation versus functional-first languages.
Limited type inference is typically what I (and my team) want, for the sake of self-documentation. Scala's type inference is plenty enough, and the few corner cases that were annoying in Scala 2 should be fixed in Scala 3.
Tail-call optimization is done the compiler. The lack of tail-call elimination is bothering the few maintainers of functional libraries that need to implement CPS and trampolines, but not really something the average developer will have to worry about. And it should come to the JVM with Loom, eventually.
> F# has units of measure
Scala offers more generic ways to do the same thing. Would F# need such a feature at the language-level if it had typeclasses?
> OCaml has polymorphic variants
I believe most people don't want structural typing in their GADTs.
> It was not designed as a functional programming language first and foremost, that is my point.
I don't think Martin Odersky would agree. It's not an either/or situation. Scala was designed to be a full-fledged functional language, and OO hybrid, compatible with (and leveraging) the Java OO model, and offering a strong type system that goes beyond what you find in most FP languages.
That is a lot less true since Scala 3.
> Subtyping also has many complex consequences.
Sure. But it also means I can use any library from the Java ecosystem, and that's a huge reason behind the big number of Scala jobs compared to other FP languages.
> There is limited type inference and tail call optimisation versus functional-first languages.
Limited type inference is typically what I (and my team) want, for the sake of self-documentation. Scala's type inference is plenty enough, and the few corner cases that were annoying in Scala 2 should be fixed in Scala 3.
Tail-call optimization is done the compiler. The lack of tail-call elimination is bothering the few maintainers of functional libraries that need to implement CPS and trampolines, but not really something the average developer will have to worry about. And it should come to the JVM with Loom, eventually.
> F# has units of measure
Scala offers more generic ways to do the same thing. Would F# need such a feature at the language-level if it had typeclasses?
> OCaml has polymorphic variants
I believe most people don't want structural typing in their GADTs.
> It was not designed as a functional programming language first and foremost, that is my point.
I don't think Martin Odersky would agree. It's not an either/or situation. Scala was designed to be a full-fledged functional language, and OO hybrid, compatible with (and leveraging) the Java OO model, and offering a strong type system that goes beyond what you find in most FP languages.
> awkward currying
Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.
> Subtyping also has many complex consequences
But also substantial benefits!
> There is limited type inference
I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.
> tail call optimisation
This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).
> F# has units of measure
I dearly miss those. Type Providers even more so.
> OCaml has polymorphic variants
Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.
> It was not designed as a functional programming language first and foremost
This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.
More languages are becoming more and more like Scala, btw.
https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...
And the concept of a programming language paradigm is fake from the start anyway ;)
https://www.cambridgeblog.org/2017/05/what-if-anything-is-a-...
Personally, even though I haven't really thought it through deeply, I feel like Scala would be better if everything were curried.
> Subtyping also has many complex consequences
But also substantial benefits!
> There is limited type inference
I wish Scala would improve in this regard. Maybe paradoxically, inference works better with code tuned for subtyping and variance.
> tail call optimisation
This will be fundamentally solved by Project Loom. At least on the JVM (there's also Scala on JS and on LLVM).
> F# has units of measure
I dearly miss those. Type Providers even more so.
> OCaml has polymorphic variants
Could be nice in Scala. Or maybe not, can't tell now. And there's always the risk of too many features, which makes a language worse, not better.
> It was not designed as a functional programming language first and foremost
This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary, not fundamental. In other words, Scala erases the distinction, it's fully OOP and fully FP. Scala has higher order functions, ADTs, pattern matching, a module system, like SML/OCaml. But it uses keywords `class` and calls it's instances "object" like Java. And it's interoperable with Java. But theoretically there's no fundamental distinction.
More languages are becoming more and more like Scala, btw.
https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...
And the concept of a programming language paradigm is fake from the start anyway ;)
https://www.cambridgeblog.org/2017/05/what-if-anything-is-a-...
> This is misleading at best. It was designed to show that the distinction between OOP and FP is arbitrary,
Possibly misleading yes, it is certainly a subjective point. I guess it reflects the struggle I had doing FP in Scala versus alternatives. I don't think I'm alone either, the Haskell community contains a lot of Scala refugees. Note that I have not looked at Scala 3.
Possibly misleading yes, it is certainly a subjective point. I guess it reflects the struggle I had doing FP in Scala versus alternatives. I don't think I'm alone either, the Haskell community contains a lot of Scala refugees. Note that I have not looked at Scala 3.
> doing FP in Scala versus alternatives
I think Scala is the language most actual functional programming on this planet takes place these days. Be it just FP or pure FP.
I especially like pure FP in Scala. One can do that with Cats Effect (from the TypeLevel family of languages) or ZIO. They're both awesome, so check them out and pick what you'll like best.
https://typelevel.org/cats-effect/
https://zio.dev/
You don't even need to reach out to Scala 3 (still not as mature in its tooling support), you can have a great time with the latest Scala 2 (2.13).
> versus alternatives
I think of Scala as a opinionated take on ML and a module system that is tailored to JVM (and is seamlessly interoperable with Java) that just happens to have syntax heavy on braces/parentheses. Otherwise, what's not to like? :)
I think Scala is the language most actual functional programming on this planet takes place these days. Be it just FP or pure FP.
I especially like pure FP in Scala. One can do that with Cats Effect (from the TypeLevel family of languages) or ZIO. They're both awesome, so check them out and pick what you'll like best.
https://typelevel.org/cats-effect/
https://zio.dev/
You don't even need to reach out to Scala 3 (still not as mature in its tooling support), you can have a great time with the latest Scala 2 (2.13).
> versus alternatives
I think of Scala as a opinionated take on ML and a module system that is tailored to JVM (and is seamlessly interoperable with Java) that just happens to have syntax heavy on braces/parentheses. Otherwise, what's not to like? :)
I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.
I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route.
I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!
I get that it is probably more intellectually stimulating for many engineers than the project they are working on, but it also reflects in over engineering of distributed systems for simple problems. I do wonder if there is really any net gains for a company to go the functional route.
I would love to see some research on this as people have been championing it for decades now, and seems suspiciously absent!
> scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery
This feels to me like a low effort and vague criticism.
Essentially, this is a complaint about an arbitrary group of developers that they're playing around with tech (whatever that tech might be) instead of delivering...
Obviously, in this case you can't say that specific thing about Python/JS/PHP/whatever developers, because "monads and type theory" just don't apply in these languages. (I know Python has MyPy, but let's put that aside for the simplicity of the argument.)
But for some non-scala/functional engineers, somebody could complain that they're wasting time playing with GUI frameworks, testing frameworks, async libraries, whatever...
The truth is, people can clown around with any technology, just as people can deliver with Scala/FP or something else.
This feels to me like a low effort and vague criticism.
Essentially, this is a complaint about an arbitrary group of developers that they're playing around with tech (whatever that tech might be) instead of delivering...
Obviously, in this case you can't say that specific thing about Python/JS/PHP/whatever developers, because "monads and type theory" just don't apply in these languages. (I know Python has MyPy, but let's put that aside for the simplicity of the argument.)
But for some non-scala/functional engineers, somebody could complain that they're wasting time playing with GUI frameworks, testing frameworks, async libraries, whatever...
The truth is, people can clown around with any technology, just as people can deliver with Scala/FP or something else.
> I'll also add that scala/functional engineers are also more likely to focus their energies on monads and type theory rather than product delivery.
Then how do you explain that a very significant number of "top" tech companies have teams who manage to deliver products written in Scala or other FP languages?
Then how do you explain that a very significant number of "top" tech companies have teams who manage to deliver products written in Scala or other FP languages?
Teams have managed to deliver products in also sorts of languages, Cobol for example.
Did the choice of language benefit the delivery, maintenance and TCO is my question.
If I choose Haskell/Scala over Java (FYI as a programmer I'm not a fan of Java) what benefit will it actually bring the business, and does it out weight the negatives, over what time frame and how much risk?
There are technical tradeoffs everywhere. But you cannot make a caricature of FP developers, supposedly not willing to spend energy on delivering products.
Lots of tech companies have proved that you don't need to follow Google and constrain your workforce to a small list of vetted languages. Most teams who chose Haskell, OCaml, Scala, Rust... are productive and able to deliver products.
Lots of tech companies have proved that you don't need to follow Google and constrain your workforce to a small list of vetted languages. Most teams who chose Haskell, OCaml, Scala, Rust... are productive and able to deliver products.
> There are technical tradeoffs everywhere. But you cannot make a caricature of FP developers, supposedly not willing to spend energy on delivering products.
That is my personal experience, a tiny data point, again where are the studies that give some actual useful guidance?
I wrote a great project using Racket, everyone should use Racket, its cool, lets blog it ... gains momentum, its new its exciting it promises change ... people start to have different experiance, bad decisions are made ... new bandwagon, lets all rush to that yay. Having been around for long enough to see this cycle, I think it's right to ask for some well thought evidence, or gathering of trade offs to help decision making.
That is my personal experience, a tiny data point, again where are the studies that give some actual useful guidance?
I wrote a great project using Racket, everyone should use Racket, its cool, lets blog it ... gains momentum, its new its exciting it promises change ... people start to have different experiance, bad decisions are made ... new bandwagon, lets all rush to that yay. Having been around for long enough to see this cycle, I think it's right to ask for some well thought evidence, or gathering of trade offs to help decision making.
But my point is does moving to FP, which is the direction of change, actually bring any benefits to the actual outcome?
My question is simple as that, yet as engineers we get lost in the detail of the doing and some hand wavy suggestion that it makes things better, yet where is the actual evidence for this?
Be pro FP or not, or any other programming paradigm, lets say logic based (prolog etc), where is there any measures on how it benefits outcome.
I appreciate this isn't something that can be easily measured, but that is arguably a key problem with the state of the industry, that its emotion, intuition and bandwagon driven.
My question is simple as that, yet as engineers we get lost in the detail of the doing and some hand wavy suggestion that it makes things better, yet where is the actual evidence for this?
Be pro FP or not, or any other programming paradigm, lets say logic based (prolog etc), where is there any measures on how it benefits outcome.
I appreciate this isn't something that can be easily measured, but that is arguably a key problem with the state of the industry, that its emotion, intuition and bandwagon driven.
Yup, Scala is to Haskell what F# is to Ocaml.
> Scala is to Haskell what F# is to Ocaml
That's not quite precise, IMHO.
F# is an awesome language that I hold very dear, but it is a castrated form of OCaml. It has only a few features that OCaml doesn't have. For example Type Providers or Unit of Measurement. These are nice and useful features, they're not gimmicks, but they're not fundamental.
On the other hand, Scala isn't a hollowed out Haskell. Haskell, admittedly, is a more powerful language and has features Scala doesn't, like a linear type system. And it's just different, non-strict, whereas Scala is strict. But Scala is also very powerful in other fundamental areas, where Haskell is weak. Scala has a superior module system, it's biggest strength IMO. Haskell's modularity story is that great AFAIK.
That's not quite precise, IMHO.
F# is an awesome language that I hold very dear, but it is a castrated form of OCaml. It has only a few features that OCaml doesn't have. For example Type Providers or Unit of Measurement. These are nice and useful features, they're not gimmicks, but they're not fundamental.
On the other hand, Scala isn't a hollowed out Haskell. Haskell, admittedly, is a more powerful language and has features Scala doesn't, like a linear type system. And it's just different, non-strict, whereas Scala is strict. But Scala is also very powerful in other fundamental areas, where Haskell is weak. Scala has a superior module system, it's biggest strength IMO. Haskell's modularity story is that great AFAIK.
I remember perusing a book on ML (the language) and having aha moments such as "so this is where the '_' naming convention comes from" and "this is where pattern matching was borrowed from". Monads (aka zio/cats) are not built-in, the "lazy" keyword is a far cry from strictly lazy evaluation. I say "Scala to Ocaml" on the JVM is equivalent to "F# to Ocaml" in the .NET world (there must be some category theory joke in this topology).
> I don't even view Scala as a functional language, as functions (methods) are not first class. Lambdas are encoded as objects with a single method. It's much more expressive than Java and so better at expressing many functional programming ideas, but it's not a functional-first language, it's an evolution of Java.
It' technically true that Scala's fundamental building block is object, not function.
But that is in my eyes more of an implementation detail. Scala is a language that blurs the distinction between FP and OOP to the point of meaninglessness. You can do FP and still organize your code into classes/objects/traits (aka modules). You can choose to do side effects. Or you can waive them and do pure FP (like in Haskell) with TypeLevel or ZIO.
> it's an evolution of Java
I would say that it's kanda the other way around. Scala is a beacon that almost all languages are converging towards, not just Java.
https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...
> complex language with many experimental and interacting features
It doesn't have that many features. Some people even call Scala simple for this reason. But the features that is has are _very_ powerful. Some maybe even too powerful for my taste (implicit conversions anyone?). And they're orthogonal so they can be composed together.
Sadly, such composition can be brittle and non-beginner friendly, especially when it fails -- things like weird type errors or weird unexpected behavior at runtime, or compiletime for that matter, etc. So Scala will give you a lot of rope to hang yourself onto, if you'll be blindly taking it.
But it doesn't have to be that way. You (or a senior developer) have to know what you're doing. Then you can reap significant benefits.
It's good news that Scala 3 significantly improves on this front -- it emphasizes programmer's intent instead of Scala's internal mechanics.
Sure, in some languages, this risk isn't even on the table (Go, etc). But having power also comes with benefits, not only the potential problems I've described above.
It' technically true that Scala's fundamental building block is object, not function.
But that is in my eyes more of an implementation detail. Scala is a language that blurs the distinction between FP and OOP to the point of meaninglessness. You can do FP and still organize your code into classes/objects/traits (aka modules). You can choose to do side effects. Or you can waive them and do pure FP (like in Haskell) with TypeLevel or ZIO.
> it's an evolution of Java
I would say that it's kanda the other way around. Scala is a beacon that almost all languages are converging towards, not just Java.
https://www.lihaoyi.com/post/FromFirstPrinciplesWhyScala.htm...
> complex language with many experimental and interacting features
It doesn't have that many features. Some people even call Scala simple for this reason. But the features that is has are _very_ powerful. Some maybe even too powerful for my taste (implicit conversions anyone?). And they're orthogonal so they can be composed together.
Sadly, such composition can be brittle and non-beginner friendly, especially when it fails -- things like weird type errors or weird unexpected behavior at runtime, or compiletime for that matter, etc. So Scala will give you a lot of rope to hang yourself onto, if you'll be blindly taking it.
But it doesn't have to be that way. You (or a senior developer) have to know what you're doing. Then you can reap significant benefits.
It's good news that Scala 3 significantly improves on this front -- it emphasizes programmer's intent instead of Scala's internal mechanics.
Sure, in some languages, this risk isn't even on the table (Go, etc). But having power also comes with benefits, not only the potential problems I've described above.
I'd be interested to see Scala 3, my comments/opinions apply to Scala 2 only.
Haskell's slogan was "avoid (success at all cost)", so it's hardly surprising that it's been considered niche since its inception.
It's seen adoption among at least a couple of large companies: Standard Chartered, and Facebook uses it to make a DSL for spam filtering. The key point for at least those adopters is that it has a fast turnaround time for quickly changing code and still having it be correct.
Is this objective data? No, certainly not, but it's probably better than pure speculation.
I personally speculate that it has a lot to do with what type of problem you're solving. If you're solving difficult/intricate problems language matters a great deal, but if you're just doing CRUD the language choice probably matters much less. Or if, as above, you're working in a domain where being correct the first time matters a lot.
It's seen adoption among at least a couple of large companies: Standard Chartered, and Facebook uses it to make a DSL for spam filtering. The key point for at least those adopters is that it has a fast turnaround time for quickly changing code and still having it be correct.
Is this objective data? No, certainly not, but it's probably better than pure speculation.
I personally speculate that it has a lot to do with what type of problem you're solving. If you're solving difficult/intricate problems language matters a great deal, but if you're just doing CRUD the language choice probably matters much less. Or if, as above, you're working in a domain where being correct the first time matters a lot.
I learned that supposedly the Haskell motto "avoid success at all cost" wasnt suppose to mean what people think: https://news.ycombinator.com/item?id=12056169
https://discourse.haskell.org/t/new-blog-post-haskell-doomed...
I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link):
"An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…"
I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.
https://discourse.haskell.org/t/new-blog-post-haskell-doomed...
I honestly think this is/was an idiotic move; especially since the alternative reading 'avoid "success-at-all-cost"' is not thaaat much better, like (from the second link):
"An example is I/O. For literally years Haskell had no I/O to speak of; more precisely, I/O was unreasonably difficult. For practical utility that was pretty inconvenient. But we stuck to purity…"
I mean, would you want to rest your business on such an attitude? (Which is a great attitude, also gave monads, explained in the link, and advanced the language while keeping it pure). I am not saying a language/environment has to be business friendly, but if you want businesses to use it, it better be.
> I mean, would you want to rest your business on such an attitude?
Haskell started as a research language by academics, for academics. Business concerns have not been a large concern in its language evolution. That's fine IMO, it's good to have a place where CS researchers can experiment relatively freely without having Big Corporate Stakeholders demanding absolute backwards compatibility for all time (see Python 2->3 for an example of that).
The best parts of Haskell have slowly been copied by other languages (for example: typeclasses became traits in Rust, list comprehensions are in Python, goroutines look a LOT like Haskell threads, etc), while the experiments that didn't work out as much (lazy I/O for example) just don't get copied.
"It's no good for business" just misses the point of a research language completely IMO. That said, some people want to make it more business-oriented and have been making strides towards that goal. Haskell does not really have a BDFL, so anyone can (try to) move the ecosystem in any direction they wish.
Haskell started as a research language by academics, for academics. Business concerns have not been a large concern in its language evolution. That's fine IMO, it's good to have a place where CS researchers can experiment relatively freely without having Big Corporate Stakeholders demanding absolute backwards compatibility for all time (see Python 2->3 for an example of that).
The best parts of Haskell have slowly been copied by other languages (for example: typeclasses became traits in Rust, list comprehensions are in Python, goroutines look a LOT like Haskell threads, etc), while the experiments that didn't work out as much (lazy I/O for example) just don't get copied.
"It's no good for business" just misses the point of a research language completely IMO. That said, some people want to make it more business-oriented and have been making strides towards that goal. Haskell does not really have a BDFL, so anyone can (try to) move the ecosystem in any direction they wish.
I agree it is good to have it as a research language; but one shouldnt expect jobs in that field then (which the op seems to do). One can hope though.
> I mean, would you want to rest your business on such an attitude?
From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
From a business pov, the idea would be to assess whether you're happy with what can be done in userland rather than expect syntactic or semantic changes. I can't think of a company that started doing haskell waiting for future features to be added in the language.
Do you know of any person that made a decision based on the slogan contents? It was an obvious joke. I've seen people claiming to avoid a language that posts a joke on the front page (honestly, appeasing to those people were a sure way to add those costs the slogan is about), but never because of the message.
Anyway, removing the parenthesis makes it clear that the operations are associative. Otherwise the phrase would be wrong, and Haskell developers really dislike that kind of wrong.
Anyway, removing the parenthesis makes it clear that the operations are associative. Otherwise the phrase would be wrong, and Haskell developers really dislike that kind of wrong.
I think you took the wrong message from my message.
I was saying that the Haskell people were unapologetic (and obviously tongue-in-cheek)... and that one perhaps shouldn't expect massive commercial success when the people in charge obviously weren't going for that.
I was saying that the Haskell people were unapologetic (and obviously tongue-in-cheek)... and that one perhaps shouldn't expect massive commercial success when the people in charge obviously weren't going for that.
> (in an industry where successful solutions always get mimicked).
This is in my opinion not the case.
Just to give one example: WhatsApp managed to get to half a billion users with about 60 employees by using Erlang for their infrastructure.
Nevertheless, Erlang is far from being a mainstream language (even though it is used in industry).
In my opinion, in what kind of infrastructure is used/mimicked, a lot of hype is involved.
This is in my opinion not the case.
Just to give one example: WhatsApp managed to get to half a billion users with about 60 employees by using Erlang for their infrastructure.
Nevertheless, Erlang is far from being a mainstream language (even though it is used in industry).
In my opinion, in what kind of infrastructure is used/mimicked, a lot of hype is involved.
That's not the industry I'm talking about. I work in finance.
Haskell has been a huge success in how it has inspired the industry. I believe there is more where that came from. I think Haskell Generics could be really powerful if it was made way more usable and intuitive.
I don't think this is a good philosophy to follow. Javascript for example was a terrible language. It's better now because they modified it and most people use typescript... but it was shit starting out and it's initially popularity had nothing to do with how well it worked.
I will say that haskell does solve many of the problems we face in software engineering today including coding ourselves into a corner. The problem is the paradigm is extremely hard and that's what hampers its success.
I will say that haskell does solve many of the problems we face in software engineering today including coding ourselves into a corner. The problem is the paradigm is extremely hard and that's what hampers its success.
> Basically, it's 2022. People have tried it and it hasn't worked out.
It worked well enough for us when we tried it.
I guess the issue is that people and companies really have bad expectations on what "works out" means, and how different languages may need different kinds of environment/investment. If you expect to run a haskell shop the same way you run a java shop, you'll run into trouble as soon as your original team leaves. Likewise, if you run your java shop as you would run a haskell shop, expect trouble.
It worked well enough for us when we tried it.
I guess the issue is that people and companies really have bad expectations on what "works out" means, and how different languages may need different kinds of environment/investment. If you expect to run a haskell shop the same way you run a java shop, you'll run into trouble as soon as your original team leaves. Likewise, if you run your java shop as you would run a haskell shop, expect trouble.
> "F# has been more successful"
F# was built to be successful rather than pure. The Early History of F# writeup[1] talks about Don Syme wanting to get strongly typed functional programming "delivered in such a way that it could be adopted by large numbers of programmers", and SML.NET which was being developed at the time was not looking like it would do that. He then worked with someone to port Haskell to .NET and got it running, but with input from Simon Peyton-Jones decided on a different direction. Then went towards OCaml and whether it could run on either JVM or .NET and had this exchange:
> "OCaml already shares a platform with C (at least with the native−code compiler), so all the C libraries are already available... Yet it can still be a lot of effort to link with a C library.[...] There's hard work to be done to realise this vision, but in principle a clean interop story sure beats the endless rehashing of other people's code in language X as a library in language Y. Myself and others involved in the Project 7 are working on one approach to achieve this interop, i.e. compiling languages directly to .NET MS−IL, in the style of MLj, often adding extensions to the language in order to improve the interop. We are also working on improving the .NET infrastructure, proposing support for features such as parametric polymorphism in MS−IL..."
That is, Don Syme was not focused on the most pure ideological code first, he wanted something a large number of programmers could use, and adapting the language and tooling for that goal. F# became a thing supported by Microsoft, by Visual Studio, interops with C# libraries, and C# being able to use libraries written in F#, with very low friction as they share the same runtime, garbage collector, basic type library, exception system, etc. Quoting from the PDF again:
> "As an aside, I think it would be an interesting question to say "OK, let's take it for granted that the end purpose of our language is to produce components whose interface is expressed in terms of the Java or .NET type systems, but which retains as many of the features and conceptual simplicity of OCaml and ML as possible." I'm not sure exactly what you'd end up with, but whatever it was it could be the language to take over from C\# and/or Java (if that's what you're interested in...) But without really taking Java/.NET component building seriously right from the start I feel you're always just going to end up with a bit of a hack − an interesting, usable hack perhaps, but not a really good language"
F# is a bit awkward, not perfectly pure, has to cope with .NET nulls and C# being the big force for the direction of.NET and so on. 20 years later, well who knows but in the StackOverflow survey of 2018 F# is 9th "most loved language" and OCaml is 25th.
[1] https://fsharp.org/history/hopl-final/hopl-fsharp.pdf (chapter 6, the decision to create F#, particularly)
[2] https://insights.stackoverflow.com/survey/2018/#technology
F# was built to be successful rather than pure. The Early History of F# writeup[1] talks about Don Syme wanting to get strongly typed functional programming "delivered in such a way that it could be adopted by large numbers of programmers", and SML.NET which was being developed at the time was not looking like it would do that. He then worked with someone to port Haskell to .NET and got it running, but with input from Simon Peyton-Jones decided on a different direction. Then went towards OCaml and whether it could run on either JVM or .NET and had this exchange:
> "OCaml already shares a platform with C (at least with the native−code compiler), so all the C libraries are already available... Yet it can still be a lot of effort to link with a C library.[...] There's hard work to be done to realise this vision, but in principle a clean interop story sure beats the endless rehashing of other people's code in language X as a library in language Y. Myself and others involved in the Project 7 are working on one approach to achieve this interop, i.e. compiling languages directly to .NET MS−IL, in the style of MLj, often adding extensions to the language in order to improve the interop. We are also working on improving the .NET infrastructure, proposing support for features such as parametric polymorphism in MS−IL..."
That is, Don Syme was not focused on the most pure ideological code first, he wanted something a large number of programmers could use, and adapting the language and tooling for that goal. F# became a thing supported by Microsoft, by Visual Studio, interops with C# libraries, and C# being able to use libraries written in F#, with very low friction as they share the same runtime, garbage collector, basic type library, exception system, etc. Quoting from the PDF again:
> "As an aside, I think it would be an interesting question to say "OK, let's take it for granted that the end purpose of our language is to produce components whose interface is expressed in terms of the Java or .NET type systems, but which retains as many of the features and conceptual simplicity of OCaml and ML as possible." I'm not sure exactly what you'd end up with, but whatever it was it could be the language to take over from C\# and/or Java (if that's what you're interested in...) But without really taking Java/.NET component building seriously right from the start I feel you're always just going to end up with a bit of a hack − an interesting, usable hack perhaps, but not a really good language"
F# is a bit awkward, not perfectly pure, has to cope with .NET nulls and C# being the big force for the direction of.NET and so on. 20 years later, well who knows but in the StackOverflow survey of 2018 F# is 9th "most loved language" and OCaml is 25th.
[1] https://fsharp.org/history/hopl-final/hopl-fsharp.pdf (chapter 6, the decision to create F#, particularly)
[2] https://insights.stackoverflow.com/survey/2018/#technology
> I mean how many people here, currently working in language X, would want to hire someone that is better than they are?
I have always tried to hire better than I am (and ever will be); not to say i'm very good, but a lot of people are very bad. I hired, multiple times in my (30+ year) career people who are much better than I am at pure tech stuff like creating great code. I would love for someone to make me obsolete (I don't think looking stupid is a thing), then I can focus on other stuff. In my first company I was the founder and CTO; I replaced myself with a much better CTO who was so much better that I suddenly had literally nothing to do. So I went on to create + run our research (r&d) group which was a lot more fun than being CTO. Far too many people stay in positions they don't like for pure ego; I don't care what they call me as long as I like the work and I get paid enough, in that order.
I guess when you have a job and this happening it would be less good. Although I would see it as a sign to go do something else.
I have always tried to hire better than I am (and ever will be); not to say i'm very good, but a lot of people are very bad. I hired, multiple times in my (30+ year) career people who are much better than I am at pure tech stuff like creating great code. I would love for someone to make me obsolete (I don't think looking stupid is a thing), then I can focus on other stuff. In my first company I was the founder and CTO; I replaced myself with a much better CTO who was so much better that I suddenly had literally nothing to do. So I went on to create + run our research (r&d) group which was a lot more fun than being CTO. Far too many people stay in positions they don't like for pure ego; I don't care what they call me as long as I like the work and I get paid enough, in that order.
I guess when you have a job and this happening it would be less good. Although I would see it as a sign to go do something else.
> "as long as I like the work and I get paid enough, in that order."
If you can deal with not getting paid enough, in what way is it "not enough"?
If you can deal with not getting paid enough, in what way is it "not enough"?
but emotionally it would seriously piss me off
That is why choices like that should be left to project managers. As someone who is coding less and managing more these days, I have none of that ego left. If I could hire someone twice as good as me I would do so in a heart beat[1] and then go home and celebrate my great luck.
[1] Assuming they aren't an asshole etc. etc.
That is why choices like that should be left to project managers. As someone who is coding less and managing more these days, I have none of that ego left. If I could hire someone twice as good as me I would do so in a heart beat[1] and then go home and celebrate my great luck.
[1] Assuming they aren't an asshole etc. etc.
> I mean how many people here, currently working in language X, would want to hire someone that is better than they are?
Isn’t the adage “A players hire A players, B players hire C players”?
Isn’t the adage “A players hire A players, B players hire C players”?
[deleted]
Finding Haskell jobs is the problem, not 'functional jobs' in general.
I'm reminded of an old joke:
This could be a great year for Haskell's usage in industry, we hope to see its adoption rate jump by as much as 25%. That's right, a whole engineer!
Back on topic: I imagine you're thinking mainly of Scala and Clojure?
This could be a great year for Haskell's usage in industry, we hope to see its adoption rate jump by as much as 25%. That's right, a whole engineer!
Back on topic: I imagine you're thinking mainly of Scala and Clojure?
Elixir has most job offers, if I'm not mistaken. But that's just what caught my attention recently.
I hear many people complain that they can't find Haskell jobs. Could of course be that OCamlers, F#ers, ... don't complain that much ;)
I hear many people complain that they can't find Haskell jobs. Could of course be that OCamlers, F#ers, ... don't complain that much ;)
Just search your favorite job board, you'll see that Scala is far more popular than anything else in this space. Elixir is pretty niche, you can clearly see that on https://whoishiring.io (that is scraping HN among other sources).
I think this is not a useful or productive mindset. I mean the idea of "I spend hundreds of hours learning $TECH in order to get a job in it".
If you learn it because it is interesting to you and you enjoy the process of learning and using the language/tech, then that's all good. How to "monetize" your hobby is a separate question that should not factor in whether you should or should not cultivate it. There are probably many ways to monetize it. Landing a job is just one way.
If you learn it because it is interesting to you and you enjoy the process of learning and using the language/tech, then that's all good. How to "monetize" your hobby is a separate question that should not factor in whether you should or should not cultivate it. There are probably many ways to monetize it. Landing a job is just one way.
There's a fair amount of FP jobs in Scala land.
Also, I'm not an expert on Haskell, but to my knowledge, popular Scala FP libraries such as cats or zio are basically ports of Haskel into Scala.
> cats or zio are basically ports of Haskel into Scala
Not really. And ZIO takes special pride in that not being the case.
That's not to say that the authors didn't know (about) Haskell and its libraries. But these are distinctly Scala takes on the topic. Especially ZIO, heavily relying subtyping and vairance, is very far from Haskell while still being pure FP.
ZIO's "FP" library called "ZIO Prelude" totally revamps the "traditional" Type Class hierarchy, using Scala's intersection types feature. The name ("Prelude") is the only Haskellism there :)
https://www.youtube.com/watch?v=OwmHgL9F_9Q
https://zio.github.io/zio-prelude/docs/overview/overview_dia...
https://github.com/zio/zio-prelude/
Not really. And ZIO takes special pride in that not being the case.
That's not to say that the authors didn't know (about) Haskell and its libraries. But these are distinctly Scala takes on the topic. Especially ZIO, heavily relying subtyping and vairance, is very far from Haskell while still being pure FP.
ZIO's "FP" library called "ZIO Prelude" totally revamps the "traditional" Type Class hierarchy, using Scala's intersection types feature. The name ("Prelude") is the only Haskellism there :)
https://www.youtube.com/watch?v=OwmHgL9F_9Q
https://zio.github.io/zio-prelude/docs/overview/overview_dia...
https://github.com/zio/zio-prelude/
Author doesn't say he has trouble finding a Haskell job. If I had a Haskell blog that regularly reaches the HN front page, I'd write a "looking for a job" post there as the first thing in my search, not after exhausting all other avenues.
After running a whole lot of coding interviews, one thing I've noticed is that people that take a functional approach to solving problems more typical end up having a hard time. Mostly because the functional style is more difficult to debug.
This can also be a classic case of why coding interviews are often a poor approximation of real world tasks.
Imperative (and especially dynamic) languages typically make it easy to get something "working", but it can take many iterations or lots of unit tests until it's robust enough to be worthy of handling a production load. That time spent futzing around with it isn't often capturable in an interview. If it is, chances are the interview isn't asking something representative of real-world scenarios, or it's taking a very narrow slice of one where someone's approach is going to change a lot of they're not just working in the narrow slice.
Functional (and especially typed functional) languages do make it harder to get something up and running, but they tend to have a nice side effect that if the compiler is satisfied, it won't need more work. That usually happens because you can capture the domain in a type declaration that the compiler requires you to account for all cases of. And if you're missing something, it's easy to adjust because the act of adding another case to your domain makes your compiler point out exactly where else to update your code.
Imperative (and especially dynamic) languages typically make it easy to get something "working", but it can take many iterations or lots of unit tests until it's robust enough to be worthy of handling a production load. That time spent futzing around with it isn't often capturable in an interview. If it is, chances are the interview isn't asking something representative of real-world scenarios, or it's taking a very narrow slice of one where someone's approach is going to change a lot of they're not just working in the narrow slice.
Functional (and especially typed functional) languages do make it harder to get something up and running, but they tend to have a nice side effect that if the compiler is satisfied, it won't need more work. That usually happens because you can capture the domain in a type declaration that the compiler requires you to account for all cases of. And if you're missing something, it's easy to adjust because the act of adding another case to your domain makes your compiler point out exactly where else to update your code.
I'm still a newb to F#, but did a few Advent of Code 2021 in it. Once I learned to do a log function that logged/dumped input to a file - and then returned the input - it was trivial to stick this log function anywhere in the pipes or folds or wherever to get a view of the program state.
I would then use the "Send to repl" feature to fire off single pieces of my program expressions to get instant feedback on the code I was writing. Long before the entire program was run in whole, each part had been run many times.
If you're in a classic whiteboard interview sessions you are robbed of this possibility. That's unfair because it's a big part of working with F# (I would guess other functional programs as well). You might feel you "pay" a bit in avoiding mutable state and having everything as an expression, but you gain so much in return, but you gotta use it!
I guess my argument is that a whiteboard situation might favor an imperative style, where you would write, compile, run and not use repl throughout development?
I would then use the "Send to repl" feature to fire off single pieces of my program expressions to get instant feedback on the code I was writing. Long before the entire program was run in whole, each part had been run many times.
If you're in a classic whiteboard interview sessions you are robbed of this possibility. That's unfair because it's a big part of working with F# (I would guess other functional programs as well). You might feel you "pay" a bit in avoiding mutable state and having everything as an expression, but you gain so much in return, but you gotta use it!
I guess my argument is that a whiteboard situation might favor an imperative style, where you would write, compile, run and not use repl throughout development?
Because they didn't use state? Can you elaborate what you mean?
I haven't really figured out the "why", but the observation is that people that start using the typical functional portions of a language (map/reduce/whatever) are more likely to get bogged down if the code doesn't do what they expect. And this is even for people that seem really good at it.
Debugging functional code is a bit different and not everyone picks up this skill. That's why functional code tends to be harder to debug and people who pick up this skill will take longer in debugging it.
The main reason is printing. All your code is inlined into a single expression. You can't really throw a print statement in there. With haskell it's even crazier as if you do manage to print your code it comes out backwards.
The main reason is printing. All your code is inlined into a single expression. You can't really throw a print statement in there. With haskell it's even crazier as if you do manage to print your code it comes out backwards.
This is because creating the exact right abstraction for the job is time consuming. It may pay off later, and your typical FP person is fairly convinced that it will in terms of being able to be confident you got things right without having to test a lot of basic shit first (types tend to replace tests).
This is not suitable for the typical interview format.
This is not suitable for the typical interview format.
That theory seems relatively sound. I'm digging more into functional programming again, because I think reading code needs to be easier than writing code, or at least reading code should be as easy as possible, and maybe it can meet that need.
[deleted]
We're looking for F# devs, pls drop me an email to [email protected].
F# knowledge is valuable even if you don't use it. I've been down that rabbit hole a few times in the past 10 years or so, and even though I don't use it for work, it changed the way I code.
Learning is its own reward.
Also, if you are looking for an F# job, ping me and we can chat :)
Also, if you are looking for an F# job, ping me and we can chat :)
Don't worry about it. The functional style can be translated to helping you code functionally in other languages and solve problems with a functional bias.
It's a good thing.
It's a good thing.
If you can also write c# that's a nice combination to pick the right tools for a use-case
If you want a job in F# at enterprise company, let me know. I'm hiring at all levels.
[deleted]
[deleted]
It's a good idea to try to find a job this way, but given that he has been part of the Haskell community for a long time one might ask "Why can't he find a job using his network?" given his accomplishments.
I have never ever seen a job ad asking for Haskell, and the only time I needed to hire a Haskell dev (with NLP skills), a post to the Haskell mailing list led to zero replies, so we had to re-implement everything in Java.
Now I don't think this is a problem of functional programming not being popular, because there are some commercial shops using LISPs around.
I would like to read more blog posts about commercial implementations in "minor" languages.
I have never ever seen a job ad asking for Haskell, and the only time I needed to hire a Haskell dev (with NLP skills), a post to the Haskell mailing list led to zero replies, so we had to re-implement everything in Java.
Now I don't think this is a problem of functional programming not being popular, because there are some commercial shops using LISPs around.
I would like to read more blog posts about commercial implementations in "minor" languages.
> Why can't he find a job using his network?
I think his blog has a fair readership, and constitutes a part of his network, so I see this as him doing exactly that!
Given that it's on the front page of HN right now, I imagine he's getting better reach than he might have from asking a few people he knows, so it seems like a very sensible thing to do.
I think his blog has a fair readership, and constitutes a part of his network, so I see this as him doing exactly that!
Given that it's on the front page of HN right now, I imagine he's getting better reach than he might have from asking a few people he knows, so it seems like a very sensible thing to do.
> a post to the Haskell mailing list led to zero replies
There is Haskell Weekly with weekly job offers:
There is Haskell Weekly with weekly job offers:
As of November 2020, over 4,100 people subscribe to Haskell Weekly.
Over the last five issues, the average open rate was 37% and the average
click rate was 16%.
Offtopic question: How can you (reliably) meassure open rate of a newsletter? I'd assume mail clients as well as webmailers preventing any sorts of tracking, and tracking only those that have lax privacy requirements would taint the whole metric, wouldn't it?
Yes, it does (Haskell Weekly uses Mailchimp):
How we calculate open and click rates
The open rate is a percentage that tells you how many successfully delivered
campaigns were opened by subscribers. To find this out, Mailchimp loads a
tiny, transparent image into each campaign, and counts how often the image is
loaded among the delivered campaigns. The image is invisible to your
subscribers.
Yepp, but most mailclients block externally-linked content in HTML emails. Only inlined content is loaded.
And if you measure only those clients that ignore that/whitelist that, the metric is skewed/biased towards less-privacy sensetive users.
And if you measure only those clients that ignore that/whitelist that, the metric is skewed/biased towards less-privacy sensetive users.
I remember looking through some random Haskell job board out of curiosity last year and an the listings were overwhelmingly for Crypto/Web3 startups, with pay ranges clearly not targeting US devs (I think mid $30s was a common low end)
> I have never ever seen a job ad asking for Haskell
I see those occasionally, even here, on HN: in those "who's hiring" threads, and a few linked from this thread. But they tend to be odd: working on astrology, cryptocurrencies/NFTs/etc, or other unfortunate conditions coming along with it.
I'm also writing in Haskell at work, though that started as a Perl job. But for the reason mentioned above, I'm not sure if it's a good idea to look for a Haskell job, even if you want to write in it: restricting jobs to just Haskell certainly makes it much harder to find openings in places that work on something sensible/useful, and satisfying other requirements (especially if you also include ones like remote work). Unless one is particularly focused on just the process and not on the result, using awkward technologies to achieve useful goals must be preferable to using nice technologies to achieve something of a dubious value.
I see those occasionally, even here, on HN: in those "who's hiring" threads, and a few linked from this thread. But they tend to be odd: working on astrology, cryptocurrencies/NFTs/etc, or other unfortunate conditions coming along with it.
I'm also writing in Haskell at work, though that started as a Perl job. But for the reason mentioned above, I'm not sure if it's a good idea to look for a Haskell job, even if you want to write in it: restricting jobs to just Haskell certainly makes it much harder to find openings in places that work on something sensible/useful, and satisfying other requirements (especially if you also include ones like remote work). Unless one is particularly focused on just the process and not on the result, using awkward technologies to achieve useful goals must be preferable to using nice technologies to achieve something of a dubious value.
> astrology, cryptocurrencies/NFTs/etc
they are eating rather a lot of the experts; there was prior concern here on HN (if I remember correctly) about the negative effects that has on the Haskell community as a whole if most talented devs work on virtual beanie babies. I think, because the crypto communities are putting so much money into formal verification and dsl writing advantages, it is good for the whole.
they are eating rather a lot of the experts; there was prior concern here on HN (if I remember correctly) about the negative effects that has on the Haskell community as a whole if most talented devs work on virtual beanie babies. I think, because the crypto communities are putting so much money into formal verification and dsl writing advantages, it is good for the whole.
I would say his readers count towards his network. I don't think this is any different to somebody announcing on linkedin that they're looking for opportunities.
Haskell Developer - 6 to 12 months project - Remote (May 21, 2021) https://www.freelancermap.de/projektboerse/projekte/entwickl...
This is a posting from 8 months ago, also geared towards freelancers (not a permanent hire).
> I have never ever seen a job ad asking for Haskell.
I mean, just look at the Haskell subreddit or Haskell weekly news?
I mean, just look at the Haskell subreddit or Haskell weekly news?
The Cardano blockchain system is heavily based on Haskel. It is one of the largest ecosystems in this space and is growing rapidly. The author can try to find work with IOHK ( https://iohk.io/ ), the Cardano foundation ( https://cardano.org/ ) or one of several other companies doing commercial or research work around Cardano.
There's a good summary of why Cardno uses Haskell here - https://medium.com/@cardano.foundation/why-cardano-chose-has... - functional programming seems to have been a key influence in how Cardano's approach to smart contracts is built, avoiding centralized state - some insights in that here https://sundaeswap.finance/posts/concurrency-state-cardano
Potentially Cardano could become one of the most significant uses of Haskell in the wild, if it gets traction of course
Potentially Cardano could become one of the most significant uses of Haskell in the wild, if it gets traction of course
That blog post makes a big deal out of formal verification. However, my understanding is that if you really want to do formal verification on a practical scale, you are better off using a less fashionable language that's nonetheless had orders of magnitude more investment in verification tooling (such as Java).
Hasura is brilliant and is written in Haskell mostly. Give them a try: https://hasura.io/careers/?jobId=vso4JFIiAd8G
What makes them brilliant?
I work for Obsidian Systems (https://obsidian.systems/) writing Haskell. I believe we're still hiring engineers, and I've pinged the partners with a link to this post.
I have a theory if you want a haskell job you have to compromise heavily on many other aspects of job criteria such as salary, preferred location, interest in the domain etc. Why? Because there are so few of those jobs that it is highly selective and leaves you no selectivity for other aspects.
Want $300k + Haskell? You better be someone who wrote GHC!
Want $300k without Haskell? Just need US residence, and coding skills and be a bit ruthless.
I think a good Haskell job is the on where you build your own micro SaaS using Haskell.
Want $300k + Haskell? You better be someone who wrote GHC!
Want $300k without Haskell? Just need US residence, and coding skills and be a bit ruthless.
I think a good Haskell job is the on where you build your own micro SaaS using Haskell.
People who work on GHC are good C/C-- programmers working at Microsoft Research (Cambridge) for 60K GBP :)
The only person deeply involved in Haskell at MSR Cambridge was Simon Peyton Jones. And he was Senior Principal Reserarcher. You can look up the total compensation for that level on public salary sharing websites yourself. You are off at least by a factor of 5.
I see. Although, for Cambridge, UK, I might be off by a factor of 2 at most, I believe.
nb spj has left MS Research: https://discourse.haskell.org/t/new-horizons-for-spj/3099
Doesn’t Microsoft research pay top dollar ?
Do they have side income based on their leadership of GHC?
> Just need US residence
"If you're homeless, just buy a house"
"If you're homeless, just buy a house"
It wasn’t a social commentary, just an observation that way many more people are at the intersection of can code and can work in the US, vs have some serious Haskell/FP bragging rights.
I had a job writing Haskell. Then when COVID rolled in we were all put on furlough as the startup had iffy funding. Now I work at a larger company slinging JavaScript.
Am I happier? Well, I'd say the technology I work on is a lot less interesting. But I wouldn't trade in stability and benefits for another early age startup, just to write monads again.
Am I happier? Well, I'd say the technology I work on is a lot less interesting. But I wouldn't trade in stability and benefits for another early age startup, just to write monads again.
I find it to be a really odd when people want to work with specific languages. Languages are just a means to an end, not an end themselves. When I've made career changes it's because I wanted to solve certain problems or learn about specific layers of the stack (embedded and HW). I don't care what language is optimal in a domain. If I don't know it I'll learn it, but a language isn't gonna solve the domain specific issues. It's just a tool.
I don't find it odd. Its actually kind of frustrating using tools that make your job harder. Everything else being equal, I would choose a job where I coded in Kotlin over Java since I get frustrated easily with Java.
Haskell is the only language I ever learned (out of dozens, including Lisp and Forth) that felt like learning something completely new, like none of my existing programming knowledge applied. Working in Haskell means exploring a very different neighborhood in design-space. It's much more of a change of pace than learning about a specific layer of the stack.
For me Haskell and Prolog were both like that.
In this case, I suspect that Mark is interested in the distribution of jobs associated with Haskell as much as in the language itself. Haskell shops tend to solve certain kinds of problems and have certain philosophies about software. If you're interested in these problems and philosophies, a good way to find a job aligned with your interests is to find a job writing Haskell.
Languages are means to end, where the end you reach is significantly affected by the means you used to get there.
- Using Haskell means you can model your domain more precisely and have higher correctness guarantees.
- Using Rust means you get memory safety while maintaining the speed of C++, where the vast majority of vulnerabilities are memory safety issues.
- Using SQL means you can apply an optimizer on top of what is essentially relational algebra over tables.
In all of these cases, a less effective tool could be used, yes. But "it's just a tool" doesn't capture the fact that tools do solve domain-specific issues, and OP is not wrong to seek an employer who acknowledges the value of Haskell has to add.
- Using Haskell means you can model your domain more precisely and have higher correctness guarantees.
- Using Rust means you get memory safety while maintaining the speed of C++, where the vast majority of vulnerabilities are memory safety issues.
- Using SQL means you can apply an optimizer on top of what is essentially relational algebra over tables.
In all of these cases, a less effective tool could be used, yes. But "it's just a tool" doesn't capture the fact that tools do solve domain-specific issues, and OP is not wrong to seek an employer who acknowledges the value of Haskell has to add.
I get all that, but it still feels backwards a bit? I work in HW but I write a lot of software tools and prototype control firmware (though I come from an enterprise background). I generally have to write python, C++ or C (all context dependent). If somebody came to me saying "I want to work in C" or "Python" I'd say "so"? They should be saying they are interested in solving optimization problems, image quality search problems, etc. I understand Haskell is great for certain use cases but that applies to every language barring joke ones. Why would an employer hire somebody if they are simply interested in the tool through which the problem is solved not the domain itself? What signal does that provide and what evidence do I have that the person will become component in the domain? The way the original post is framed feels backwards to me.
I should also add, I was one of these people that just wanted to write C++ template metaprogramming all day and I had a hard time find jobs due to this exact line of thinking. Once I relaxed this constraint, I was able to find a new job AND use the programming tools I want, assuming its appropriate for the context.
I should also add, I was one of these people that just wanted to write C++ template metaprogramming all day and I had a hard time find jobs due to this exact line of thinking. Once I relaxed this constraint, I was able to find a new job AND use the programming tools I want, assuming its appropriate for the context.
> They should be saying they are interested in solving optimization problems, image quality search problems, etc.
They are. OP has been spending 30 years not being paid to use the tools he wants.
> but that applies to every language barring joke ones
Some languages are far more effective for a domain than others. To stretch it further than Haskell, there's a reason why Verilog is used in hardware over something like C. It would be enormously frustrating to work against my tool to get something done. Programmers who focus on "getting stuff done" in these situations are succeeding despite their tools, which is commendable, but we should still push to using better tools.
> interested in the tool through which the problem is solved not the domain itself
Many factors play into why someone works at a company, whether it's cost-effective to use a certain tool, whether a tool is trendy, whether the candidate is passionate about the domain, or whether the candidate is passionate about the tooling. A lot of people aren't passionate about the domain of adtech, for example, unlike self-driving cars, but they work in these areas because they like the practice of engineering.
They are. OP has been spending 30 years not being paid to use the tools he wants.
> but that applies to every language barring joke ones
Some languages are far more effective for a domain than others. To stretch it further than Haskell, there's a reason why Verilog is used in hardware over something like C. It would be enormously frustrating to work against my tool to get something done. Programmers who focus on "getting stuff done" in these situations are succeeding despite their tools, which is commendable, but we should still push to using better tools.
> interested in the tool through which the problem is solved not the domain itself
Many factors play into why someone works at a company, whether it's cost-effective to use a certain tool, whether a tool is trendy, whether the candidate is passionate about the domain, or whether the candidate is passionate about the tooling. A lot of people aren't passionate about the domain of adtech, for example, unlike self-driving cars, but they work in these areas because they like the practice of engineering.
> OP has been spending 30 years not being paid to use the tools he wants.
You know you're right about that and I hadn't really thought about what you mentioned in your post overall. But it makes a lot of sense
You know you're right about that and I hadn't really thought about what you mentioned in your post overall. But it makes a lot of sense
The programming language informs the core tech stack, so the programming language is more like the tool box, than the tool itself.
But the question really should be: Why are no large software development projects done in Haskell?
It is a common language in University CS-classes, so it gets a push from that.
What is missing from the platform?
It is a common language in University CS-classes, so it gets a push from that.
What is missing from the platform?
There are. But from experience with my customers that use Haskell, they don't go around advertising it much.
I hope this guy finds a good Haskell job and doesn't end up in the blockchain world, which is way too prominent in the Haskell ecosystem.
I hope this guy finds a good Haskell job and doesn't end up in the blockchain world, which is way too prominent in the Haskell ecosystem.
It takes a lot to learn to a degree of proficiency. Industry is about solving business problems easily. Hiring a fresh grad to throw together your SAAS business is all too common and they pick and easy to use framework the butcher it into a successful business and terrible mess for future senior devs to clean up.
[deleted]
Tooling. It's the same thing that sunk Scala in industry.
Some programming languages are more conductive for some types of applications.
I've been reading this blog on and off for years. In case you're reading on a screen orientation that causes the sidebar and "About Me" link to vanish, the writer is Mark Jason Dominus, author of Higher Order Perl.
Mercury is hiring ~50 developers to write Haskell this year. Our entire backend is in Haskell, and powers banking for many startups and e-commerce companies
Try it out at demo.mercury.com
Jobs page: mercury.com/jobs
To the OP: I asked our team to reach out to you
Try it out at demo.mercury.com
Jobs page: mercury.com/jobs
To the OP: I asked our team to reach out to you
As far as I know, Facebook has possibly the biggest Haskell deployment in form of one of their anti abuse tool.
There is also the Cardano ecosystem which is mainly built on Haskell and runs one of the biggest and most active blockchains ever.
Hmm and there is a lot of discussion about it being a barrier to adoption.
I think it is a good tech choice to be honest, I want my blockchain carefully built and audited.
I think it is a good tech choice to be honest, I want my blockchain carefully built and audited.
They also have a consistent history of wildly missing delivery dates though.
You mean, Haxl? [1] But AFAIK only a few devs are involved for the development.
[1] https://github.com/facebook/Haxl
[1] https://github.com/facebook/Haxl
No, their SPAM filter is (yes, still) in Haskell.
https://engineering.fb.com/2015/06/26/security/fighting-spam...
https://engineering.fb.com/2015/06/26/security/fighting-spam...
(For context: the spam filter uses the Haxl library. Yes Haxl itself has few developers; but it has many users)
Testament to how powerful Haskell can be :)
I’ve seen a small team of functional programmers tackle projects that would require dozens of OOP programmers. The challenge is finding them!
I’ve seen a small team of functional programmers tackle projects that would require dozens of OOP programmers. The challenge is finding them!
I imagine that is at least as much a feature of the type of programmers that self select to become "functional programmers" as it is a feature of the inherent advantage of function programming.
I worked with a guy who was an serious Lisp-hacker who could do fantastic things in Lisp and was always advocating that we do certain things in Lisp. But he was also a great programmer when 'forced' to use C++ or Perl, he just grumbled more while programming.
I worked with a guy who was an serious Lisp-hacker who could do fantastic things in Lisp and was always advocating that we do certain things in Lisp. But he was also a great programmer when 'forced' to use C++ or Perl, he just grumbled more while programming.
C++ and Perl are bad examples here. They are really expressive languages. I’d like to see the same developer using Go or Java 8.
At the risk of exposing myself, I’ve had to jump in and make changes to Sigma on several occasions. It was painful and I am not convinced having it in Haskell did anyone a favor.
Pretty wild to read so many comments about "programmers and their one true language write terrible code anyway/or are weird" when the person being commented on wrote one of the best perl books there is (and one of the best programming books period) and made a point of saying "I've never written it professionally". The entire blog post is about him attempting to make a transition! Those aren't the "one true language" people.
Proda, a proptech company in London, has a large team of haskell programmers (local and remote). They make software to help commercial real estate investors get a better handle on their data. www.proda.ai
full disclosure: I helped start proda.
full disclosure: I helped start proda.
> I understand what it means when someone says that a monad is a monoid in the category of endofunctors.
Finally, someone who understands the magic sentence.
Finally, someone who understands the magic sentence.
Any blog with Robertson Davies deserves promotion. My favourite Canadian author. And I certainly hope he finds haskell work, burrito or not.
Davies has showed up on my blog a few times. It's possible you will enjoy these miscellaneous notes on _The Manticore_: https://blog.plover.com/book/Manticore.html
Interesting. Nice notes, thanks! I liked "Leven of malice" and found myself thinking of it again recently reading "the shipping news": -the resonances of small (and not so small) town newspaper publishing in the two. And Proulx writes of similarly broken people.
"A mixture of frailties" is a great read for anyone who has uprooted themselves for serious study or work, and suffers culture shock.
My mum was an art historian and studied under Anthony Blunt at the Courtauld Institute so you can understand how "Cornish" read to me.
If you haven't read "Possession" by AS Byatt, I think having enjoyed "Cornish" you would like it. A very different book but touching many similar concepts without the magical realism perhaps. (Academic rivalries, art history)
I often think of the "putting yourself on trial" rap from "the Manticore" -my own star chamber isn't always as even handed.
"A mixture of frailties" is a great read for anyone who has uprooted themselves for serious study or work, and suffers culture shock.
My mum was an art historian and studied under Anthony Blunt at the Courtauld Institute so you can understand how "Cornish" read to me.
If you haven't read "Possession" by AS Byatt, I think having enjoyed "Cornish" you would like it. A very different book but touching many similar concepts without the magical realism perhaps. (Academic rivalries, art history)
I often think of the "putting yourself on trial" rap from "the Manticore" -my own star chamber isn't always as even handed.
“I’m not sure I should admit this”. Way to bury the lede.
Seriously mate, good luck. I love Haskell too despite having no professional experience in it.
Seriously mate, good luck. I love Haskell too despite having no professional experience in it.
I, also, would like for Mark Dominus to have a job coding Haskell.
Without saying anything about this particular person, I've found an interesting pattern with people who seek out a specific programming language to work in: their actual code tends to suck pretty bad. People that obsess over any particular language will typically obsess over it because they learned some new abstraction trick and seem to think that everything should be rewritten in it. And so instead of focusing on the problem they have to solve, they become obsessed with rewriting code that already has solved problems...and they tend to do it in a way that is short and succinct but utterly opaque and black-boxish. No thanks.
Again, I'm not expecting that everybody who does this is like this, but I've seen it enough that it is a pretty strong negative warning signal.
Again, I'm not expecting that everybody who does this is like this, but I've seen it enough that it is a pretty strong negative warning signal.
How about people who say “I've done professional work in 17 languages but none is much like Blub. Blub looks interesting and I'd like to give it a try.”
That seems like a less dubious motive.
That seems like a less dubious motive.
while i don't disagree with you (i have also encountered the type of people you're referring to), i think the stance is more valid than people want to give it credit for.
I would go so far as to say many of the people I've encountered who push back on "abstractions" and keep talking about how programming is "about solving problems" are the ones who allow the codebase to slowly go to shit in the name of features, and progress eventually grinds to a halt until a big rewrite. And in my experience, there are _way_ more of these types of people than the ones over-abstracting. Or it's possible my last company was just skewed toward that culture.
Either way, I've only known a couple people who seem to balance these concerns well and they are the best programmers I know.
I would go so far as to say many of the people I've encountered who push back on "abstractions" and keep talking about how programming is "about solving problems" are the ones who allow the codebase to slowly go to shit in the name of features, and progress eventually grinds to a halt until a big rewrite. And in my experience, there are _way_ more of these types of people than the ones over-abstracting. Or it's possible my last company was just skewed toward that culture.
Either way, I've only known a couple people who seem to balance these concerns well and they are the best programmers I know.
I have experienced this as well. Perhaps coincidentally the type of language they're always obsessed with is a functional one. I've yet to see a dev who's rabid over mutable state. They're usually bonzo for free monads.
That being said, I've generally found people who are obsessed over a single "technological thing" at work (language type, language, framework, OOP dev principles) rarely produce anything of value. They're usually on a mission to prove themselves right at any cost. Flexibility and ingenuity are the keys to a productive dev career.
That being said, I've generally found people who are obsessed over a single "technological thing" at work (language type, language, framework, OOP dev principles) rarely produce anything of value. They're usually on a mission to prove themselves right at any cost. Flexibility and ingenuity are the keys to a productive dev career.
"They're usually on a mission to prove themselves right at any cost." Exactly.
That being said I wish there were more devs obsessed with mutable state. Some problems are inherently mutable, and trying to make them immutable doesn't actually get rid of the state, it just pushes it around awkwardly. Classes, for as much hate as they get (mostly deserved IMO), are a godsend for those types of problems. And while they're helpful, stateful programming is still extremely hard. I really wish there was more innovation in this area.
That being said I wish there were more devs obsessed with mutable state. Some problems are inherently mutable, and trying to make them immutable doesn't actually get rid of the state, it just pushes it around awkwardly. Classes, for as much hate as they get (mostly deserved IMO), are a godsend for those types of problems. And while they're helpful, stateful programming is still extremely hard. I really wish there was more innovation in this area.
You can work with mutable state in Haskell, you just have to be explicit about it (e.g. State monad).
In Denmark wildcat banker Lars Seier's crypto startup explicitly hires Haskell-developers:
https://www.concordium.com/careers
https://www.concordium.com/careers
I'm in a similar situation to Mark. I left my previous company at the end of 2021.
I needed to take a break so I decided to take some time to learn Haskell better and
study open source Haskell projects before starting my next job search.
For what it's worth here's a list of Haskell hiring-related things I've come across. https://gist.github.com/hs211216/7e734535eadc869df26562b33db...
For what it's worth here's a list of Haskell hiring-related things I've come across. https://gist.github.com/hs211216/7e734535eadc869df26562b33db...
This is ridiculous. Of course there are no "haskell jobs". Nobody knows haskell. Looking for haskell programmers is like looking for a four-leaf clover. Actually it's more pointless because a four-leaf clover makes a nice instagram story. So if haskell is so great, why don't you teach a few of your friends to program in it, and increase the number of haskell programmers available?
The only reason there are "python jobs" is because django exists. The only reason there are "ruby jobs" is because rails exists. The only reason there are "javascript jobs" is because browsers exist. The only reason there are "C++ jobs" is because algorithmic trading and video games exist. The only reason there are "scala jobs" is because the JVM exists (and concurrency is hard). What real-world problem does haskell solve that python does not, or what "killer framework" is implemented in haskell? Why not make it and prove that haskell is worth learning?
All of that said, if you really want to program in haskell at a job, find a company that is all-in on microservices. They may allow you to write small services in haskell, as long as they know that if you leave the company, and they can't find one of the friends you taught a haskell for great good, they can find a java dev to rewrite it.
The only reason there are "python jobs" is because django exists. The only reason there are "ruby jobs" is because rails exists. The only reason there are "javascript jobs" is because browsers exist. The only reason there are "C++ jobs" is because algorithmic trading and video games exist. The only reason there are "scala jobs" is because the JVM exists (and concurrency is hard). What real-world problem does haskell solve that python does not, or what "killer framework" is implemented in haskell? Why not make it and prove that haskell is worth learning?
All of that said, if you really want to program in haskell at a job, find a company that is all-in on microservices. They may allow you to write small services in haskell, as long as they know that if you leave the company, and they can't find one of the friends you taught a haskell for great good, they can find a java dev to rewrite it.
Hey, he is the author of Higher-Order Perl!
Not sure if this is still relevant today, but I registered as a Haskell developer at https://www.haskellers.com/ decades ago and for a while, I received a number of offers from companies searching for Haskell developers, primarily from fintech.
Not any recent ones though. Also not sure if that’s because that site has grown old or because I have.
Not any recent ones though. Also not sure if that’s because that site has grown old or because I have.
Companies have a need for the application of the tools, not the tools themselves, though. Just like customers don't have the need for a task to be completed with a specific tool (but they might be particular about the process).
There's a mismatch in expectations here, from programmers to customers, via companies and hiring processes.
There's a mismatch in expectations here, from programmers to customers, via companies and hiring processes.
HubSpot is hiring a Haskell developer in Belgium, not sure if the position is remote though.
https://www.hubspot.com/careers/jobs/3630647?hubs_signup-cta...
(I'm not affiliated to HubSpot in any way)
https://www.hubspot.com/careers/jobs/3630647?hubs_signup-cta...
(I'm not affiliated to HubSpot in any way)
I really want to like Haskell, there is great programs that I use and love in Haskell (pandoc, glirc, hoogle, hackage), but the ecosystem (cabal, stack, ghc) really drag you down, with libraries incompatibilities, slow upstream updates, too many language extensions and custom operators to decode the code you didn't write. But usually there is great documentation to compensate and usually good error reports from ghc.
Haskell is nice to write little programs with few dependencies to avoid incompatibilities. I personalty used, and continue to use it to write a small monolithic blogging platform with too many dependencies. It works really well, is efficient, and the code is really easy to update, even after not looking at the code for few month. But if I would do it again, and for a production system, I would split my code into multiple micro-services.
Haskell is nice to write little programs with few dependencies to avoid incompatibilities. I personalty used, and continue to use it to write a small monolithic blogging platform with too many dependencies. It works really well, is efficient, and the code is really easy to update, even after not looking at the code for few month. But if I would do it again, and for a production system, I would split my code into multiple micro-services.
I suggest not throwing out the baby (the monolith) with the bathwater (dependency hell). Some languages are better than others at managing dependencies. You might like Rust in this regard; it has no global namespace, so IIUC, that minimizes dependency conflicts.
I hope Mark gets the Haskell job he wants!
Try Tweag https://boards.greenhouse.io/tweag (write a cold email if nothing fits in the list).
That's like picking a plumbing job because you get to work with hex instead of torx screws. As a professional solution-provider, you're free to offer only work with a specific set of tools but don't expect jobs to magically appear to accommodate your preference of tools. If you're a plumber, your worth is in the value you create and the tools are a footnote (which you might have to justify anyway). Software engineering is not any different.
That's like saying a painter should be happy to get a sculpting job, because he is a professional art-provider.
The other person’s analogy is better, yours sucks.
Using the previous analogy, but applying your critique, it would be asking the plumber to become an electrician.
Personally I cannot imagine being a programmer and only writing in one language. I currently code in multiple languages, and have forgotten more as well (at least I hope I don’t need PexBasic anymore)
Using the previous analogy, but applying your critique, it would be asking the plumber to become an electrician.
Personally I cannot imagine being a programmer and only writing in one language. I currently code in multiple languages, and have forgotten more as well (at least I hope I don’t need PexBasic anymore)
I recently had to choose between two job offers, and language was among the most important (although not the only) factors. I ended up choosing the job that lets me write functional Scala, rather than continue writing Python, which has been a major source of frustration in my current job.
A better analogy might be a carpenter who chooses to build houses in the traditional nail-free Japanese joinery style, vs the American nails-everywhere style.
A better analogy might be a carpenter who chooses to build houses in the traditional nail-free Japanese joinery style, vs the American nails-everywhere style.
well, some engineers are lucky enough to get to specify the environment that makes them the happiest, even if it's rare compared to the number of opportunities out there.
Philly is the best. Everyone should come to Philly!
Tontine Trust is making the global pensions industry Functional with a new OECD endorsed design described by a Nobel Prize Winning Economist as "a pension system for the world that can never go bankrupt". See: https://tontine.com
We always have room for more Haskeller mathematicians with solid experience.
We always have room for more Haskeller mathematicians with solid experience.
I would love a job writing Haskell but any of the jobs I’ve seen would involve a 6 figure pay cut. Haskell is such a joy to work with.
That's sad, but fair. You pay for the joy. In other words, demand is weaker than supply, compared to other jobs, like COBOL.
Looking for a job in a particular programming language, without saying anything about the problem domain, seems weird to me. But I suppose I'm unusual in that I've found a problem domain (accessibility) that I deeply care about, and will cross languages and platforms to work on projects in that domain.
I don't know if OP is going to see this.
I feel he'll be happy at Jane Street Capital.
They use OCaml though (and I think they have a large part in building OCaml), but I suppose an expert Haskeller would have no trouble at all picking up OCaml if they want to.
I don't know if they have remote work possibilities though.
I feel he'll be happy at Jane Street Capital.
They use OCaml though (and I think they have a large part in building OCaml), but I suppose an expert Haskeller would have no trouble at all picking up OCaml if they want to.
I don't know if they have remote work possibilities though.
To build smart contract fuzzers you usually use Haskell. I did my best here: https://twitter.com/pcaversaccio/status/1491014990140407814
It'd be interesting to see whether this guy got the job due to this HN post or not.
Honestly I'd just like a job writing code that actually benefits people or is even seen by the light of day. That isn't killed off by layers of mismanagement, "agile methodology", moving goal posts.
[deleted]
Tweag hired 50+ developers in 2021. We're aiming to hire 50+ developers in 2022. https://tweag.io/careers.
Chaos Group does some cool work in Haskell: https://www.chaos.com/all-products
Work at Mercury [0]. They train folks who haven’t used Haskell before.
[0] https://mercury.com/jobs
[0] https://mercury.com/jobs
The guy should just join Plutus Pioneers program and become one of the first certified Cardano developers. Can't those guys charge like $1000 an hour? LOL
I would like to hire a serious Haskell hacker.
[email protected]
[email protected]
No landing page, and the qualifiers are "serious" and "hacker". Just based on past experience this feels like an underfunded start-up position. Do something different if you take this project seriously.
We’re a garage band no doubt. We tend to do contract-to-hire, but we pay up-front, so we assume the risk of there not being a fit.
I haven’t done the elite interviewing rounds and been paid all the millions per year in SV in a while, but at least at that time this would have been a much better deal than anyone without a FAANG offer letter could get. We mark to levels.fyi, not Glassdoor.
I haven’t done the elite interviewing rounds and been paid all the millions per year in SV in a while, but at least at that time this would have been a much better deal than anyone without a FAANG offer letter could get. We mark to levels.fyi, not Glassdoor.
tiko.energy is hiring Haskell developers for roles in Zurich (Switzerland) and Milan (Italy). https://tinyurl.com/3v45m4kd (this goes to LinkedIn).
We probably would not consider someone as far away as Philadelphia on a permanent basis however, as we expect to operate at least a hybrid model in the future.
We probably would not consider someone as far away as Philadelphia on a permanent basis however, as we expect to operate at least a hybrid model in the future.
Cardano uses Haskell and Cardano smart contracts are exploding right now.
Startups everywhere, or start your own.
Startups everywhere, or start your own.
I would like a job using Motif to create GUI apps for UNIX workstations using plain C.
edit: messed up some words
edit: messed up some words
Check out mercury bank and hasura
I would like a job writing Clojure and/or Elm.
I would like a job writing any language.
I suppose "author" is out of the question.
I would like a job painting things green. It's kind of a category error.
Cardano. Plutus.
main = putStrLn "job"
I would like a job watching mexican soap operas.
Too bad all those jobs got automated.
I bet such a job exists somewhere, because someone has to watch each episode of the soap opera as a QA check before it gets aired.
My wife used to work as a translator for Netflix for a while; all the episodes get cut up in chunks of a few minutes that get doled out to different translators/QA people so that the plot does not leak out.
Wouldn't that potentially hurt the translations? Without getting the full context of the scene or plot you potentially misread some scenes.
In Haskell?
He can do what most Haskell folks do; write Haskell for fun, but earn a living delivering pizzas or making coffee.
This dude should apply for some jobs. As a hiring manager, I don't spend much time searching for blog posts about someone being interested in a new job.
The part about resignation without having a new job may be totally fine, but I'd be curious to understand the circumstances.
A person that confuses a job application with a blog post might get confused about other aspects of work responsibilities.
The part about resignation without having a new job may be totally fine, but I'd be curious to understand the circumstances.
A person that confuses a job application with a blog post might get confused about other aspects of work responsibilities.
they have a following on their blog, so rather than cold-apply to various (possibly terrible) companies and get thrashed around by their recruiters, they figure someone may be able to give them a high-quality lead and a foot in the door. Seems 100% reasonable to me.
> A person that confuses a job application with a blog post might get confused about other aspects of work responsibilities.
Are you serious about this? It seems like an extreme over-generalization and very unlikely to be true at all.
> A person that confuses a job application with a blog post might get confused about other aspects of work responsibilities.
Are you serious about this? It seems like an extreme over-generalization and very unlikely to be true at all.
It looks like the author needs to update their about page:
https://blog.plover.com/meta/about-me.html
> I may be best known for my book Higher-Order Perl, published in 2005 by Morgan Kaufmann, and for my other work in Perl. But as a programmer I consider myself uncommited to any particular language or system. As with everything else, I try to go for breadth rather than for depth.
https://blog.plover.com/meta/about-me.html
> I may be best known for my book Higher-Order Perl, published in 2005 by Morgan Kaufmann, and for my other work in Perl. But as a programmer I consider myself uncommited to any particular language or system. As with everything else, I try to go for breadth rather than for depth.
I don't understand. What part do you think needs to be updated?
Not the parent, but I'm guessing that you are here asking for a job in Haskell, but the about says:
> ... I consider myself uncommitted to any particular language ...
(Also, you mis-spelled "uncommitted")
> ... I consider myself uncommitted to any particular language ...
(Also, you mis-spelled "uncommitted")
I still don't understand. Do you?
(Thanks for pointing out the typo.)
(Thanks for pointing out the typo.)
Re typo: You're welcome.
Re the other: I think they feel it's contradictory for you to say that you're uncommitted to any particular language while at the same time specifically saying that you'd like a job programming in Haskell. I can see how someone might feel that there's a tension between those two assertions, but I don't see it as contradictory, nor as implying that the "About" needs modification.
It was probably just a throw-away comment, and not really worth close analysis.
<shrug>
Re the other: I think they feel it's contradictory for you to say that you're uncommitted to any particular language while at the same time specifically saying that you'd like a job programming in Haskell. I can see how someone might feel that there's a tension between those two assertions, but I don't see it as contradictory, nor as implying that the "About" needs modification.
It was probably just a throw-away comment, and not really worth close analysis.
<shrug>
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.