Live data from Hacker News

Holding a Program in One's Head (2007)

paulgraham.com

91–100 of 104 posts

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

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

The closest experience I've had to this is using RSpec and Capybara to do test-driven development.

Here's an actual snippet of a test I wrote before writing the corresponding code for an app that's now in production:

  describe "adding participants" do                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
    context "when user has created a new event" do
      before :each do
        visit root_path
        click_link 'Get Started'
        fill_in 'Name', :with => 'Tres'
        fill_in 'E-mail', :with => 'tres@sogetthis.com'
        click_button 'Next'
      end
    
      it "should prompt for more participant info" do
        page.should have_field 'Name'
        page.should have_field 'E-mail'
        page.should have_button 'Add Participant'
      end
    
      it "shouldn't let you enter an invalid e-mail" do
        fill_in 'Name', :with => 'Tres'
        fill_in 'E-mail', :with => '#)(*)($*#)($*'
        click_button 'Add Participant'
        page.should have_content 'invalid'
      end
    end
  end
It's been an absolute joy to work this way. I'd love to see this level of abstraction make its way into the mainstream in other languages and environments.

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

#92

Earlier quoted context omitted.

>>>> "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." Dude, if you have some concrete insights in these areas, you definitely should go into specifics . A lot of us would be very interested.

My apologies, I thought that it was outside of the context of the conversation. A surprisingly high percentage of people have nutritional deficiencies. For example, an alarmingly high percentage of people in the US are deficient in Magnesium, an essential nutrient (meaning that your body cannot manufacture it). http://en.wikipedia.org/wiki/Magnesium_deficiency_%28medicin... > 57% of the US population does not meet th…

Interesting. Where have you learned this information? Are there some books / studies / other sources you can point to? (Not a demand for evidence ... just that I'm curious to look more into this).

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

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

Completely true. That is exactly the Bret Victor's point in "Inventing on Principle":

http://vimeo.com/36579366

http://worrydream.com/#!/LearnableProgramming

Programming tools (languages, APIs, IDEs) needs to reduce the problem you need to hold in your head.

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

#94
post #42
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 t…

TDD done correctly should allow the validation of "speed of thought" changes. It happens to me often that ideas spawned between my ears break functionality in the actual application if the application is complex. It doesn't mean that the idea was invalid, tests simply illuminate what else needs to be changed if you'd like to go forward with the change.

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

#96
post #52

Earlier quoted context omitted.

> Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others. The best way to learn something is to come up with it yourself. If you base your architecture on what you read in books or elsewhere, you probably only have a limited understanding of…

The best way to learn something is to come up with it yourself. That's been bugging me, and it's been bugging me because it's not entirely right. It's not entirely wrong either, though. Given an undirected graph, in which you need to calculate the shortest path between two vertices, would you slog it out or would you just find a shortest path algorithm? Now move that up a level, from feature implementation to feature…

> Given an undirected graph, in which you need to calculate the shortest path between two vertices, would you slog it out or would you just find a shortest path algorithm?

Probably just find an algorithm. This is because my goal was not to learn about shortest path algorithms, rather it was to find the shortest path. Whichever algorithm I chose and however I implemented it is of minimal concern - if it turns out to be bad, I can probably redo it without significantly affecting any other part of the program. I claim that, if, on the other hand, you wanted to learn about shortest path algorithms, it would be better to first at least try to think of a solution or two, then go for the books.

Speaking of software architecture, given the profound impact a solution will have and how disastrous bad choices can get, it should be your goal to learn about whatever you're dealing with.

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

#97
post #52

Earlier quoted context omitted.

> Consider though that in this community 99.9% of the time others have solved your problem before. You could reinvent the wheel (which is arrogant), or you could do some research to see which architecture has been successful for others. The best way to learn something is to come up with it yourself. If you base your architecture on what you read in books or elsewhere, you probably only have a limited understanding of…

The best way to learn something is to come up with it yourself. That's been bugging me, and it's been bugging me because it's not entirely right. It's not entirely wrong either, though. Given an undirected graph, in which you need to calculate the shortest path between two vertices, would you slog it out or would you just find a shortest path algorithm? Now move that up a level, from feature implementation to feature…

> If you had to federate identities between two directories, would you hack something together

Right, that "try it yourself" part can get very big and impractical. But the idea still stands: it would be better if you first tried to think how a solution would look like and what it would do, in very general terms. Are the two systems very similar and a solution would be little more than mapping one thing onto another? Or are the systems very different and complex translations would be have to be performed?

Once you do that, you can have a look at any existing solutions, and almost certainly you'll have a better understanding compared to if you didn't do the thinking part first.

It is also important not to switch the order of "thinking" and "looking". If you first look for existing solutions, then your thinking will be biased by what you have seen.

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

#98
post #86

Earlier quoted context omitted.

> 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. Reminds me of a misconception a vocal student I met had about math. She thought she could understand the attraction of math because the symbols and equations could look pretty. I had to explain that the beauty was not in the symbols, but in the pictures and concepts they could evoke in you…

Feynman had a neurological condition called synesthesia [1], which is when senses get mixed together in the same neurological pathway and you can "taste" a sound or "hear" a color. Which is very interesting since Feynman was said to have a "frightening" ease with equations, like an intuitive understanding of what they meant. [1] http://en.wikipedia.org/wiki/List_of_people_with_synesthesia...

I didn't know that was a thing. I fit this description.

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

#99
post #95

I just came across this article in a HN post last week that was discussing a similar theme. I think it does a great job explaining the challenges of beings programmer... http://alexthunder.livejournal.com/309815.html

This is a fantastic summary, and I thank you for sharing.

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

#100
post #87
post #60

Earlier quoted context omitted.

Those types of problems are not programming problems per se, but more like riddles for math inclined. Once you know the solution, the coding tends to be rather trivial with regard to control and data structures.

Olympiad programs are pure algorithms, which I agree are more math intensive than most "normal" programming done today (though I wouldn't dismiss math as "riddles"). But that's my whole point: most problem domains have some mathy parts, whether in the algorithms or from the problem domain. As we reduce the cognitive burden of plumbing and architecture that exists in programming today, these meaty parts will take up a…

Oh, but they are riddles. Hanoi tower, permutations, travelling salesman kind of problems. Algorithmically tricky (not hard, the problems are in textbooks for ages), but trivial from a programming perspective. The kind of problems that a physics major would think constitutes programming, but mostly irrelevant to complexity met in either the industry or CS academia.

I do some machining as a hobby; there are decades old teasers like turning a cube inside a hollow cube on a lathe from a piece of round stock. I feel like those are very much like Olympiad problems in nature, and just as remote from real-life machining exercises.

Post reply on HN