Skip to main content

Chapter 12: Beating the Averages

3 replies [Last post]
jonathansimon
Offline
Joined: 2003-06-07

This chapter is Graham telling his story from Viaweb - "the first web based company" as he tells it. But it's largely a description of why Lisp is a superior programming language for business development, and what his company succeeded because of it.

I disagree with this view. I do believe that certain languages are better suited for certain tasks than others - but I have developed some very good applications very quickly in Java. Not to say that you can't do it in Lisp. I'm just saying Lisp isn't the only option.

What's interesting is that there is little mention to how the programmer thinks. I used scheme for a while in college, so I know the beast a bit -- though I'm no master by any means. But I do have a better time with Java now, as I did then, because I can visualize application code more easily. I worked for a while with graphical languages, mostly for music programming. I had an easier time at first mapping visual building blocks to methods. After I got a little more experienced, my understanding became deeper, but I still have a visualization for my code. I can see it in my head.

Now this doesn't have anything to do with experience. I just think different developers work different ways. I have a harder time working in scheme or Lisp than I do in Java, or Python for example. Just interesting.

I wonder what power lies in the language itself, vs. the mind of the programmer.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
johnm
Offline
Joined: 2003-06-06

> This chapter is Graham telling his story from Viaweb
> - "the first web based company" as he tells it. But
> it's largely a description of why Lisp is a superior
> programming language for business development, and
> what his company succeeded because of it.

Lisp was certainly convenient but the trick was the whole server side focus combined with the aggressive listening to what their users both said and did (or didn't) do. I love the story of fixing a bug while the customer was talking to the support person and then telling the user to log out and try it again.

In terms of Lisp being the key, that's mostly just preference. It would be more honest to say that scripting/dynamic languages provide a leverage that better matches that context for development. We've been using languages such as Tcl with the same kind of leverage.

> What's interesting is that there is little mention to
> how the programmer thinks. I used scheme for a while
> in college, so I know the beast a bit -- though I'm
> no master by any means. But I do have a better time
> with Java now, as I did then, because I can visualize
> application code more easily. I worked for a while
> with graphical languages, mostly for music
> programming. I had an easier time at first mapping
> visual building blocks to methods. After I got a
> little more experienced, my understanding became
> deeper, but I still have a visualization for my code.
> I can see it in my head.

Yeah, there's an old study that found that the only factor that clearly correlated with the level of a programmer was how many languages they knew.

> I wonder what power lies in the language itself, vs.
> the mind of the programmer.

IMHO, it's not so much a question of either/or but of how well the language allows for the distinct and succinct expression of the programmer's intent.

jonathansimon
Offline
Joined: 2003-06-07

> Lisp was certainly convenient but the trick was the
> whole server side focus combined with the aggressive
> listening to what their users both said and did (or
> didn't) do.

I think the main things is the listening to users part. Most software teams don't even do that -- so technology isn't even an issue.

> I love the story of fixing a bug while
> the customer was talking to the support person and
> then telling the user to log out and try it again.

Sure, but that really freaks me out from a stability standpoint. I was cringing when I read parts of this knowing that they were just pushing stuff into production like that. Assuming all your tests are automated, you can get pretty quick, but not [i]that[/i] quick.

> In terms of Lisp being the key, that's mostly just
> preference. It would be more honest to say that
> scripting/dynamic languages provide a leverage that
> better matches that context for development.

Dig.

johnm
Offline
Joined: 2003-06-06

> I think the main things is the listening to users
> part. Most software teams don't even do that -- so
> technology isn't even an issue.

Ah, but without the server side approach (or something equivalent) they wouldn't have been able to so aggressively turn the feedback cycles. To be clear, I certainly agree that any team/organization/etc. can gain a lot from really hearing what their users are saying/doing but a yearly release cycle granularity ain't so good for software.

[...]
> Sure, but that really freaks me out from a stability
> standpoint. I was cringing when I read parts of this
> knowing that they were just pushing stuff into
> production like that. Assuming all your tests are
> automated, you can get pretty quick, but not
> [i]that[/i] quick.

Yep, it's funny how disconcerting that much trust in yourself, team, software, etc. can be. :-)