Hacker News Reader

Comment by gear54rus | Hacker News Reader

So if you consider some stack to be inferior (maybe because its highly inconsistent in its design or it only runs on closed and locked down platforms or whatever) you still should just dismiss it as 'oh its just a tool' instead of accepting that it's shitty and makes you miserable when working with it? Why wouldn't I want to work with best thing ever if it helps me keep my sanity every day?

Do you want to use something that makes you miserable? Is any language including those designed by 3 year old 'just a tool' that is to be used despite obviously being shitty?

Never understood that argument.

View on HN

I think an analogy would be the following: You need to hammer a nail in a piece of wood. You could do this with a screwdriver but hammer is better suited for the job. However, a hammer made out of glass is less useful than the screwdriver.

In other words, some kinds of tools are better suited for a problem than others, but there exist tools that inferior even though they were designed to solve your original problem.

You should pick the best tool for the job. It might be unclear what that tool is and some tools are better than others at solving the same problem, even if they are designed to solve the same problem.

I take your point, but can we avoid this analogy please? Let’s talk about actual code if we’re going to talk about the best tool for a job that requires it.

It reminds me of something early in my career that irked me like few work-related things things have: “Building software is like building a house” — No, it isn’t. Not even a little bit.

I think it is more like growing a garden.

Sometimes I feel like a gardener tending to the code base. Pruning deadcode and planting new modules...

I prefer making the distributed club sandwich analogy ...

Never heard of that one, and if it works for you then more power to you! Analogy's are all about making sense of new data using older previously understood data, so if the old reference doesn't ring any bells... you just need to find one that does.

I think parents point was, for whom does the hammer made of glass helpfully accomplish anything for?

One of the main problems I have with that analogy is that a language is not like a tool at all. Frameworks and libraries are like tools. Different classes are like a different flavor of tools - Haskell/ML, C#/Java, and a plethora of others.

Maybe you should look within yourself and fix up whatever part of your personality is making you miserable? I'm not being flippant. Programming languages don't make people miserable.

There isn't really an argument, just an observation that the most efficient way of thinking about programming is in data structures and algorithms which are mostly language independent. Nobody should be spending most of their time leveraging language features, so it isn't critical to use any particular language.

I have a large range of pens of different quality. I have a favourite pen. But I'm willing to use any pen if I need to write something down. My focus is on composing a message, not on worrying about the quality of my calligraphy or the occasional scratchy mark. If 'm going to be writing all day I'd rather have my favourite pen but any one will do.

Programming is in my opinion not just about data structures and algorithms. It is also about designing abstractions that capture the domain you're working in well, whether it be by designing classes in an OOP language, or data types and functions in a functional language.

It's not just about what a program does and how quickly it does it. What matters at least as much is how easy it is to understand, modify and extend. Of course, that isn't necessarily language-dependent either, but I think some languages make it easier for you to design nice abstractions.

For example, C can make it more difficult to write nice abstractions since it forces you to worry about memory allocation and memory safety, and doesn't really offer facilities for generics.

Saying a language makes you "miserable" does not forcibly mean you literally want to kill yourself because of it.

I can totally see myself having more or less fun executing the exact same programming job, depending on the language I'm asked to used. And yes, to some extent, some projects (especially the ones where you have to start from an old codebase in a deprecated and ancient language) make me "miserable". That doesn't mean I'll quit my job on the spot.

I agree.

I used to be a C++ programmer. I was good at it. I could do advanced template magic. I understood multiple inheritance and used it correctly, for the right purpose. I literally had dreams in C++.

Then I started using Java, and realised that I could be 5x as productive with far fewer headaches chasing down yet another linker error with some unintelligible error message.

What do you mean __malloc is undefined!? How could it possibly be missing? It was there a minute ago! I'm linking the standard library already, so what exactly do you want me to do about it, Mr C++ Compiler!?

Then I discovered IntelliJ IDEA, and I swear that I felt like the skies had opened up, there was a beam of light shining upon me, my spirits were lifted, and I could hear the voice of God saying: "Fear not! For now you can make changes globally and ye can rest assured that this will not break thy code!"

And then along came C#, which was just-like-Java, but with another 2x boost in productivity from all the built-in stuff that Java was missing, the language niceties, and the removal of the boilerplate. It has made me so happy over the years. Nearly two decades of effortless productivity.

I mean, seriously, how ridiculously awesome and simple is the "async" keyword!? It's like magic! I love it. LINQ is neat. The debugger is awesome. IntelliTrace is nifty. I could go on.

At one point recently I was forced to use C++ to write just a few hundred lines of code. It was physically painful. The language is a quagmire of footguns. The code I wrote was trivial string processing code, yet despite using only std::string it still somehow managed to crash.

I decided right then and there that I'm never going back to C++. Never! It's not worth it. My sanity, nay, my very soul deserves better.

I agree with you that there is a deeper problem if choice of programming languages makes you miserable (with the possible exception of the situation where things are so bad that it makes it difficult for you to do your job and that makes you miserable).

At the same time though, I think you might be writing off the link between choice of programming language too easily. Rather than pens, where there is relatively little difference even between a fountain pen and a ballpoint, a better example might be a carpenter choosing between power tools and hand tools. There are definitely carpenters who are strongly specialized in using hand tools who would not enjoy being forced to use power tools.

I suspect this may boil down to different people coming to programming for different reasons. Some people are primarily interested in the end product of programming while others are interested in the process of using code to build abstractions. My opinion is that room should be made for each approach.

> Programming languages don't make people miserable.

Try coding in MUMPS then saying that again. Or Intercal. Or Whitespace.

Or Malebolge, a language explicitly designed to make people miserable.

> Programming languages don't make people miserable.

JavaScript makes me miserable when I have to fix it.

The argument is to use the right tool for the right job and not just the hammer that you’ve become an expert in.

If you know of a tool that is the wrong tool for every job, then yes, it’s still just a tool. Just use something else.

Vast majority of the time, I pick up a project half-way with an existing codebase rather than start from scratch, and it's natural to just keep using what's there unless there's a showstopper, in which case I make the bare minimum addition so I could keep going.

So yeah, just a tool.

The things that make work pleasant are a sense of purpose, feeling valued, being stretched, having autonomy, personable colleagues, a good physical environment, decent equipment. These are far more important than what language you happen to be using.

Those are the lowest common denominator of things that make work pleasant. To that list I would add:

* opportunities for growth in both breadth and depth (perhaps that falls under “being stretched”)

* opportunities to mentor and to be mentored

* a voice in the philosophy, goals, direction, and projects of the team or even the company

* flexible work hours, abundant vacation time, and a culture that makes full use of both

That attack seems unwarranted, especially for the argument put forth above, which you really don't seem to have understood.

The argument is that, even when you compare between very good tools, each one of them will make your life miserable when you apply it to a problem for which it is not designed, and for which a different tool is a much better choice.

I.e. there's no "one tool that is the best thing" that can be applied to all your tasks, because the tasks are widely different so tools are necessarily limited. That doesn't preclude some tools designed for the same type of task being clearly worse than others of the same kind (your argument).

It's not that simple.

First you can't always choose the stack you work with. You work with other people, who may have expertise in different languages. You may have to reuse existing code written in different languages. And it's rarely the case that some stack is better than another on every aspects, there is usually some form of compromises to be made.

"Love is understanding.." MLK

"People fear what they don't understand and hate what they can't conquer." Andrew Smith

Reply on news.ycombinator.com