4 ms·
I like the idea behind your post because it's true for lots of people - when you're so close to it, you don't realise that you're arguing over maybe 10% efficie
by anko 10y ago
I like the idea behind your post because it's true for lots of people - when you're so close to it, you don't realise that you're arguing over maybe 10% efficiency in lots of cases.
But i think programming is kind of unique in this respect too.
The tools sometimes let you approach a problem in a different way; sometimes "just getting on with it" means you're wasting a lot of time dealing with stuff that wouldn't be an issue in a better language.
To give you a concrete example, it's like when you do a CRUD application with a properly normalised database and then you need to add auth. And then you realise a transaction made at a certain date has messed up all later transactions. And then you realise you need to add an audit trail. And then you realise that needs to scale its services independently and you have to add micro-services. And then you realise you've got yourself into consistency issues because your services are sharing state through your db, etc etc.
Or you just implement CQRS and all those problems go away (yep you have different problems).
But i'm just saying that tooling matters, and picking the right tools can be worth hundreds of thousands of dollars.
I think the C / C++ argument is a strawman, it's not using all the features of a language that matters, it's picking the right ones.
- discreteevent 10y agoYour point about "picking the right ones" is fair enough and of course the language can make some difference but not anywhere near the difference the architecture makes. Which is exactly what your point about CQRS outlines. Google and Amazon built businesses on Java, a tool that is as boring as a hammer. It was the architecture that mattered.
- discreteevent 10y ago"In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice." - Peter Norvig https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815
- anko 10y agoYep I agree that architecture plays the largest part. But I really don't think it's about a language being boring vs not! Pure functions are easier to reason about. So it makes sense that a language that encourages their use will be easier to reason about - which will help with maintainability. Same goes for concurrency patterns - the closer they are to the language, the less room for mistakes. I think the same for testing, but a lot of the time it's up a layer of the stack with a framework.