7 ms·

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

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.

0x69420 4y ago
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
- hboon 4y ago
  I prefer Kent Beck's version: > Make it work, Make it right, Make it fast
  - gorgoiler 4y ago
    Very nice. For the jobbing engineer, no one should ever see your code until after step two. Make it work, [take a break], Make it right, [push it for code review, gather feedback, make changes, push to master], Make it fast.
hypertele-Xii 4y ago
> 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.
- BraveNewCurency 4y ago
  > 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".
  - hypertele-Xii 4y ago
    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.
  - eline44 4y ago
    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. :(
math-dev 4y ago
I disagree. A program is meant to produce useful output. Yes it should be written well (code clarity is a very strong correlator to the validity of a program), but the primary goal is that it should work.
carapace 4y ago
You're channeling Dijkstra (who famously didn't even have a computer until his colleagues forced him to get a Mac so they could send him email.)
- wawjgreen 4y ago
  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.
  - carapace 4y ago
    > 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-edsger-dijkstra-computer-scientist https://www.mentalfloss.com/article/49520/retrobituaries-eds... > That's like saying being an expert cook but not wanting to taste food. Oh ho! Don't let him hear you say that, eh? You'd get a scolding. He's the one who said, "Computer science is no more about computers than astronomy is about telescopes" and "Calling it computer science is like calling surgery knife science." The analogy would be more like "an expert chef who refused to eat frozen dinners" maybe? :)
    - 082349872349872 4y ago
      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 suitability function would be evaluated over the entire lattice; in practice, that function, whether explicitly or implicitly, includes a strong weight for "distance from existing solutions". In either case, this split in focus between the interior and the boundaries of the solution space means that programmers are often highly concerned with specific details that do not even appear (because they have been abstracted away) in the objects with which informaticians work. As an example: theory people love to use 1-ary trees (induction steps cost nothing in proofs, but cases are expensive) and they will use 2-ary trees (sometimes even without pressure to sympathize with the machine) but systems people and programmers use k-ary trees (where, if it's been determined by measurement and not by compatibility, k depends upon "the" bandwidth-delay product between the storage hierarchy levels for which the tree is optimized ... or at least what the bandwidth-delay product had been at the time of writing).
gingerBill 4y ago
Author of the article here: 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. I originally wanted to write the previous article in normal prose article, regarding the topic of "Pragmatism in Programming", however I thought I’d experiment in style by writing in a proverbial style. > 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. I partially disagree with this. If the code executes without bugs (very rare) and produces the correct output, then that code solves the problem. The next task is to make it readable, comprehensible, and easy to maintain whilst not trying to introduce other bugs. I recommend reading Casey Muratori's article on "Semantic Compression" https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015 This article is a good overview of the idea I am trying to express in this reply. It's very important to get things working BUT then actually improve it, don't just stop there!

0x69420 4y ago

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

hboon 4y ago
I prefer Kent Beck's version: > Make it work, Make it right, Make it fast
- gorgoiler 4y ago
  Very nice. For the jobbing engineer, no one should ever see your code until after step two. Make it work, [take a break], Make it right, [push it for code review, gather feedback, make changes, push to master], Make it fast.

hypertele-Xii 4y ago

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

BraveNewCurency 4y ago
> 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".
- hypertele-Xii 4y ago
  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.
- eline44 4y ago
  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. :(

math-dev 4y ago

I disagree. A program is meant to produce useful output. Yes it should be written well (code clarity is a very strong correlator to the validity of a program), but the primary goal is that it should work.

carapace 4y ago

You're channeling Dijkstra (who famously didn't even have a computer until his colleagues forced him to get a Mac so they could send him email.)

wawjgreen 4y ago
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.
- carapace 4y ago
  > 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-edsger-dijkstra-computer-scientist https://www.mentalfloss.com/article/49520/retrobituaries-eds... > That's like saying being an expert cook but not wanting to taste food. Oh ho! Don't let him hear you say that, eh? You'd get a scolding. He's the one who said, "Computer science is no more about computers than astronomy is about telescopes" and "Calling it computer science is like calling surgery knife science." The analogy would be more like "an expert chef who refused to eat frozen dinners" maybe? :)
  - 082349872349872 4y ago
    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 suitability function would be evaluated over the entire lattice; in practice, that function, whether explicitly or implicitly, includes a strong weight for "distance from existing solutions". In either case, this split in focus between the interior and the boundaries of the solution space means that programmers are often highly concerned with specific details that do not even appear (because they have been abstracted away) in the objects with which informaticians work. As an example: theory people love to use 1-ary trees (induction steps cost nothing in proofs, but cases are expensive) and they will use 2-ary trees (sometimes even without pressure to sympathize with the machine) but systems people and programmers use k-ary trees (where, if it's been determined by measurement and not by compatibility, k depends upon "the" bandwidth-delay product between the storage hierarchy levels for which the tree is optimized ... or at least what the bandwidth-delay product had been at the time of writing).

gingerBill 4y ago

Author of the article here: 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. I originally wanted to write the previous article in normal prose article, regarding the topic of "Pragmatism in Programming", however I thought I’d experiment in style by writing in a proverbial style. > 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. I partially disagree with this. If the code executes without bugs (very rare) and produces the correct output, then that code solves the problem. The next task is to make it readable, comprehensible, and easy to maintain whilst not trying to introduce other bugs. I recommend reading Casey Muratori's article on "Semantic Compression" https://caseymuratori.com/blog_0015 https://caseymuratori.com/blog_0015 This article is a good overview of the idea I am trying to express in this reply. It's very important to get things working BUT then actually improve it, don't just stop there!