One of the most interesting recent threads was the one about how people got started with Lisp. Here is another potentially interesting issue: how did your impress your clients, bosses or colleagues with Lisp applications, language features or tools? One of the reasons I ask is because I haven't impressed anybody--yet :)
Paolo Amoroso <amor...@mclink.it> writes: > One of the most interesting recent threads was the one about how people got > started with Lisp. Here is another potentially interesting issue: how did > your impress your clients, bosses or colleagues with Lisp applications, > language features or tools? One of the reasons I ask is because I haven't > impressed anybody--yet :)
Don't know if that counts. I took part on the "Linux World" far last year. The reactions of the people were. - Well I remember - What is Lisp - Does really anyone work with it yet.
Well the most astonished faces I can remember, was as we showed how one can patch a running application, second suprise was sometimes that one could do OO in Common Lisp...
Paolo Amoroso <amor...@mclink.it> writes: > how did your impress your clients, bosses or colleagues with > Lisp applications, language features or tools?
"network chip" (packet pipeline) simulator front-end w/ emacs (for pay), including configurable register windows, update via ipc, and single-step mode. an hour to do, an hour to demo, an hour for the (now dead, yay) startup to have its java programmer pour bignum hours into a feeble replacement. all but forgotten (except the GPL bits ;-).
GNUGO front-end w/ emacs (for you and everyone).
etc.
elisp may not get the respect it deserves, but that's another thread.
what impresses people changes -- perhaps some day people will be more impressed w/ the backwards (and slow) pace of software methodologies that people used to harbor. as in, "ugh, that doesn't look like fun".
Thien-Thi Nguyen <t...@glug.org> writes: > Paolo Amoroso <amor...@mclink.it> writes:
> > how did your impress your clients, bosses or colleagues with > > Lisp applications, language features or tools?
> "network chip" (packet pipeline) simulator front-end w/ emacs (for pay), > including configurable register windows, update via ipc, and single-step > mode. an hour to do, an hour to demo, an hour for the (now dead, yay) > startup to have its java programmer pour bignum hours into a feeble > replacement. all but forgotten (except the GPL bits ;-).
> GNUGO front-end w/ emacs (for you and everyone).
> etc.
> elisp may not get the respect it deserves, but that's another > thread.
Elisp with (require 'cl) has all my respect :)
cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
Friedrich Dominicus <fr...@q-software-solutions.com> wrote: > Well the most astonished faces I can remember, was as we showed how > one can patch a running application,
Redefining functions in Emacs counts as patching a running application, right ? -- Georges Ko (Taipei, Taiwan) 2002-05-02 g...@gko.net / ICQ: 8719684 Jeudi 2 mai 2002
Paolo Amoroso <amor...@mclink.it> wrote: > One of the most interesting recent threads was the one about how people got > started with Lisp. Here is another potentially interesting issue: how did > your impress your clients, bosses or colleagues with Lisp applications, > language features or tools? One of the reasons I ask is because I haven't > impressed anybody--yet :)
Are there any "elevator pitches" for lisp? I.e. statements, questions etc. you could use in an elevator to convince or at least get interested in the value of CL?
oh ... we're talking about working elevators here, so you have about 30 seconds ....
Running a multi-threaded web server in Lisp under emacs (AllegroServe, to be precise). Each incoming request is handled by its own thread; if an error happens, the thread can fall into the debugger where you can examine the entrails, change the code, compile the change, move down a few frames and continue the thread, without interrupting processing on other threads.
Java-based web servers claim to be able to do this inside their IDEs, but as of two years ago (last time I looked) they were lying. I suspect they are still lying even today if the code change involves changing object layout.
I've also done a bunch of work with Lisp in multi-language, peer-to-peer processing environments. Many times one of my coworkers would message me saying that "your piece of the system is reporting errors". I'd go over, look at the error logs, sometimes telnet to my running Lisp process and look at its internal state (another impressive thing that's trivial in Lisp, painful elsewhere), and nearly all the time I'd discover that another process was actually at fault - my stuff was getting the blame because it was REPORTING the error rather than crashing and restarting itself.
> Are there any "elevator pitches" for lisp? > I.e. statements, questions etc. you could use in an elevator > to convince or at least get interested in the value of CL?
> oh ... we're talking about working elevators here, so you have > about 30 seconds ....
I would start off with "Did you know that you can patch or upgrade your lisp application while it is actually still running on your clients machine?"
That is of course after "Yes, you can compile it." "No, there are other data types besides lists" and "Actually, lisp applications can perform well within the speed range of mainstream languages" etc...
* Paolo Amoroso <amor...@mclink.it> | One of the most interesting recent threads was the one about how people | got started with Lisp. Here is another potentially interesting issue: how | did your impress your clients, bosses or colleagues with Lisp | applications, language features or tools? One of the reasons I ask is | because I haven't impressed anybody--yet :)
The first thing I did that impressed a system admin and got him on my side "against" management was to write a small set of wrapper functions around the /etc/passwd database, which you can do in any language, and then write setf methods for them that did the real thing. While any sysadmin knows that changing a user ID involves a file system walk for files owned by the existing user ID and changing them one by one, this operation is not generally thought of as
(setf (user-id (find-user "username")) 666)
This operation is now abstracted away from the script-like solution and can now also be implemented in the kernel, or by modifying an unmounted file system, or something else. So, a unified approach to getting and setting all the fields of the password file was so attractive that he helped me get Common Lisp in the door. And that is just setf... -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Georges Ko <g...@gko.net> writes: > Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
> > Well the most astonished faces I can remember, was as we showed how > > one can patch a running application,
> Redefining functions in Emacs counts as patching a running > application, right ?
Absolutely. And the ability to do this feels a lot more impressive once you run into a bug in a part of Emacs written in C. Then your only choice is to completely rebuild Emacs from source. Yuck. (And sometimes impossible, if you don't have enough room in your user account).
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
In article <3229353106350...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> (setf (user-id (find-user "username")) 666)
> This operation is now abstracted away from the script-like solution
Of course this can also be easily done in Perl (using tied variables) or Dylan (using -setter functions), but with syntax the sysadmin would probably find more familiar.
Which would read the file into a MAKE-HASH in at the start, query values, as needed, update them, as neded, and then push out all the updates at the end at once?
The scheme would get rather "old" rather quick if you had to rewrite /etc/passwd each time you do a component of the SETF... -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://www.ntlug.org/~cbbrowne/spiritual.html Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
* Bruce Hoult | Of course this can also be easily done in Perl (using tied variables) or | Dylan (using -setter functions), but with syntax the sysadmin would | probably find more familiar.
Sure, but in which case you would not be able to sell anything new.
However, I wonder how you could miss the fact that we were trying to share actual stories of how we convinced people to use Common Lisp, not some hypothetical story of how the one Dylan fan in the universe could have done it. _Please_, do not reply. I do not really want to know. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
* Christopher Browne | Interesting. | | The one problem I'd see with this is that it would get awfully | inefficient if you try to do a more extensive update
Well, you seldom do this in the first place because it is so inefficient. Only in the very rare case would you ever want to change a user's uid. But that you could express the operation abstractly simply as a setf on the innocuous accessor, is sufficiently elegant that a competent sysadmin would see the sheer charm of it. I mean, the whole point of this thread is to share stories of how we convinced people that Common Lisp was good, right? I did just that. *sigh*
I am not sure what you think this does, but my example has find-user, which takes a user-name and returns all the data about a user in a user object, and user-id which is an accessor into the object. The fact that it has access to the old value and can do more intelligent things than just setting the slot in the user information was kind of the key here.
| The scheme would get rather "old" rather quick if you had to rewrite | /etc/passwd each time you do a component of the SETF...
That is a separate layer of abstraction entirely and is not even handled. The accessors into the user database are already sufficiently abstract in, e.g., Linux that editing /etc/passwd is deprecated and discouraged. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
In article <3229380240459...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> * Bruce Hoult > | Of course this can also be easily done in Perl (using tied variables) or > | Dylan (using -setter functions), but with syntax the sysadmin would > | probably find more familiar.
> Sure, but in which case you would not be able to sell anything new.
> However, I wonder how you could miss the fact that we were trying to > share actual stories of how we convinced people to use Common Lisp
I didn't miss it, and your story is valuable, but even more valuable would be stories that don't depend on ignorance on the part of the sysadmin but that rather show capabilities only Lisp has, rather than something convenient in Lisp but also convenient in the scripting languages already installed on the machine.
We used ICAD tool to generate 84 aircraft components -- solid representation and drawing -- in 15 minutes instead of 6 months. Similarly created bracket designs that also reduced the number of detail parts. Hundreds of wire part selections and connector terminations using ICAD (mostly ACL) and Oracle. These and other applications developed much more quickly in a Lisp-based tool (ICAD uses Allegro's flavors tech) than with C++ or even Java (although C was used to get to Oracle thru the back door), allowing companies to bridge the gap between software developers and mechanical engineers.
Paolo Amoroso wrote: > One of the most interesting recent threads was the one about how people got > started with Lisp. Here is another potentially interesting issue: how did > your impress your clients, bosses or colleagues with Lisp applications, > language features or tools? One of the reasons I ask is because I haven't > impressed anybody--yet :)
* Bruce Hoult | I didn't miss it, and your story is valuable, but even more valuable | would be stories that don't depend on ignorance on the part of the | sysadmin but that rather show capabilities only Lisp has, rather than | something convenient in Lisp but also convenient in the scripting | languages already installed on the machine.
Ignorance? Are you for real? (Well, I know you are not.)
The difference between a story of a solution and a blabbering idiot is that the solution has actually been demonstrated, whereas the blabbering idiot only talks about some hypothetical world in which he _could_ have done it, but has yet to do it. Anybody can take a prism and produce a color spectrum today, but Isaac Newton was the first to do it. I imagine you being the unimpressed idiot who said "I could do have done that" -- of course you could -- after the fact. The point is that nobody had done this, yet. But you probably do not understand this, considering that Dylan is reinvention incarnate.
If you would not have been convinced, fine. If you are not happy that someone else was convinced, fuck you. If you think you are my target audience for anything, you are not. If you continue to parade your ignorant destructiveness, you show the world who Dylan is for and why you post in comp.lang.lisp to get an audience. Get lost, whining loser. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Bob Bane <bb...@removeme.gst.com> wrote... > Running a multi-threaded web server in Lisp under emacs (AllegroServe, > to be precise). Each incoming request is handled by its own thread; if > an error happens, the thread can fall into the debugger where you can > examine the entrails, change the code, compile the change, move down a > few frames and continue the thread, without interrupting processing on > other threads.
Is AllegroServe the only one with this capability (or with the best implementation of it), or are there other Lisp web servers or server-OS combinations that can do this (or do this equally well)?
> > Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
> > > Well the most astonished faces I can remember, was as we showed how > > > one can patch a running application,
> > Redefining functions in Emacs counts as patching a running > > application, right ?
> Absolutely. And the ability to do this feels a lot more impressive > once you run into a bug in a part of Emacs written in C.
As Georges has pointed it out it sounds as if he does not find that impressing. Which probably shows what Lisp makes you think is all granted. Re-defining some stuff, what a deal...
Well I suggest he tries something like that in Java, C, C++ and how they are all called... It will work in Smalltalk, but again if you are used to it it makes you think all languages work that way..
In article <3229385759350...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> * Bruce Hoult > | I didn't miss it, and your story is valuable, but even more valuable > | would be stories that don't depend on ignorance on the part of the > | sysadmin but that rather show capabilities only Lisp has, rather than > | something convenient in Lisp but also convenient in the scripting > | languages already installed on the machine.
> Ignorance? Are you for real? (Well, I know you are not.)
Yes I'm for real. Ignorance is the precisely correct word. They almost most certainly have Perl installed, and probably use it. If they don't know how to use tied variables to implement transparent updates to things external to the program using a simple asignment statement then that is ignorance, pure and simple.
You can talk about Isaac Newton and prisms if you like, but this isn't some revelation, it's been standard practice in the Perl world for a number of years -- perhaps most obviously in the various database libraries. I've used it in my own code plenty of times.
I guess like many of the other stories here, mine depends on the ability to patch live images.
I've been writing this system which interfaces web pages running ASP which calls VB functionality (actually coded in C++ and linked into IIS via a DLL) which talks CORBA to our lisp server.
When we decided to make a change to the IDL, and just typed (load-server), redefined the new function, hit C-M-x. The guy at the other desk had to recompile the C++ world, and _stop_ IIS because there's no way to unlink/relink the DLL.
He agreed Lisp has certain advantages. :-)
[He's now a reasonably competent lisp programmer, btw]
This is not a direct reply to your question (I can't claim a great deal of CL machismo yet) but since I started programming I've had this sense that my motivation was to write cool software. This has always been a vague thought for me, so maybe this is a good time to ask myself, "Hey, what is it about cool software that's so cool?"
The care taken to create a complete and conscious design--that tops my list. When all design decisions are considered and choices are made based on careful thought, rather than rushed through and left to chance, that is something to stop and notice. Hacks are not cool because hacking implies no thought. Charlie Batch's work on Internationalization for Allegro CL is impressive. The emacs calandar code is cool. Olin Shivers' preamble to "The SRE regular-expression notation" about 100% and 80% solutions covers this idea well.
Customizable software is cool. But more fundamental is adaptablility. Being able to set the indent or the syntax highlight in emacs to whatever tickles you right is somewhat cool, but the fact that emacs' is designed so well that it has survived for 25 years, is available on such a wide range of systems, and can be adapted to whatever text editing use one can conceive--that deserves a big salute. The next level of cool is adaptable software that is adaptive, but right now I can't think of any examples of this.
Software that deals with a massive data set is cool. The scope of the search problem for Google and the effectiveness of their software is what makes Google cool--and the way they get all those pigeons to ... never mind.
Software with a massive data set and a massive number of users is double impressive. Hearing about ITA software and the time constraints on their problems in order to serve such a large network of the travel market impressed me. Hearing Philip Greenspun talk about how many gazillions of requests/sec his AOLServer was handling always seemed impressive. Machismo.
Culture around impressive software is a good side benefit of being impressive. For example Kent Pitman was telling some guy not to be superstitious the other day. I've been told by another CL programmer, "It's not voodoo!" when my approach to understanding a bug was wrong. A comment like that stings a bit, but when it is right on, it can be appreciated. That part of the CL culture is to think things through and do your homework before making decisions, judgements, or coming up with "explanatory" theories. So it's nice to see that the complete and conscious design principle is part of the CL culture.
Software that deals with nonlinear problems is cool.
Software that saves a lot of time is an easy win.
So what makes for impressive software? I've elaborated on some of the easy answers with some examples, but I'm sure there are more insightful criteria for what makes for cool software, and many more examples of systems that fit the bill.
The following articles have been motivating reads:
> The difference between a story of a solution and a blabbering idiot is
[SNIP]
> If you would not have been convinced, fine. If you are not happy that > someone else was convinced, fuck you. If you think you are my target > audience for anything, you are not. If you continue to parade your > ignorant destructiveness, you show the world who Dylan is for and why you > post in comp.lang.lisp to get an audience. Get lost, whining loser.
If you are not happy because someone is not suitably impressed by your *startling revelations*, then backatchya buddy. If the above paragraph is not evidence that you, Erik, are "ignorant destructiveness" personified, then I don't know what is. Finally, if *you* are the type of person who Common Lisp is for, then I intend to stop using it immediately.
> One of the most interesting recent threads was the one about how people got > started with Lisp. Here is another potentially interesting issue: how did > your impress your clients, bosses or colleagues with Lisp applications, > language features or tools? One of the reasons I ask is because I haven't > impressed anybody--yet :)
It is almost the same story - the things that impressed me about Lisp and made me want to learn it are the same things that I have slowly been able to impress my business partner with (though he has yet to learn it).
There hasn't been one thing (well, maybe the toplevel), but lots of individual things combined together and, at the same time, shedding lots of annoyances that exist in C/Java.
Defining method dispatch on value as well as type. We are tired of filling our code up with this crap: if (someObj != null){ someCount = someObj.getCount(); } else { someCount = 0; } instead of simply (getCount someObj) and let the method dispatch recognize that someObj is nil and retrieve 0 (or whatever) for us.
Multiple return values.
Incremental compilation.
Dynamic function creation ( with compilation!!)
A single multiple purpose collection type (the list) as opposed to different templates / classes for Vector, Stack, Set, Tree.
redefinition of classes while preserving the objects (just started using this - LOVE IT)
multiple inheritance AND garbage collection (the sometimes C++ vs. Java debate)
And, of course, the big one: the top level. instant testing, powerful debugging, experimentation, true "hacking". My business partner is threatening to build one in Java or C. I told him not to bother.
Anyway, I don't need to preach to this choir. My business partner, like me, is a programmer. When we took up Java years back it was with a big sigh of relief: "Aaah, this is so much nicer." Java has lots of problems, and, as power goes, can be rather limiting. But so many of the annoyances and obstacles in everyday programming that come with C/C++ are taken away. It's a vacation, but like a vaction, one doesn't get much done. Even my partner admits that had we known about Lisp three years ago we never would have bothered with Java. Lisp has that same sigh of relief, but it has teeth and muscle.
