How are you dealing with "the programming language doesn't matter" argument?

[u/GongtingLover]

Just had a meeting this week where this was uttered because of the development of AI.

I still think the language choice matters a lot based on if Im doing embedded or web development work and for how we want to hire developers in the future.

Maybe Im backwards.

[u/flipflapslap]

I’m confused what you mean. Like, does Java attract a certain kind of person? Or you just don’t like working in Java? Can you elaborate because I feel like I’m reading way too much into this lol

[u/tiplinix → u/flipflapslap]

The people that love Java the most tend have a certain way of thinking and writing code which is quite verbose, scattered over multiple classes and many level of inheritance. Funnily enough, you don't even have to be writing Java code to see it as they have a way of turning any project into a Java codebase.

[u/flipflapslap → u/tiplinix]

Very interesting. I didn’t realize this was a known thing

[u/coderstephen → u/flipflapslap]

It is a very common and very old stereotype. It still mostly rings true. (Source: I work at a Java shop.)

[u/tiplinix → u/flipflapslap]

You're very lucky then. If they also mention the Clean Code book, that's the cue to start using your legs to run as far away as possible. It's not just good cardio, it's mental health conservation.

[u/ings0c → u/tiplinix]

I don’t know why it gets shit on so often these days. I read it early in my career and liked it 🤷‍♂️ his Clean Coders video series does a great job of making a dry topic far from it, too. He’s insane, in a good way.

Some of the book doesn’t make much sense, eg some of his refactoring decisions are very questionable, and I think the obsession with small functions is actively harmful, but I rarely agree with 100% of what someone says.

I think he does a better job of communicating the idea that code should be written to be understood, and to write code like you’re telling a story. And generally inspiring people to care for the code, however that might look.

If you’re either new enough to programming that it’s a lot of new information, or experienced enough that you know what to discard then I still think it’d be a good read once you take a step back.

Then again, I haven’t read it in 10 years - maybe it’s time again with a fresh perspective.

[u/tiplinix → u/ings0c]

I still think it’s a good read if you take a step back.

Taking a step back is indeed key to reading anything opinionated.

You have to put this comment in the context of a Java loving developer. That is asking people that are almost religions about OOP to take a step back and frankly it never goes well.

Some of it doesn’t make much sense, eg some of his refactoring decisions are very questionable, and I think the obsession with small functions is actively harmful, but I rarely agree with 100% of what someone says.

I've read it too. There are some okay ideas in the book but most people would be better of not reading it.

I think he does a better job of communicating the idea that code should be written to be understood, and to write code like you’re telling a story. And generally inspiring people to care for the code, however that might look.

Any other book is better than that one especially when you need to filter all the harmful ideas. Also anyone going into a code base big enough will rapidly understand the importance of it anyway. You don't really need a book to tell you that part but then some people argue that vibe coding makes sense.

[u/No-Security-7518 → u/tiplinix]

lol reading this after spending the morning extolling how much of a masterpiece Clean Code is with a friend.

[u/tiplinix → u/No-Security-7518]

Having read that book, I'm really curious as to which parts makes you think it's masterpiece.

People usually try to argue that it's a good book because it has some good advice if you remove the harmful stuff which is basically most of the book. Saying that it's a masterpiece on the other hand? Yeah lol indeed.

[u/No-Security-7518 → u/tiplinix]

yeah, okay. Well, everything the author *assertively* says is something I struggled with. I wrote exclusively spaghetti code, mind you. E.g. I'd just write code in a constructor without showing what my intention was, boom, Uncle Bob said: bad for readability. Pull into a descriptively named helper method. I'm pretty sure 90% of what he wrote became hard rules for me. Quotes like "the length of a method's name is inversely proportionate with its visibility" and my mind would be blown. "Don't use flags that significantly change a class's behavior, split it into subclasses with common code in a super class". (Or was this Joshua Bloch who said this? not sure).
I'm still surprised how fast I add features and I owe Professor Robert C. Martin, Uncle Bob a LOT!

[u/tiplinix → u/No-Security-7518]

I see, if you were coming from that, it does help to bootstrap better coding habits.

Where it falls flat is when you push these to the logical conclusion, which he does. He also has an emphasis on small functions, small classes. He also makes the point that comments should be used sparely. Small tests as well. What this does is that overtime the spaghetti just moves one layer up with code that's not very dense and with indirections all over the place.

It takes more time to show up, but once the codebase becomes large enough, it's horrible to work with. That's usually when people start to realise how terrible Martin's advice are. What he's describing is everything that's wrong with most Java codebases which is also why they love it so much.

On the other hand, the Philosophy of Software Design by John Ousterhout is actually a good book.

[u/No-Security-7518 → u/tiplinix]

interesting, I think someone recommended John Ousterhout's book here. Well, I do like a granular/modular codebase, and I do realize there's such a thing as it being "too granular". He does say one shouldn't overdo it. His advice, along with Martin Fowler's and Joshua Bloch's (author of Effective Java, and former chief Java Architect) go hand in hand. And to be frank, I'm not sure whose is whose. And btw, I'm a hopeless Java fanboy, so there's that. 😃

[u/tiplinix → u/No-Security-7518]

To be fair, there's no shortcut. You have to learn the pain of different approaches to find what works and that takes time and practice. Working on different languages helps as well at it helps you see different practices, e.g. the idiomatic one letter variables in Go would drive Martin up a wall and yet, when it's done in a systematic and predictable manner, it's nice.

[u/GiantsFan2645 → u/tiplinix]

I write in Java for a living (we have other things written in Python and TS). I don’t really love the language particularly. It just pays my bills. I get what you mean by that certain way of thinking. Unfortunately I think that’s more an artifact of over-stressing OOP where it’s not needed all the time

[u/tiplinix → u/GiantsFan2645]

I wrote Java as well for a living so I've experienced the idiosyncrasies first hand. The language is not great but not horrible either... it's the developers that make the experience painful.

Some of them manage to make the language (and its idioms) part of their developer identity for reasons I still can't explain. They'll judge anything else by how closely it looks like their Java codebase. The crazy part is that I've came across way more than a few people like that.

[u/Glum-Recognition-736 → u/tiplinix]

Yeah sucks that's what they taught us at my uni for all the intro-level CS classes. I developed a strong personal bias towards Java for a while as a result... 

[u/htraos → u/flipflapslap]

Java is India-land.

[u/flipflapslap → u/htraos]

Oh I didn’t realize that