Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Timeless Way of Programming

tomasp.net

Post reply on HN
Print view View original

11–20 of 49 posts

Re: The Timeless Way of Programming

#11

Post by jackblemming »

PaulDavisThe1st wrote: post #10
jackblemming wrote: post #5

There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.

This is really misreading the whole concept of patterns in both architecture and software. The goal is not to somehow equate or even link the two disciplines. Instead it is to note that when you go about arranging stuff to do stuff (e.g materials to be buildings, or programming languages to be programs), it is likely that there will (over time) emerge ways of doing things (patterns) that you can (and likely should) u…

And you’ve misread the whole concept of my post. There’s nothing wrong with finding parallels with different disciplines. I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.

Re: The Timeless Way of Programming

#12

Post by avgcorrection »

revskill wrote: post #2

To me, tao of programming is not related to computer or technology. It's based on human character. Good people produce good code, or "timeless" code, bad people write "bad" code (means it's a tech debt).

If tech debt is always bad then it seems like a bad indirect analogy. Taking on money debt is often a sound decision.

Re: The Timeless Way of Programming

#13

Post by mxkopy »

jackblemming wrote: post #11
PaulDavisThe1st wrote: post #10

Earlier quoted context omitted.

This is really misreading the whole concept of patterns in both architecture and software. The goal is not to somehow equate or even link the two disciplines. Instead it is to note that when you go about arranging stuff to do stuff (e.g materials to be buildings, or programming languages to be programs), it is likely that there will (over time) emerge ways of doing things (patterns) that you can (and likely should) u…

And you’ve misread the whole concept of my post. There’s nothing wrong with finding parallels with different disciplines. I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.

Such a strange gripe to have.

Architecture as a default comparison makes sense on many levels. You don't make blueprints for pottery. The level of 'coincidental' design is much lower in architecture than it is in painting. There are much more specified 'primitives' that you can use in architecture that directly reflect the capabilities of the construction, etc.

And even before programming architecture was used metaphorically. 'Architecting a plan' and all that. It's not too difficult to understand how design in architecture differs from design in other areas, in a way that makes using it as a metaphor useful.

Re: The Timeless Way of Programming

#15

Post by bitwize »

PaulDavisThe1st wrote: post #10
jackblemming wrote: post #5

There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.

This is really misreading the whole concept of patterns in both architecture and software. The goal is not to somehow equate or even link the two disciplines. Instead it is to note that when you go about arranging stuff to do stuff (e.g materials to be buildings, or programming languages to be programs), it is likely that there will (over time) emerge ways of doing things (patterns) that you can (and likely should) u…

It happens in writing too, but in writing we call them "tropes".

Re: The Timeless Way of Programming

#16

Post by nradov »

TakeBlaster16 wrote: post #8
jackblemming wrote: post #5

There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.

I feel like people glamorize architecture in general. Sure the Empire State Building was probably fun to design, but 99.9% of architects are just designing bland office buildings or long hallways of apartment boxes. On average it's probably just as exciting as a software architect designing their 100th CRUD webapp.

A friend of a friend is an architect who designs McDonald's restaurants all over the Midwest. I'm not sure if that's how he envisioned his career, but it's steady work.

Re: The Timeless Way of Programming

#18

Post by ssivark »

jackblemming wrote: post #11
PaulDavisThe1st wrote: post #10

Earlier quoted context omitted.

This is really misreading the whole concept of patterns in both architecture and software. The goal is not to somehow equate or even link the two disciplines. Instead it is to note that when you go about arranging stuff to do stuff (e.g materials to be buildings, or programming languages to be programs), it is likely that there will (over time) emerge ways of doing things (patterns) that you can (and likely should) u…

And you’ve misread the whole concept of my post. There’s nothing wrong with finding parallels with different disciplines. I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.

> I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.

I concur with the spirit of this gripe. While architecture certainly might be ripe for fruitful parallels, I think it might be over-emphasized because most discourse is derivative regurgitation. Most people are not generating original insights from their own experiences, but regurgitating (at best mildly extending) Christopher Alexander (or other derived work). Christopher Alexander tied to mine architecture for systems metaphors (because that was his background), and a group of software folks back in the day tried to map that to software development -- in other words, a lot of it was purely incidental. And they were all barely scratching the surface; there are likely many other fields with many other interesting analogies. Fresh perspectives that try to mine new lessons (from different domains) would be really interesting.

Re: The Timeless Way of Programming

#19

Post by nsajko »

jackblemming wrote: post #5

There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.

"Comparing programming to architecture" might sound silly, but it's possible to learn about design in general from other design-heavy fields.

Re: The Timeless Way of Programming

#20

Post by barrysteve »

revskill wrote: post #2

To me, tao of programming is not related to computer or technology. It's based on human character. Good people produce good code, or "timeless" code, bad people write "bad" code (means it's a tech debt).

That's in Christianity too, a good tree produces good fruits. Judge a person by their fruits, ect.

Programming requires more conscious specificity than faith wants to indulge in, so we need more than it.

Post reply on HN