Legendary Productivity and the Fear of Modern Programming

http://techcrunch.com/2015/09/11/legendary-productivity-and-the-fear-of-modern-programming/

by wyclif • 11 years ago

87 51 11 years ago

techcrunch.com

gaius• 11 years 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• 11 years ago

Means JScheme, which, yes, isn't one of his better-known works. The whole article is like that.

dasil0032• 11 years 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• 11 years 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• 11 years 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_Machine3• 11 years 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.

danmaz743• 11 years 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".

jrochkind1• 11 years ago

If you say 'have designed' instead of 'have built'... I don't think we'd say the world economy has been designed, exactly.

crimsonalucard2• 11 years ago

The OP is referring to white box systems where the programmer thoroughly understands everything. The economy may be artificial, but its' immense complexity makes it a black box.

dasil0032• 11 years ago

The world economy is not analogous to "any piece of software", it is loosely analogous to something like "all software running on the Internet" or some other broad set of heterogenous systems.

xiaoma2• 11 years 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• 11 years 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.

nickpsecurity9• 11 years 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

Oberon System 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

The processors 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.

minthd• 11 years ago

"Woz prototyped the guts of the Apple II, but needed a lot of help from people like Fernandez to turn it into reliable, repeatable hardware":

https://www.reddit.com/r/business/comments/3jyovw/woz_jobs_d...

akavel2• 11 years ago

Also, how about:

- Donald Knuth (TeX, METAFONT); even more surprising here given that he's mentioned in the article a few times on other accounts; https://en.wikipedia.org/wiki/Donald_Knuth

- Fabrice Bellard (QEMU, FFmpeg, & other) https://en.wikipedia.org/wiki/Fabrice_Bellard

nickpsecurity9• 11 years ago

Good examples.

graycat2• 11 years ago

Right. You saved me from making this outstanding correction.

So, Knuth did TeX, METAFONT, Web, Weave, and Tangle for literate programming, and published the literate version of the code. Essentially just one guy.

xiaoma2• 11 years ago

Or Bill Joy: vi, c shell and large parts of BSD.

kragen• 11 years ago

Knuth had help from his graduate students. Some of them did their dissertations on work they did in TeX and I think METAFONT too.

nickpsecurity9• 11 years ago

I intended to prove that wrong one day given what I've seen Moore, Wirth, LISP machine people, etc do with no more than two people. However, if I'm to be honest, anything I come up with individually will be a rehash of what a bunch of others came up with. So, hard to even say it was my own work unless I did something radically different across the board from the circuits up.

hga3• 11 years ago

The Lisp Machine project had way more than 2 people, and something more than 2 full time equivalents.

crimsonalucard2• 11 years ago

not one bug? lets be real.

nickpsecurity9• 11 years 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

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• 11 years ago

Bram has written a post (link: 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 ;)

nickpsecurity9• 11 years 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• 11 years 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.

graycat2• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

Legendary Productivity and the Fear of Modern Programming

Related Stories