

Bill Clementson's Blog: Lisp is for Entrepreneurs - Part 2 (Amazon) - cstejerean
http://bc.tech.coop/blog/060304.html

======
pfedor
Yeah, I also like Stevey's blogs.

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.

~~~
Goladus
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:

    
    
          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.
    

Suppose you need to swap the position of the functions on each line, such that
"do_other_thing" comes before "do_thing" and "to_the_pain" comes before
"to_the_death."

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.

~~~
aston
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.
    

? And what IDE wouldn't make that pretty from the get go? And why would you
have more than one instance of something like two functions needing positions
switched when that could've been refactored out? Very artificial example, and
even still doesn't demonstrate the strength of Emacs over somethink like
Visual Studio.

~~~
Goladus
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).

------
mjstumpf
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.

~~~
cstejerean
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.

------
cellis
_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.

~~~
calambrac
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.

~~~
cellis
Very well put.

------
aston
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.

~~~
cstejerean
I agree. But it makes me wonder, why did the "smart" developers choose Lisp
and not something else?

~~~
aston
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.

~~~
jimbokun
"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.

~~~
rontr
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.

------
downer
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.

