Bill Clementson's Blog: Lisp is for Entrepreneurs - Part 2 (Amazon)(bc.tech.coop)
bc.tech.coop
Bill Clementson's Blog: Lisp is for Entrepreneurs - Part 2 (Amazon)
http://bc.tech.coop/blog/060304.html
5 comments
the biggest bottleneck is the speed of thinking, not the speed of typing.
I agree, but I've had experiences where I get a glimpse of the solution in my mind and I struggle to get it down fast enough, afraid that I might lose it before I get it all down somewhere. In situations like those, I'm very much grateful for touch-typing, autocomplete, and terse languages.
I agree, but I've had experiences where I get a glimpse of the solution in my mind and I struggle to get it down fast enough, afraid that I might lose it before I get it all down somewhere. In situations like those, I'm very much grateful for touch-typing, autocomplete, and terse languages.
PG uses vi? For Lisp? Has he gone mad?
Well, on second thought this makes sense if he's programming in Arc and Scheme these days since Slime wouldnt help much.
In theory I agree with you about editors. One tends to do more thinking than typing, but you need an editor that gets out of your way. I think the same applies to touch typing. Once I get into a state of flow I don't want to have any distractions. For now emacs isn't helping since I still need to lookup certain functionality. But it definitely looks promising.
Well, on second thought this makes sense if he's programming in Arc and Scheme these days since Slime wouldnt help much.
In theory I agree with you about editors. One tends to do more thinking than typing, but you need an editor that gets out of your way. I think the same applies to touch typing. Once I get into a state of flow I don't want to have any distractions. For now emacs isn't helping since I still need to lookup certain functionality. But it definitely looks promising.
Your working environment influences your thinking. You don't have to be typing all the time for a poor editor to interfere with your ability to get things done. Try coding for 3 months exclusively in notepad and see how much productivity you lose. (Or note what other tools you wind up using to make up for the deficiency)
The information you have visible on the screen and easily accessible in a keypress or two is also critical to thinking quickly and efficiently. Yegge once mentioned that he had the perl documentation as emacs .info pages, meaning it probably takes him a few seconds to find a number of frequently used resources. That means he'll probably be better at leveraging standard functions than someone who uses Google. I find the split-screen function in emacs far superior than trying to have multiple windows windows open and arranged on the screen.
One way that emacs is superior to Visual Studio is the keyboard macro facility. I frequently find that I need to make some minor correction that needs to be repeated a few times. Either it's too small a change to be worth refactoring completely using language abstractions or a clunky macro system like MS word, or too complicated to be suitable for copy/paste or find/replace. In a lesser editor, you build up a subconscious resistance to making small corrections like that, so even though you may not be typing furiously all the time, the weaknesses of the editor still affect the way you think and the solutions you're willing to use.
start macro(C-[), search to semicolon(C-s, ;), kill to end of line(C-k), move to beginning of the line(C-a), yank killbuffer(C-y), move to beginning of line(C-a), move down, end macro(C-]).
This is a quick macro that moves everything after the semicolon to the beginning of the line, and can be repeated for consecutive lines as often as necessary. Suppose you had a section of code that looked like this:
Without a keyboard macro facility like the one in emacs, you're stuck jumping around using copy-paste. It will probably take a few minutes, and when you're done you'll have probably lost your train of thought. So even though it may have had a small effect on the lines of code you produced within a given 5-10 minute period, it may significantly affect the trajectory of the entire session. After you get used to emacs, using a macro like this is as easy as typing a line of code.
Visual Studio has its advantages. It has a terrific runtime debugger, for example, and is great for visualizing data structures. But it's worth talking about, and Yegge has some great insights.
The information you have visible on the screen and easily accessible in a keypress or two is also critical to thinking quickly and efficiently. Yegge once mentioned that he had the perl documentation as emacs .info pages, meaning it probably takes him a few seconds to find a number of frequently used resources. That means he'll probably be better at leveraging standard functions than someone who uses Google. I find the split-screen function in emacs far superior than trying to have multiple windows windows open and arranged on the screen.
One way that emacs is superior to Visual Studio is the keyboard macro facility. I frequently find that I need to make some minor correction that needs to be repeated a few times. Either it's too small a change to be worth refactoring completely using language abstractions or a clunky macro system like MS word, or too complicated to be suitable for copy/paste or find/replace. In a lesser editor, you build up a subconscious resistance to making small corrections like that, so even though you may not be typing furiously all the time, the weaknesses of the editor still affect the way you think and the solutions you're willing to use.
start macro(C-[), search to semicolon(C-s, ;), kill to end of line(C-k), move to beginning of the line(C-a), yank killbuffer(C-y), move to beginning of line(C-a), move down, end macro(C-]).
This is a quick macro that moves everything after the semicolon to the beginning of the line, and can be repeated for consecutive lines as often as necessary. Suppose you had a section of code that looked like this:
do_thing(x, y, x); do_other_thing(a, b, c);
to_the_death(j, k, l); to_the_pain(wfb);
do_thing(c, f, e); do_other_thing(t, t, q);
#etc for maybe a dozen lines.
Without a keyboard macro facility like the one in emacs, you're stuck jumping around using copy-paste. It will probably take a few minutes, and when you're done you'll have probably lost your train of thought. So even though it may have had a small effect on the lines of code you produced within a given 5-10 minute period, it may significantly affect the trajectory of the entire session. After you get used to emacs, using a macro like this is as easy as typing a line of code.
Visual Studio has its advantages. It has a terrific runtime debugger, for example, and is great for visualizing data structures. But it's worth talking about, and Yegge has some great insights.
Your example is sort of self-defeating insofar as who would ever type code that looked like
do_thing(x, y, x); do_other_thing(a, b, c);
to_the_death(j, k, l); to_the_pain(wfb);
do_thing(c, f, e); do_other_thing(t, t, q);
#etc for maybe a dozen lines.
I took that example directly from a task that I had myself a short while ago. It is likely to happen any time you must deal with volumes of real data. It's true that if you are using lisp, that particular scenario (which is narrow, not artificial) will be less relevant. But if you are developing in Lisp, Visual Studio is not a real option anyway. The thing is, any time you need to move a bunch of text around that may not exactly conform to your particular object hierarchy, keyboard macros can make the task trivial. If you do decide to completely refactor, keyboard macros help you there as well.
This particular example was inspired by a lexical definitions file, which is a series of regular expressions with code attached to each one. Here's a sample from my actual code:
"!" {lexer_debug(yytext, SIMPLEOP_BANG); yylval.ptnode = lex_leaf(SIMPLEOP_BANG, NULL); return SIMPLEOP_BANG;}
"%" {lexer_debug(yytext, SIMPLEOP_REMAINDER); yylval.ptnode = lex_leaf(SIMPLEOP_REMAINDER, NULL); return SIMPLEOP_REMAINDER;}
What this says is that when the lexer encounters an exclamation point, it first calls a debug function with the text it found and the associated token enum. Then, it creates a leaf node and assigns the result to yylval.ptnode, then it returns the token enum. I have 66 different definitions in the file. Each one passes unique arguments to the various functions. It is difficult to compress the code much further than this. There is very little to be gained by combining everything into one function. Some of the tokens (braces and constants, in particular) have additional code that must be run. If I tried to refactor, I'd have to create a new conditional framework to account for the special cases (either a switch or function pointers since this is C). That would increase logical complexity (the lexer already did the comparison, why do it again?), incur performance overhead for no good reason, and ultimately would not gain me much in the long term.
My original code had the debug function and the leaf function backwards. I needed to fix that. I had two options. I could refactor the whole damn thing and debug the result (which would include 6 special cases), or I could spend 60 seconds recording a keyboard macro and 10 to execute it 60 times. Option two is simply not an option in Visual Studio.
Another example:
Suppose you're using python and have a whole bunch of functions to wrap in classes. The one drawback of 'the whitespace thing' is that if you try to use tabbing to do this it's easy to make a few mistakes and screw up your block structure. It's better to just insert X spaces at the beginning of each line. I made a macro to do exactly this, and can easily bind it to F8 whenever I need to use it. I use F7 and F8 as my utility keys, for functions I don't use all the time but need to be fast when I do use them. I'll probably eventually write a function that will let me cycle the behavior of my function keys sort of like the ability bar in World of Warcraft. That's basically what minor modes are for already (though I don't know how to use them yet).
This particular example was inspired by a lexical definitions file, which is a series of regular expressions with code attached to each one. Here's a sample from my actual code:
"!" {lexer_debug(yytext, SIMPLEOP_BANG); yylval.ptnode = lex_leaf(SIMPLEOP_BANG, NULL); return SIMPLEOP_BANG;}
"%" {lexer_debug(yytext, SIMPLEOP_REMAINDER); yylval.ptnode = lex_leaf(SIMPLEOP_REMAINDER, NULL); return SIMPLEOP_REMAINDER;}
What this says is that when the lexer encounters an exclamation point, it first calls a debug function with the text it found and the associated token enum. Then, it creates a leaf node and assigns the result to yylval.ptnode, then it returns the token enum. I have 66 different definitions in the file. Each one passes unique arguments to the various functions. It is difficult to compress the code much further than this. There is very little to be gained by combining everything into one function. Some of the tokens (braces and constants, in particular) have additional code that must be run. If I tried to refactor, I'd have to create a new conditional framework to account for the special cases (either a switch or function pointers since this is C). That would increase logical complexity (the lexer already did the comparison, why do it again?), incur performance overhead for no good reason, and ultimately would not gain me much in the long term.
My original code had the debug function and the leaf function backwards. I needed to fix that. I had two options. I could refactor the whole damn thing and debug the result (which would include 6 special cases), or I could spend 60 seconds recording a keyboard macro and 10 to execute it 60 times. Option two is simply not an option in Visual Studio.
Another example:
Suppose you're using python and have a whole bunch of functions to wrap in classes. The one drawback of 'the whitespace thing' is that if you try to use tabbing to do this it's easy to make a few mistakes and screw up your block structure. It's better to just insert X spaces at the beginning of each line. I made a macro to do exactly this, and can easily bind it to F8 whenever I need to use it. I use F7 and F8 as my utility keys, for functions I don't use all the time but need to be fast when I do use them. I'll probably eventually write a function that will let me cycle the behavior of my function keys sort of like the ability bar in World of Warcraft. That's basically what minor modes are for already (though I don't know how to use them yet).
I have never commented on an entry on news sites before, and that is the 100% truth. I felt compelled enough to do so now.
That blog entry is the largest load of arrogant, self-indulgent crap I have ever seen coalesced into one place. Either he is doing a piss-poor tribute to the "Bastard Operator from Hell" writings that were common a few years ago.. or he is genuine and the epitome of people I strive to avoid in this industry.
One of the things I like about the web space is that, by and large, I don't have to deal with people like him. They're usually trapped in the lower levels of firmware, device drivers, and OS kernels by choice, because they've hit a sweet spot, built fortresses and refuse to retrain themselves.
That blog entry is the largest load of arrogant, self-indulgent crap I have ever seen coalesced into one place. Either he is doing a piss-poor tribute to the "Bastard Operator from Hell" writings that were common a few years ago.. or he is genuine and the epitome of people I strive to avoid in this industry.
One of the things I like about the web space is that, by and large, I don't have to deal with people like him. They're usually trapped in the lower levels of firmware, device drivers, and OS kernels by choice, because they've hit a sweet spot, built fortresses and refuse to retrain themselves.
the lower levels? He's not arguing for coding in assembly, but Lisp - THE high level language. Unfortunately it takes some (myself included) several years to realize that.
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. - Frederick P. Brooks, Jr
I think people considering the switch to a new lang need to read No Silver Bullet, from those considering COBOL to those considering Rails or CL.
I think people considering the switch to a new lang need to read No Silver Bullet, from those considering COBOL to those considering Rails or CL.
At the risk of misinterpreting what you're getting at: the lesson to take from NSB is not "Don't switch languages" or "Switching languages is ineffective".
The lesson is: "Software development is inherently difficult; don't expect that to change just because you switch to a better language."
Brooks readily embraces and promotes the idea that better languages are vitally important, to strip away complexity that isn't strictly necessary for the already sufficiently complex task of building large software systems.
The lesson is: "Software development is inherently difficult; don't expect that to change just because you switch to a better language."
Brooks readily embraces and promotes the idea that better languages are vitally important, to strip away complexity that isn't strictly necessary for the already sufficiently complex task of building large software systems.
Very well put.
This article makes an argument for having smart people, not for coding in Lisp. There's no indication that they couldn't've written something similarly powerful in some other language, only that they chose not to.
I agree. But it makes me wonder, why did the "smart" developers choose Lisp and not something else?
Well, in the article, the smart developers actually chose C, too. And all of Google's smart developers are choosing C++ and Python. 37 Signals' smart developers are choosing Ruby. Ad infinitum...
We really need to get away from arguing for the goodness of languages based on the success of the people using them.
We really need to get away from arguing for the goodness of languages based on the success of the people using them.
"We really need to get away from arguing for the goodness of languages based on the success of the people using them."
I think it devolves into this when you get into a Blub situation.
So you want to tell someone: "But it has closures! Macros! Object orientation based on multiple-dispatch generic functions! First class functions!"
And you see this stunned, glazed look come across your listener's face.
"Well, Paul Graham made a ton of money on it. Peter Norvig wrote great books about Lisp and now runs Google research. Richard Stallman made it the macro language for the greatest editor ever invented [EDITOR'S NOTE: only try this one with committed Emacs users.]. The Guy who wrote much of the spec for Java after James Gosling wrote famous compilers for Lisp dialect and authored the document that defined the Common Lisp standard. The Greatest Computer Science Course Ever taught at MIT uses a dialect of Lisp. A company who is cleaning their competition's clocks in the airline reservation business uses Lisp."
Etc. etc.
I think it devolves into this when you get into a Blub situation.
So you want to tell someone: "But it has closures! Macros! Object orientation based on multiple-dispatch generic functions! First class functions!"
And you see this stunned, glazed look come across your listener's face.
"Well, Paul Graham made a ton of money on it. Peter Norvig wrote great books about Lisp and now runs Google research. Richard Stallman made it the macro language for the greatest editor ever invented [EDITOR'S NOTE: only try this one with committed Emacs users.]. The Guy who wrote much of the spec for Java after James Gosling wrote famous compilers for Lisp dialect and authored the document that defined the Common Lisp standard. The Greatest Computer Science Course Ever taught at MIT uses a dialect of Lisp. A company who is cleaning their competition's clocks in the airline reservation business uses Lisp."
Etc. etc.
It would be much more compelling to say, "Joe Schmoe picked up this language in a weekend and used it to create a dating site that got 3mil users in a year" than "a few superstar genius programmers who built things you'll never ever build swear by it."
Most people are convinced by examples they can relate to and feel they can achieve, not by the feats of the top experts in a field that feel outside of most people's reach.
Most people are convinced by examples they can relate to and feel they can achieve, not by the feats of the top experts in a field that feel outside of most people's reach.
It's like selling a religion because John Travolta and Tom Cruise are in it...
well said. well, the having chose Lisp part might not be the most interesting part, but deciding to write an application as an Emacs plugin is pretty interesting.
This is a very relevant question. People don't explore it enough.
A related question is, why was PG afraid that Viaweb's competitors would find out about Lisp and start using it? If smart people did well regardless of language, would that fear make any sense at all?
A related question is, why was PG afraid that Viaweb's competitors would find out about Lisp and start using it? If smart people did well regardless of language, would that fear make any sense at all?
I have heard the claim, fifth-hand, that Yahoo rewrote Stores in C++ in order to get it to scale.
I know that when Google acquires start-ups, the rewrite for scaling commences... so it seems at least somewhat plausible.
I know that when Google acquires start-ups, the rewrite for scaling commences... so it seems at least somewhat plausible.
But, as the quoted article exemplifies, he is about as passionate about programming languages as he is about text editors. He will write one blog article about Lisp and Erlang and how they would give you competitive advantage, and then another article about how Emacs makes you more productive than any other editor, and how using IDEs is for lesser programmers.
Now, I'm not sure about programming languages. But the part about text editors is plain ridiculous. There are great hackers who use vi (Paul Graham) and there are great hackers who swear by Microsoft's IDEs (John Carmack). How many lines of code do you write per day? 100? 200? 500? No matter how great a coder you are, the biggest bottleneck is the speed of thinking, not the speed of typing. I would even say learning touch-typing is an overkill, as far as writing code is concerned.
So that's the reason I'm not taking Stevey's rants exactly seriously. Tomorrow he may decide that eating the right kind of cereals for breakfast is necessary for achieving greatness, and you bet he will be able to make a case for it as convincing as he does for Ruby and Emacs. He is a very exceptional blogger, no question of that.