This is a continuation of a discussion from another thread.

I have reduced the amount of quotes to make this a bit more readable and concentrate on the important points.



You made two claims: that there were no compilers, and that there were no libraries. I replied that there are compilers everywhere, and that there are lots of libraries, which can be installed through the means I listed. SBCL is not UNIX-only, by the way.



That is simply not true. Your problem is that you do not understand lists. What does it mean to copy a list? I return to that further below.



Because people like you are running around and proclaiming things about Common Lisp like it was still LISP 1.5. The corporate/business environment is always doing things like everyone else, so this negative propaganda is quite effective.



What do I have?



No, you presented half knowledge and jumps to conclusions without basis. In each of your examples, I first have to correct misconceptions and then try to answer what questions remain.



Ah, so how do you pass a function to something like MAP in Java? In other words, how do you translate this code snippet:



i.e., given a list, return a new list composed of the return values of applying the given function to the given list. A more concrete example:



i.e., given the two lists (1 2 3) and (3 4 5), return the result of adding them element-wise (this should return (4 6 8)).



No, they do not. You have not understood what quote does. (List 1 2 3) returns a new list containing 1, 2, and 3, while '(1 2 3), which is the same as (quote (1 2 3)), returns a list literal.



How on earth did you come to expect list and quote to be the same thing? The only thing irregular here is your expectation.



Because you did not ask the question. You just presented some misconceptions, which I corrected.



No, you seem quite average in that respect.



That is just the name (it is CDR, by the way, not CBR). Common Lisp also defines FIRST and REST as aliases for them. However, cons cells are more flexible than just to build lists.



Well, that is another misconception of yours: a cons cell is not a list, obviously. It is (or better: can be used as) a list node.



Now we return to your list manipulation problems. Just take a little look at the HyperSpec: the conses dictionary. There, you have everything you need, including, for example, using lists as sets. That is just what is in the language standard itself; there are several libraries providing more functions. Examples include SERIES, which implements lazy lists and generators, and ALEXANDRIA, which has several utilities, as well as a shallow copy-list.

Looking at why there is no copy-list in the ANSI Common Lisp standard, you have to ask, what does it mean to copy a list? Should the objects contained/referenced in the list also be copied? How deep does this go? There is COPY-TREE in the standard, which recurses into every cons contained in the list/tree (conses are more flexible than simple list nodes, because you can put more lists in both parts of a cell, thus constructing a tree). The ALEXANDRIA copy-list is a simple (mapcar #'identity list), if I recall correctly.



Not "can't be done", obviously (because of Turing equivalence and all that). However, I do not see how you would emulate the three-tier condition system (condition, handler, restart) in Java, which only has a two-tier exception system (exception, catch). I also know that, for example, the lack of multiple dispatch can be worked around in the elaborate visitor pattern, but that adds a lot of ever-replicated effort, which cannot even be refactored due to the lack of a real macro system. I do not know how to get something like advices (before, after, and around-methods) in Java.



And you were complaining about the lack of higher-level list functions?



See above.



Macros are real Lisp. We can go into implementation philosophy, too, but that is a different can of worms. I shall just mention here that I do not have to wait for the language designers to implement a new keyword.



Yes, of course. The problem is that you claim great experience and that therefore, you are right about Lisp being inferior to any modern language (even Java). You are giving yourself too much credit, and that has to be addressed, too, in addition to refuting your other, more concrete claims.



Yes, this is known as the Turing tarpit.



Perhaps not, but you do not seem to have understood it anyway.

Just to be clear: I do not claim that Lisp is superior to any other modern language. I only claim that it is at least equal to others.

_________________
A good system naturally covers all corner cases without further effort.

I don't know too much about lisp and even less about lisp in corporate environment, but I'd guess there are two more important reasons:
- corporate environment likes to use technologies for which it is easy to find resources. I'd believe that there are a lot more competent e.g. Java programmers than lisp programmers. (That again may be due to false propaganda, but I suspect there are other factors as well)
- although Java is not by any means superior language compared to lisp (and may well be inferior), there is a lot of SW infrastructure based on Java: J2EE/JEE5 application servers, messaging solutions, SOA infrastructure, portal servers etc. I don't know if similar are available for lisp programmers, but at least they are probably not so readily available. Also it might be possible to use the "non-lisp" SW infrastructure from lisp, but again I suspect it would be more or less of a "hack". And of course, you can program everything the infrastructure provides (transactions, concurrency, high availability, long running business processes, human workflows etc) yourself in lisp, but I very much doubt it would be productive. (Now then you can claim that all the wonderful infrastructure that exists for Java programmers should have been implemented in lisp for lisp programmers, and you may be right, but I think we shouldn't go there.)

