I love HN don’t get me wrong, but my coworkers and I like to poke fun at it. Some jokes are “why didn’t you just use rust?” and “Well what did Paul Graham have to say about it?” when debating something. It’s a culture like any other. I would say a lot of super smart people are here, who have deep knowledge on the most esoteric niche subjects, and provide a lot of sage wisdom and advice. But there are a lot of cranks too (including myself!).

I think this forum attracts a non-trivial number of people who have a hyperfocus issue beginning with the letter A.

In many HN threads with lots of comments, at some point in the thread (and very often starting at or near the top), the comments successively veer off to the right, sometimes to a ridiculous extent, forcing rightmost comments into a thin vertical column that is a pain to read. And worse, the main topic of the OP is often not discussed much at all, since the majority of comments are about these minute inconsequential details, as you say above - and since these trivia subthreads tend to get upvoted the most.

It's why grammar nazis are the most insufferable, because their picking apart of your sentences appears to invalidate your argument, when really they're just being pricks.

This seems like sage advice, especially in a time where people have become so focused on the developer experience and the software lifecycle. But for the sake of conversation, can I fish for an area of disagreement?

I notice that the WGID principle often gets hijacked into the strong version - let's call it the "Software is Just A Craft" conjecture. This version says that we've basically got software all figured out, and from here on out, everything is just different flavors of the same process. C for this, Python for that - it's just up to the craftsman to choose his tools wisely. To me, this kind of fatalism seems like the death of programming as a technology field. I don't know if it's a lack of imagination, or just getting too comfortable as a practitioner of "the craft", but some people seem to relish the idea that there can be no progress, only practice.

As a concrete example, consider Python's inability to use native threads. I see some people talk about this as a tradeoff, as if you're trading the performance of C for the convenience of Python in a zero-sum game. But that's just an approximation. Python _could_ have native support for threads if it was designed better. You could leave everything about its syntax alone, but just allow threading, if only the time was put into engineer it that way. Of course now, it's too late - we have too many legacy systems and too much code relying on how it was already built. But this is not the same as it being in a fundamental trade space. Python is just missing a feature, and now we know better.

It strikes me, then, that the level-headed "choose the right tool for the job" advice is really more just a way to be pragmatic in the here-and-now of writing software. You're not going to write a new operating system, language and ecosystem by the end of this week, so you have to realistically assess your options and grade them on their strengths and weaknesses. I just want to make the point that this is not core to the nature of programming languages and paradigms, just from wanting to build useful things on a schedule. But it has to be possible to make things strictly more expressive, strictly more performant, strictly easier to debug, strictly more portable, strictly... better?

That's pretty miserable, really. At least it pays reasonably well.

I've been programming since I was maybe 13, and being 34 today I find this to be more and more true. Programming IS JUST A TOOL to get something done. When I say "just a tool", I do not mean to ~undermine OR overexcite~ the concept of a tool. The real power to seek as a programmer is knowing lots of programming platforms and paradigms, as then you have the knowledge to select the best tool or technique to accomplish solving a specific problem within a domain at hand.

Sometimes that 'best tool' really just happens to be the one I have X years of experience in, because I'm here, right now, in front of the project, and have solved the same problem Y times before with acceptable results (systems running, people getting value as expected). That doesn't automatically justify being a stick-in-the-mud and never adopting any new technology ever.

But it also means that jumping to new tools on a semi-annual basis, you'll have a hard time having justified confidence you can deliver something of value. I have to qualify with "justified" because... I've seen too many folks who have confidence and... really shouldn't. And I recognize that because I can see how I was once there.

I had a call from someone in 2017 asking about something I'd built for them in 2002. System was still running. Someone had been doing basic system upgrades every so often, but they'd hit some logical issues and needed more insight, and pinged me. Last year I noticed a previous client project started in 2000 was still up. I've no doubt they've updated some of the back end stuff, but some of the stuff I put in place I can still see (html comment, semi-unusual url structure, etc).

Understanding that what you build might actually be in place, working for people for 15-20 years is hard to get your head around until you've actually done this for 20 years. When I was 20 I could not understand the ramifications of decisions impacting people or companies for 20 years - I just didn't have that life experience - no one at 20 does. We're often fed magical press releases about acquisitions and exits and we read stories of things shutting down, getting sunset, etc. Those aren't the norms though, I don't think.

