4 ms·

In my experience, no they don't spend much time debating the tools with their fellow craftsmen. And if you look at the tools themselves, they don't change much.

In my experience, no they don't spend much time debating the tools with their fellow craftsmen. And if you look at the tools themselves, they don't change much. They do tend to spend money on good quality versions of the same old tools though and just get on with it. It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week. To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. When Carmack wrote Doom he didn't use half of what C++ had to offer. It was just boring C with classes. But the application (Doom) was more than interesting at the time.

TeMPOraL 10y ago
> To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now. That's why I like hobby projects - you get to choose problems that are interesting.
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 ago
  Your 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 ago
    Yep 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.
collyw 10y ago
"It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week." That seems to depend on the language. Django seems to be the established framework for Python, Rails for Ruby, there are plenty of choices if you have some special need. JavaScript on the other hand....

TeMPOraL 10y ago

> To be honest I think a lot of it is because the applications themselves are a bit boring so we like to get our kicks with the tools. That's true for many of us (but not all - probably e.g. not for most of my cow-orkers; for some people, this is just a 9-5 job). This is the "art" aspect of programming. We can care about the process just as much (or more) than we care about the actual deliverable. I definitely see most of the jobs I've done so far as utterly boring; e.g. most of the web development work I've seen or done would barely challenge a monkey cognitively. What makes things difficult there is usually not the problem, but a) constantly changing definition of the problem, and b) self-imposed complexity. Same seems to be true in desktop projects I work on now. That's why I like hobby projects - you get to choose problems that are interesting.

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 ago
Your 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 ago
  Yep 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.

collyw 10y ago

"It's more like spending money on a boring well supported commercial framework and focusing on the application rather than jumping to every half invented new thing every week." That seems to depend on the language. Django seems to be the established framework for Python, Rails for Ruby, there are plenty of choices if you have some special need. JavaScript on the other hand....