_________________
Offending ad removed

1. I didn't claim there were no compilers.
I've already touched on that point in a previous message, and you've included my quote above so there should be no misunderstanding about that. I even brought up CLisp for windows two posts ago so there should be no further need to discuss that.

2. I said "no one has the libraries", which is true -- not "there are no libraries".
Further to this, you didn't answer my question about what I would need to do to run a hypothetical Lisp program you would hypothetically send me.

3. I said SBCL is unix only because that's what it says on the SBCL web page.
Please see http://www.sbcl.org/platform-table.html for more information. There is no need to discuss that at all.



I've already explained that everyone who has studied computer science understands what a list is, what a list node is, and how to implement both. If you want to insist that I don't understand lists, as a way of dealing with what I said about how cons is not a list (but a node) and then turn around and state the obvious (cons is a list node not a list) then you've proven my point -- the list primitive in Lisp is low-level, and as a result of this exposure there are no generic high level list functions in Lisp, such as, for example, oh, a generic list copy function. You've not yet addressed this point, so I'm going to have to assume you don't want to. That's fine, we don't need to talk about that anymore either.



I don't accept your argument; "people like me"? I was just asking questions. Well, I don't really want to talk about that with you either, it's clear you have no intention of discussing any possible flaw in Lisp nor how it might be improved. It's always "Propaganda" and "people like you" and "you don't understand computer science". Don't you find that odd, that I will ask questions and you get all defensive? If there is a simple, easy answer to what I've asked then where is it? Why do you fall back on claims of mass propaganda?



You have some facts which support my argument. You claimed that ASTs aided programmer understanding of code, I just proved that they were created to aid machine interpretation and human readability was likely at the bottom of the list when designing ASTs. Read it again: "The logic can then be manipulated in a manner more consistent and convenient from the backend's POV". It has nothing to do with human readability. Now, I could be wrong -- but your argument otherwise appears to have no foundation.



Easy. I write a function to do that, which you might consider a "macro". For kicks I call the function mapcar. It takes two lists as an argument and returns a new list. Looks like this: mapcar(list1,list2);.



No, they do not. You have not understood what quote does.[/quote]

Actually I do but it is difficult to understand. It would be a form of torture for someone to try and figure it out learning Lisp as their first language. That was my point. It can, and will, cause massive problems for people when they try to code Lisp.



You seem intent on minimizing my knowledge of Lisp; despite all the quotes, code examples, and links to Lisp FAQs and SBCL web pages I've provided, despite your own lack of knowledge of Java (for example) you seem to place great emphasis on the fact that I don't code in Lisp. I don't get it, is that crucial to the argument you are presenting? Is it somehow okay to ignore what I am saying, or talk down to me because you feel I am average, or that I am not someone who programs in Lisp? I've presented some relatively heavy issues in this discussion and I feel you haven't addressed them. You've blatantly ignored questions such as "what is Lisp's generic copy list function" and "what would I need to do to run a Lisp program you might send me". I have to wonder, are there even answers for these questions at all? Because I haven't seen them. You might notice I am not making a big deal of you not understanding Java. Mainly because it's irelevant. Take the hint please.



Yes, those are some big questions, and they're all answered in the modern OO languages. Let's say I have a list, called CustomerList. If there is some problem in the generic copy function which is provided, I can over-ride the add function to do whatever necessary processing I need to do. I'm sure you can also, in Lisp, re-code what look like higher level list functions for whatever list you are using. Actually here's another interesting question. Say you have a list of fruit and a list of meat. The meat list requires special code for copying some random variable properly, and the fruit object has a separate way of copying itself.

if you now have a list of both fruit and meat objects, and you, say, copy them into a new list adding the prices element by element (a better example might be adding working hours of people randomly assigned to worker dogs) -- well, would Lisp automatically use the right code to copy the particular object in the list it's working on?

Let's also complicate things further. let's say that depending on the type of list the two types of object were in, such as a "FullInfoList" and a "QuickViewList", copy on certain types of objects would be done differently. Can Lisp do that and if so, is it implemented in the code for the list or the code for the object?

