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

Holding a Program in One's Head (2007)

paulgraham.com

Post reply on HN
Print view View original

61–70 of 114 posts

Re: Holding a Program in One's Head (2007)

#61

Post by minkles »

jimbokun wrote: post #59
minkles wrote: post #42

Earlier quoted context omitted.

Those are called functions.

Sometimes. Sometimes it is one or more programs writing to a queue or topic, and other programs reading from that topic. Or programs writing to and others reading from a Unix pipe. Or programs talking to each other using HTTP. Or Erlang processes communicating concurrently on one machine or across a network. Or different programs sharing one database. Or many objects communicating by passing messages in a small talk…

> Or programs writing to and others reading from a Unix pipe.

write(message), read() -> message

> Or programs talking to each other using HTTP.

request() -> response

> Or Erlang processes communicating concurrently on one machine or across a network.

sendMess(message), waitMess() -> message

> Or different programs sharing one database.

execute(query) -> response

...

I'm a mathematician at heart so I'm staying away from category theory as long as possible.

Re: Holding a Program in One's Head (2007)

#62

Post by lanstin »

btown wrote: post #47

IMO this is one of the most important skills for a developer to have. In an age of Github Copilot and similar systems, it's both far more viable (because, per OP's #1, you won't get distracted by the "side quests" of implementing utilities you need, when you can just tab-complete to get them) and far more vital (because with that productivity increase comes an increase in the complexity of problems you'll be asked to…

This is one of my standard interview questions, how do you familiarize yourself with a multi-million line code base with partially correct partial documentation (in addition to generated documentation). Looking for interesting tooling, and stepping thru the framework code to see how it all comes together (and enough concrete details to verify the claimed work history).

I'm not sure about the advantage to seeing all the code at once for understanding it. Surely for refactoring or massive editing, but to encode it into your brain, I feel the crucial thing is more abstract than actually seeing the code.

I personally find the large screen is something that's more useful when I am moving between different low-concentration tasks (confluence, slack, teams, emacs, whatever) but for deep problem solving/thinking, just 1 window I can see everything completely with a full-screen emacs is more conducive. I assume other editors than emacs would have this same facility. Extremely rapid answering of different questions about the code via LSP type facilities is more key than seeing a bunch of text at once, so I can follow the flow of my thoughts. Sometimes, when I'm trying to make sure that 2 or 3 functions have the same flow/logic (yeah, haven't found the abstraction to replace them with) I'll want a big side-by-side comparison of 2 or 3 places at once.

This ability to follow into third party code you use was one of the initial attractions of Gentoo - you can build all from source, keep source and symbols around, and edit/trace the code for anything on the system. Reading a lot of code I think makes my own code better.

Re: Holding a Program in One's Head (2007)

#63

Post by ellis0n »

jimbokun wrote: post #59
minkles wrote: post #42

Earlier quoted context omitted.

Those are called functions.

Sometimes. Sometimes it is one or more programs writing to a queue or topic, and other programs reading from that topic. Or programs writing to and others reading from a Unix pipe. Or programs talking to each other using HTTP. Or Erlang processes communicating concurrently on one machine or across a network. Or different programs sharing one database. Or many objects communicating by passing messages in a small talk…

Totally agree and it depends on the current context of the programmer. For example, in the ACPUL language the program is split into boot images, files, modules, functions and expressions. All of these represent different levels of context encapsulation

Re: Holding a Program in One's Head (2007)

#64

Post by lanstin »

nfw2 wrote: post #24
corytheboyd wrote: post #3

> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…

I think that many, perhaps even most, engineers incorrectly believe that the main purpose of abstraction in code is simply DRY, as if the goal is to save keystrokes or something. In my view, the purpose of abstraction is to compress the concepts of your application into digestible and manueverable chunks, and DRY is just a heuristic for beginners to follow to help point to where appropriate abstraction boundaries may…

New software demands a new vocabulary, and if those new concepts correspond exactly to implemented code, everything becomes very clear and possible to share with new people.

As well, the division of a project into layers where each layer has a manageable amount of concepts, 5-7 for normal layers, becomes much easier for people to learn and use correctly. If I have to keep 12 things in mind while using a layer, it's going to be a lot harder to get correct.

Re: Holding a Program in One's Head (2007)

#65

Post by PaulHoule »

I'll call out

   7. Don't have multiple people editing the same piece of code. 
   You never understand other people's code as well as your own. No matter
   how thoroughly you've read it, you've only read it, not written it. So
   if a piece of code is written by multiple authors, none of them understand
   it as well as a single author would.
On some level it's true but it is also true that most of the world's code is in some sort of maintenance mode and the original developer is not always available. When I work on code that I think would be difficult to maintain I write a lot of comments to explain invariants that should be followed or anything strange. (Hmm, there are three different kinds of "row" talked about in this source file)

If you have a front end-back end system and you want to do something simple like add a field to a form there's a strong case for a single developer or maybe paired developers to make all the changes to make that change happens as opposed to assign two developers (not paired) to communicate with each other about doing the task, or worse yet, assign two teams. You might have had two people build out the front-end and back-end systems but for sustainable maintenance one person should be able to ship a feature.

Re: Holding a Program in One's Head (2007)

#66

Post by corytheboyd »

nfw2 wrote: post #24
corytheboyd wrote: post #3

> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…

I think that many, perhaps even most, engineers incorrectly believe that the main purpose of abstraction in code is simply DRY, as if the goal is to save keystrokes or something. In my view, the purpose of abstraction is to compress the concepts of your application into digestible and manueverable chunks, and DRY is just a heuristic for beginners to follow to help point to where appropriate abstraction boundaries may…

DRY is an okay rule at the absolute beginning of your programming career, but it must become obvious why it is too simple for you to advance much further. DRY is most certainly not abstraction.

I actually took a general Software Development course when I was in school that sort of touched on things like Linux, source control, debugging, and other things I now forget— it was an elective though. It was neat, the teacher even introduced us to Ruby, which was a cool experience for a bunch of dumb kids who thought the whole world ran on Java or C++ :) I liked it so much I went on to implement Ruby-isms in C++ for my other classes, and use those to orchestrate solutions. Completely dumb in retrospect, but I thought it was so cool at the time. And hey I guess that’s a great example of learning early on how to “hide the bad parts!”