With that in mind, my criteria for choosing the 'right tool' has shifted some in the last few years, and I'm always a bit more hesitant to jump on latest shiny trends, as... I do get somewhat concerned about the long term viability. That has to be a factor in 'best tool' calculations, no? (sorry for long ramble)...

The problem is it takes years to learn one tool, and it take years to see one case as screws, another as nails, etc.

EDIT: OTOH, as you gain more experience, you can classify problem better and look or even develop tools that solve that particular problem. Which is why angular / react / vue is developed and popular.

Somewhat. You can't become an expert in a matter of months, but by the same token, my PHP and Java skills didn't get demonstrably better between years 8 and years 9 of experience.

Other things outside the language got better. One was my ability to understand problems and potential solutions (from both technical and business/operations perspectives). Another was the ecosystems around those languages. Best practices, documentation and tooling all evolved to deal with new needs, new hardware, etc. The ability to adapt to those changes and understand the role of the core language/tech in addressing problems is key. Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself - you'll never know every single aspect of everything, so learn to accept that.

> Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself

Exactly in my view, programming language such as PHP and Java isn't tool, they are a set of tools. However the toolset are different between each programming language, let's say that in PHP the hammer has larger head than Java.

Let's say that programming features such as iteration (for / while loop) and conditional expression (if) are tools, that can be used to solve specific problems.

Well sorry if the analogy or metaphor isn't really accurate...

That helps for 'solo' stuff. Trying to introduce those ideas and techniques in existing teams is almost always more difficult than it should be.

Yes, thankyou! I think about this every time I see "Systems are so powerful we can just throw RAM/CPU cycles at every problem, efficiency doesn't matter..." as if everyone on the planet is doing web apps, and there are no engineering/architectural situations that might drive certain languages or design principles. Such as this:

https://www.intel.com/content/dam/www/programmable/us/en/pdf...

I guess I'm just focused on a niche market...

Sayeth the graybeard.

Basically, this has ensured that I do not accept truisms about how everything is kinda similar - it isn't, and that has real world consequences. In the case of OOP it's generally the consequence of boring you out of existence since it is so inextricably linked to Java at this point.

I'll grant you that you can solve problems with any language, though. ;-)

Think about languages as tools: focus on the tools you need to use. Your career will be long and there will be plenty of time to branch out, but you have very limited time for mastery, so you should master the tools you use often.

All too often, I find this devolves into me scouring the internet for "C++ is ok but the ownership model is so primitive that I would never start a new project in it" and comparing it to "My problem with Rust is that it's still such a nascent language I can't trust it to have the libraries I need". Who are these people, and why are they saying these things? Are their gripes relevant to me? I have no way to know!

Honestly, just pick one and run with it. Part of becoming an experienced programmer is developing your own heuristics for how to pick the right tool for the right job and how to read this type of discussion, and a big part of that is building up both wins and losses to train your intuition.

When they say "OOP is now considered an anti-pattern, most companies are moving towards reactive FP", do they really mean "I work at snapchat and the ads group I work for is moving away from OOP. My friend at amazon said he's doing the same thing"?

If it's an internet forum and you don't see references or citations, it's probably safe to assume it's the latter. They might still be right, but not verifiably so.

Lot's of FP "fans" just writing procedural code with a terrible mess of functions and no architecture as well. Quite the mixed bag. But they're very passionate and believe in talking about FP as the one true way. I suppose most things go through a phase like that though.

But if you've been around long enough, you don't get too jazzed about any one thing.

So it is kind of strange that nowadays FP == anything Haskell like.

Likewise I learned OOP via Turbo Pascal 5.5, followed up with frameworks like Turbo Vision and OWL, picked C++, Smalltalk and plenty of other OOP languages.

So it also feels ironic that nowadays OOP == anything Java like.

You don't start a moderate-sized project! You start a small project and then grow it to become moderate.

There are some other more subtle issues.

This article goes in depth into some less well known ones related to data structure efficiency.

https://jaxenter.com/disadvantages-of-purely-functional-prog...