Final question, where does this code logically belong in Lisp? Is it overwritten and thus hidden from the programmer, who just happily uses the languages list copy function, or do you need to use a special function name for each type of list?

(That's three questions).






Well, at least you're honest about it...

"Looks like this: mapcar(list1,list2);"
And where does this take the function as parameter? In C# I could use "list1.Zip(list2,(a,b)=>a+b)" but afaik the current version of java has no lamdas, first class functions or anything like that(I think Java 1.7 adds them), so you'll need to use a hack like anonymous classes.

And while I know almost nothing about lisp it looks to me like you completely miss the point of lisp. List has powerful meta-programming features which java doesn't support at all, and C# only in the extremely restricted form of expression trees. How do you not see the appeal of being able to manipulate the languages itself to fit more to a complex problem domain. I hit the borders of the language quite often in C#.

_________________
Sanity is for the weak.

You will have to explain what you mean by that.



A computer and an operating system. If that operating system happens to be one I can compile on, I can send you an executable. Otherwise, you also need a Common Lisp implementation to compile the code yourself.



I have already provided you a link to a whole bunch of high level list functions. Copying lists can be done with, e.g., COPY-TREE or (mapcar #'identity list), depending on your needs, but I must add that I have rarely come across a need for a simple copy.



You were claiming that Lisp was not a general purpose language suitable for modern programming challenges.



I hate that, too, but what should I do, let your ridiculous claims go unanswered?



That is not mutually exclusive. My point is that the almost coincidental closeness of Lisp notation to the AST can be a benefit for all sides.



A macro is a function that transforms code structure. This has nothing to do with the question of writing higher-order functions.



Where do I pass the function? Can I do mapcar (function, list1, list2);?



No, not really. Normally, when the Lisp reader reads something, it evaluates it. Quote returns its argument unevaluated.



No, my intent is to put it into perspective. You made a lot of claims about how Lisp is inferior and unusable, and all you can give as a basis for those claims are misconceptions and your own lack of willingness to learn Lisp.







Yes. A simple copy:



Copying and tallying in one pass is perhaps easiest with an explicit loop (yes, the example is not very useful):





It is implemented in the code of the generic function. One way is something like this:



However, if there is common code in those two copy functions, like if there is just some preparation you have to do before copying, you would use advices:





We have multiple dispatch on the types of the functions arguments (note the plural). The Common Lisp Object System is built around generic functions providing the dispatch.

I have the hunch that this is the first time you have seen defclass and consorts.



You say that as if it was a bad thing, but all I do is refute your pseudo-argument of authority.

_________________
A good system naturally covers all corner cases without further effort.

No I get it, as I have said 3 or 4 times in this discussion that's part of why I moved away from C++ into Java.

Anyways, I thought he just wanted a function to add the elements. Normally what would happen here (in java anyways) is that you create a function in the object or list class you're using, which adds the elements. It's extremely rare that you would actually want to pass a function for operation on list elements (read; that you have to or that doing so is the best way of doing things). However it is warranted enough to actually be a part of java.

First off, ever sort anything?



where CompareByFoo is your custom Comparable class which implements the standard compare function that you like. Such as:


There are other ways; I'd mention that JiGo uses a type of function passing as well.



then later something like this:



where "BlackMoveTokenImpl.class" is a class which contains a run method or something you want to use.

When they wanted to call the function they would do "return new tokenClass();" or "return tokenClass.newInstance()" where tokenclass was set equal to "WhiteMoveTokenImpl.class" after a hashtable lookup. I thought that was cool and used the technique in my SGF editor for a long time.

Actually funny story. I was using this method of passing functions dynamically when I realized it was pointlessly obtuse, and re factored the need to do things that way out of my program. it made more sense to just over-ride an "execute" method in a general "SGFTag" type class in the subtype like "BlackMove" or whatever. That way, the code for the sgf property execution was kept in the file belonging to that tag, and not in a giant hashtable housed in a file with no other purpose in life but to house that file. But more power to JiGo for doing it that way, and more power for languages that operate that way as a normal course of business. Again, I programmed in assembly language, basic and C for years and years, and I loved it.

So anyways yes, you can pass functions in Java, or you wouldn't be able to define your own library of custom plug and play sorting algorithms, to bring up the likely most applicable example.

Well, let me put it this way. Say you wanted to sell a program you wrote in Lisp. Besides the actual program, what libraries and other files will you need to distribute with the program? Since, as we all know, not everyone has Lisp set up on their PC. Maybe you're lucky and you have a compiler that statically links everything. I view that as horrible, but given that most people are unlikely to have one lisp program on their computer let alone two there is probably no harm in static linking.

See, though, if you want to dynamically link everything you have to get people to install the libraries. And that can be difficult. So that is what I meant by "no one has the libraries", and I am pretty sure I am right about that.



No libraries?



Well it's like you said. Can you define custom copy operators that kick in automatically when COPY-TREE is performed on them? If not, then you don't have high level list operators. You're just operating on the primitives. That's the problem, which causes you to have to write your own set of copy functions and so forth instead of just including whatever exception is appropriate at the time you write the class or the list (when you create the situation where an exception can occurr).

For example if I am writing a nethack style adventure game and I want to save the state of the level once it's been exited. All the tiles contain objects, some of which are bags, which all need to be saved. And the contents of bags need to be saved. If you just save the list of objects in the tile, you miss out on the list of objects in a bag on the tile. You save the bag and the pointer to the list of contents -- but not the contents. So what you do is you specify during the save/load (i.e. copy) procedure, that certain list elements must be copied in a certain way. You do this right in the bag class. Let's say you use serialization, for example (particularly suited to a SGF editor btw). In the serialization for bag, you serialize all of the contents of yourself at some point during your own serialization. This recursively would serialize any other bags you contain as well. You never have a problem copying lists like this because the copy function is high level - it does not work with the primitives. The primitives are hidden from the coder when dealing with them in that way.

You can always convert a list to an ArrayList though and then perform operations on the primitives. This is also useful at times. But usually it's just better to figure out how to do it as a List.



It isn't. it's a specialist language designed for mathematical expression in the late fifties. It was then modified to do AI programming. It was implemented on extremely old computers like the IBM 704 and the PDP-6, where the implementators were forced to design the language in a way that made it work on the hardware they had. The hardware was extremely limited. It was some of the first hardware that didn't require moving too many vaccum tubes around. Thats why you have IBM 704 registers as accessors in the language, because you are actually coding in a form of assembly language, as low level as you can get. That's how languages were back then. Hey, it was better than punch cards. But today we have things better than punch cards, and also better than Lisp.

As I said, you can code your way out of whatever wet paper bag you find yourself in. Today Lispers have made certain that you can do anything in Lisp. But that doesn't mean you're supposed to. Note that the leading program on the Google AI challenge is written in Lisp. I am not suprised. Note that Microsoft office is written in (I assume) Visual C or something close to it. Not lisp. They COULD have written it in Lisp though. Unix was done in C too. Lisp CAN do anything and I'm sure if you take the logic of the Google AI challenge program and translate it into ALGOL it would work just as well. But why bother? Use Lisp for what it's good for, use C for what it's good for.

For beginners, avoid Lisp and focus on Python or Pascal or something. Pascal is a great language for beginners too, although even it has it's flaws.

I can easily say this even though I detest python and pascal and would never write a line of code in either even if I was paid. because it's true.



Depends on how you define macro. A macro is a short form for a longer list of commands. This usage is actually more common and accepted that the c preprocessor definiton which is much closer to how you are using the word.

I am justified in saying macro because Java is an interpreted language, the libraries I link to are written in Java. There's nothing in them I can't over-ride. There is no difference because of the space programs exist in. You can cut and paste classes in a JAR even after they've been compiled.

I could even write a roulette program that randomly moved .class files out of one directory into another until only one was left, then ran that class file. It's an interpreted language even though it is also compiled. And if you really wanted to you could use ant macros or any preprocessor macro you wanted and recompile those .class files on the fly.



I answered this in my previous post to Li Kao. In short, "yes".


Cool -- looks kind of like what I would imagine you do in java but with different syntax.


Yes I would usually prefer iteration for most purposes as well (so I snipped the example).



Yes, that's also how Java seems to do things.



[/quote]

Well it's one thing to suppose that I have never seen defclass before, quite another to suppose that and then go on to base your argument on the assumption you are correct, without any real evidence to support that. Yes, I know you don't like what I am saying about Lisp. But what I am saying is true, and backed up by information in the Lisp FAQ, on the SBCL website, and so forth. Here's one relevant quote from McCarthy's page at standford on the history of LISP:



This statement is quite different form how Lispers like to imagine how their beloved syntax was created.

Here's another from nearby:



If you read between the lines, you see that LISP was developed to do what it could given hardware limitations. if those hardware limitations were not present, you wouldn't have to deal with primitives directly, and you wouldn't need to deal with them in such primitive ways for nontrivial applications.

I'll conclude with my take on McCarthy's own conclusion:



Lisp's strengths are it's nature as a mathematical expression language and to do AI research. It is a relatively low level language. It's syntax is a disadvantage. Given these three points I would not advise a beginner to start with Lisp.

I don't really understand the assertions that 'Lisp's strengths are it's nature as a mathematical expression language and to do AI research.' and 'It's syntax is a disadvantage.' For the former, there just doesn't seem to be much reason to say that, is there any evidence that it's true? For the latter, that's entirely subjective, and not really an argument.

Um, please forgive my ignorance. On the topic of copying: Isn't lisp a functional programming language without mutable state? Well, in the programming model at least. No doubt they do other things underneath for the sake of efficiency when they detect it's possible. Anyway, that would make the particular subject of deep copies of lists kind of beside the point.

_________________
19/02/2011: this grumpy person takes a voluntary holiday from L19.

Regarding libraries: I see now what you mean. Common Lisp is similar to Perl, Python, or Ruby in that regard, except it can also save a complete image. That yields a single executable without dependencies. For example, my window manager (stumpwm) goes that way. There are also techniques to shave off unneeded core language parts from an image in order to reduce the size of the binary executable.

Regarding saving a level state for a nethack game: There are persistence libraries for Common Lisp where all you need to do is mark the classes of the objects you want saved as persistent. This is possible through the use of the Meta-Object Protocol (MOP), which is somewhat similar to what is called "reflection" in Java (except that it is fast and completely integrated). Doing this completely with primitive lists is rather an entry for the "Archaic Lisp contest", but nonetheless possible without much effort.

I simply do not get how you can comment the snippets showing modern Common Lisp as "hey, that is quite similar to Java", but at the same time insist that Lisp were archaic and unfit (unless you also characterize Java like that). I do note that you simply discarded the demonstration of method advices, though.

Regarding your quotes about the origins of Lisp: Those are reminiscences that are about as relevant to Common Lisp as reminiscences about ALGOL are for C99. The details you mention are about the first LISP (around 1960), and they do not appear anywhere in the Common Lisp standard (1994). I have already written about s- and m-expressions in the other thread. The point is that even though s-expressions were originally intended as an "internal" format, it has been discovered that they are extremely useful as a direct syntax. That is why no one bothered to actually implement m-expressions, and that is also why Rich Hickey chose them for Clojure.

In other words: What is the most expressive programming language that has ever been invented? Haskell. Why not Lisp? Lisp has not been invented, it was discovered.

_________________
A good system naturally covers all corner cases without further effort.

Well, Common Lisp is multi-paradigm. You can do object-oriented, functional, aspect-oriented or even plain structured programming in it. A certain basic "functionalness" is encouraged, though, as is object-orientation.

Functional programming is emphasized much more in Scheme and Clojure. There is a saying that Scheme says "Buddha is small, clean and serious", while Common Lisp says "Buddha is large, has hairy armpits, and laughs." Common Lisp is very pragmatic.

_________________
A good system naturally covers all corner cases without further effort.

You're absolutely right. John McCarthy, the guy who invented Lisp and implemented it and so on and so forth, the same John McCarthy who is regarded as the father of Computer Science and of Artificial Intelligence, has a completely subjective view of the language he invented and it's place in the field of study he invented.

I'm curious ... usagi, what would be a decent test of LISP as a full language for you? Suppose someone were to create an executable. What is the minimum that executable should demonstrate, and on what platform? What would you consider to be a reasonable timeframe for completion and delivery of this executable?

Some background: I'm a fairly reasonable programmer, with only a passing understanding of LISP. I am also out of practice, doing mostly scripting lately. I am willing, however, to take a bit of time to give this a try. I mean, if the language has reasonable resources for both learning and development, I should be able to take a reasonable amount of time to produce a non-trivial product.

What do you say? Is there a challenge for me to meet?

No not at all, I just had some questions, such as, what would it take for someone to run a Lisp program. I write stuff which I want to either distribute or sell. If using Lisp makes it very difficult for me to distribute my program I wouldn't use it. I was also interested in some of Lisp's special features, but from investigating the language there appears to be no real use for it anymore. I mean come on, there's dozens of different languages. We could probably nix half of them and no one would really notice. I was curious, I guess, that's all. Especially since it was being brought up in a discussion on what languages would be best suited for beginners, given all I know about Lisp.

Could I insert something here?

From the earliest days every couple years a new language gets introduced. Some of these remain in use over the decades, others fade relatively rapidly. There are reasons for that (why the "survivors" survive). Or in some cases why some new language does succeed in replacing an old one (usually it incorporates the capabilities of the old).

I could argue that having been considered useful for a lot of people for at least a couple decades should be weighted more heavily in the decision of what langauge to learn than any current hype.

If you are going to be going into programming seriously then you will be learning several langauges over your career but of these half (or more) will be the hoary veterans.

(I don't know what you're referring to, sorry if I missed something, but I assume John McCarthy said something along the lines of 'lisp is outdated'.

Are you serious? Is this actually your argument?

Do you think John McCarthy is solely responsible for all the work that's gone into common lisp, scheme, clojure (in themselves all different from the original lisp implementaitons)? If not, were all the other people who worked on these labouring under a misapprehension, not realising that the statement of some guy (who fathered computer science, no less, and thus has absolute knowledge of the subject) has invalidated the point of the work they're doing? That the languages they enjoy programming in and find useful are actually inferior to other languages, and they just haven't noticed because they're idiots/blind/stupid?

Or maybe these people know something you don't. Maybe lisp, or at least dialects of lisp, are really good languages that are just as good as any other for most tasks, better for some, worse for others...

Also, I don't retract the statement that your views on lisp are subjective. Just because some guy who knew more also said it (assuming he did) also doesn't make them objective, and doesn't make him objective either.




Another 'wait, what?' argument here. Your argument makes very little sense...we could replace python with ruby, they're similar in many ways, but does that mean that we should? And even if it did, why this way around rather than replacing ruby with python?

Of course we could do the same things we do now with fewer languages. We could do find without java, for instance, and many of the people who hate java could probably supply 'good' reasons to do so. But this isn't an argument against not using any particular language, and isn't obviously a correct argument in the first place.

I know what you mean, but I disagree.

Hype notwihstanding, there are languages which are more suitable for learning programming, and ones which are less suitable. And this really have nothing to do with the actual popularity or longevity of a language. Unless you are assuming you will learn one and only one language (in which case it would depend on what you want to do - for example if you are planning to be a web developer with one and only one language, I suggest javascript.)

There are several factors that can make a language good for a beginner or not. Remember - we are not talking complex programs here, just learning and slowly going up the ladder. Clear application of the concepts, intuitive syntax, overall stability, accessibility of resources, and most importantly - abundant learning material and a hopefully a large and diverse community. From my personal experience, good languages to learn programming concepts from are for example Pascal/Delphi and Java. Bad ones would be, among others C, C++, Ruby, PHP, and yes: Lisp, Common or not. Usagi mentioned quite a few of the reasons for that, and for what its worth - I do agree with him.

But regardless - in all these languages you can be a wiz, and if you are, chances are you'd argue for the superiority of your particular little language/skill until the cows come home, and the more obscure the language/skill the more aggressive the argument and the more personal the discussion gets. We see examples in this very thread. In each of the languages great code can be written, and difficult problems solved. In each a lot of crappy code has been written as well. Good programmers write good code in whatever language they use, and bad programmers are a pest anyhow, so who cares.

And people who turn into programming language evangelists are just misguided, imho.

_________________
- Bantari
______________________________________________
WARNING: This post might contain Opinions!!

Bantari, I think that you do make some valid points, but there are also some things I find debatable, especially those that seem to be directed at me.

For one, I did not evangelize. I specifically said that I do not claim any kind of superiority of Lisp. All I did was claim that it is at least equal to other, more mainstream choices when it comes to building "serious" applications.

Your criteria for good languages to learn programming are perhaps OK. ("Intuitive syntax" is an illusion, though; "intuitive" just means "what I expect from prior experience", which is irrelevant for someone not having such prior experience. On the other hand, someone who does have prior experience with different syntax may benefit from acquiring a new perspective---the languages we know enable the ways we think.) However, your next step would be to confirm whether these criteria are met by the individual languages you mention. I would not know where to look for good Pascal or Delphi tutorials, I would also not know where to find the community, and it would take quite some work to confirm the stability of the implementations. I think that this is just the case for you and the languages you deem bad for learning, nothing more.

I can just tell you that Common Lisp has brought me up to dan level in programming, in record time. It also meets your criteria, by the way.

I refrain from summarily dissing things I do not know good enough, even Java, and I do not claim superiority of things I am a fan of, even Common Lisp. I try to be aware of the limits of my knowledge. I will give recommendations, however, and I will contradict anyone who out of ignorance puts things down that do not deserve it.

_________________
A good system naturally covers all corner cases without further effort.

Never said you did - it is you who felt addressed.
As a matter of fact, this is one of my pet peeves of lately, since there seems to be a lot of that in the RoR community. This is what I referring to, sorry for the lack of clarity. You made some good points about Lisp too, even though it seems to me you get your panties up in a bunch about usagi's questions and remarks - and all he seems to be saying is that Lisp does not look like its a good first language to learn, which I agree with.



I beg to differ on this issue.
I simply find 2 + 2 more intuitive that + 2 2. Even to a non-programmer (ESPECIALLY to a non-programmer, I'd say!)
I would assume most of us would agree on this point. Same goes for most of the other examples you give about Lisp syntax.

Remember - even if somebody does not have any experience with programming languages and their syntax, he did not grow up in a vacuum, and he caries a lot of conceptual conventions from school, work, and life in general. A lot of languages use syntax which at least attempts to cater to these common conventions. It seems to me that Lisp does not care much, and instead it caters to some other values. It does not make it bad, it just makes it less beginner-friendly.

This is not a critique of Lisp - I will be the first to admit that I have absolutely no clue about it, I judge it merely from the examples you yourself provided... I assume these were 'especially clear' examples, which seems to reinforce the point usagi is trying to make. From what I read suggests that its a great and powerful language. But trying to feed it to beginners is not good since you present them not only with the hurdle of having to learn basic concepts of programming, but also force them to throw out some of the ideas they consider 'natural' in favor of syntax that's precise but maybe not quite as readable.

_________________
- Bantari
______________________________________________
WARNING: This post might contain Opinions!!

I realize that (that is what the "seems" is for), but I want to ensure that this also is clear for observers.



No, he explicitly stated that Lisp is not a general purpose language suitable for modern programming challenges. That is a much bolder claim, one that damages the public impression of Lisp much more, but which is also much easier to refute.



You are trying to transfer prior experience from mathematical expressions to programming expressions. This transfer is a rather thin one, however.

Infix notation is only used for very basic binary operators in mathematics. Other operators write their arguments above, below, or as a sub- or superscript (sums, products, limes, logarithms, for example). Exponentiation is even done implicitly just through superscripting one of the arguments. Unary operators mostly come before their argument (sin and cos, for example, or such things as the Hamilton operator).

In C, operators usually come before their arguments, which are written in an ad-hoc list format: "operator (arg1, arg2)". Infix operators are an exeption, and they are only defined for some built-in functions (this is a difference between built-in and user-defined functions). If C had a unified syntax, you would have to write "+ (2, 3)". So, when you have learnt "2 + 3" in C, you actually have only seen a special case, which does not tell you much about how C syntax works generally. Also, "=" means totally different things in C and in mathematics: in mathematics, it is symmetric, denoting equality of both sides, while in C, it is assymmetric, its left operand needs to be an "lvalue" (i.e. a place that can be assigned to), and it denotes assignment. I think that it is surprising for a beginner that "x = 2 + 3;" is valid, but "2 + 3 = x;" is a syntax error. The similarity to mathematical notation can be seen as misleading here.

Now (without claiming that this approach is superior, just equal), in Lisp, you write "(+ 2 3)". This is how Lisp evaluation works generally. You can write your own implementation of "+", which works the same way: "(plus 2 3)". I think that the similarity of C syntax to mathematical notation is quite superficial, only applies to certain built-in features, and does not really aid in understanding C.



Which examples do you mean? I can attempt to translate them to a language of your choice, in order to compare.



We can have a similar argument about "readable" as about "intuitive", since people often mean "similar to C" (or Python, or Ruby) when they say "readable". However, it is easier to define criteria for "readable" than for "intuitive", so this needs not be a handwaving argument. We can incorporate this into the comparison mentioned above.

_________________
A good system naturally covers all corner cases without further effort.