Re: LFM + LFSP = LFE?

[Avi Bryant <address@hidden>]

On Thu, 12 Jun 2003, David Herman wrote:

> I agree. A friend told me that to convince someone to change tools, you
> can't just prove to them your tool is better, you have to prove to them
> it's at least ten times better than anything they currently have. For
> most people, they'll hit the first roadblock with something new and
> abandon it for familiar territory. I think to be a successful advocate
> you have to show point-for-point how your tool matches everything the
> existing tools can do, and then blows them out of the water with X, Y,
> and Z. (And then, of course, the hard part, which is getting them to
> hang in there through the learning curve.)

But this is exactly the point I'm trying to make, about why Smalltalk can
appeal to children but not "the masses".  Let's say, for the sake of
argument, that writing code in a Smalltalk environment is 5 times more
productive than writing code with a text editor.  Your hypothetical
programmer isn't going to be convincable, because it's only 5 times, not
10 times, better overall than what he already uses, and in some specifics
it's bound to be worse.  To a child, the choice is very different - they
have no prior expectations, no inertia to overcome, they simply choose the
better tool.

I *know* I'm not going to sell Smalltalk to the majority of Java
programmers.  That's their problem.

> In this case, using text files for source code might be primitive, but
> programmers know how to use this pretty powerfully, e.g., find | xargs
> grep and the like. It's scary to a programmer to relinquish control to
> a mysterious black-box environment that they can no longer tweak with
> their familiar toolset. Given that this kind of tweaking is the primary
> activity of programmers, it's natural that they feel pretty protective
> of their familiar methods.

But if they are programming in Smalltalk, then they presumably don't find
the Smalltalk environment (which is all written in Smalltalk, with source
easily and obviously available and modifiable) to be a mysterious black
box.  It's like saying "I hack elisp in vi because then I can customize my
editor".

> The Excel example was interesting, because while it's true nobody
> normally thinks "I'd rather pop open a text editor to cook up a quick
> spreadsheet," programmers do, in fact, appreciate that you can open a
> CSV file directly in Excel: it's so much easier to print("1,2,3") than
> find some library that can manipulate the binary file format. So again,
> text might be primitive, but it's a least common denominator that a
> programmer is guaranteed to have tools for.

Which is why having a textual representation of the source code is crucial
- you just don't need to be editing it directly.  Actually, it's becoming
more and more common to store Smalltalk source as XML files, which opens
up a whole new set of common denominator tools.  A Java environment could
never get away with this, but once you give up the text editor as the
primary editing tool, why not?