The insistence on immutability comes from FP being closer to mathematics. But, computers aren't actually abstract equation solving machines. They are machines that spend much of their time copying data between mutable storage cells of various kinds. So, a lot of very important and common algorithms require mutability and don't have natural, efficient immutable equivalents. But FP requires you to be immutable, so, you can end up paying a heavy efficiency tax. Not many pure FP game engines out there!

Even when there are problems that are theoretically pure functions, like a compiler, real world compilers like LLVM or Graal are not functional, because you give up too much performance by doing that. Functional problems still benefit from not gratuitously copying data all over the place, mutating graphs in place, etc. Cache locality is too powerful an optimisation to give up.

OOP is fundamentally a paradigm about modelling a mutable world. It turns out that most software isn't implementing a pure function but rather a reduced model of reality, so, that makes it highly appropriate. Almost any database for example is a mutable model of reality (even if a fictional one like in a game). OOP languages have weak mutability controls, but fundamentally, a mutable variable is more "powerful" in some sense than an immutable one.

FP languages are often rather poor on things that OOP emphasises heavily, like encapsulation. FP gives you data structures and functions. Namespaces, usually. Beyond that it gets ropey. The core insight of OOP is that you often want to bind code to data very strongly, because that lets you really control the scope of functions much more easily. This in turn makes it easier to scale up teams, as people can more easily own their little corner of the world. OOP languages like Java have a lot of visibility control features, and are still getting more even in recent years.

Inheritance (subtyping) gets shit on a lot these days by the kids, but it's a very natural paradigm to model certain kinds of problems, for example it makes a lot of sense for GUI toolkits. Game engines also get a lot of good mileage out of it. Pure composition using layers is less effective, partly because it translates to worse machine code. Virtual method dispatch is highly optimised and thus a relatively efficient way to share and customise code. Interface dispatch is less efficient and proxying calls to composed inner objects, even less so again.

FP languages often end up trying to bolt on features to the functional paradigm that are natural fits in imperative OOP-oriented languages. For example, FP languages handle errors with a Maybe type and monads. OOP languages can do this too, but they can also do exceptions which are often a more natural way to handle errors, with various benefits. Strictly this is an imperative vs FP thing not an OOP vs FP thing.

There are some other issues that are less fundamental. FP languages are part of a family tree, and for whatever reason that family tree loves obscure syntax with lots of operator overloading. There are many OOP languages that are designed by industrial designers for usability in large teams, so they restrict how much of a mess you can make. FP languages are generally research languages that have little usage in industry, so FP code can often end up being very hard to read with a lot of bizarre custom operators. You could make a clear, easy to read and abuse-resistant FP language but nobody does.

Many interesting points in this comment, but I am not sure about the mutable part of this assertion. I see those two concepts often presented as fundamentally intricated but modelisation is an effort of abstraction not tied to implementation choices, and objects can be perfectly immutable.

Using these words, I would simply say OOP is fundamentally a coding paradigm about modelling a system, nothing more. And that is why it has been so successful.

Using OOP and avoiding mutability when appropriate, I would say you get most of FP benefits without abandoning the modelisation capabilities and objects features.

And more and more FP constructs are now integrated in OOP languages. Then APIs can become more important than the language itself.

That's what have been demonstrated by modern Java in my opinion.

It's really not (and I'm as one of the most outspoken critics of laziness in Haskell).

Is there a consensus one way or the other? Not only no, but $PROFANITY no. The person who claims that there is... yeah, consider them a blowhard who is out of touch with reality.

Try not to get bogged down by what others say. If you’re looking for a job in a particular industry, follow the fads of that industry. Otherwise, just keep building your knowledge and worry less about whether it’s the right specific technology.

There's another dimension of the issue: types of the project the person has experience with.

Something that works in a low-level Windows desktop doesn't necessarily work in high-level Linux web. Something that works for NASA or SpaceX doesn't necessarily work for a mobile game startup. Something that works for FAANG is not necessarily the best way for a web site that's running on a single server. Something awesome for a social network is not guaranteed to do any good for a bank, or a research lab.

That "something" can be pretty much anything: languages, libraries, IDEs, frameworks, project management practices, hiring practices. The only thing these projects have in common is "people need to write code that does something". Almost everything else is different. And yet we have many discussions where people working in different industries, on projects with different requirements, budget, users, revenue sources are arguing which language is better.