Live data from Hacker News

The Essence of Programming (2021)

gingerbill.org

51–60 of 69 posts

Re: The Essence of Programming (2021)

#51

Earlier quoted context omitted.

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…

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…

> 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_).

Re: The Essence of Programming (2021)

#52

"Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." - Rob Pike, "Rules of Programming" The essence of programming is data.

Author of the article here:

I quote Rob Pike along with many others in the previous article I wrote (which is linked in the article): "Pragmatism in Programming Proverbs" https://www.gingerbill.org/article/2020/05/31/progamming-pra...

And to be clear, I am making a distinction between the essence of "programming" and the essence of a "program". I agree that with Rob Pike that (and to quote myself) "The purpose of a program is, and ought to be, something that transforms data into other forms of data".

Re: The Essence of Programming (2021)

#53

Earlier quoted context omitted.

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…

> 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…

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.

Re: The Essence of Programming (2021)

#54
post #27

The essence of programming is designing a way to transform data. You ask yourself, "what is the nature input data and how it arrives" "what is the nature of the desired output data." When I started learning programming from books, the internet and later formal study this wasn't stressed nearly enough. A program transforms data. So much else starts falling into place about all the various abstraction techniques useful…

I would agree to some extent, but I would add to this particular sentiment that it's also about the representation of data.

Re: The Essence of Programming (2021)

#55

Earlier quoted context omitted.

> The fact that it happens to execute without bugs and produces the correct output is far less important than the code being readable, comprehensible, and consistent as part of the larger system. It's more important that a function looks good, than that it actually works? I'm sorry, but that sounds stupid. A computer is a functioning machine first. If it worked from the start, it wouldn't need to be fixed later. You…

> I'm sorry, but that sounds stupid. A computer is a functioning machine first. It is not stupid - just counter-intuitive, which should give us a pause to think. You say, "A computer is a functioning machine first" - yes - but consider why SICP says, "Programs are meant to be read by humans and only incidentally for computers to execute." (see a discussion on the quote https://news.ycombinator.com/item?id=16431701 ).

> Programs are meant to be read by humans and only incidentally for computers to execute.

A silly thing to say while sitting at the top of the tower of abstraction, ignoring the fact that programs that actually work provide the foundation for the entire system.

Computer programs were originally intended for humans. Entire office buildings of humans with the job title "computer" would examine paper documents and carry out instructions therewithin.

Your linked quote talks about efficiency and style of code, which is a far cry from "execute without bugs and produce correct output" - an unavoidable necessity for a functioning computer.

Re: The Essence of Programming (2021)

#56

Earlier quoted context omitted.

> A person so deeply involved in CS and not having a computer??? I looked for a reference just now and couldn't find one. This mentions it: > Dijkstra was famous for his general rejection of personal computers. Instead of typing papers out using a word processor, he printed everything in longhand. https://www.mentalfloss.com/article/49520/retrobituaries-eds... > That's like saying being an expert cook but not wanting…

The difference as I see it: computer science (sorry, "informatics") is a mathematical discipline, and hence tends to concern itself with, out of a given class, the minimal (and maximal, when existent) object(s). Programming is an engineering discipline, and hence tends to concern itself with, out of a given class, the intervals within that lattice that are optimal by some suitability function. In principle, the suita…

So well put! I bow.

- - - -

FWIW, when I was poking around last night looking for references for the "forced to get a Mac" story I found this.

Tony Hoare:

> The first time I visited Edsger in Eindhoven was in the early Seventies. My purpose was to find out more about the THE operating system, [Dijkstra, May 1968.] which Edsger had designed. In the computing center at which the system was running I asked whether there was really no possibility of deadlock. "Let's see" was the answer. They then input a program with an infinite recursion. After a while, a request appeared at the operator's console for more storage to be allocated to the program, and this was granted. At the same time they put a circular paper tape loop into one of the tape readers, and this was immediately read into buffer file by the spooling demon. After a while the reader stopped; but the operator typed a message forcing the spooler to continue reading. At the same time even more storage was allocated to the recursive program. After an interval in which the operator repeatedly forced further foolish storage allocations, the system finally ground to a complete halt, and a brief message explained that storage was exhausted and requested the operator to restart operations.

> So the answer was YES; the system did have a possibility of deadlock. But what interested me was that the restart message and the program that printed it were permanently resident in expensive core storage, so that it would be available even when the paging store and input/output utilities were inoperative. And secondly, that this was the very first time it had happened. I concluded that the THE operating system had been designed by a practical engineer of high genius. Having conducted the most fundamental and far-reaching research into deadlock and its avoidance, he nevertheless allocated scarce resources to ensure that if anything went wrong, it would be recognized and rectified. And finally, of course, nothing actually ever did go wrong, except as a demonstration to an inquisitive visitor.

https://history.computer.org/pioneers/dijkstra.html

Re: The Essence of Programming (2021)

#57

Earlier quoted context omitted.

> 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…

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 co…

> 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!

Re: The Essence of Programming (2021)

#58

"Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." - Rob Pike, "Rules of Programming" The essence of programming is data.

or, from ~15 years earlier, with vocabulary to match: "Show me your flowcharts, and conceal your tables, and I shall continue to be mystified; show me your tables and I won’t usually need your flowcharts: they’ll be obvious."

Unless your tables and column names are constrained to 8 characters. =/

Re: The Essence of Programming (2021)

#59

Earlier quoted context omitted.

certainly an intriguing case, Dijkstra. I smell pedantry...but I could be wrong. A person so deeply involved in CS and not having a computer??? That's like saying being an expert cook but not wanting to taste food.

> A person so deeply involved in CS and not having a computer??? I looked for a reference just now and couldn't find one. This mentions it: > Dijkstra was famous for his general rejection of personal computers. Instead of typing papers out using a word processor, he printed everything in longhand. https://www.mentalfloss.com/article/49520/retrobituaries-eds... > That's like saying being an expert cook but not wanting…

I don't think you can do astronomy without telescopes: they are the basic ingredient. :)

Re: The Essence of Programming (2021)

#60

Earlier quoted context omitted.

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 co…

> 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!

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.
Post reply on HN