Re: The Next Move in Programming

From: Kenny Tilton (ktilton_at_nyc.rr.com)
Date: 02/15/04 

Date: Sun, 15 Feb 2004 20:59:44 GMT

Dave Roberts wrote:
> Kenny Tilton wrote:
>
>
>>btw, I had a "bug" this morning a compiler would have caught, passing a
>>number where a point (a structure of two numbers) was demanded. But! The
>>bug was simply because I had changed an API so that it no longer
>>tolerated either a number or a point, and I was working my way thru
>>various Cello demos propagating the new state of things.
>
>
> So this brings up a good point. One of the ways that I typically work
> through API changes in C/Java is just that: I recompile and let the
> compiler tell me all the places that are now broken.

Yep, and that does have some appeal, but then there is the downside, not
being able to run until all that work is done. The Lisp Way is to work
in small pieces, so I can have an idea, put in, and give it a try just
like that. I might then decide it was a bad idea, or more likely have an
even better idea, or an /additional/ good idea made possible by the
first change. (One good change leads to another?) Now I have broken two
APIs, but I am running/thinking/improving left and right just wreaking
havoc with the code and it is getting better and better all the time.
I'll sweep up when it all stabilizes.

I wager that with a less friendly compiler I would spot opportunities
for small improvements and just put them off to another day that never
comes, and be more prone to hacking small temporary (ha!) workarounds
rather than fix things properly if I hit some minor obstacle while coding.

  With Lisp, do I have
> to go through a complete re-test cycle?

(a) I just wait till it comes up. Of course on a thirty-person team I
would be tarred and feathered for breaking everyone else's code, and
they would not have the advantage of having made the change and would
spend hours scratching their heads. Of course in time they would just
assume Kenny had been at it again and reach for the tar straight away.

(b) Regression test suites are, well, sweet.

(c) Like I said, Lisp programs at best consist of a smaller amount of
smarter code, so it does not take long to encounter the broken bits.

(d) The breakage is never subtle, so they are easy to spot/fix whwn they
do come up.

>
>
>>With a compiler checking my code, I could not even have tested the
>>change without first changing all the demos to suit, or I would have had
>>to leave in place code which accepted a number but threw an error, so
>>the compiler would see a suitable overloaded function for code I had not
>>yet refactored.
>>
>>In Lisp I just leave hopeless code sitting around until I get back to
>>it, and if it turns out I decide a given refactoring was a mistake,
>>boom!, out it goes and no time was wasted on propagating a doomed change.
>
>
> Hmmmm... my reaction to this is actually negative in the sense that I get
> nervous about forgetting things that I haven't yet done.

That will pass. Lisp is all about knocking down the barriers to
productivity, one of which is anxiety over breaking something that
works. Once it becomes clear that code can be got working again without
much trouble, I am free to continually reshape it as I spot better ways.

In a production environment one does want a regression test to run, but
that should be true no matter what language I am using.

  If I was using
> Java with Eclipse as my IDE, I'd just back out changes using the IDE and it
> wouldn't be a big deal either. That isn't a language thing, it's an IDE
> thing.

It's an IDE thing /because/ the language is unfriendly to incremental
development. Here's an example, came up yesterday. I had to add a
parameter to a function call to handle a new use case. No existing call
needed it. So that became an &optional parameter with a default of zero
(what everyone else wanted). Boom! Done.

  Speaking of which, is there a good IDE for Lisp with refactoring
> support? Emacs is great, right up to the point where you want to do some
> massive code reorganization or function/variable renaming, then I find it
> painful (go back to search/replace). I would think this would actually be
> pretty easy for a Lisp to do given the simple syntax.

Sounds like a good open source project for you. :) AllegroCL at least
searchs across collections of files and shows me where to look, but
that's about it. MCL has a "who calls" dialog, I used to use that a lot.

kenny 

-- 
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application

Relevant Pages

  • Re: The Next Move in Programming
    ... > compiler tell me all the places that are now broken. ... API changes in Java and C++ are usually overload and or name changes. ... > Java with Eclipse as my IDE, I'd just back out changes using the IDE and it ... is there a good IDE for Lisp with refactoring ...
    (comp.lang.lisp)
  • Re: Lisp in a Box
    ... I have been using Lisp for a long time, ... wanted to configure a compiler and IDE before I could use it. ... I also hate installers. ...
    (comp.lang.lisp)
  • Re: Java connected Lisp
    ... versions of GNU Classpath and SBCL, ... Invent a nice and fast interface for calls from Lisp to Java and back. ... The trick could be to hack the compiler so that it recognizes accesses ... Rewrite the "compiler" ...
    (comp.lang.lisp)
  • Re: Reflections on a classic Lisp Paper
    ... its Lisp-1 semantics than defmacro, but would not serve CL as well. ... fexprs into those languages. ... this was the Lisp Machine's philosphy that led to offering ... do changes that the compiler cannot know, ...
    (comp.lang.lisp)
  • Re: Which programming language is better to start
    ... How does Lisp handle monomorphic types? ... If you don't specify a variable to have a type then the compiler ... ML does a lot of pattern match optimisations which, ... These operation would be done by representing the data as lists ...
    (comp.programming)