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

The Essence of Programming (2021)

gingerbill.org

Post reply on HN
Print view View original

21–30 of 69 posts

Re: The Essence of Programming (2021)

#21

Post by hboon »

0x69420 wrote: post #9
gorgoiler wrote: post #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…

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

I prefer Kent Beck's version:

> Make it work, Make it right, Make it fast

Re: The Essence of Programming (2021)

#22

Post by [deleted] »

kazinator wrote: post #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 device…

[deleted]

Re: The Essence of Programming (2021)

#23

Post by mcbishop »

t-3 wrote: post #16
BraveNewCurency wrote: post #4

Earlier quoted context omitted.

> 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 is never rewritten. Projects last longer than expected; programmers get bored or burned out; management moves on the newer challenges. The attitude of ‘good enough’ reflects reality. Instead of being rewritten, software has features added. And becomes more complex. So complex that no one dares change it, or improve it, for fear of unintended consequences. But adding to it seems relatively safe. We need dedi…

> We need dedicated programmers who commit their careers to single applications. Rewriting them over and over until they’re perfect.

I love this.

Re: The Essence of Programming (2021)

#24

Post by gorgoiler »

hboon wrote: post #21
0x69420 wrote: post #9

Earlier quoted context omitted.

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

I prefer Kent Beck's version: > Make it work, Make it right, Make it fast

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.

Re: The Essence of Programming (2021)

#25

Post by izuchukwu »

edfletcher_t137 wrote: post #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.

If you've chosen the right data structures and organized things well, the interfaces will be self-evident too.

Re: The Essence of Programming (2021)

#26

Post by carapace »

gorgoiler wrote: post #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…

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

Re: The Essence of Programming (2021)

#27

Post by harry8 »

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 to perform that kind of transformation (procedural, oo, functional etc) and technologies used to assist, (testing, debuggers, etc) once you keep that thought front and central in your mind. At least I feel it really did it for me.

Reading code is the same. Where are the places the data coming in? Where is it going out? Sometimes this is a better place to start than "main"

I'm sure that's really obvious to many but I'm not sure it is to the author in a way that is being successfully communicated:

”programming is a tool to solve problems that you have in the domain of computers”

Taking a baseball bat to a computer, on some level can meet the suggested definition of programming, but I don't like it that it does. I also don't much care for the use of "problems" there either.

The above is especially opinionated because I'm particularly interested if people disagree!

edit: I'm definitely still learning programming here.

Re: The Essence of Programming (2021)

#28

Post by wawjgreen »

carapace wrote: post #26
gorgoiler wrote: post #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…

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

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.

Re: The Essence of Programming (2021)

#29

Post by hyperpallium2 »

harry8 wrote: 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…

Pedantry: the only exception I could think of is a timer (delay, alarm clock), where the output is when, not what. sleep 10

Yes, information technology is for processing information.

Any transformation can be decomposed into lossy and lossless components (aka bijectve and non-bijective; reversible and non-reversible). The nice thing is that the lossless component can be automatically checked for that property.

Re: The Essence of Programming (2021)

#30

Post by carapace »

wawjgreen wrote: post #28
carapace wrote: post #26

Earlier quoted context omitted.

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

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 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? :)

Post reply on HN