The interesting thing this brings up is whether programming hiring is too specific. Why do we hire reactjs programmers with e-commerce experience instead of react programmers, e-commerce programmers, or programmers?
To me this guy sounds like he could do anything, just see if he's easy to work with and see if he likes your domain. He's certainly said enough about programming over the years that he shouldn't need a leetcode grilling.
Anyway my point was it can get quite narrow what we look for in a coder when in fact some broad experience might be just what is necessary. For instance I've coded apps for iPhone and Android despite being ostensibly a back end financial trader. I'd think a lot of coders wouldn't want to be siloed into the first thing they get a job in.
If the average tenure is 20 years and person A takes 1 month to become effective and person B takes 6 months, then person B has to be 2.1% more productive to be greater ROI. If the average tenure is 1 year then person B has to be 83% more productive for greater ROI.
Increased job liquidity means employers seek increasingly specific fit above all other considerations.
There is no programming job in the world that would take me six months full-time to become effective. Maybe a month, if it's an awful setup in an awful, unfamiliar programming language with unhelpful colleagues. It sounds like you're assuming if you hired a React programmer to work on your React app, it would take that programmer 1 month to get up to speed, while it would take a Haskell programmer 6 months. I claim: if your codebase is complex enough and your situation unusual enough that it would take a React programmer 1 month to write productive React code, the Haskell programmer will take 2 weeks. This is because the vast majority of the learning curve is in your domain and setup, not in how React components work. (Assuming for sake of argument they are actually smarter.)
People vastly overestimate how long it takes a decent programmer to learn new tech.
I've had a very hard time finding a new job given that my current job doesn't use any kind of "tooling" or outside libraries to get things done, other than rather obscure and domain specific ones (e.g. libgps). Ideally I'd like to pivot to web development given that I have some hobbyist experience with it, but I'm not very good at "specific frameworks".
If someone were to ask me to sit down and write something in React/Vue.js/whatever on the first interview, I don't think I could without the docs or a tutorial available. I can write JS just fine, I can't write any specific framework, even though I have the mental model and concepts behind how they work and how to use them. So when I see a job that specifically asks for e.g. React, I just don't apply. Same story with companies that ask for Django rather than the more generic "Python web development experience". I could pick up Django within two weeks if you hired me. I know what it is and what MV(C) is. Isn't that enough?
This is also the reason many companies rewrite code to new framework because they cannot find developers that know how to program in the old framework. Really narrow-minded if you ask me. You just need a good programmer than can easily learn new languages/frameworks. It might take a good programmer a week to learn a new language/framework.
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.
> If someone were to ask me to sit down and write something in React/Vue.js/whatever on the first interview, I don't think I could without the docs or a tutorial available
I've been in the web development doing all "ends" since I-lost-count-how-many years and even with a library which has rather a small API surface like React, I also need to search things every once in a while. If they don't allow you to do that in an interview, they have unrealistic expectations.
> I could pick up Django within two weeks if you hired me. I know what it is and what MV(C) is. Isn't that enough?
Most of the time, it is enough. There is also an unlikely chance that they have a lot of complexity and need someone who knows the internals and can fix obscure bugs. That probably wouldn't be you for Django/React. I sometimes was that person in the past and it's very stressful so, it's not something a developer would seek to become anyway.
I guess their point is "why don't you go ahead and learn django in 2 weeks, sacrifice a few weekends and nights so you can blow away the easy pitches we're tossing at you during the interview". Pick a web framework and learn it and then you at least have a basis for your claims.
I'm currently working with a C++ dev who has exactly zero previous experience with the web, but because he essentially finished his part of the system, he picked up web-related tasks.
My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program".
I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form.
I don't agree with this assumption because of a hidden variable: time.
Even the smartest person on this planet still needs time to learn things.
Someone just starting to use a new environment won't have the months and years of practical experience with the many frameworks and libraries out there. They won't have the battle scars to know out why one library is better than the other one for this specific use case. They won't have the experience to know why structuring the code in this specific way is better than the other way.
And thing about the other myriad gotchas every environment has, that someone only picks up over time, as they try to use all the corners of a specific software stack.
I mean, yeah, sure, a smart dev will look up best practices and carry over some of their existing experience, but unless they're a true polyglot (and that takes many years as you probably need at least 1 super intense year with each or more like 2-3 years with several), they will still be a solid mid level dev, but not a true senior dev using the new framework.
> 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'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.
> 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.
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.
My feeling is a lot of that is driven by recruiters. It's probably a lot easier to sift through dozens of resumes by looking for keywords. It's a bit shit though. There's plenty of jobs I'd like to apply for specifically because they advertise that they use technologies I haven't worked with. I could spend the time trying to convince them I can learn quickly and my other skills make me an asset, but I'm afraid of it being a waste to do so if a lack of "X years experience in Y" trips some red flag.
As an aside, advertisements for developer positions need some sort of intervention. I'm tired of not knowing who the company is ("Exciting opportunity with growing startup in the whatever space!"). I also see things like "experience with object-oriented programming required". These days that's like saying "we're looking for a driver who has experience with steering wheels" and really puts me off.
I spent my entire job hunt last year, neglecting to apply for positions that interested me, because whether I thought I was capable or performing or not, I know that my resume, basically just a projection of my past experience, would never get me through the resume screening step. Actually in fact, the first few applications I put in never made it past screening and I couldn’t even be mad. It made perfect sense why on paper I’m not qualified.
I could probably find a way to make myself look qualified, but it’s be a lot of work and frankly, I haven’t had the drive or passion for programming required to do that for years. Probably just easier to quit and find some new career at this point.
He's easy to work with. I was a technical reviewer on his book, and not only was he extremely good at communication, he gracefully handled stupid bullshit from me that nobody could reasonably be expected to handle. In terms of interpersonal ability, I think he's head and shoulders above the crowd.
We tend to get hired for what we've done before, rather than for what we want to do in the future. Although it wasn't always like that for me. For a long time I felt it was totally normal to learn a completely new language for a new job.
My first job was Visual C++, my second job was Java and XSLT, my third job was Ruby, my fourth was Groovy with some Java and Ruby. Then after some more Java and Ruby, I ended up in Javascript + Angular, then Typescript + Vue, now Typescript + React.
I feel like I'm fairly lucky in that I at least still get to hop frameworks; there are tons of people who've been doing Java+Spring for 20 years now. I wouldn't mind moving to Kotlin or Scala, but that's hard to find. At least for me; most recruiters still look at what I did in the past, and they see a lot of Java, so they assume that's what I do.
Hiring for a particular language/framework/ecosystem combination almost always limits the prospects for the employer. Any seasoned programmer with some C, Python, Java and JavaScript experience can get up to speed with your shiny UI or cloud framework and won't brag about it. The opposite is rarely true. That AWS, Node.js or Blockchain expert can hardly write a Python module in C.
Good programmer can switch niches and will still be a good programmer, there's no doubt about it. Problem is that it still takes some time. You can't just pick up a new language (or even just a new framework) and immediately start producing your best code. It takes time to pick up the style and best practices, and to learn all the nuances. Also very importantly to embrace that new mindset, which can be sometimes hard when you've been doing something in a particular way for long time. There's always that warming up period where you instinctively still try to stick to your habits from the previous language, and you end up with Frankenstein looking code for a while.
There are certainly Haskell jobs in the Bay area. No idea about Philadelphia. MJD doesn't seem to have embarked on a Haskell job search so far, beyond the blog posting announcing his availability. So my bet is that he gets plenty of takers.
The Philadelphia tech job market exists, but...it's not like New York/Boston/SF. The major players are Comcast(...), Vanguard and a smattering of Big Pharma companies. There is a startup scene (most notable success likely being Gopuff), but not a huge one.
Thankfully, the remote situation has improved dramatically, so I agree, they should be ok :)
It really depends on the size and resources of your company. I used to work for a large French ecommerce company where most of the stack was in Clojure and most of the people we hired were totally new to this language and/or were Clojure fans but were new to the ecommerce world. It didn’t really matter as long as they were motivated because we had the resources to train them and give them time to learn.
I left ~1 year ago to join a very early-stage startup where we’re currently 5, and while I would love to hire people that don’t master at least most of the stack we use, I just can’t because we really don’t have the resources to afford to have someone spending time (their time and also other people time) learning everything. This probably an extreme example but it illustrates the point: even if you’d like to hire people in a broader spectrum, you can’t always afford to. [ I hope that at one point we’ll be able to do it :) ]
I somewhat agree with your point, but the I think software developers underestimate the difficulty in getting someone up to speed when the "tech stack delta" is significant. Every piece of technology you need to learn isn't a linear increase in time, but rather more quadratic. Learning just k8s might take N weeks, and learning Go might take M weeks, but learning k8s and Go at the same time takes more than N+M weeks, and might take something more like N X M weeks (or really 0.1N X 0.1M or something). Learning one tech while also learning another tech makes each more difficult. I push employers to understand this and instead of throwing people into the tech pile, have them hit each tech bit one at a time, but the sink-or-swim belief is strong.
Personality in my opinion and humility are the biggest two things when I care about who my team mates are. If you have more than one hot head you are not going to be happy, they will eventually clash and one or both or more will try to leave. Programming can get frustrating and stressful on its own, why add to the fire?
People learn to program over time. You want to resolve bugs the sooner the better, if you spend all day arguing or you’re working with one of those “its not my code my code is perfect” types you’re going to have to do more work to get things moving. People who think they know it all can hold you back, some devs are great at some things at the same time some at others. Find a nicely balanced team that can work together.
Why do we hire reactjs programmers with e-commerce experience instead of react programmers, e-commerce programmers, or programmers?
We do hire less specialized programmers, we just don't pay them at the scale that someone with 30 years of experience might expect. If the job really needs someone that knows a specific tech immediately then the expectation is that a candidate has at least pursued a decent amount self-learning, which for someone with 30 years of experience should be easy to do in a couple of weeks. (The author here has done that*) All else being equal we still wouldn't pay them the same as someone with 5-10 in that specific tech though.
I wonder if it’s a signal of how much their are willing to
Invest in people. I’ve been interviewing recently and have seen many companies are explicitly “we don’t care about language exp we will teach you, we want good ppl”.
I've been in the industry for ten years, and this is the first time I hear about asking for things like "e-commerce experience". My CV consists of telecom, e-commerce, fintech, mobility and music industry.
Is it really like that somewhere? In the US, or in particular domains, or in particular technology space? If it matters, I've mostly been working with JVM, but two quite different paradigms - Java (OOP) and Scala (pure FP; I understand everything the haskell guy talks about).
I've had an interviewer literally stop the interview to give me career advice when I told him I was a generalist. His advice was that whenever he hears about someone who's a full stack generalist he knows they aren't that good. His advice was to specialize and get really really good at something.
Keep in mind I'm super senior. Much older than most people in this industry.
Fully agree, the only reason I have some stuff on Github it isn't even for the joy of doing FOSS and contributing to a better world, rather to keep HR happy that I am actually proficient on stuff done as hobby coding.
However that is something that most families cannot manage, and one cannot be expected to create portfolios on SCM of the year just to prove their skillset.
I cannot answer either the more broad or more specific questions in these threads. But my 2 cents as to:
"Why do we hire reactjs programmers with e-commerce experience instead of react programmers, e-commerce programmers, or programmers?"
In my neck of the woods, we generally hire specifically PeopleSoft Programmers, ideally with Payroll experience. Here's why:
1. First and foremost, developers need to do more than spit out code. They need to thoroughly understand business problems, work with business analysts and product owners to hash out requirements, be able to meaningfully discuss these requirements, create design that they can independently sanity-check meets these requirements, and then work on translating it into code.
2. They need PeopleSoft experience and knowledge - it's a specific ecosystem and language with specific requirements and constraints and capabilities. Programmer needs to fully understand these early on when they discuss requirements and solution with business.
3. Payroll experience helps, again for them to be able to discuss things meaningfully with the business.
I know that this ("Dev needs to be able to gather requirements") is self-evidently true across development world, but I want to underline that our developers can meaningfully discuss intricacies of Canadian and Provincial tax code, payroll processes and regulations, time and labour, benefits, pension, and other adjustments with their functional counterparts; while also having meaningful discussions with our DBA & Infra teams on indexes, stats, etc. All in the specific world of PeopleSoft where code resides in database, with specific component processor which offers about 30 different ways to trigger code on a page, while ensuring data integrity etc.
With that in mind, historically, it's just as easy and perhaps easier/faster/cheaper, to train a new grad (and we do, a lot!), rather than get somebody experienced in a completely different ecosystem and try to retrain them.
Now, PeopleSoft is a very specific (quirky, legacy, idiosyncratic, crazy, etc) ecosystem, but I think using it as an extreme example may show some of the core reasons why even in less extreme environments, requirements are fairly specific. Yes, a good programmer with wide experience has a lot of skills. But by numbers, I think most devs work in business areas with specific set of common industry/sector problems and solutions, which reward specialization.
Why React at all? Is JavaScript really that horrific or does nobody know what they are doing?
I suspect the goal is to widen candidate availability to the maximum, cast the widest net. I find this odd because compensation is now absurd competence, experience, and product quality be damned.
you have to fit into the company's software ecosystem, if everyone uses php or python there and you do Haskell it does not matter if you're a MIT PhD that happens to be a Haskell core developer that can rewrite chrome in Haskell in a month, it just does not fit.
That been said, there are definitely companies need Haskell developers, it just has less positions for a smaller pool of developers.
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.
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.
“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 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.
> 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.
> 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.
>This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming).
Those people dicking around with C++ templates make the whole project slower to compile and more difficult to understand though. I don't really know anybody that can easily read the finished template magic that you need to achieve anything meaningful in C++. Something which I think is not so much the case with using a good type system fully.
Agreed. I don’t have anything near your experience, but I have done Haskell in production for two years, and other things for longer. And yet I always say I’m not smart enough to use a language like JavaScript, I need a dumb language like Haskell :-)
Anecdotally, and counter to yours: I’ve generally found that people who focus on a language for the intelligence attributes it supposedly implies of users are often simply deep experts in that language and it’s application mistaking that expertise for general intelligence.
I 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.
>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).
> 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.
> Haskell people skew smarter than most other languages.
In my experience this has nothing to do specifically with Haskell, but more a somewhat-time-varying collection of niche languages. e.g. Haskell roughly equivalent to lisp programmers roughly equivalent to [a few others], but not equally likely to find them 1998/2008/2018 or whatever.
There is a flip side though, which is that a subset of them are not actually good team members. Depending on your project and team scale and role for them this can either not really matter or be deadly.
That's true of any medium-small language, though. I'd argue it isn't true for the smallest of languages, because there's a genre of small languages that are made largely to trap nontechnical people into bad decisions, but it's true for all of the medium-small languages.
Languages that are niche enough to require passion to find and get running average a much better quality programmer, because why wouldn't they? Tesla drivers are, on average, better drivers, because fewer teenagers drive expensive cars. Conlangs have the highest intelligence per speaker, on average, because they require intention to learn. Subscription MMORPGs have the smartest players, because a $15/mo subscription filters out most children. Nearly two decades ago, the guy who made this forum wrote a post about this exact phenomenon with Python, before Python was actually relevant in the industry or had a million resources to learn. Filters work.
You aren't saying something controversial; you're just saying a more limited version of something that everyone already knows because you have tunnel vision. Filter the worst half out, and shockingly, the average looks better. This is a novel idea and you are a genius for coming up with it.
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.
> 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.
> This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming).
I'm not sure why you say this is dicking around as the payoffs for moving things higher up are usually orders of magnitude better
I'd tend to agree. Every time I do any functional programming (which is rare), it leaves me with a 'better way to do this' feeling and a different view on things when I go back to writing a regular OOP language.
On the other hand, I've worked with a lot of C++ programmers, that tend to be a bit smarter than the Java/C# programmers I've worked with. But, and it's a big but, some C++ programmers I've worked with really do have the Dunning Kruger effect. They write what they think is "smart code", but it's really horrifically complex code, that others have mentioned here as too complex for the next guy to easily debug. "If I had more time I'd have written less".
(disclaimer, I clearly suffer from DK based on what I've just written...)
Language isn’t the be-all end-all of a software project. I’ll take a well maintained and well documented Java codebase over a write-only Haskell codebase with more lines of language extension imports than lines of comments.
Software developers who only look for jobs always in That One Language freak me out.
Yep. I wanted a job writing haskell. Got a job writing haskell. It was one of the worst jobs I ever hard (for non-haskell reasons). Team dynamics, culture, how good is a manager, how overengineered is a code base, how easy it is to feel valued and given responsibility. There's so many more important things than the language that now I actively don't care at all. Plus, I think these elitist programming languages attract more jerks so I'd rather avoid anything too niche and go for a Go job or something.
I'm not that sure about "for non-haskell reasons".
Haskell seems to select for people who enjoy going off on puzzling tangents, and it seems like it takes so much learning that for many, meta skills such as good engineering and communication practices fall by the wayside.
> Language isn’t the be-all end-all of a software project.
Certainly not, but at some point you make a move to scratch an itch. Sick of doing typeless python with runtime issues everywhere? A typed language may be a good break from that. Annoyed of Haskell in a company where people care more about their exceptions than about the business? Maybe you'll do the opposite move.
It's not so much about doing things the one right way as experimenting with what makes you productive and happy. And if people find they're comfortable doing that one thing only, good for them.
Same. Left it for job that doesn’t involve Haskell and far happier. Turns out picking jobs based on technology misses other important factors like what the technology is used for and how a workplace treats its people. Now I use technology I’d rather not, but in a super positive environment, and I’m happier than I ever was before.
> Now I use technology I’d rather not, but in a super positive environment, and I’m happier than I ever was before.
I tried that, but knowing the issue your whole team faces or that is putting you in a crunch would have or likely been avoided with a better language was too grating for me.
Agreed on most points there. On the flip side, I was running away from That One Language (Java). I was put off by its verbal diarrhea (when it came to naming classes - blame it on Spring perhaps). And the gratuitous use of OOPs concepts (which I attribute to being a scripter for much of my working life). Perhaps it was more to do with the organization I worked for, it might have been a very (toxic) culture thing that they encouraged - 1) If you didn't know Java you weren't cool. 2) If you didn't know Java you didn't understand OOPs. Lots of companies have such culture issues over languages. Its managers/leadership's job to ensure the tool doesn't become the master, to the detriment of goals.
I've been deliberately been a slow-poke when it came to absorbing languages, far from the bleeding edge within the ecosystem I was in. Hasn't hurt at all. Pushing back on trends (once you're 'inside' a language) means you are looking around, and absorbing more of the problem (business domain).
If you emerge from an old-job into a new-job, and the only take away is bleeding-edge language/platform features, there's some richness of experience that's been missed IMO, maybe its useful at early career stage, but you need to see the whole picture, not just uber details about a language.
> I’ll take a well maintained and well documented Java codebase
I get your point but at some point the boilerplate becomes depression inducing for me, I can't see myself being motivated to work on a Java codebase, the language and the patterns that arise from it just get in the way of solving the problem too much. It's like having to do a relatively easy job but only being allowed to use one hand, it becomes frustrating that you can't use both hands when you see it would take 1/2 effort and then I become even less motivated to work and it's a bad spiral :)
Something similar happened to me. I worked at a job where someone proposed using a purely functional React framework. Ironically I ended up implementing most code and everyone else left eventually so I worked on it alone. People underestimate how non-standard that stuff is. Nowadays I rather avoid using a Functional programming language although I've seen also other companies using or considering pure FP but it's usually a one man army...
Yeah, I recently took a job with a language I don't really know and don't really like. I'm doing it because it's for a beneficial and positive product that I'm happy to improve for customers.
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.
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.
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#.
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.
All he's done is write a blog post yesterday saying "does anyone want to give me a Haskell job? I have no substantial experience in Haskell". Bit early to say he can't land a Haskell job.
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…
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.
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.
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.
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.
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.
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)
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.
> 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.
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.
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.
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.
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?
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.
There's other things in the world than money. Even if that is your philosophy, consider that learning obscure functional languages might make you a better programmer across the board.
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 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 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:
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?
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.
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.
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.
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).
Readit News
To me this guy sounds like he could do anything, just see if he's easy to work with and see if he likes your domain. He's certainly said enough about programming over the years that he shouldn't need a leetcode grilling.
Anyway my point was it can get quite narrow what we look for in a coder when in fact some broad experience might be just what is necessary. For instance I've coded apps for iPhone and Android despite being ostensibly a back end financial trader. I'd think a lot of coders wouldn't want to be siloed into the first thing they get a job in.
Increased job liquidity means employers seek increasingly specific fit above all other considerations.
People vastly overestimate how long it takes a decent programmer to learn new tech.
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?
Something like CSS would be much harder to fake.
I've been in the web development doing all "ends" since I-lost-count-how-many years and even with a library which has rather a small API surface like React, I also need to search things every once in a while. If they don't allow you to do that in an interview, they have unrealistic expectations.
> I could pick up Django within two weeks if you hired me. I know what it is and what MV(C) is. Isn't that enough?
Most of the time, it is enough. There is also an unlikely chance that they have a lot of complexity and need someone who knows the internals and can fix obscure bugs. That probably wouldn't be you for Django/React. I sometimes was that person in the past and it's very stressful so, it's not something a developer would seek to become anyway.
My manager today was wondering if that's particularly efficient, to which I replied "he knows how to program".
I mean, the guy has a PhD in physics - I bet that what he's doing now isn't even his final form.
Even the smartest person on this planet still needs time to learn things.
Someone just starting to use a new environment won't have the months and years of practical experience with the many frameworks and libraries out there. They won't have the battle scars to know out why one library is better than the other one for this specific use case. They won't have the experience to know why structuring the code in this specific way is better than the other way.
And thing about the other myriad gotchas every environment has, that someone only picks up over time, as they try to use all the corners of a specific software stack.
I mean, yeah, sure, a smart dev will look up best practices and carry over some of their existing experience, but unless they're a true polyglot (and that takes many years as you probably need at least 1 super intense year with each or more like 2-3 years with several), they will still be a solid mid level dev, but not a true senior dev using the new framework.
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.
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.
As an aside, advertisements for developer positions need some sort of intervention. I'm tired of not knowing who the company is ("Exciting opportunity with growing startup in the whatever space!"). I also see things like "experience with object-oriented programming required". These days that's like saying "we're looking for a driver who has experience with steering wheels" and really puts me off.
I could probably find a way to make myself look qualified, but it’s be a lot of work and frankly, I haven’t had the drive or passion for programming required to do that for years. Probably just easier to quit and find some new career at this point.
I sent him a more detailed message about this but I wanted to have it on the record here.
Kragen: Thanks for your kind words. I am happy to know that you found me easy to work with.
My first job was Visual C++, my second job was Java and XSLT, my third job was Ruby, my fourth was Groovy with some Java and Ruby. Then after some more Java and Ruby, I ended up in Javascript + Angular, then Typescript + Vue, now Typescript + React.
I feel like I'm fairly lucky in that I at least still get to hop frameworks; there are tons of people who've been doing Java+Spring for 20 years now. I wouldn't mind moving to Kotlin or Scala, but that's hard to find. At least for me; most recruiters still look at what I did in the past, and they see a lot of Java, so they assume that's what I do.
If the purpose of the test were to evaluate the applicant’s technical ability, then this would be true.
I’ll lay odds that is not the purpose of the testing, though.
Thankfully, the remote situation has improved dramatically, so I agree, they should be ok :)
I left ~1 year ago to join a very early-stage startup where we’re currently 5, and while I would love to hire people that don’t master at least most of the stack we use, I just can’t because we really don’t have the resources to afford to have someone spending time (their time and also other people time) learning everything. This probably an extreme example but it illustrates the point: even if you’d like to hire people in a broader spectrum, you can’t always afford to. [ I hope that at one point we’ll be able to do it :) ]
People learn to program over time. You want to resolve bugs the sooner the better, if you spend all day arguing or you’re working with one of those “its not my code my code is perfect” types you’re going to have to do more work to get things moving. People who think they know it all can hold you back, some devs are great at some things at the same time some at others. Find a nicely balanced team that can work together.
We do hire less specialized programmers, we just don't pay them at the scale that someone with 30 years of experience might expect. If the job really needs someone that knows a specific tech immediately then the expectation is that a candidate has at least pursued a decent amount self-learning, which for someone with 30 years of experience should be easy to do in a couple of weeks. (The author here has done that*) All else being equal we still wouldn't pay them the same as someone with 5-10 in that specific tech though.
Is it really like that somewhere? In the US, or in particular domains, or in particular technology space? If it matters, I've mostly been working with JVM, but two quite different paradigms - Java (OOP) and Scala (pure FP; I understand everything the haskell guy talks about).
Keep in mind I'm super senior. Much older than most people in this industry.
However that is something that most families cannot manage, and one cannot be expected to create portfolios on SCM of the year just to prove their skillset.
"Why do we hire reactjs programmers with e-commerce experience instead of react programmers, e-commerce programmers, or programmers?"
In my neck of the woods, we generally hire specifically PeopleSoft Programmers, ideally with Payroll experience. Here's why:
1. First and foremost, developers need to do more than spit out code. They need to thoroughly understand business problems, work with business analysts and product owners to hash out requirements, be able to meaningfully discuss these requirements, create design that they can independently sanity-check meets these requirements, and then work on translating it into code. 2. They need PeopleSoft experience and knowledge - it's a specific ecosystem and language with specific requirements and constraints and capabilities. Programmer needs to fully understand these early on when they discuss requirements and solution with business.
3. Payroll experience helps, again for them to be able to discuss things meaningfully with the business.
I know that this ("Dev needs to be able to gather requirements") is self-evidently true across development world, but I want to underline that our developers can meaningfully discuss intricacies of Canadian and Provincial tax code, payroll processes and regulations, time and labour, benefits, pension, and other adjustments with their functional counterparts; while also having meaningful discussions with our DBA & Infra teams on indexes, stats, etc. All in the specific world of PeopleSoft where code resides in database, with specific component processor which offers about 30 different ways to trigger code on a page, while ensuring data integrity etc.
With that in mind, historically, it's just as easy and perhaps easier/faster/cheaper, to train a new grad (and we do, a lot!), rather than get somebody experienced in a completely different ecosystem and try to retrain them.
Now, PeopleSoft is a very specific (quirky, legacy, idiosyncratic, crazy, etc) ecosystem, but I think using it as an extreme example may show some of the core reasons why even in less extreme environments, requirements are fairly specific. Yes, a good programmer with wide experience has a lot of skills. But by numbers, I think most devs work in business areas with specific set of common industry/sector problems and solutions, which reward specialization.
I can see why that works for the employer but as an employee I would be terrified of that becoming a career dead end.
I suspect the goal is to widen candidate availability to the maximum, cast the widest net. I find this odd because compensation is now absurd competence, experience, and product quality be damned.
That been said, there are definitely companies need Haskell developers, it just has less positions for a smaller pool of developers.
This comes with downsides around dicking around with trying to jam every part of the computation into the type system (not unlike C++ template meta programming).
But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.
Source: worked on one of the biggest production Haskell code bases on Earth, was involved in early design discussions on both React and Ember, and wrote big pieces of an ECMA-262 compiler/VM.
Haskell people skew smarter than most other languages.
Sorry for saying it out loud.
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.
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.
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.
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.
(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.
Those people dicking around with C++ templates make the whole project slower to compile and more difficult to understand though. I don't really know anybody that can easily read the finished template magic that you need to achieve anything meaningful in C++. Something which I think is not so much the case with using a good type system fully.
Anecdotally, and counter to yours: I’ve generally found that people who focus on a language for the intelligence attributes it supposedly implies of users are often simply deep experts in that language and it’s application mistaking that expertise for general intelligence.
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.
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).
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.
In my experience this has nothing to do specifically with Haskell, but more a somewhat-time-varying collection of niche languages. e.g. Haskell roughly equivalent to lisp programmers roughly equivalent to [a few others], but not equally likely to find them 1998/2008/2018 or whatever.
There is a flip side though, which is that a subset of them are not actually good team members. Depending on your project and team scale and role for them this can either not really matter or be deadly.
Languages that are niche enough to require passion to find and get running average a much better quality programmer, because why wouldn't they? Tesla drivers are, on average, better drivers, because fewer teenagers drive expensive cars. Conlangs have the highest intelligence per speaker, on average, because they require intention to learn. Subscription MMORPGs have the smartest players, because a $15/mo subscription filters out most children. Nearly two decades ago, the guy who made this forum wrote a post about this exact phenomenon with Python, before Python was actually relevant in the industry or had a million resources to learn. Filters work.
You aren't saying something controversial; you're just saying a more limited version of something that everyone already knows because you have tunnel vision. Filter the worst half out, and shockingly, the average looks better. This is a novel idea and you are a genius for coming up with it.
Well that’s me out. I’ll stick to JavaScript and C#.
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.
You can write good code in any language and likewise with bad code. What does it say about a speaker who makes such surface level and broad sweeping statements about a user based on the tool rather than the user's experience?
At least to me, it smells of unrigorous thinking. It's an unprincipled stereotype that conflates cause and effect.
I'm not sure why you say this is dicking around as the payoffs for moving things higher up are usually orders of magnitude better
On the other hand, I've worked with a lot of C++ programmers, that tend to be a bit smarter than the Java/C# programmers I've worked with. But, and it's a big but, some C++ programmers I've worked with really do have the Dunning Kruger effect. They write what they think is "smart code", but it's really horrifically complex code, that others have mentioned here as too complex for the next guy to easily debug. "If I had more time I'd have written less".
(disclaimer, I clearly suffer from DK based on what I've just written...)
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.
Dead Comment
Haskel. Perfect code for a perfect world.
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.
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.
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.
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'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.
map[string]interface{}, pervasive null, and lack of sum types kept pager duty ringing.
> 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 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 :)
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.
- 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.
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.
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.
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…
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 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.
Deleted Comment
Seriously, F# is used a lot more than you might think in the financial world!
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.
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.
Also, having the discipline to study to improve your skills, will most definitely be beneficial in other spheres of your life.
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)
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.
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.
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.
Isn’t the adage “A players hire A players, B players hire C players”?
Deleted Comment
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?
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.
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 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?
Also, if you are looking for an F# job, ping me and we can chat :)
There's other things in the world than money. Even if that is your philosophy, consider that learning obscure functional languages might make you a better programmer across the board.
It's a good thing.
Deleted Comment
Deleted Comment
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 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.
There is Haskell Weekly with weekly job offers:
https://haskellweekly.news/issue/301.htmlhttps://haskellweekly.news/advertising.htmlI 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.
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 mean, just look at the Haskell subreddit or Haskell weekly news?
Potentially Cardano could become one of the most significant uses of Haskell in the wild, if it gets traction of course