In article <700aoa$il...@nclient1-gui.server.virgin.net>, J. Malcolm Lewis <j._malcolm.le...@virgin.net> wrote:
>I don't actually expect an answer to this, but I hope some one does answer.
Oh, you mean this is a troll. You won't be the first...
>What is the point in programming in LISP?
What is the point of programming in any language? To get a job done.
Or do you mean "why use Lisp when other languages are good enough, and more popular?" Sure, most programming languages are Turing-equivalent. Do you really want to program a Turing machine? I thought not.
And popularity is an awfully bad metric of language capability, unless of course your job is recruiting lowest common denominator programmers.
IMHO Common Lisp offers the ideal tradeoff between fine-grained control and abstract expressiveness. If you want to generate C-like code for maximum speed, you can. If you don't care about performance, and just want to do something quick and dirty, you can do that too. Need to create an application-specific language on top of Lisp? Piece of cake. You can let the garbage collector deal with memory, or you can explicitly manage it yourself. Common Lisp lets *you*, not the language designer, choose how hard you want to work.
And other languages *aren't* good enough. Not for the kinds of work I do. -- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please) chuck...@home.com (MIME enabled) Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
I haven't been using Lisp up until now. Now I have run across a problem where I either need to use a language that includes dynamic-binding of objects at run time or implement it on the fly. As far as I've been able to tell that effectively limits the competition to Lisp and Smalltalk. Lisp also has multiple-inheritence. I'ld enjoy hearing other options. (Yes, I did consider emulating dynamic-binding in a language that I already know. That's why I'm reading the Lisp groups.)
J. Malcolm Lewis wrote:
> I don't actually expect an answer to this, but I hope some one does answer.
> What is the point in programming in LISP?
-- Charles Hixson charleshix...@earthling.net (510) 464-7733 or chi...@mtc.dst.ca.us
Charles Hixson <charleshix...@earthling.net> writes: > I have run across a problem where I either need to use a language > that includes dynamic-binding of objects at run time or implement it > on the fly. As far as I've been able to tell that effectively > limits the competition to Lisp and Smalltalk. Lisp also has > multiple-inheritence.
By the way, Smalltalk also doesn't have "multimethods" (last I checked, anyway, which is a few years back). That is, operation messages are sent to one argument with all other arguments as data. In CL, you can write an operation on arguments of varying classes without being forced to create an asymmetry by saying that one argument is somehow more important than another.
There are other differences, too, of course.
The most striking is probably that Lisp, at least Common Lisp, doesn't really force a particular "style" of programming. CL gives you a flexible choice of style; I've seen people program in a functional style while others use an object-oriented style while still others use a FORTRAN-esque straight-line style. You can also substantially redefine the syntax of CL to accomodate other syntactic needs. The importance of this is that the mere purchase of the language doesn't bind you to a certain way of viewing and structuring your code.
Smalltalk, while a powerful and respected language, is traditionally regarded by many as more stylistically rigid.
> I'ld enjoy hearing other options.
Dylan is another. (See the Harlequin web page for details.) But its basic difference in character is that it has a more "conventional syntax" feel to it. It's not C/C++ compatible in syntax (which is probably just as well) but it is what is sometimes called a "conventional", infix, block-structured syntax. And although it offers a lot more dynamic flexibility than most static languages, when compared to Lisp, Dylan is a lot more "static". (Whether that's good or bad isn't possible to say in absolute terms; it depends on the needs of your application.)
In article <36280f7c.85789...@news.newsguy.com>, trashcan@david- steuber.com (David Steuber "The Interloper") says...
> What is the point of trolling in this news group?
The same as trolling in any ng. What is the point of a troll that isn't crossposted? It could just a be a good way of provoking us into posting something interest, in which case Kent Pitman's contribution to this thread is perfect.
FWIW, I use Lisp because so I can write code that writes code that writes code without my hair turning grey. It's easier to do this in Lisp than in Forth, which makes it easier than in most other languages.
Lisp also helps me find the ideal way to represent solutions to problems, while most languages merely help find good ways to represent data. Once upon a time, programmers were advised to write "pseudo code" and then turn it into "real code". In Lisp, it's easy to get a computer to run the _pseudo code_.
So, I began by learning to write code (in Basic and assembly language). I then learned to write code that writes code. The final step, while learning Forth, was to realise that the code that writes code is also code. At this point, the mind boggles a bit, but you get used to it and eventually begin doing useful things with it.
A few programmers may have accidently done something close, by writing CGI code that writes JavaScript that writes HTML. It becomes rather more interesting when all three stages are running in the same process, as with Lisp, Forth, Prolog, and perhaps a few other languages. Then the "leaverage" you get is only limited by your ability to imagine neat ways of representing code. Techniques like OOP, FP and LP are just some of the possibilities, but definitely _not_ the limits.
As the ad copy for Hellraiser put it, "There are no limits." -- Remove insect from address to email me | You can never browse enough will write code that writes code that writes code for food
On Wed, 14 Oct 1998 16:07:05 +0100, m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) claimed or asked:
% FWIW, I use Lisp because so I can write code that writes code that writes % code without my hair turning grey. It's easier to do this in Lisp than in % Forth, which makes it easier than in most other languages.
I am looking at lisp for a much more mundane reason. I want to write a complex program that is probably beyond my reach. Lisp seems to be the language that could reduce the size of the code to something that is within my reach, maybe.
For me, it boils down to reducing the amount of effort I need to produce a certain amount of work. If lisp fits the bill, I may never go back to C style languages again for real programs.
In article <3627499c.166206...@news.newsguy.com>, trashcan@david- steuber.com (David Steuber "The Interloper") says...
> % FWIW, I use Lisp because so I can write code that writes code that writes > % code without my hair turning grey. It's easier to do this in Lisp than in > % Forth, which makes it easier than in most other languages.
> I am looking at lisp for a much more mundane reason. I want to write > a complex program that is probably beyond my reach. Lisp seems to be > the language that could reduce the size of the code to something that > is within my reach, maybe.
That's exactly what I mean. Take a good look at how macro functions are used in Lisp, esp in Common Lisp. The backquote syntax helps a lot.
Many programmers will have stumbled on something close, like the web example I gave in my earlier post. I was stumbling in that direction while I was still using Basic, and that lead me to Forth. Then I found Lisp. Finally I could see what I was doing.
Let the machine write the tedious code for you. Then all you have to do is write the interesting code. Paul Graham's book, On Lisp, has some excellent examples. All of them should be within your reach.
> For me, it boils down to reducing the amount of effort I need to > produce a certain amount of work. If lisp fits the bill, I may never > go back to C style languages again for real programs.
I've noticed that the effort mainly involves two kinds of code. (Yes, it's another binary view!) One kind of code does things that you've not done before, and perhaps don't (yet) know how to do. The other kind is all too familiar but there's loads of it, making it tedious and painful to write. Perhaps even error prone. Boredom is warning sign. If the code is boring, you're probably doing something wrong.
So, any tool that removes and/or hides redudant details can help you write better code. It'll keep you alert. Repetitive (copy&paste) coding can put you to sleep, which is not good for a programmer.
BTW, my sigfile refers to an example of "repetitive TV presenting". Good pay, early hours, easy mistakes. Yet some programmers code like that... -- Remove insect from address to email me | You can never browse enough "Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins
>I don't actually expect an answer to this, but I hope some one does answer.
>What is the point in programming in LISP?
Hmmmm. The answer from a non-guru. The request that come into our Hospital Information System are the type that we have no expertize in and really no time to work on. None the less must get done. Enter lisp...the expert (requestor for help) and I can set down and write the story of what needs to be done (psuedo-code?). If I do my job well, this is the top-level function. For example: There "a" (as in one) realtionship of 12 linear and 4 angular measurements of a face that not matter what the ethnictist of the the face are condsider pleasing. Now here are these 12 measurements from a patient, does this face meet the aesthic standard...if not why not. I am sure this could be done in any language....the point is I, as really an non-programmer by this groups standards, did it with the help of Dr Epker in about 6 hours in lisp. Dr Epker (a non-computer person at all) understood what was going on, why it was going on, and what the pits falls might be. because you get to write the dang thing in english (using last for crd first for car etc).
Lisp lets even a hack (in its worst connotation) like me get the job done qucikly and correctly. (now i am trying to do it lisp-like but that is another story)
In article <MPG.108ece2bff0f07e5989...@news.demon.co.uk>, m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
|> So, I began by learning to write code (in Basic and assembly language). I |> then learned to write code that writes code. The final step, while |> learning Forth, was to realise that the code that writes code is also |> code. At this point, the mind boggles a bit, but you get used to it and |> eventually begin doing useful things with it.
I think that one route to successful automated problem solving (or AI or automated reasoning or whatever you want to call it) will be by pushing this method (hierarchical automated code generation) a bit farther. The folks who pay me prefer I not spend my time chasing this idea, and I am not adequately informed about how far the techique has advanced. Can anyone give me some pointers (not basic AI texts, which I have) to papers, web sites, etc on this? Thanks.
u...@machine.domain wrote: > In article <MPG.108ece2bff0f07e5989...@news.demon.co.uk>, m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
> |> So, I began by learning to write code (in Basic and assembly language). I > |> then learned to write code that writes code. The final step, while > |> learning Forth, was to realise that the code that writes code is also > |> code. At this point, the mind boggles a bit, but you get used to it and > |> eventually begin doing useful things with it.
> I think that one route to successful automated problem solving (or AI or > automated reasoning or whatever you want to call it) will be by pushing > this method (hierarchical automated code generation) a bit farther. The > folks who pay me prefer I not spend my time chasing this idea, and I > am not adequately informed about how far the techique has advanced. > Can anyone give me some pointers (not basic AI texts, which I have) > to papers, web sites, etc on this? Thanks.
On 19 Oct 1998 13:07:42 GMT, kra...@cme.nist.gov (Tom Kramer) claimed or asked:
% I think that one route to successful automated problem solving (or AI or % automated reasoning or whatever you want to call it) will be by pushing % this method (hierarchical automated code generation) a bit farther. The % folks who pay me prefer I not spend my time chasing this idea, and I % am not adequately informed about how far the techique has advanced. % Can anyone give me some pointers (not basic AI texts, which I have) % to papers, web sites, etc on this? Thanks.
I have heard of a concept called "genetic algorithms". As far as I can tell, they've only been applied to really small bits of machine level code. Wouldn't it be interesting if one could write a program, perhaps in Lisp, and pass it as the input to another program that would use this idea to find a better way of implementing the input program? It would also have to be able to work on itself of course :-)
I've also heard that genetic algorithms take a long time to run in even the simplest cases. Perhaps scaling up to something as complex as a series of Lisp forms would be computationally infeasible for a while or longer.
>>>>> "DS" == David Steuber "The Interloper" <trash...@david-steuber.com> writes:
DS> I have heard of a concept called "genetic algorithms". As far DS> as I can tell, they've only been applied to really small bits DS> of machine level code. Wouldn't it be interesting if one DS> could write a program, perhaps in Lisp, and pass it as the DS> input to another program that would use this idea to find a DS> better way of implementing the input program? It would also DS> have to be able to work on itself of course :-)
What genetic programming might do is help generate Lisp functions to solve a given input->output mapping. Interaction with a genetic programming system would work along these lines:
(genetic-prog '((1 . 2) (-2 . 4) (3 . 9)))
=> (LAMBDA (X) (* X X))
John Koza's seminal work on this area was done using Lisp (naturally). I recommend taking a look at the very readable Lisp code taken from his book[1], at:
The file is koza-book-gp-implementation.lisp. See also litlflet.lsp taken from [2] which demonstrates a form of genetic programming that is capable of generating modular code, instead of one monolithic function.
See comp.ai.genetic for stimulating discussions on genetically inspired methods of computation.
Good luck, Ikram
[1] Koza, John R. 1992. Genetic Programming: On the Programming of Computers by Means of Natural Selection. Cambridge, MA: The MIT Press.
[2] Koza, John R. 1994. Genetic Programming II: Automatic Discovery of Reusable Programs. Cambridge, MA: The MIT Press
