10 ms·

Legendary Productivity and the Fear of Modern Programming

87 points by wyclif 11y ago

gaius 11y ago
Peter Norvig may be immediately associated with JSchema Umm, what? One of many weird things in this article. Generally non-programmers do not write well about programming.
- abecedarius 11y ago
  Means JScheme, which, yes, isn't one of his better-known works. The whole article is like that.
  - deleted 11y ago
    [deleted]
- dasil003 11y ago
  Yeah the weirdness. It's funny because I'm generally sympathetic to the thrust of the article, but then there are these random sentences that just read like a Markov chain.
- nan567 11y ago
  The author may not be a programmer (hence the weirdness) but the points are generally articulated well. I agree with and like the conclusion a lot.
jacques_chester 11y ago
Whether software is the most complex systems humans have built very much depends on what you consider to be a system. And whether you agree that software is the most complex thing humans have built also seems to correlate, to a remarkable degree, with whether you build software for a living.
- Turing_Machine 11y ago
  "Whether software is the most complex systems humans have built very much depends on what you consider to be a system." Indeed. To take just one example, the world economy is a system created entirely by human beings, yet seems to me to be much more complex than any piece of software. People try to model pieces of the economy with software, with varying degrees of success, but I don't think it's feasible (it may be impossible) to model the economy as a whole.
  - danmaz74 11y ago
    I don't know if software systems are the most complex systems we built, but you can't compare it to the world economy, which is an emergent property that nobody has "built".
    - Turing_Machine 11y ago
      It's composed of the individual actions of human beings, so yes, it was built. It certainly isn't a natural phenomenon. "Emergence" doesn't have any bearing on it. The properties of music and art are emergent, too. Doesn't make them not constructed by humans.
      - ArkyBeagle 11y ago
        The economy is emergent in ways that art and music are not.
      - toothbrush 11y ago
        The difference is intensional or extensional behaviour.
      - danmaz74 11y ago
        > It certainly isn't a natural phenomenon. Now, this is interesting. You mean that we humans aren't a natural phenomenon? :D
xiaoma 11y ago
>While no one programming legend can possibly accomplish any big feat solo, there are programmers worthy of fame for their supreme productivity. Actually at least one programming legend did according to many: ------ Woz designed all the hardware and all the circuit boards and all the software that went into the Apple II, while the other Steve spewed marketing talk at potential investors and customers on the phone. Every piece and bit and byte of that computer was done by Woz, and not one bug has ever been found, “not one bug in the hardware, not one bug in the software.”[15] The circuit design of the Apple II is widely considered to be astonishingly beautiful, as close to perfection as one can get in engineering. Woz did both hardware and software. Woz created a programming language in machine code. Woz is hardcore. -Geek Sublime: The Beauty of Code, the Code of Beauty
- Kenji 11y ago
  Wow, thank you for that quote. That boggles my mind. Not one bug? I've seen impressive programmers in my life but never like this.
  - nickpsecurity 11y ago
    Look at Wirth's and Gutknecht's Lilith project. After seeing Xerox's PC's, they independently from Apple invented a PC and GUI line involving: a custom computer; a CPU from bit-slice chip; an ideal assembler (M-code); a high-level, safer language (Modula-2) built for it; compiler; primitive OS; basic tools. This work and much of its methodology later became the Oberon language and system, also a 2 person job. They also implemented custom HDL's and hardware for it later on. I believe one person, esp of Wirth's or Gutknecht's capacity, could've built all this albeit with a lot more time required. The key was simplicity, layers, understanding each module, and incrementally building them. Lilith System http://www.cfbsoftware.com/modula2/Lilith.pdf http://www.cfbsoftware.com/modula2/Lilith.pdf Oberon System http://e-collection.library.ethz.ch/eserv/eth:3180/eth-3180-01.pdf http://e-collection.library.ethz.ch/eserv/eth:3180/eth-3180-... Synthesis of Hardware Circuits from Sequential Programs http://inf.ethz.ch/personal/wirth/Oberon/286.pdf http://inf.ethz.ch/personal/wirth/Oberon/286.pdf The processors http://oberoncore.ru/_media/library/computersystemdesign.pdf http://oberoncore.ru/_media/library/computersystemdesign.pdf People like them are the true "full-stack" developers. Apps, OS, circuits... coded it all and integrated it cleanly usually in 2 year periods.
