Harleqin wrote:
usagi wrote:
Anyways, yes, you're right I've never written anything serious in Lisp. Who has?
One recent example is ITA software, who sold to Google for 700 million dollars this year. There are lots of success stories at the
ALU wiki.
Thanks for the links. I took a look at some of them, interesting stuff.
Harleqin wrote:
Quote:
They don't have a compiler. Well, that isn't actually true, but no one has the libraries.
No, to both; these are common myths without any connection to reality. Almost all modern Common Lisp implementations have compilers and use them. Also, there are tons of libraries for any purpose you might imagine. The most popular can be installed through clbuild, the gentoo lisp overlay, asdf-install, or (brand new) quicklisp. You can also browse Cliki.
Well, clbuild is not a compiler, it's a development tool that tries to find a compiler (such as SBCL, which is UNIX-only) to help Lisp progammers. I did find out however that there is CLISP for windows, which does include a compiler.
Hypothetical situation; You have written somtething in Lisp I would enjoy taking a look at -- Something small and cool. Could you send me a copy of the program? I don't have Lisp installed right now. Just to run said example program, what would do I need to do?
Harleqin wrote:
Quote:
Writing something like a sgf editor or flashcard drilling program for sale and use would be a true nightmare for both programmers and end users, but easy tasks in more modern programming languages.
What makes you say that? You can take some OpenGL binding or McCLIM and have it up and running just as easily as in other languages.
I wasn't implying Lisp has a lack of windowing capabilities. I was referring to having to rewrite a linked list library for Lisp for each program since it doesn't have any high level list processing capabilities. Such as a generic list copy function. This is actually what got me off C++ into Java, C++'s list management (and in general, STL and their object management in general) sucked in comparison. Now I may be wrong, but if C++/STL didn't have the generic OO-data structure I found useful in writing reusable code, I doubt Lisp would either. The information I found online only served to reinforce that. If I was going to reccomend a language to beginners. I don't know if that would be a major concern, but it would be up there.
Harleqin wrote:
Quote:
Am I wrong in that assumption, that Lisp isn't nearly as suitable as, say, Java or C# for writing killer applications? And if I am right, what is it exactly that Lisp was designed to do?
Yes, you are wrong.
Then why isn't Lisp used more often in a corporate/business environment? I don't think it is because C is so popular. Lots of programs are written in Delphi (i.e. pascal) or other languages. Even visual basic. But comparatively few real programs are written in Lisp. As a lisper yourself why do you think that is? There's got to be something about the language that is not suitable. I guess I am just speculating on what that might be. If it turns out that it's nothing but some sort of stigma due to the number of brackets or whatever, then so be it, I might learn Lisp in greater detail myself. But I'm finding it's a little more than that. There are barriers -- even just subtle ones, which prevent people from moving into Lisp. If those could be addressed, I believe it would be a better world. But they haven't been addressed for a long time, and I doubt they will be addressed in the future.
Harleqin wrote:
Quote:
I am not sure I understand. I find the point and the example difficult to understand. Perhaps I've been infected by the java way of doing things. But all joking aside, if you mean it's easier for the computer to understand "(+ 2 (* 3 4))" than "2 + 3 * 4", I'd be inclined to agree.
I mean that it is easier for the programmer to reason about. Lisp syntax is extremely regular (not in the grammar sense) and explicit.
Well, it's my personal belief that (2 + 3) * 4 is easier to understand than (+2 (*3 4). BEDMAS is pretty explicit about such things. That's what I learned in school as a kid, so it makes sense to me to keep using it. I suppose if you learn (+ 2 (* 3 4)) in school you'd want to use that. But I can't imagine learning it for no reason other than "it's more clear". That's never true the first time you see it, so why bother learning it? Is there some flaw in BEDMAS?
Harleqin wrote:
Quote:
Again I find the examples very difficult to follow.
Yes, it is difficult to argue on the basis of your limited understanding of Lisp.
No, I didn't mean I had a limited understand of Lisp and I therefore could not understand your examples; What I meant was that your examples were difficult to follow in a general sense. It appeared from your examples that you really didn't understand what I was trying to say. Even until just now, you seem to be making the case that abstract syntax trees are easier to understand than "that other way of doing things". My point is that they're not -- and the only reason Lisp does things that way was because it was easier to implementat on older computers. Starting from today and claiming it is easier to understand really isn't true.
One asks, what's the use of abstract syntax trees, anyways?
Quote:
They represent the logic/syntax of the code, which is naturally a tree rather than a list of lines, without getting bogged down in concrete syntax issues such as where you place your asterisk.
The logic can then be manipulated in a manner more consistent and convenient from the backend's POV, which can be (and is, for everything but Lisps
very different from how we write the concrete syntax.
(from:
http://stackoverflow.com/questions/3860 ... ntax-trees)
And there you have it.
Further.. I should probably comment on your tactic of claiming I don't understand Lisp. That is indeed true to a degree but it doesn't mean I don't know what I am talking about. Claiming that I don't know Lisp is a cheap shot, one which backfired here because I was able to show a strong knowledge not only of Lisp's history and reasoning during implementation but to provide actual code examples which clearly demonstrate what I was talking about. While at the same time you made claims about Java that aren't true (like, for instance, you can't pass functions).
Writing abstract syntax trees is a ridiculous expectation for first year computer science students, or really anyone doing programming as a day job these days because it is simply no longer necessary to cater to the vagaries of machine hardware AT ALL. Everyone understands "Let x = 2 + 3". No one understands "2 3 + x =" . Well okay, some people do. Engineers. Specialists. Oh, and Lispers, because they are using a mathematical expression language from the FIFTIES to do application and systems programming.
But most people don't understand, nor have a need, and there is really no reason to do things that way anymore. We're not programming on PDP-6's anymore. You ever
use a PDP-6? I'm sure you have, welcome to the club. I prefer to use more modern computers nowadays.
Here is one very simple yet poigant example which I came up with in about 2 minutes playing around in JLisp51 (
http://www.kenliu.name/software/lisp51/lisp51.html)
A.
(list 1 '(2 3) 4)
;Output ==> 1 (2 3) 4
B.
(list 1 (list 2 3) 4)
;Output ==> 1 (2 3) 4
From the examples above one would think (list 1 2 3) and '(1 2 3) would produce the same result.
And indeed, they do.The shocker comes when you try to actually use that in a real program, you know, to do something elegant:
C.
'(1 (list 2 3) 4)
;Output ==> (1 (LIST 2 3) 4)
D.
'(1 list(2 3) 4)
'Output ==> (1 LIST (2 3) 4)
E.
'(1 '(2 3) 4)
'Output ==> (1 (QUOTE (2 3)) 4)
Do you see what the problem is? You can '(2 3) or you can (list 2 3). You can '(1 2 3) or you can (list 1 2 3). But there is a difference between "'(1 (list 2 3) 4)" and "(list 1 (list 2 3) 4)". Therefore, the syntax is irregular. Understanding oddities like this is non-intuitive and I, personally, view that as a problem and that is one reason why I don't think Lisp is good for beginners. It can and will cause massive problems for people trying to write programs for the first time.
Harleqin wrote:
Quote:
But the point I was making is not that ",@" is readable or unreadable. The point I was making is that ",@" is esoteric and difficult for beginners to understand.
It is quite clear once you understand how macros work. "Practical Common Lisp" has a very nice explanation for that.
I believe it can be clear, and I believe, like a PERL program, it can be prohibitively un-clear to a beginner. Kind of like BASIC spaghetti code. People do it because it's there. If you remove that part of the language they do it another way because they have to. Lisp is part of a family of very old computer languages that allow people to do things in certain ways that really aren't very good ways. We know that now. If Lisp simply removed things like "syntactic sugar", it would be a better language for it. But that would expose other design flaws in the language. Don't get me wrong -- every language has design flaws. Including Lisp. But Lisp's flaws in particular make it a poor language choice for beginners, as I have outlined.
Harleqin wrote:
Quote:
I mean, look at the above Lisp. No wonder they invented syntactic sugar. But when do you stop? Why don't you just write
Code:
CustomerList.add(CustomerRecord);
and be DONE with it all? Finally and forever?
I do! I write
Code:
(push customer-record customer-list)
and that's it.
Why didn't you just write that in the beginning? Why all the examples with list? You're right that I don't understand Lisp very well, although I gurantee I know more about it than any other Java programmer you're likely to encounter. But this is all part and parcel of what I am talking about. Lisp is difficult to follow.
Harleqin wrote:
Quote:
Yeah I get what you're saying. But you can do that in any language.
Well, on the face of it, yes. This is also known as the Turing tarpit. However, it is easier to do in some languages than in others. Having real macros on the level of the abstract syntax tree is a feature the lack of which is difficult to work around.
Quote:
What I was referring to in a roundabout way was the syntax (aforementioned) screwups like incorporating hardware kludges into the software -- the "cons problem", which was designed to aid translation into assembly language and so forth.
Lisp just has support for lists on the basic language level. Modern applications usually do not even use
cons, they use CLOS objects with explicit names from the problem domain.
Of course they don't use cons. Cons are CAR, CBR, etc. which come from IBM 704 hardware address register names -- i.e. Contents of Address Register (CAR). On the surface not even the name makes sense until you realise memory space was SO limited on early computers they had to do addition in the address pointer register. It was a hack. It was done that way because it was the only way to do it. And it was a kluge. Carrying that over into software was neccessary at the time, but nowadays it's just an ugly kudge. If CONS was deprecated and people were forced to use the other ways of doing it in Lisp, then Lisp would instantly gain popularity.
Really, if I wanted to use cons I'd program in assembly language. Modern languages don't use cons because they implement real linked lists with first, last, rest, etc. accessors and people just use those. There is really no need for cons at all. Anymore.
Harleqin wrote:
Quote:
Then there is the single quote problem, where by you are quoting something, but there's no end-quote. But actually there is, it's a different character that looks like it belongs somewhere else. Like
Code:
(list 1 '(2 3) 4)
;Output: (1 (2 3) 4)
Makes brilliant sense, in a way, but looks weird and is not good for beginners because it is esoteric.
Why is it esoteric?
It's esoteric because no one does anything like that anymore. The reasoning has mostly been lost but it had a lot to do with how people conceived AI and computer science in general in the fifties. They were still banging it out back then discovering elements of good style and why they were important. Using a single escape character to qoute inside a single expression-program encased in brackets? You've got to be kidding. There are STRONG benefits to the Lisp way. But it is not for beginners. Not for a first language.
Harleqin wrote:
Quote:
Let me explain my idea this way. Let's say we are going to design a brand new computer language that will solve all of the world's software engineering problems. This language would be taught in every school to every child and the next ten years would all be about implementing it in EVERYTHING.
Let's say that to save time we were also going to start with Lisp, but it was going to be reviewed to make sure it was a suitable language -- just to be certain. During the review process someone says "Wait a minute, isn't Lisp, fundamentally, a language that manipulates lists?" and everyone says yeah, sure, of course. Then he says "Well then why does the list primitive which the entire language is build on only contain two elements? Why don't we update that one, small part of the language so that a list, natively, can have any number of elements that anyone would want?"
And everyone says sure, why not. But then some guy in the back says "Wait a minute! Computers 50 years ago had to do things this way!!" so they all agreed they would leave cons in, just in case. Just in case you needed to implement it on an IBM 704 or PDP, where including first, last, rest accessors would be somewhat problematic.
Quote:
John McCarthy developed the basics behind Lisp during the 1956 Dartmouth Summer Research Project on Artificial Intelligence. He intended it as an algebraic LISt Processing (hence the name) language for artificial intelligence work. Early implementations included the IBM 704, the IBM 7090, the DEC PDP-1, the DEC PDP-6 and the DEC PDP-10. The PDP-6 and PDP-10 had 18-bit addresses and 36-bit words, allowing a CONS cell to be stored in one word, with single instructions to extract the CAR and CDR parts. The early PDP machines had a small address space, which limited the size of Lisp programs.
(from:
http://www.faqs.org/faqs/lisp-faq/part2/section-13.html)
Then they said no, that's ridiculous, why should we cater to 50 year old hardware limitations? But, they still decided to leave cons in -- "We'll leave in the cons just in case there arises a problem for which higher level structures already present in Lisp (like arrays, hashmaps or using "proper lists") can't solve."
Thus you have the current Lisp style of doing things. But there are still big problems with this
because cons are there, and the fact that there are alternate ways of doing things doesn't solve these problems. Example --> no copy list function. You have to write your own, from scratch, every time. Or, do I have that wrong? I might. It's true I don't have
serious experience with lisp. Maybe someone wrote a library or something.
Well, you have not understood lists. How would you construct a single-linked list? Each node would have two things, a value and a pointer to the next cell. That is exactly what a cons cell is: a container for two things. A list is then either the empty list, or a series of cells, where each has a value and a pointer to the next cell, terminated by the empty list. This has nothing to do with hardware. It is just a very simple data structure, which is very useful to implement a language with.
In fact, John McCarthy had first developed Lisp syntax as a way to write mathematical statements. It was then discovered that it was very easy to directly implement as a programming language.
Every first year comp.sci student is taught how to implement linked lists. We don't need cons to understand that. You probably meant to say "you have not understood how Lisp implements lists". But indeed I do.
And therefore, that cons aren't actually lists at all is precisely the point I was making. That is what leads to the problems I mentioned about not having higher level list manipulation functions, and having to reinvent the wheel each time you write a program. We don't need cons. We need higher level list functions. It's simple, without higher level list functions you will forever be writing and rewriting your own, or you simply won't have higher level list functions.
Harleqin wrote:
Quote:
Example; I just wrote a few programs recently; a NetHack like program, an advanced SGF editor with tag-editing features, and a flascard program that drills CJK, which I actually use in the highschool classroom when I teach occasionally. If I wrote those programs in Lisp I would have had to write separate linked list libraries for EACH PROGRAM. Instead, I saved time by writing them in Java.
Take a look at the source code of the old Intercom text adventures. They are written in a Lisp dialect, which allowed a very direct description of the worlds. Similar exercises seem to be in the new "Land of Lisp" book. You do not need linked list libraries, they are part of the language standard. If you want this kind of comparisons, here is a report on an experiment:
http://www.flownet.com/gat/papers/lisp-java.pdf. Really, there is no problem writing the programs you mention in Common Lisp.
I was taking a look at those studies yesterday, actually. I read an interesting take on it from a D programmer, who completed the challenge in something like 1.5 hrs (faster than anyone else) because, as he said, D contained all the structures neccessary to tackle that particular problem. I suspect if the test were different, the results would be completely different. Those test results also show that the difference between programmers was larger than the difference between languages, suggesting that spending time training programmers was time better spent than figuring out what language to use.
Harleqin wrote:
Quote:
The end user doesn't care what language it is written in and I saved time by not having to reinvent the wheel three separate times. To tell you the truth Harlequin, I'm scared to try lisp because I don't want to end up proving to myself it is a giant waste of my time and then dumping it.
I call FUD. I have never seen a language where you can take the DRY (Do not Repeat Yourself) principle as far as in Lisp. Java is always "verbose language is verbose".
Okay, then does Lisp have STL or anything like it, which would enable people to use, for example, a generic list copy function?
Harleqin wrote:
Quote:
But I remain puzzled by people's attachment to a 50 year old language with hard to grasp, irregular syntax, that has no higher level list operators.
It is not irregular, it is easy to grasp (unless you cannot let go of ALGOL-derived syntax), and it has all kinds of higher level list operators, many of which you do not even find in Java and similar languages. Where is MAP, MAPCAR, MAPCON, MAPL, MAP-INTO, REDUCE in Java? What, you cannot pass functions? What kind of stupid language is that? You should consider that the people who are attached to Lisp even though they know the ins and outs of Java and similar languages perhaps have found something.
You can't seriously believe that there is something in Lisp that can't be done in a serious, modern programming language. No one here, not even I, made the claim that Lisp
can't do something -- I even said 'well that's not entirely true' when claiming they didn't have a compiler. The problem is that it is esoteric and irregular, at the very least in comparison to what people are taught in comp.sci programs and what they experience working as programmers.
For example? Okay. You can pass functions in Java. That's how I wrote my SGF editor; using a hash map of SGF tags to functions which would evaluate their contents.
MAP and associated? Well I don't think you really mean to say that Java (and just for example, again, I know many other languages) doesn't have something whereby you can apply function to successive lists of arguments.
Hell I could even write a MAPC function if I really wanted to, something which would allow me to do mapc(function, arguments), just like in Lisp. The question is why I would want to. If there was a pressing need to do that I could do it.
Now consider lisp. There is a pressing need for a generic list copy function. What do I do? Help me solve this problem! I ask because I really want an answer -- it's probably the one thing keeping me away from trying something in Lisp.
Harleqin wrote:
Quote:
The examples you give can all be written in one line of Java (or whatever); something like CustomerList.add(CustomerRecord); where CustomerList and CustomerRecord are variables/lists/whatever.
Again, you simply have no idea of even the basic functions Lisp provides.
(Push customer-record customer-list). That is even without going into the power CLOS (the Common Lisp Object System) provides. I am pretty sure I can match any Java code snippet you provide with a more concise and at least as readable version in Common Lisp.
Of course you could. I can do the same in Java; you just write a macro or function or class or whatever to do whatever you want and then call that. "push" is, in fact, a Lisp macro. Real lisp takes several lines to do that as you demonstrated in an earlier post. But in Java (for example) .add a feature of the language itself; it is not a macro. The difference is that push can not redefine the core structures used by Lisp. .add, in Java (for example) IS the core structure of the langauge, and it works on anything. Unlike push.
Harleqin wrote:
Quote:
What you mentioned about coding your problem domain and thinking in terms of that has, generally speaking, already been done. So from the standpoint of someone who has a great deal of experience with languages, including Lisp, I wouldn't recommend for beginners.
You obviously do not have any great experience in Lisp.
No, for the reasons I mentioned, I do not have any great experience in Lisp. But that isn't really an answer to what I said -- it's just trying to discredit what I said by claiming I don't know what I am takling about. I think we have seen I know more about Lisp than you give me credit for (I have provided unique, concrete examples of Lisps), while at the same time you yourself have demonstrated a lack of knowledge about other languages, such as Java (claiming that you cannot pass functions, and that it can not do stuff like MAPCON, etc. which is also not true).
Believe me, if there were answers, I might try Lisp more. It's just I don't have time right now...
A lot of what you said does indeed make sense, but please keep in mind you can code any language to do whatever you want. There is hardly a language alive today where you CAN'T code your way out of whatever wet paper bag you find yourself in. Those arguments works Lisp and Java, and C and whatever. The only problem I have here is that I don't think Lisp is really a language suitable for beginners because the paper bag functions like an event horizon. After looking at lisp for a long time you begin to consider that perhaps not every problem is a nail, and maybe the real problem is that you are trying to use Lisp for something it isn't designed to do.
Whether or not I am an experienced Lisper has no bearing on that. You do not have to be an experienced Lisp programmer to understand the history, implementation and use of a language.