Live data from Hacker News

The Essence of Programming (2021)

gingerbill.org

1–10 of 69 posts

Re: The Essence of Programming (2021)

#2
This seems on the right track. On the notion of ”programming is a tool to solve problems that you have in the domain of computers” though:

Writing a computer program serves two separate purposes: to communicate a set of functions to the machine, but also to communicate the purpose of these functions to a human. The former is for execution and the latter is for code review and, later, debugging.

Any old clown can get a computer to do something approximating a solution to the problem at hand. If it has bugs then the author — or more likely some other poor sap down the line — will be on the hook to first understand the intent, and then make the code match the intent.

In a professional shop you will have code review where this “debugging” step happens first. Your reviewer will read your code to infer your intent and upon agreeing with that, check your style and composition for inconsistencies or lack of clarity.

To that extent, a large codebase is akin to a mathematical proof where each new module and function represents a lemma on which the final proof depends. No serious scientist would present their thesis without a progression of isolated and carefully laid out lemmas and corollaries, and no serious programmer throws up a thousand line function with 15 arguments, global state, and — if in a dynamic language like Python — inconsistent return types.

Your code is a proof to your reviewer that you are on the right track. 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.

Re: The Essence of Programming (2021)

#3

This seems on the right track. On the notion of ”programming is a tool to solve problems that you have in the domain of computers” though: Writing a computer program serves two separate purposes: to communicate a set of functions to the machine, but also to communicate the purpose of these functions to a human. The former is for execution and the latter is for code review and, later, debugging. Any old clown can get…

> 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 can always study someone's work to figure out how it works. There's no point studying a system that doesn't.

Re: The Essence of Programming (2021)

#4

This seems on the right track. On the notion of ”programming is a tool to solve problems that you have in the domain of computers” though: Writing a computer program serves two separate purposes: to communicate a set of functions to the machine, but also to communicate the purpose of these functions to a human. The former is for execution and the latter is for code review and, later, debugging. Any old clown can get…

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

> If it worked from the start, it wouldn't need to be fixed later.

True. But you ignore the fact that NO SOFTWARE IS EVER DONE. Software always has bugs, and even if it didn't, it will bitrot as the business needs change.

In theory, it's better to have 100% working software. In practice, that never happens (or only happens for a few weeks at best). Eventually the software needs to be changed. In that case, software that is "written for humans" will always be easier to change than "software that used to work, but now we need to change it, but nobody understands it".

Re: The Essence of Programming (2021)

#5

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…

> If it worked from the start, it wouldn't need to be fixed later. True. But you ignore the fact that NO SOFTWARE IS EVER DONE. Software always has bugs, and even if it didn't, it will bitrot as the business needs change. In theory, it's better to have 100% working software. In practice, that never happens (or only happens for a few weeks at best). Eventually the software needs to be changed. In that case, software t…

Pseudocode is the easiest to change, but also literally does nothing.

Software in practice needs to run to classify. Without that it's just a .txt file that won't compile.

Otherwise you're talking about a standard, a protocol, a document with no program. Instructions for humans how to program computers.

Re: The Essence of Programming (2021)

#6
The author said that he found that most beginners spend exorbitant amounts of time finding the best way - I don't have the same experiences; It goes mostly like this: Imagine wanting to play a game of chess but not knowing the rules - of course, you won't be playing much chess, maybe you will be moving some pieces, but that would not be the chess, you don't know what moves/games are possible - it will feel daunting and impossibly difficult; now if you ever watched chess master play the game, it feels so super easy, mostly because he has the idea/intuition about the game; he doesn't have to think about every single possible move, only a portion of them that he knows (through a pattern matching - he played tens of thousands of games, and probably more) that are good; now replace 'game' with programming; beginners are handicapped by abstraction and complexity that is today's world of programming, and not the by the 'perfectionism'. Once they understand the scope of the problem they are trying to solve, and the possible ways they can go around solving it, the implementation is just trivial, even for beginners. For example, take junior web devs for example. How can you not expect them to waste time finding the 'right choice' (not even the best one), when there are hundreds of new web frameworks, css toolkits, html preprocessors etc...

