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#.
> worked on one of the biggest production
> Haskell code bases on Earth
While I think there's probably some low-range filtering going on with Haskell, I think that only shows that Haskell isn't that fit for writing much production software, since, for all the "smart people" very little has been done with Haskell.
What I think Haskell does attract are people that like to develop overwrought, abstract, and ornate systems. Another reason it hasn't proven to be terribly useful for production software.
I do like the experimental space languages like Haskell play in, and think there is strong net benefit to our field as a whole, by finding ideas that work when brought into that field. So I like people out there mucking around with different programming idioms/domains/approaches.
If I see significant Haskell or Lisp experience on a resume, I tend to be wary.
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.
Haskel. Perfect code for a perfect world.
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.
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”?
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.
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 :)
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:
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%.
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 mean, just look at the Haskell subreddit or Haskell weekly news?
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.
"If you're homeless, just buy a house"
- 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.
It is a common language in University CS-classes, so it gets a push from that.
What is missing from the platform?
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.
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.
That seems like a less dubious motive.
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.
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.
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.
Potentially Cardano could become one of the most significant uses of Haskell in the wild, if it gets traction of course
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.
ben@rocinanteresearch.net
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.
> 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.
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.
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.
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.
Try it out at demo.mercury.com
Jobs page: mercury.com/jobs
To the OP: I asked our team to reach out to you
full disclosure: I helped start proda.
Finally, someone who understands the magic sentence.
Seriously mate, good luck. I love Haskell too despite having no professional experience in it.
For what it's worth here's a list of Haskell hiring-related things I've come across. https://gist.github.com/hs211216/7e734535eadc869df26562b33db...
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.
Not any recent ones though. Also not sure if that’s because that site has grown old or because I have.
There's a mismatch in expectations here, from programmers to customers, via companies and hiring processes.
https://www.hubspot.com/careers/jobs/3630647?hubs_signup-cta...
(I'm not affiliated to HubSpot in any way)
We always have room for more Haskeller mathematicians with solid experience.
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.
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.
Startups everywhere, or start your own.
edit: messed up some words