> With due respect for your enthusiasm, I don't think that a few weeks worth > of thinking can bring any significant innovation. The tough part is not to > understand why a new feature may be useful, but to realize why it may not > be a good idea.
This might be a little bit off-topic, but what is the current state of the ANSI standard (AFAIK they are reviewed all five years) ? Are there any activities to add new features or cleaning up ambiguous items ?
Charlton Wilbur <cwil...@mithril.chromatico.net> wrote in message <news:87znva1cg6.fsf@mithril.chromatico.net>... > And even then, designing a new language does not necessarily mean > rejecting all that has gone before. Did Bertrand Meyer discard what > he had learned from other languages when he designed Eiffel? Did > Bjarne Stroustrup discard what he had learned from other languages > when he started down the path that led to C++? Did Kernighan, > Ritchie, and Thompson discard what they had learned when they created > C? Of course not.
Actually I dare say that the answer is yes on all counts. And I would add the remark that the world would have been better off without these, with the possible exception of Eiffel.
These designers, deliberately or not, discarded lots of useful ideas for which efficient compilation is difficult to implement. Multiple dispatch, garbage collection, dynamic typing.
Stroustrup declined nearly every opportunity to improve on weak areas of C, in the name of preserving backward compatibility. Actually, many things can be fixed in an entirely backward compatible way, for example allowing arrays to be assigned and returned from functions, or allowing the . and -> operators to be interchangeable. Stroustrup could have specified that C++ evaluation takes place left to right, thereby eliminating those stupid sequence points that only serve as programming pitfalls. That would have been completely backward-compatible as well. He introduced a completely useless keyword, ``class'' which behaves only slightly differently from ``struct'', yet he did not fix the stupid overloading of the meaning of ``static'', which could have been done by a new keyword. For example the ``private'' and ``public'' keywords introduced for writing access specifiers could be used at file scope to determine the linkage of an external declaration.
> All of them saw deficiencies in the existing > languages, and created a new language with what they considered > strengths and with as few weaknesses as possible.
That's not the case with C; C started out as a deliberately dumbed-down imitation of BCPL called B that could fit onto a machine with 8 kilowords of memory. C was designed to to do job, not to be a showcase of language design. That job was maintaining an operating system and related tools in a reasonably portable and maintainable expression.
In a paper called _The Development of the C Language_, Ritchie admits that he did not fix the precedence of the & and | operators when && and || were added because a whopping 600 kilobytes of C code already existed.
> It's not weird at all. In C (and many similar languages), there are > a lot of different "syntax embellishments" to actually help reading. > LISP uses only parentheses. This makes it very easy to parse by a > computer, but not by (mant? most?) humans.
Well, the argument is that in Lisp, eventually you don't `see' the parentheses --- the mind filters them out as irrelevant to understanding what's going on. Then you just start reading code in a literal sense. The syntax embellishments aren't necessary.
-- Fred Gilham gil...@csl.sri.com If there is one consistent theme to be found in the great works of the 20th century, it seems to me to be the presentation of a doomed quest: the search to find something capable of filling that great void that has been left in the soul of man by the repudiation of God. --- Skylar Hamilton Burris
Andreas Hinze <a...@smi.de> writes: > Paolo Amoroso wrote:
> This might be a little bit off-topic, but what is the current state of > the ANSI standard (AFAIK they are reviewed all five years) ? Are there > any activities to add new features or cleaning up ambiguous items ?
According to the annual report for year 2000 from the committee [1], there has been no active projects and generally the committee has been falling apart.
Here are some interesting quotes from the aforementioned web-site:
"Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals may have fallen as low as three."
"J13 continues with no active projects. There was one meeting during 2000, conducted by electronic online chat."
"Despite the best of intentions and genuine interest in standardizing areas of current development, no project proposals have been generated. The Chair does not foresee any to be immediately forthcoming."
-- Richard Krushelnitskiy "I know not with what weapons World War III will rkrush (at) gmx.net be fought, but World War IV will be fought with http://rkrush.cjb.net sticks and stones." -- Albert Einstein
Hi all, i changed the topic because i found that this now goes far away from the original thread. I'm not very experienced with Lisp history and when to introduce new stuff but i'm still wondering about that:
> According to the annual report for year 2000 from the committee [1], > there has been no active projects and generally the committee has been > falling apart.
> Here are some interesting quotes from the aforementioned web-site:
> "Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals > may have fallen as low as three."
> "J13 continues with no active projects. There was one meeting during > 2000, conducted by electronic online chat."
Why aren't there active projects ? At least multithreading and foreign function support are concepts that would be nice to have in the standard. And i think there are a lot of other topics too.
> "Despite the best of intentions and genuine interest in standardizing > areas of current development, no project proposals have been > generated. The Chair does not foresee any to be immediately > forthcoming."
Is this process that complicated ? If i look at CLOCCs port library i find the first "proposal". AFAIK the only purpose of this library is to "hide" differences in implementations that are not covered by the standard.
I'm _not_ talking about bigger libraries. Erik Naggum made some good comments about that some time ago. What i mean is that it is less usefull to have a set of features in almost every lisp implementation when every implementation does it in their own way (i.e. FFI).
> Hi all, > i changed the topic because i found that this now goes far away from the > original thread. I'm not very experienced with Lisp history and when to > introduce new stuff but i'm still wondering about that:
> Richard Krush wrote:
> > According to the annual report for year 2000 from the committee [1], > > there has been no active projects and generally the committee has been > > falling apart.
> > Here are some interesting quotes from the aforementioned web-site:
> > "Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals > > may have fallen as low as three."
> > "J13 continues with no active projects. There was one meeting during > > 2000, conducted by electronic online chat."
> Why aren't there active projects ? At least multithreading and foreign > function support are concepts that would be nice to have in the standard. > And i think there are a lot of other topics too.
Speaking personally as someone who would have been first in line if he thought this was a productive tack to take, but not in any official representative of anything, the answer is simply this:
I personaly think ANSI is a large, too-slow, not-very-useful entity to be accomodating all but the most low-level basic standards. It was probably appropriate to standardize CL itself this way, but even then it's quite clear that the long time-line caused by ANSI resulted in some companies going bankrupt in the meanwhile. Was ANSI the cause? Probably not. But did producing an ANSI standard cost a serious lot of money on the part of all Lisp vendors? Yes.
Further, there is no evidence that the support already present in the existing vendors is an impediment to anyone. The amount of work required to hook yourself into the multithreading component of most vendors is quite small, and even to port to a different system is often quite small. There is a bigger difference on the foreign function call thing, but even then, it should be possible in most cases to keep that work to a relative minimum.
Users love to point to things like this because they want everything on a silver platter if they can get it, but the cost of getting this silver platter is high enough that the rough edges present will buy you more in terms of other things vendors could provide.
In sum, if vendors perceived that users were failing to buy Lisp merely because of lack of a standard system of the kind you're talking, then vendors themselves would rush to advertise these facilities.
If users perceived that the differences were annoying enough, they would get together themselves and make an informal standard and insist that vendors adhere, but no such movement has occurred.
The fact that there is no motion on either of these leads me to believe that users just find this easy to grumble about because it's visible and "seems" easy.
There is a hidden assumption in all of this that ANSI is the only kind of standard, and that things are only worthy "community achievements" if they are standards. I think these are bad assumptions. There are more streamlined ways to make standards, and there are not-formally-standardized-things that are nevertheless fine good community achievements and resources. Often, standards bodies want you to believe otherwise because, after all, they are in the commercial business of selling you their stamp of approval. But think of college degrees: they're nice for those of have them, but their absence is not proof that the person does not know what they're doing.
> > "Despite the best of intentions and genuine interest in standardizing > > areas of current development, no project proposals have been > > generated. The Chair does not foresee any to be immediately > > forthcoming." > Is this process that complicated ?
EXPENSIVE.
> If i look at CLOCCs port library i find the first "proposal". AFAIK > the only purpose of this library is to "hide" differences in > implementations that are not covered by the standard.
You can't just open the process of change to only a set of known outcomes. You mostly can just either open to editorial correction to arbitrary change or nothing.
> I'm _not_ talking about bigger libraries. Erik Naggum made some good > comments about that some time ago. What i mean is that it is less > usefull to have a set of features in almost every lisp > implementation when every implementation does it in their own way > (i.e. FFI).
If you are a customer of the implementation that isn't meeting your needs, complain to that vendor. If you are a customer, why isn't "I need this" a stronger argument than "the standard requires this" (which personally to me sounds like make-work). If you're not a customer, why do you care (other than, again, make-work) whether some vendor you don't use carries it? Yes, it might win the occasional debate point to say CL had these features, but all useful CL's have these features and you should just assert that fact anyway in a debate.
My bottom line points: * I allege that these issues do not stand in the way of anyone deploying a successful commercial product. * I further allege that money which you want to go to these things could better be used addressing vendor-specific issues that do stand in the way of successful commercial products.
> I can build rocket ships in my native tongue (C). Translating my rocket > ship into Lisp results in a broken machine. I am missing doors, windows, > glass, steering controls, landing gear, wings, and fuel. I have a > complete toolbox in C. In Lisp, I just have a screwdriver.
Sigh... This subject comes so often here that we could think that there exists people that know how to post to comp.lang.lisp but not how to use google.
(with-quote Item # 3021 - C Tool Belt Suggested Price $9.95 Our Price $6.50
A true classic, our C Tool Belt comes with all the tools you'll need for fashioning quality software. Comfortable, natural material can be draped around hips. Basic instruction manual includes directions for making a buckle. Rock is made of genuine granite, the same material used in many of the finest buildings in the world. Pointy stick has built-in hardwood handle and may be used by left-handed or right-handed people with equal ease.
Features: all hide construction pocket for spare rock holster for pointy stick
Spare rock sold separately. Not for sale to residents of Massachusetts, California, or any other state with restrictions upon ownership of rocks and/or pointy sticks.
Item # 5274 - Common Lisp Tool Belt Suggested Price $40,000. Our Price $10,000.
Our Common Lisp tool belt is designed with the tinkerer in mind. The three-axis Bridgeport Series I Standard Mill (included) is located on the hip pocket for easy access, while the high-speed Intaglio Printer is tucked away in the back for more convenient carrying. Detachable GPS may be worn on wrist.
Features: dual cutting heads -- water jet and plasma Computer Numerical Control interface CRC Handbook, OED, PDR, and DSM IV included in documentation
Item # 38661 - C++ Tool Belt Suggested Price $100.00 Our Price $69.95
Make a fashion statement with our modern C++ Tool Belt. Features genuine synthetic rock and over 3,000 custom made pointy sticks so you'll always have exactly the right tool for the job. Belt comes with heavy duty buckles, zippers, velcro, buttons, hook and eye fasteners, snaps, frogs (both the fastener and the amphibian), clasps, sequins, lace trim, and mounting points for clip-on suspenders. Expansion kits of pointy sticks available.
Features: trendy colors pocket for spare rock holster for pointy stick
Note: Synthetic rock should not be used in situations where it may come into contact with other objects such as the pointy stick. Synthetic rock composed of man-made materials, repeated use may cause skin irritation or death.) ;*** note the parent nicely closing the with-quote form ***
If you try goole with "group:comp.lang.lisp lisp better" you find 14500 messages. The first 3 of these threads are :
Re: *Why* is LISP better? comp.lang.lisp - 05 Aug 2002, posté par Erik Naggum - Afficher l' arborescence (97 articles)
Re: How is Lisp "better"? comp.lang.lisp.x - 28 Jul 1998, posté par Blake McBride - Afficher l' arborescence (21 articles)
Re: Lisp better than C? comp.lang.lisp - 25 Dec 1991, posté par U20...@uicvm.uic.edu - Afficher l' arborescence (17 articles)
As you can see the last one is rather recent. So read before always asking the same question.
I suggest that we make a few biased demos of lisp features for this kind of question and then ask people to do the same in C[#,++], J[#,++,ava], [J]Python, etc.
> Hi all, > i changed the topic because i found that this now goes far away from the > original thread. I'm not very experienced with Lisp history and when to > introduce new stuff but i'm still wondering about that:
> Richard Krush wrote:
>> According to the annual report for year 2000 from the committee [1], >> there has been no active projects and generally the committee has been >> falling apart.
>> Here are some interesting quotes from the aforementioned web-site:
>> "Membership was stable at eleven in 1999 and 2000, but 2001 paid renewals >> may have fallen as low as three."
>> "J13 continues with no active projects. There was one meeting during >> 2000, conducted by electronic online chat." > Why aren't there active projects ? At least multithreading and > foreign function support are concepts that would be nice to have in > the standard. And i think there are a lot of other topics too.
"Nice to have" does not mean that it's likely to actually happen.
>> "Despite the best of intentions and genuine interest in >> standardizing areas of current development, no project proposals >> have been generated. The Chair does not foresee any to be >> immediately forthcoming." > Is this process that complicated ? If i look at CLOCCs port library > i find the first "proposal". AFAIK the only purpose of this library > is to "hide" differences in implementations that are not covered by > the standard. > I'm _not_ talking about bigger libraries. Erik Naggum made some good > comments about that some time ago. What i mean is that it is less > usefull to have a set of features in almost every lisp > implementation when every implementation does it in their own way > (i.e. FFI).
For there to be a standards meeting costs a pile of people a pile of money, because they have to see about getting together in one spot. In order for the committee to start a meeting and then say "meeting adjourned" more than likely costs $100K, and that's a meeting in which NOTHING actually gets accomplished.
It is _vastly_ more likely that you'd find better value in working on the "UFFI" project, more than likely by building/improving the binding to one CL implementation or another. If you spent $100K on that, you'd probably be able to get some meaningful improvements and make it work with a goodly number of CL implementations. -- (concatenate 'string "cbbrowne" "@acm.org") http://www3.sympatico.ca/cbbrowne/rdbms.html Zaphod's just zis guy, you know?
>> if people don't care I have little reason to implement it...
> You have to do some `supply-side' thinking --- `build it and they will > come'. Of course, you are taking the risk that you will build it and > they'll stay away in droves. But if you win, you win really big.
maybe.
> If you decided to revive the T implementation, personally I'd > definitely comment on it, and one part of my comment would be `thank > you very much'.
t was pretty cool, and also a few details of my current scheme vm were borrowed from t. now that I think of it though still substantial work is needed on the vm, and maybe I should work more on making persistence work...
I could look into implementing t, and consider how much work it would be for my current vm. allready many of the internals of my vm have been being altered, however most of the changes were intended to make it more general...
I was considering making a kind of "glue" interface to allow persistent stuff to reference stuff generated at runtime, this would likely solve a few problems of mine.
> But I found your language design really frustrating. You seemed to > want to combine some aspects of Python, Scheme and Common Lisp. It > didn't seem at all promising to me and I thought silence would be the > most charitable response.
I had thought the mishmash aspect was a good point, oh well... or was it the features from the various languages I had chosen?...
> You should realize that good self-image comes from accomplishment. If > you do something good, you WILL become world famous. I kid you not. > That's just the way the Internet is. You will get messages from all > over the world either praising you or asking for free upgrades. :-)
yes, but accomplishment is the hard part. at present my most promising project is my os, even though development has been slow recently.
my language would have been a branch of my vm, which is a branch of my os. my vm is still cruddy, as an os involves plenty of other work as well...
> So you've got a lot of time on you hands: pick a project and see it > through. Then put it out there. Repeat until satisfied.
maybe can do...
the simplest approach for me right now would be to continue using scheme but probably add what stuff I was thinking on top. the alternate syntax could be a different reader, though selecting which reader to use might be difficult or kludgy. one idea is to select via a command line option, or the file suffix. another option could be to have reader and language configuration stuff embeded in comments, though possibly this would be annoying...
I've been thinking recently that Mike McDonald deserves kudos, and perhaps apotheosis, for his work on Free CLIM (aka McCLIM). I know it's not finished yet, but IMHO it is usable by the adventurous.
(This is not to minimize the contributions of others who worked on Free CLIM. The whole thing is amazing to me.)
I recently had occasion to want to experiment with the graph stuff in CLIM. I noticed that it wasn't in the Free CLIM I'd checked out, so I did a CVS update, and lo and behold, there it was, about 90% functional too! :-)
-- Fred Gilham gil...@csl.sri.com When an economist criticizes any human institution because it has failed to convey to mankind an incommunicable attribute of God, we can safely dismiss that economist. The trouble is, there remains a market for these economists in academia. I regard this fact as one more piece of evidence for the failure of tax-subsidized education. -- Gary North
> Hi, > I don't want to start a religious war. I am on my travels through > learning computing, and wanting to explore the universe of Computer > Science. This is just my opinions of Lisp so far.
> I have learned the very basics of Lisp. It is in my opinion a weird > language. It uses strange named operators (car...) and lots of (() ). > I am left witha very superficial look at what appears to be a retro > language, a throwback to a time when computers were the size of > buildings. It is hard to think in Lisp or what I can use it for.
> I can not imagine why I should keep trying to program in this language when I have > better, easier modern languages with a cleaner syntax and operators with > names that make sense to me. SO far everything I understand I can do in > Lisp I can just as well do in another language I know. I know not the > ways of Lisp or what it is about that has enabled it survive this long.
> So far the only thing I have learned to do with Lisp is make a stack > using a very strange syntax. I could easily code this same problem in > Python or C or Java much faster and easier to read (to me).
> What oh what makes Lisp or Scheme useful? Are they just hacker languages > that a hacker must know to be accepted by the hacker community? Or is > there really something about Lisp (or Scheme) that makes them stand apart > from the easier (IMO) to understand languages like Python, Java or C/C++?
> How has Lisp survived through the years? I have come across many many > computer languages in my studies, and the majority of them died before > they were even conceived. Yet Lisp, Fortran, and C survived. I know C and > Fortran. They are not too hard to understand. But Lisp is IMO very hard to > understand (first, everything is literally backwards in it...).
> I would like to learn how to program in Lisp, so I can appreciate > something of the history of Computer Science. I am also interested > in understanding Lisp, because I have read that it teaches you to think > about problems recursively. But I am still struggling to figure out how > to write an interesting program in the language.
> If you can explain to a neophyte Computer Scientist why learning to code > in Lisp will enlighten me and will be worth the pain of getting > acquainted with it, I'd like to know!
> Also are there any free e-books on programming in Lisp or Scheme? > Are there any places I can get Lisp (or Scheme) code so I can look at to > learn how to think in these languages?
> I am still interested in the way of Lisp and Scheme so I am not closed to > learning about it. But my only experience with it is a funny taste. It is > completely opposite of how I think and I can not think at all in this > language. I just stare at the clisp prompt wondering what I should do > next. I can write simple programs that process a list, but it is a toy. > There must be more to it than just making toys.
>> It's not weird at all. In C (and many similar languages), there are a >> lot of different "syntax embellishments" to actually help reading. LISP >> uses only parentheses. This makes it very easy to parse by a computer, >> but not by (mant? most?) humans.
> Well, the argument is that in Lisp, eventually you don't `see' the > parentheses --- the mind filters them out as irrelevant to understanding > what's going on. Then you just start reading code in a literal sense. > The syntax embellishments aren't necessary.
Yes, you can rely upon an editor's automatic indenting to let you see whether parentheses are out of place without needing to explicitly count them.
Furthermore the spare characters like [ ] { } come in really handy when implementing reader macros.
> In article <umi9336kgck...@corp.supernews.com>, cr88192 wrote: > > Kaz Kylheku wrote: > >> Nobody cares about the braindamaged spec for your nonexistent language, so > >> stop > >> bringing it up, you lunatic. It's not topical here. Maybe try the > >> patience of comp.compilers for a change.
> > hell, at least this is some feedback. > > if others feel similar I guess it explains the lack of reply.
> > if I write a compiler will this topic be more acceptable?...
> Not in this forum unless it is a compiler for the language ANSI Common Lisp.
Since when? As far as I'm aware, it's for any kind of Lisp except Scheme, which has its own group, and maybe Emacs Lisp and AutoLisp for the same reason.
I've posted stuff on MacLisp here not so long ago. Sosumi. And if Paul Graham or anyone else wants to post Arc stuff here for general discussion, he's welcome to, at least until Arc gets its own group.
Le Hibou -- Dalinian: Lisp. Java. Which one sounds sexier? RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
Erik Naggum wrote: > So far, the willingness to listen does not even extend to Paul Graham's Arc. > Novices with a desire to reinvent the world before they know what it is like > should take notice of this. Improving on Common Lisp is /very/ hard. And > most of the "improvements" on Scheme are neither improvements nor Scheme.
Agreed. Common Lisp is the best language we have.
It even bothers me that people are busy inventing new languages which are clearly inferior to existing ones in all important aspects.
This is not to say that people shouldn't try, but that they should bear in mind that if they cannot claim their language is better than Common Lisp (or at least a useful subset of it) in at least one important way, maybe they should keep it to themselves. It isn't needed, and there are too many languages already.
And language designers should be able to program in numerous quite different languages, and should maybe cut their teeth by designing a few special purpose languages, as I have done.
This doesn't prevent people inventing languages which aren't as good as Lisp -- False was worth inventing, to show what could still be done even if you limit your compiler size to one kilobyte, for example.
> Erik Naggum, Oslo, Norway
Le Hibou -- Dalinian: Lisp. Java. Which one sounds sexier? RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
> In article <pan.2002.08.25.07.02.46.793119.14...@charter.net>, Mr. Neutron > wrote: > > language. I just stare at the clisp prompt wondering what I should do > > next. I can write simple programs that process a list, but it is a toy. > > There must be more to it than just making toys.
> This is your personal problem that has nothing to do with any programming > language. If you can't think of what to do, it can only be because you have > reached your wit's end.
> You should go back to one of those programming languages that you cited; these > will give you enough impedance so that you can push against them and dissipate > your energy to create the feeling that you are accomplishing something.
> C is great for this; you can start with no idea at all, and starting writing > thousands of lines of supporting code in hopes that the idea will materialize > in the meanwhile.
> ``Gee, I don't know what I will write, but I bet it will need a linked list, a > better malloc routine, some binary trees and reference-counted strings, > a buffer management module, ...''
BTDT. Implemented in C (for my last employer) a library containing heap management, (singly, as God intended) linked lists, side-effect free functions for C's ASCIZ strings, hash tables and a better interface to Regex.h
This saved me lots of effort.
Greenspun's tenth rule in action, but at least, having implemented Lisp several times previously, I knew how to do it properly.
Le Hibou -- Dalinian: Lisp. Java. Which one sounds sexier? RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
"Mr. Neutron" wrote: > I would like to learn how to program in Lisp, so I can appreciate > something of the history of Computer Science. I am also interested > in understanding Lisp, because I have read that it teaches you to think > about problems recursively. But I am still struggling to figure out how > to write an interesting program in the language.
I was for many months trying to think of an interesting program to write in Fortran, because number crunching didn't interest me. Then I discovered Artificial Intelligence. I was soon pointed in the direction of Lisp and never looked back.
Almost all programs written nowadays could just as well be written in COBOL, Fortran, or something similar. Most programming problems are deadly dull, and you don't need Lisp for these. AI is a different matter -- nothing suffices except Lisp or Prolog. So look for a problem that you cannot solve easily in your favourite languages and try Lisp on it.
> If you can explain to a neophyte Computer Scientist why learning to code > in Lisp will enlighten me and will be worth the pain of getting > acquainted with it, I'd like to know!
> Also are there any free e-books on programming in Lisp or Scheme? > Are there any places I can get Lisp (or Scheme) code so I can look at to > learn how to think in these languages?
Paul Graham's On Lisp, and if you want Scheme there's SICP.
> I am still interested in the way of Lisp and Scheme so I am not closed to > learning about it. But my only experience with it is a funny taste. It is > completely opposite of how I think and I can not think at all in this > language. I just stare at the clisp prompt wondering what I should do > next. I can write simple programs that process a list, but it is a toy. > There must be more to it than just making toys.
This is because you're having to think up (Lisp is higher level than C or Java). I had the same problem with Prolog, which is higher level than Lisp, but I persevered, and after heavy use grokked it.
> Thanks
Le Hibou -- Dalinian: Lisp. Java. Which one sounds sexier? RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
In article <pan.2002.08.25.18.02.50.608289.14...@charter.net>, Mr. Neutron wrote:
> glass, steering controls, landing gear, wings, and fuel. I have a > complete toolbox in C. In Lisp, I just have a screwdriver.
What toolbox would that be? The one with strcat and strcpy? Or the one with malloc and free? sort and bsearch? setjmp and longjmp?
Are you aware that Lisp has an object oriented programming system, dynamic typing, complex numbers, bignum integers, rational numbers, packages, structural macros, lexical closures, restartable conditions, a sequence processing library, strings, symbols, vectors, multidimensional arrays, structs, packages, sophisticated stream I/O, built-in parser and evaluator, ...
Get real.
> That is my frustration with Lisp so far. I can build rockets. But in Lisp > I am starting all over again. It is sort of intimidating. I am actually > kind of interested in the challenge. But I need a guide to teach me. > I just can't find a guide. It would be nice if there was a Lisp for C > programmers book around.
> That's why I am griping. It's not that I think Lisp sucks. It is that I > can not communicate in it at all. I am a stranger in a strange land in > Lisp.
In article <cf333042.0208260739.379a2...@posting.google.com>, Kaz Kylheku wrote:
> things can be fixed in an entirely backward compatible way, for > example > allowing arrays to be assigned and returned from functions, or > allowing
Ewww. That's what you get for trying out Google news posting. The preview looks normal, then the lines break when you actually post.
>>Why do people coming to lisp complain about all the parenthesis? >>Take c code, change { } to parenthesis and move the position a little and >>you get something like
>>(for (i=0;i<10;i++) >> (for (j=0;j<10;j++) >> (if i == j >> (printf "i =j\n"); >> (printf "i not j\n"); >> ) >> ) >>)
>>That looks just like lisp, but nobody notices it because they're used to seeing >>it. What about all the damn semi-colons in c-- weird.
> It's not weird at all. In C (and many similar languages), there are a > lot of different "syntax embellishments" to actually help reading.
I have 13 years of C under my belt. 1.5 years of Lisp. I find Lisp code easier to read. And of course not to mention that reading 100 lines of Lisp can mean absorbing the semantic equivalent of 10,000 lines of C.
> LISP uses only parentheses. This makes it very easy to parse by a > computer, but not by (mant? most?) humans.
> In your example above you didn't go all the way. You should also have > removed all semicolons and replace them with parentheses, etc.
Cruft like semicolons and commas is largely replaced by whitespace. C needs the extra punctuation because of the infix syntax with unary operators. If you had a function call like
printf("%d %d\n" i ++ j)
what would that mean? Does the ++ go with the i or j? Okay in Lisp we would have parentheses, (incf j). But in C you need the damn commas among the argument expressions whether or not the ambiguity exists in the particular expression you are writing.
> Making > everything look the same has lots of advantages, but some > disadvantages. The equivalent C code would look like:
> for ( i=0; i<10; i++ ) > for ( j=0; i<10; j++ ) > if (i==j) > printf( "i=j\n" ); > else > printf( "i not j\n" );
In Lisp I can make a do-nested-times macro that will express the nested looping idiom concisely:
(do-nested-times ((i 10) (j 10)) ...)
This would certainly be worth it if I had lots of such nested loops in the code.
The macro would be smart enough to generate a loop with any number of levels of nesting:
You can do a few simple things with C macros, but they quickly run out of steam. First you give up hygiene, then you just give up.
> This is a very mild example, BTW. In C++ and C99, for example, > variable definitions (although properly nested) don't have to be > defined at the beginning of scope.
Whoa, sheer progress! From 1969 all the way to, oh, 1975.
> The following C++ program would > look like parentheses soup in LISP:
> { > File reader( ... parameters... ); > ...do something with reader... > File writer( ... parameters... ); > ...do something with both reader and writer... > }
> In LISP, you either have to group all these declarations in a single > let-like expression (assuming the semantics of your algorithm allow
In Lisp, you don't ``have to'' anything. You can compile C++ notation, if you are sufficiently disturbed to actually want it.
It's languages like C++ that force you into ``have to'' situations, so you have learned that programming languages are operated by submission.
> it), or open more and more explicit scopes, which make reading more > and more difficult.
(with-open-file (in-stream pathname :direction :input) .. do something with stream .. (with-open-file (out-stream pathname :direction :output) ... do something with both streams ...))
These scopes make reading easier, because you know exactly what is subordinate to what.
Anyway, you can make a binding construct which does this kind of flattening:
(special-let ((var1 init-form-1 ... forms working with var1) (var2 init-form-2 ... forms working with var1 and var 2) ...))
Perhaps the third parameter of each binding could specify some finalization form that is evaluated no matter how the whole block terminates, in reverse order of the definitions:
<gil...@snapdragon.csl.sri.com> wrote: >> It's not weird at all. In C (and many similar languages), there are >> a lot of different "syntax embellishments" to actually help reading. >> LISP uses only parentheses. This makes it very easy to parse by a >> computer, but not by (mant? most?) humans.
>Well, the argument is that in Lisp, eventually you don't `see' the >parentheses --- the mind filters them out as irrelevant to >understanding what's going on. Then you just start reading code in a >literal sense. The syntax embellishments aren't necessary.
I don't buy that argument. I both wrote LISP apps and read LISP apps for quite some time. In many cases, having just written a function, I'd read it back (always a good practice for catching bugs early), only to find out that reading was more difficult then writing. I have experience in other languages as well (Fortran, C/C++, x86 assembler, and Pascal). The only other language I had a similar experience is RPL (what you find in some HP calculators, such as their 28 series).
Your experience (and everybody else's on this newsgroup, apparently) might certainly be different. But for me, LISP was not the "last language" (to quote someone on this newsgroup) -- I switched to C++ and later to C#. For me, LISP always had almost everything I wanted in a programming language (real macros, CG, edit-and-continue-debugging, natural reflection and serialization, multi-dispatch). What it doesn't have, unfortunately, is a syntax I can live with.
"Adam Warner" <use...@consulting.net.nz> writes: > As I understand it symbols have a number of properties associated with > them. It would be nice if one of those properties was information about > the original case of the symbol
Such information _is_ kept; it is in the symbol's name.
e.g.
Starting /usr/bin/lisp ... CMU Common Lisp release x86-linux 3.0.8 18c+ 31 December 2001 build 3030, running on gondolin
* zi...@netvision.net.il (Ziv Caspi) | But for me, LISP was not the "last language" (to quote someone on this | newsgroup) -- I switched to C++ and later to C#.
Why is it important to you to argue against this? Did I somehow fail to make it clear that it applied to /many/ people, as opposed to /all/ that would make it legitimate to object? Do you have any new information other than what we already know? What do you wish to accomplish with your posts?
| What it doesn't have, unfortunately, is a syntax I can live with.
So write your own parser that produces s-expressions. But you have not even tried to adapt to the language or adapt it to yourself, have you? Why is it so important to you write about your unhappiness with both languages and other people's opinions and statements? Perhaps you should try to find something you /can/ live with if you are so unhappy with Lisp and this forum?
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
> I personaly think ANSI is a large, too-slow, not-very-useful entity to > be accomodating all but the most low-level basic standards. It was > probably appropriate to standardize CL itself this way, but even then > it's quite clear that the long time-line caused by ANSI resulted in > some companies going bankrupt in the meanwhile. Was ANSI the cause? > Probably not. But did producing an ANSI standard cost a serious lot of > money on the part of all Lisp vendors? Yes.
I didn't know that it is so slow and expensive. That explains a lot.
> Users love to point to things like this because they want everything on a > silver platter if they can get it, but the cost of getting this silver platter > is high enough that the rough edges present will buy you more in terms of > other things vendors could provide.
Right. I was only looking for the advantages of further standardisation without thinking about the costs.
Your explaination give me a new sight to the hole topic. I didn't realize the problems behind that hole process. Thanks for your patient explanations.
