Hacker News Reader

Comment by whateveracct | Hacker News Reader

Yep I've seen seniors/principals come in and steamroll people trying to do FP by claiming that it was inscrutable and irresponsible. Sometimes even going up the chain to cause shake-up without the team's input. Even though said FP was in production, working with a low bug rate, and the entire team was fine with it. And I've seen this happen at multiple companies.

I've come to think it's the biggest existential risk to doing Haskell in industry - it's red meat to org-chart climbing sharks. And the people who tend to be willing to learn and do FP in prod tend to not be politically-minded (usually due to strong principles and values), making them even weaker to these attacks.

View on HN

Heh, I was once walked through a live “code review” where all my code that used Java steam maps were replaced by this one dude with for loops in private methods. What a dress-down… pff, the project was canned a few months after I left. But I’m a consultant, no long term investments

Man, I got a story not with Streams but with its C# cousin, LINQ. A long time ago I've seen a senior engineer totally lambasting a junior because the junior used a LINQ ORM.

He saw DB.Users.Where(a => a.Id == 1) on the screen and launched a tirade of "Are you retarded? You're downloading the whole Users table when you do that!"

It was fun watching our boss explain how LINQ worked and seeing the shame in the engineer's face.

I've never really worked with C# before but I assume that query is about as efficient as a similar SQL statement?

Exactly.

LINQ allows you to use the same syntax for both local arrays and in an ORM, or any data source really, if you implement its IQueryable interface. You implementation can "parse" the AST and generate an SQL query, like a regular ORM.

I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start.

A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.

The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out. As I said, the team was fully functional, in production, low bug rate, generally happy.

Is it really cheaper to rewrite an entire working system (that took a year+ to build in the first place) than to just learn something new? I have learned a new language in order to inherit a working, hardened, well-made system before. But I am finding for certain senior engineers, the answer to "can I learn a new language" is a resounding no. The cost is infinite, so of course it's cheaper to rewrite. Plus they are incentivized to rewrite thanks to political reasons (i.e. it's a great way to get promoted).

The last time it happened, I was lucky enough to be accidentally shielded from accountability due to the organizational quagmire that resulted from the team blowing up. I basically got to do nothing for a year and make $200k. And I got to be less than useful to the principal who made the powerplay (not -10x level but I did get to spend time maintaining the existing FP system due to it having a single production consumer left). That dude did not like that I never turned my camera on. My manager also seemed pretty checked-out, so that was extra buffer.

So to summarize, I'll say that it's easy to have be prescient when you make self-fulfilling prophecies. That's one skill I've learned from senior management over the years.

Now, every time you hire an engineer they need to spend weeks or months learning Haskell on top of everything else. It now costs the business an extra 50K every time you get a new developer.

I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.

There are more costs than onboarding costs.

Also it's not hard to hire Haskellers or Haskell-adjacent devs. Haskell in fact makes you stand out. Those sorts of people don't need months. I've seen people new to Haskell make their first commits within a week. And they weren't geniuses or anything. But they also didn't have an attitude about it.

I guess the problem with Haskell is not really hiring, but it is simply a very hard sell to people without academic background. Haskell is for sure elegant, and has some cool features, but this is too little to get wide adoption.

Seriously, what important industrial problems does it solve? Explain it to me like to a manager you met in an elevator. If you say e.g. lower bug rate, then be prepared to show some evidence (and no, please don't compare it to Python or other dynamic languages).

So "bug rate" is not a real hard metric anyways. And I only have my experience to go on.

But I will say that bugs in Haskell tend to be easier to diagnose (helpful at 2am) and aren't usually bad (although they can be). I have debugged Other People's Code while on-call in Haskell way easier than any other language.

And finally, the vast majority of bugs can be prevented or curbed by the type system. I find every time a Haskell company runs into a nasty bug or annoying issue, libraries that make use of the type system are made that reduce or remove that class of bug entirely. This sounds like you can do it in every language, but really what can be made a "library" in Haskell dwarfs what you can reasonably library-ify in most other languages.

Now, I can't give quantitative evidence of this because I don't even know how I would begin to measure it. But these qualities are definitely a big reason why I don't even listen to job offers that aren't Haskell anymore (going on 10 years of that soon) and I have and will promptly quit a job if the company moves off Haskell.

> I like Google's strategy of having the simplest language that anybody can pickup as fast as possible. Go.

And then you lose 50k whenever the app crashes in production because someone forgot a nil/err check and your tests didn't catch it. Or you pay extra 50k whenever the whole team needs to spend a week on finding a race condition caused by someone accidentally mutating a shared slice, 20 layers below the place the corruption was seen for the first time. Or you spend extra 50k over the year for fixing all the resource leaks caused by missing defers. Or you spend 50x50k to rewrite everything in a more performant stack because of GC pauses (Discord) ;).

There are multiple ways a project can fail or add unexpected costs, and likely there's no silver bullet. There are trade-offs.

And, btw, as for simplicity, there are dozens of languages easier to learn than Go. E.g. scratch, basic, brainfuck. Why not use them? ;)