Also, about the 'best way' - given the 'right' set of constrains, there is the best way to do almost anything. Unfortunately, most of the times, there is almost no constrains.

Re: The Essence of Programming (2021)

#7

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…

> If it worked from the start, it wouldn't need to be fixed later. True. But you ignore the fact that NO SOFTWARE IS EVER DONE. Software always has bugs, and even if it didn't, it will bitrot as the business needs change. In theory, it's better to have 100% working software. In practice, that never happens (or only happens for a few weeks at best). Eventually the software needs to be changed. In that case, software t…

SOFTWARE CAN AND SHOULD BE DONE. Complicated and bloated systems are never done, but not every system (program/tool/etc) needs to be big, bloated, ugly and complex. It does not matter if the software is 'written for humans', if it's too complicated it won't be changed and/or fixed ever (basically)

On that note, Zawinski's Law:

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

This is mostly true, but it does not have to be. :(

Re: The Essence of Programming (2021)

#8
I don't think programmers, let alone beginners, worry that much about the best way to solve a problem. Usually they are struggling with any way to solve it at all.

You may get the impression from reading some online Q&A sites that everyone wants "the best" solution because of the way a lot of questions get asked. But in fact, phrases like "a good way" or "the best way" are more often than not purely rhetorical devices whose purpose is to appear competent.

The person is trying to ask the question in a way which suggests that he or she does know how to solve the problem in ways that are not so great, and is just looking for a better way. In fact, the reason they are asking is that they don't know even a bad way to solve the problem. They may have a partial solution, which has hit some roadblock or whatever.

People in this type of field sometimes have a hard time admitting they don't know how to do something. Particularly if they are not such beginners and have a track record of solving problems on their own, which has become part of their self-image.

Re: The Essence of Programming (2021)

#9

This seems on the right track. On the notion of ”programming is a tool to solve problems that you have in the domain of computers” though: Writing a computer program serves two separate purposes: to communicate a set of functions to the machine, but also to communicate the purpose of these functions to a human. The former is for execution and the latter is for code review and, later, debugging. Any old clown can get…

sorry, going to have to go with a joe armstrong truism here -- make it work, then make it beautiful, then if you really must, make it fast. note the order of the first two

a large codebase is akin to a mathematical proof iff you are using something like an lcf/λc environment; the curry-howard isomorphism does not yield meaningful programmer-level insights about the average monad transformer lens abomination implementing a rest api endpoint

mathematicians do not have to worry about dependency hell in their proofs, or whether they should be importing wiles's proof of fermat's last theorem at version 3.8.21-rc2 or -rc3

if i write a window manager, its source does not primarily function as some indication that i am on the right track to competently wrangling the x11 protocol, unless i am trying to impress a headhunter from red hat. it is, in fact, primarily meant to produce a program that competently wrangles the x11 protocol. making the code clean and sensible is akin to the courtesy demonstrated by not rendering the blueprints to an air conditioner in chicken scratch with a crayon, and ensuring that part sheets are easy to follow to the assembly

framing code as in the service of the reviewer or debugger takes what is a self-evident prerequisite for getting anywhere, and promotes it to a counterproductive mind game

“oh i'll break this function out into multiple that are called exactly once, even though all that does is make the reader scroll a bunch to follow the logic, because i know jeff is gonna get this one, and jeff is a cargo cultist who thinks robert martin is the second coming of christ”

> Any old clown can get a computer to do something approximating a solution to the problem at hand.

in my experience, far more clowns are capable foremost of endless bikeshedding -- they adore giving off the impression that they are contributing something to the effort, and in the absence of insight, they substitute a performance. “hah, bet you're glad you had me to tell you to write every item in this array on its own line” (the items in question are numbers averaging two digits)

yes, code is for human beings to read, but experience has made me wary of anyone who shows up to passionately insist to that effect

Re: The Essence of Programming (2021)

#10
"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.

Post reply on HN