[gingerBill]

Author of the article here:

"Programming is not a craft." It is a craft and ought to be treated as such. Not doing so leads to the mess in software we have today. Software that is no more complicated than software from 20 years ago but runs 100x-1000x slower than its older counter part. This is the direct result of not understanding what art and craft of programming is and not treating it as such.

I highly recommend reading the previous article to this one posted (Pragmatism in Programming Proverbs) to get a better understanding of what I am expressing, since "The Essence of Programming" is a sequel to that article.

[Micoloth]

I actually agree with GP.

Counterpoint: “the mess in software that we have today” (we at least agree on this) is precisely generated by the fact that people treat programming as a “craft”, where everytime a (apparently) new problem arises, people feel the need to “craft” together some new framework or way of doing things, only looking at the small problem at hand and without considering the bigger picture.

In other words, people treat programming as an artisanal activity instead of what it should be: an engineering discipline and possibly still a scientific pursuit.

Let’s say this: Programming could be approached as a craft by the people who apply it to real world problems. BUT, there is a very different job, which is the one of the Computer Scientist (the name has a meaning), which should instead treat programming as a science. This is currently not happening, or not fast enough, exactly because so-called computer scientists treat programming as a craft, without truly exploring the fundamentals.

I have expressed this view several times in past comments here on HN, but we are still far from having a proper, theoretically grounded framework to do coding, and crafting more short-sighted solutions to pile up on top of each other won’t help…

[gingerBill]

I think the contention here is the meaning of "craft". I don't think we are actually disagreeing about programming itself but rather how people use that term.

[avereveard]

Neh. Computational problem can and are being solved with engineering solutions. Just because a crafty cousin can program something that almost work often enough to build a business on top of it doesn't mean that engineering programs is impossible.

"Programming is a tool to solve problems that you have in the domain of computers"

Again, this is wrong. Computers are tool with well defined set of operational constraints. You use such tool to model problem _outside_ of the domain of computers, and while it's true that programmer primary effort is in understanding the model and writing transformations that produce useful result, that process is a craft only if the practicioneer is an artisan.

[gingerBill]

> Computational problem can and are being solved with engineering solutions.

I don't even understand what you are trying to say here. What you trying to tell me that I am wrong about? Please tell me exactly what I wrote to which you disagree with.

> Again, this is wrong.

Tell me something where I can do programming (a program, not a programme) which isn't a form of computer? (Be that a digital or analogue computer, i.e. something that _computes_).

[avereveard]

In the approach. Programs, whether the actual instruction set, the ux, the workspace they implement, what have you, are not essential to programming.

They're the output of model building, in so far that with model precise enough, you get tooling to create programs for you. Hence the program can't be the fundamental building block, the essence of computing.

We are limited in expressing our ideas in the language the computer speak when tooling doesn't help with higher abstractions, and this happens layers after layers after layers, from microcode all the way to bpel.

But the essence of using a tool is not using the tool, it's achieving the goal the tool was built for, using the tool is, at best, incidental to the tool not being automated enough.

[gingerBill]

> In the approach. Programs, whether the actual instruction set, the ux, the workspace they implement, what have you, are not essential to programming.

And I ask again, where do I ever make any of these claims? I've asked specifically to tell me exactly what I wrote to which you disagree with and you just reply with a strawman.

Regardless, I hope you have a lovely day and thank you for reading the article!

[avereveard]

Again, it's the circular thinking that programming is to solve problems in the domain of computers. I even quoted you the passage and everything, I understand you being full defensive but the idea is quite specific.