Re: Holding a Program in One's Head (2007)

#67

Post by akira2501 »

jimbokun wrote: post #39
akira2501 wrote: post #23

Earlier quoted context omitted.

People who are famous for running companies and not writing code.

Robert Morris, Peter Norvig and Stephen Wolfram didn't write code? (I don't recognize some of the others.)

Is that what they're famous for or even what they've dedicated most of their time to? From looking at their histories I would not describe them as "coders." Let alone presume that they have anything to offer anyone doing the same in a modern context.

"Keep the whole program in your head?"

Cool advice for small greenfield projects that you can sell to unsophisticated companies and then move on. Interesting that it comes from an investing firm that makes this precise activity it's core business and reviewed by people who are in a position to directly benefit from this.

This is all terrible advice if you want to actually contribute to or work on anything significant in your life.

Re: Holding a Program in One's Head (2007)

#68

Post by corytheboyd »

kmoser wrote: post #13
corytheboyd wrote: post #3

> […] bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above I like to explain this as “hide the bad parts behind a good API”. Anything interesting is going to require “bad parts”, which just means the low-level, difficult work. From there, compose up and up until a high level orchestration is achieved. It works so much better than the bad pa…

Said another way: push interface up and implementation down.

Well said, I’ll be taking that :)

Re: Holding a Program in One's Head (2007)

#69

Post by ellis0n »

PaulHoule wrote: post #65

I'll call out 7. Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would. On some level it's true but it is also true that most of the world's code is in some sort…

I think it was 2007 when the vision of software, developers and resources was still limited. We didn't even have IoT and the first iPhone was seen as a novelty. Now it's clear that this is not the case. I founded a company in 2006 and started focusing on code review because I was interested in code and wanted to be the best. Since the advent of GitHub, I have reviewed thousands of repositories across many languages, worked on architecture, tried to create better code, developed several operating systems, hundreds of projects and dedicated 12 years to programming languages. In the end, I realized that the world is ruled by chaos and the simplest LLM AI is best suited for the task of code functionality.

For example, consider this analogy: when we make a car, we have one wheel and a multitude of parameters that change over time. The wheel is a derivative of these parameters. In car manufacturing, time is virtually unlimited for improving the quality of the wheel. But when we develop software, we always face time constraints and an enormous set of parameters. Thousands of car engineers spend decades improving a single wheel with a limited number of parameters, while a single programmer (or a couple of programmers) have only a short amount of time to release software with a randomly variable number of parameters (a service depends on Auth0 and its parameters change). As a result the programmer cannot be certain that all parameters have been correctly handled. This is why the programming process is similar to learning, and this is where LLMs are the best.

Re: Holding a Program in One's Head (2007)

#70

Post by HeyLaughingBoy »

ellis0n wrote: post #69
PaulHoule wrote: post #65

I'll call out 7. Don't have multiple people editing the same piece of code. You never understand other people's code as well as your own. No matter how thoroughly you've read it, you've only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would. On some level it's true but it is also true that most of the world's code is in some sort…

I think it was 2007 when the vision of software, developers and resources was still limited. We didn't even have IoT and the first iPhone was seen as a novelty. Now it's clear that this is not the case. I founded a company in 2006 and started focusing on code review because I was interested in code and wanted to be the best. Since the advent of GitHub, I have reviewed thousands of repositories across many languages,…

Actually I think it was in 2007 that I was leading my company's first IoT project to get remote access to our medical instruments' operational data.
Post reply on HN