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

41–50 of 104 posts

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

#41

Post by sillysaurus »

ehsanu1 wrote: post #22
dualogy wrote: post #12

Earlier quoted context omitted.

Sounds like you have a number of tangible, palpable, feasible ideas for such super-smarter next-gen programming tools -- care to share? (Just hoping what you have in mind isn't UML + SOAP + some unintelligable über-abstracted-meta-code-gen...)

I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that…

I have one: natural language programming.

This exists. It's "Write each step of an algorithm in comments before writing any code, and (only when you're finished writing each step in English in comments) fill in the code each comment represents".

But it's impossible to convince anyone to try that, though, even though it gives all the benefits you are imagining NLP would give.

The mentality "Don't repeat yourself under any circumstances, even if it adds no complexity and increases clarity!" is unfortunately why this is undiscovered. Also, people generally go overboard with the "commenting" part -- the purpose is to be pseudocode in the way Python is executable pseudocode, while retaining the ambiguity that is necessary for natural language to be natural. So it gets a bad reputation, and its power is hidden despite it being powerful.

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

#42

Post by d2vid »

sanxiyn wrote: post #6

I agree with the power of holding a program in one's head, but I also consider this a (the?) serious bottleneck in the software engineering. I hope we discover a scalable alternative to holding a program in one's head. It doesn't need to be as good as holding a program in one's head, it just needs to approximate it. (Edit: see also Design Beyond Human Abilities by Richard P. Gabriel.)

I would argue TDD is a workaround which allows you to do meaningful work in a team context without holding a complete program in one's head.

It gets everyone to put their thoughts about what the program should do in one place. Every time you run the test suite, you are outsourcing to the test suite the task of running through your mental model of the program and thinking "what did I break".

The limitation of TDD is that it blocks rapid iteration in what the program should do. When you load the entire model of the program into your head, requirements change at the speed of thought. With TDD, they change at the speed of a lot of reading and typing.

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

#43

Post by winter_blue »

codewright wrote: post #19
mtraven wrote: post #10

It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp…

Mumble mumble Clojure mumble simple made easy mumble mumble immutable values mumble concurrency.

I have no idea what you're talking about here with the mumbles; but I can see that you're getting upvoted, so I suppose there's some hidden context here that I'm not aware of. Someone care to clarify?

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

#44

Post by andrewcooke »

kubrickslair wrote: post #8

In my experience, this is PG's most helpful/ reassuring technical essay. Recently I was working on/ creating pretty complex algorithms with gargantuan cobweb of edge cases. Not only did I had to work for 15+ straight hours, but in order to maintain productivity fasted (bar caffeine, few nuts & water) every alternate day to keep the steam going. Incredible times, and rather close to reaping the fruits now, but there i…

i'm not bashing you - i've been there myself. but that same shared experience requires me to ask: dude, how are you going to maintain that?

you need to find a simpler way... if that's how you feel now, a year down the line you're going to hate that code.

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

#45

Post by Spearchucker »

batgaijin wrote: post #36
Spearchucker wrote: post #35

Warning: controversy. The text misses the point in that having to hold a program in one's mind is not required to begin with. The real problem is complexity. There's just so much going on that it's difficult to remember. And complexity is solved through abstraction - separating the problem out into manageable components. That way the programmer works at a system level, at which components are composed into a solution…

What about Haskell? The type system tells you exactly what's going on.

Some tools are better than others. I'm not familiar with Haskell but can tell you that in the .NET world LINQ is bad, because it forces the melding of process components with data access logic.

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

#46

Post by barrkel »

winter_blue wrote: post #43
codewright wrote: post #19

Earlier quoted context omitted.

Mumble mumble Clojure mumble simple made easy mumble mumble immutable values mumble concurrency.

I have no idea what you're talking about here with the mumbles; but I can see that you're getting upvoted, so I suppose there's some hidden context here that I'm not aware of. Someone care to clarify?

http://www.infoq.com/presentations/Simple-Made-Easy

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

#47

Post by shuttlebrad »

winter_blue wrote: post #43
codewright wrote: post #19

Earlier quoted context omitted.

Mumble mumble Clojure mumble simple made easy mumble mumble immutable values mumble concurrency.

I have no idea what you're talking about here with the mumbles; but I can see that you're getting upvoted, so I suppose there's some hidden context here that I'm not aware of. Someone care to clarify?

He's probably referring to the idea that much of the complexity around today is not particularly useful - in particular, that programming with values rather than variables makes understanding a program substantially easier.

Simple Made Easy is a talk by Rich Hickey, the author of the Clojure programming language which encodes a lot of these ideas into the language.

http://www.infoq.com/presentations/Simple-Made-Easy

[EDIT: ambiguous comma :)]

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

#48

Post by jrogers65 »

For years now I have been arguing with other programmers on the merits of IDE features such as intellisense. My position has always been that they are completely unnecessary. Autocomplete is useful, sure, since it saves some typing, but that is it's primary goal - to save keystrokes, not to help you remember what a class is capable of doing.

Many programmers appear to get caught up in the small picture way of thinking, where all that they consider important is the code they are currently working on. The fact of the matter is that a piece of software is an ecosystem. Every part of it is directly or indirectly tied to every other part. It is only when we consider the system as a whole that we can create an elegant architecture. This is simply not possible if things are always seen as units and their relationships are an afterthought.

Thank you for this link. I shall be using it to add fuel to any future arguments along these lines.

EDIT:

Clearly, it takes a lot of effort and skill to pull this off. The bottleneck becomes the human. The logical question that follows is 'how do we make the human more efficient and capable of remembering more?'. The answer is diet, nootropics, meditation, exercise and knowledge of techniques (e.g. how to memorise facts rapidly). I won't go into specifics but suffice it to say that most people are undernourished and are mentally impaired because of it.

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

#49

Post by JBiserkov »

sillysaurus wrote: post #41
ehsanu1 wrote: post #22

Earlier quoted context omitted.

I have one: natural language programming. I have some ideas about how it would work, and have looked a little into how it might be implemented and have some seemingly feasible ideas there too. But I'm not an expert in either NLP or programming language development, so what do I know. A good first step in this direction is the natural programming language for creating interactive fiction, Inform 7. The problem is that…

I have one: natural language programming. This exists. It's "Write each step of an algorithm in comments before writing any code, and (only when you're finished writing each step in English in comments) fill in the code each comment represents". But it's impossible to convince anyone to try that, though, even though it gives all the benefits you are imagining NLP would give. The mentality "Don't repeat yourself under…

Some Lispers have been doing something similar for some time. There's even a saying that "Any sufficiently well-documented Lisp program contains an ML program in its comments."

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

#50

Post by skrebbel »

mtraven wrote: post #10

It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head. If they were better (more expressive, easier to interact with) they would help to solve the problems rather than require superhuman feats of endurance. pg does mention that succinct programming languages help, which is true, but they don't go nearly as far as they could. Like him, I use Lisp…

> It's actually an indictment of our programming tools that they require one to hold so much of the design context in one's head.

No, it's not, because we will keep looking for the limits. Once a programming tool allows you to do alone what you need 10 engineers for now, some genius will use those tools to do what you need 10 engineers for then, and then teams of 10 engineers will try to copy that. We'll always be driven to meet the limits of what fits in one engineers' head.

Post reply on HN