nickpsecurity 11y ago
Seems mostly right on. I don't think you need to know one language, though. You just need to understand whatever tools you use to model the problem and solution. One can get pretty far by ignoring as much of what's out there as possible, using subsets, and using a consistent style across tools. Let's you get more in your head without mastery of every detail. I still use a Cleanroom-like approach and FSM's with my programs looking similar across toolchains. re nobody accomplishing any big feat solo Seems to be a few, potential counterexamples on this list: https://en.wikipedia.org/wiki/List_of_programmers https://en.wikipedia.org/wiki/List_of_programmers Bram Cohen's Bittorrent jumps out as having traits of one programmer, a solid technical contribution, and impact. Probably more but must assess if they had help. List is misleading on that part.
- dunkelheit 11y ago
  Bram has written a post (link: http://bramcohen.livejournal.com/4563.html http://bramcohen.livejournal.com/4563.html) about what in his view separates great programmers from others (spoiler: it is the ability to come up with good architectural decisions). But then, his codeville project went nowhere so take it with the grain of salt ;)
  - nickpsecurity 11y ago
    That was an interesting write-up. I disagree with how he thinks people will come up with good architectural decisions. That blind trial-and-error is how most programming happens and most of it is anything but good architecture. It's a nice learning and exploratory process, though. For learning architecture, I'd recommend people do what I did: look up all kinds of present and past solutions to problems that worked well to see how they did it. See what they worked with, constraints, goals, specifics, and what resulted. Most discoveries are re-hashes of old ones and there's plenty of good stuff to draw on in many subfields. Some are truly novel but studying old stuff for new applications will get you pretty far. Out of the box thinking for the rest.
wslh 11y ago
One thing is to start SOLO when the field or subfield is new and a very different thing when it is mature. Game programming? individuals or small teams developing great games for the Atari 2600, Sinclair X, and Commodore Y but now that's almost impossible. You can follow the indy programming route but requires to ignore some dimension of the finished product.
graycat 11y ago
We can't forget: "adding programmers to a late project makes it later" Right, Brooks. And his solution was the chief programmer team.
marktangotango 11y ago
This article is bizarre: "The greatest programming minds are capable of using software to multiply massive integers that are bigger than the universe." What does this even mean?
- hugh4 11y ago
  We could generously assume some words are missing and it means "numbers larger than the number of particles in the universe". But there's only 10^80 particles in the universe, so that's not very impressive. You could do it, rather tediously, with a pen and paper.
- eliben 11y ago
  Here you go: $ python >>> 10e50 * 10e90 1e+142 Waaaay bigger than the number of atoms in the universe. Consider yourself the "greatest programming mind" now. You're welcome ;-)
taeric 11y ago
The point about internalizing what you are doing is sadly overshadowed here. I know folks love Bret Victor's talks about externalizing this visualization to teach people and make things easier to show to others. What that misses, is there is a great benefit to internalizing this such that you don't have to find a way to visualize it. The killer section for me is Thompson's quote regarding how hard it is to follow programs that are built with layer upon layer. Just a single paragraph really sums this up.
randomsearch 11y ago
two books I would recommend anyone wanting to become a great programmer to read: - the pragmatic programmer - clean code I'm not sure I believe articles like this, but myself and colleagues have found these books to greatly improve our coding.
15155 11y ago
> It’s simple: If code is too dependent on one person, your business is susceptible to dire wounds. Ah, reduce your product to what the lowest common denominator is capable of producing, to avoid too much "dependence" on them. AKA: Make sure your engineering team is entirely swappable, like batteries. Plug them in, burn them out, no problem.

87 points by wyclif 11y ago

gaius 11y ago

Peter Norvig may be immediately associated with JSchema Umm, what? One of many weird things in this article. Generally non-programmers do not write well about programming.

abecedarius 11y ago
Means JScheme, which, yes, isn't one of his better-known works. The whole article is like that.
- deleted 11y ago
  [deleted]
dasil003 11y ago
Yeah the weirdness. It's funny because I'm generally sympathetic to the thrust of the article, but then there are these random sentences that just read like a Markov chain.
nan567 11y ago
The author may not be a programmer (hence the weirdness) but the points are generally articulated well. I agree with and like the conclusion a lot.

jacques_chester 11y ago

Whether software is the most complex systems humans have built very much depends on what you consider to be a system. And whether you agree that software is the most complex thing humans have built also seems to correlate, to a remarkable degree, with whether you build software for a living.

Turing_Machine 11y ago
"Whether software is the most complex systems humans have built very much depends on what you consider to be a system." Indeed. To take just one example, the world economy is a system created entirely by human beings, yet seems to me to be much more complex than any piece of software. People try to model pieces of the economy with software, with varying degrees of success, but I don't think it's feasible (it may be impossible) to model the economy as a whole.
- danmaz74 11y ago
  I don't know if software systems are the most complex systems we built, but you can't compare it to the world economy, which is an emergent property that nobody has "built".
  - Turing_Machine 11y ago
    It's composed of the individual actions of human beings, so yes, it was built. It certainly isn't a natural phenomenon. "Emergence" doesn't have any bearing on it. The properties of music and art are emergent, too. Doesn't make them not constructed by humans.
    - ArkyBeagle 11y ago
      The economy is emergent in ways that art and music are not.
    - toothbrush 11y ago
      The difference is intensional or extensional behaviour.
    - danmaz74 11y ago
      > It certainly isn't a natural phenomenon. Now, this is interesting. You mean that we humans aren't a natural phenomenon? :D

xiaoma 11y ago

>While no one programming legend can possibly accomplish any big feat solo, there are programmers worthy of fame for their supreme productivity. Actually at least one programming legend did according to many: ------ Woz designed all the hardware and all the circuit boards and all the software that went into the Apple II, while the other Steve spewed marketing talk at potential investors and customers on the phone. Every piece and bit and byte of that computer was done by Woz, and not one bug has ever been found, “not one bug in the hardware, not one bug in the software.”[15] The circuit design of the Apple II is widely considered to be astonishingly beautiful, as close to perfection as one can get in engineering. Woz did both hardware and software. Woz created a programming language in machine code. Woz is hardcore. -Geek Sublime: The Beauty of Code, the Code of Beauty

Kenji 11y ago
Wow, thank you for that quote. That boggles my mind. Not one bug? I've seen impressive programmers in my life but never like this.
- nickpsecurity 11y ago
  Look at Wirth's and Gutknecht's Lilith project. After seeing Xerox's PC's, they independently from Apple invented a PC and GUI line involving: a custom computer; a CPU from bit-slice chip; an ideal assembler (M-code); a high-level, safer language (Modula-2) built for it; compiler; primitive OS; basic tools. This work and much of its methodology later became the Oberon language and system, also a 2 person job. They also implemented custom HDL's and hardware for it later on. I believe one person, esp of Wirth's or Gutknecht's capacity, could've built all this albeit with a lot more time required. The key was simplicity, layers, understanding each module, and incrementally building them. Lilith System http://www.cfbsoftware.com/modula2/Lilith.pdf http://www.cfbsoftware.com/modula2/Lilith.pdf Oberon System http://e-collection.library.ethz.ch/eserv/eth:3180/eth-3180-01.pdf http://e-collection.library.ethz.ch/eserv/eth:3180/eth-3180-... Synthesis of Hardware Circuits from Sequential Programs http://inf.ethz.ch/personal/wirth/Oberon/286.pdf http://inf.ethz.ch/personal/wirth/Oberon/286.pdf The processors http://oberoncore.ru/_media/library/computersystemdesign.pdf http://oberoncore.ru/_media/library/computersystemdesign.pdf People like them are the true "full-stack" developers. Apps, OS, circuits... coded it all and integrated it cleanly usually in 2 year periods.

nickpsecurity 11y ago

Seems mostly right on. I don't think you need to know one language, though. You just need to understand whatever tools you use to model the problem and solution. One can get pretty far by ignoring as much of what's out there as possible, using subsets, and using a consistent style across tools. Let's you get more in your head without mastery of every detail. I still use a Cleanroom-like approach and FSM's with my programs looking similar across toolchains. re nobody accomplishing any big feat solo Seems to be a few, potential counterexamples on this list: https://en.wikipedia.org/wiki/List_of_programmers https://en.wikipedia.org/wiki/List_of_programmers Bram Cohen's Bittorrent jumps out as having traits of one programmer, a solid technical contribution, and impact. Probably more but must assess if they had help. List is misleading on that part.

dunkelheit 11y ago
Bram has written a post (link: http://bramcohen.livejournal.com/4563.html http://bramcohen.livejournal.com/4563.html) about what in his view separates great programmers from others (spoiler: it is the ability to come up with good architectural decisions). But then, his codeville project went nowhere so take it with the grain of salt ;)
- nickpsecurity 11y ago
  That was an interesting write-up. I disagree with how he thinks people will come up with good architectural decisions. That blind trial-and-error is how most programming happens and most of it is anything but good architecture. It's a nice learning and exploratory process, though. For learning architecture, I'd recommend people do what I did: look up all kinds of present and past solutions to problems that worked well to see how they did it. See what they worked with, constraints, goals, specifics, and what resulted. Most discoveries are re-hashes of old ones and there's plenty of good stuff to draw on in many subfields. Some are truly novel but studying old stuff for new applications will get you pretty far. Out of the box thinking for the rest.

wslh 11y ago

One thing is to start SOLO when the field or subfield is new and a very different thing when it is mature. Game programming? individuals or small teams developing great games for the Atari 2600, Sinclair X, and Commodore Y but now that's almost impossible. You can follow the indy programming route but requires to ignore some dimension of the finished product.

graycat 11y ago

We can't forget: "adding programmers to a late project makes it later" Right, Brooks. And his solution was the chief programmer team.

marktangotango 11y ago

This article is bizarre: "The greatest programming minds are capable of using software to multiply massive integers that are bigger than the universe." What does this even mean?

hugh4 11y ago
We could generously assume some words are missing and it means "numbers larger than the number of particles in the universe". But there's only 10^80 particles in the universe, so that's not very impressive. You could do it, rather tediously, with a pen and paper.
eliben 11y ago
Here you go: $ python >>> 10e50 * 10e90 1e+142 Waaaay bigger than the number of atoms in the universe. Consider yourself the "greatest programming mind" now. You're welcome ;-)

taeric 11y ago

The point about internalizing what you are doing is sadly overshadowed here. I know folks love Bret Victor's talks about externalizing this visualization to teach people and make things easier to show to others. What that misses, is there is a great benefit to internalizing this such that you don't have to find a way to visualize it. The killer section for me is Thompson's quote regarding how hard it is to follow programs that are built with layer upon layer. Just a single paragraph really sums this up.

randomsearch 11y ago

two books I would recommend anyone wanting to become a great programmer to read: - the pragmatic programmer - clean code I'm not sure I believe articles like this, but myself and colleagues have found these books to greatly improve our coding.

15155 11y ago

> It’s simple: If code is too dependent on one person, your business is susceptible to dire wounds. Ah, reduce your product to what the lowest common denominator is capable of producing, to avoid too much "dependence" on them. AKA: Make sure your engineering team is entirely swappable, like batteries. Plug them in, burn them out, no problem.