Simplicity of a language has it costs. Programs written in simpler languages tend to be more complex to compensate for lower expressive power.

> The only reason the 10+ authors (all plenty skilled in Haskell either before joining or due to working on the project) were all gone is because said senior came in and pushed them out.

Yeah, but if the stack was something common then it still wouldn't be as big a problem.

I think you're missing my main point which is that it didn't happen. The project was successful and chugging along.

It was only when a drive-by principal engineer got wind of it that there were problems. "We don't use Haskell here" was literally the only argument for rewriting it. Nobody left before then. We were hiring people fine. The problems you are FUDing around didn't exist.

In fact, the rewrite was so slow and off-target that I had to maintain the Haskell project through a peak season with a skeleton crew of two other people who didn't leave. And we didn't even have an outage - I didn't even get paged! The project got to make the company millions of dollars yet again.

When the rewrite finally started to form, it actually had significantly less functionality than the Haskell implementation. The internal users complained so much about that. And it took just as long to create. What a failure that rewrite was.

In the end, it was the attitude you are espousing that killed the project, not anything technical or hiring-/team-building-wise. It was literally just an opinion not to use Haskell by a guy who couldn't be bothered for the life of him to try to understand it.

Isn't that kind of self-fulfilling?

Only choose technologies that are popular for production stacks -> more people using those technologies professionally(implying less using others) -> only choose popular technologies -> etc.

From a "making a quality product" standpoint it would make more sense to me to choose the technology intelligently according to the needs of the product. Anything less is just a business mythology about trying to deliver a lower quality product for a lower cost.

> From a "making a quality product" standpoint it would make more sense to me to choose the technology intelligently according to the needs of the product. Anything less is just a business mythology about trying to deliver a lower quality product for a lower cost.

The "needs of product" should include "long term maintenance cost".

They should and I'm not saying to write it in a new language just because it meets the needs a little better. But in a world where the primary motivation for most things is profit, do you think "developer/maintenance costs" are having a little too much weight in the decisions.

It's easy be prescient when you make self-fulfilling prophecies.

Uugggghhh… “maintainable way” is again super subjective. Normally when people say that what they really mean is in a way that fits a pattern familiar to them.

If software stopped pandering and coddling developers who cannot be bothered to read code we would not need conversations like these. We also wouldn’t need a bunch of superficial nonsense most developers believe they cannot live without. Most companies drastically over spend on finding and retaining developers that aren’t qualified to be there in the first place when really in most cases it’s just about trying to put text on a screen. These companies would save so much money finding people off the street, evaluating them against minimally required intelligence and just training them to read and write code in house.

> Uugggghhh… “maintainable way” is again super subjective.

It's not "super subjective" when something super niche like Haskell[1] is chosen.

There are pragmatic reasons to choose a tech stack, the biggest of which is "can we find people to maintain it?". If you cannot, then it's unmaintainable.

[1] That's the example that was chosen upthread.

You know there are entire companies using Haskell in production successfully and have been for years, right?

The number of companies using boring old Java, C#, C++ dwarfs your number by several orders of magnitude.

So that's proof that you should never deviate? Hegemony always wins?

You're gonna take heat for that position, but I'd support you, having been in the same position. Came to a team in a company that had a handful of services where folks had been "doing things" in an FP manner where it was entirely inappropriate (CRUD app, without going into details). The had wonderfully illegible, but functional, code that was lacking required basics like transaction management, yet were befuddled as to why certain integration tests or deployments were behaving unpredictably. Similar to your situation, the original decision makers were long gone by the time I arrived.

It never ceases to amaze me how far you can get with going back to basics of solid software engineering and the manifestations of those basics, mainly:

1. OOP to prove that you have a good grasp of the domain and problem space. Show me you know what's actually happening through code and tests. 2. Build relations - it's far, far, FAR easier to go from BCNF/3NF to a denormalized state than the opposite when you've got lots of data. It's also far easier to perform operations on that normalized state with certainty that your change will fucking work. 3. Focus on APIs first. Whatever the bounded context, focus on the APIs and how they'll be consumed.

It seems as though the main issue here is not with FP itself, but with the politics and power dynamics within organizations.

Oh definitely, but sadly I think the culture and people involved in FP tend to be susceptible to politics. But I am in no way _blaming_ that or acting like FP should change. Those same cultures, values, and people are what make the various FP languages and communities out there great.

Reply on news.ycombinator.com