Life In 19x19

Suji wrote:If at some point you want it to be web-based, PHP is really the way to go (or Perl).

This seems to be conventional wisdom, but I do not think it is true. Web pages can be generated in any language. For example, I use Common Lisp, Hunchentoot (a webserver in Common Lisp), and CL-WHO (HTML output library).

Harleqin wrote:

Suji wrote:If at some point you want it to be web-based, PHP is really the way to go (or Perl).

This seems to be conventional wisdom, but I do not think it is true. Web pages can be generated in any language. For example, I use Common Lisp, Hunchentoot (a webserver in Common Lisp), and CL-WHO (HTML output library).

What is it about Lisp that you like so much?

nagano wrote:

Harleqin wrote:

Suji wrote:If at some point you want it to be web-based, PHP is really the way to go (or Perl).

This seems to be conventional wisdom, but I do not think it is true. Web pages can be generated in any language. For example, I use Common Lisp, Hunchentoot (a webserver in Common Lisp), and CL-WHO (HTML output library).

What is it about Lisp that you like so much?

Lisp is very elegant and has powerful meta-programming features. But I don't think it is the right language for a beginner. I'd start with a more conventional language.

Lots of [b]Irritating Silly Parentheses (sorry, that's a LISP joke)

Harleqin wrote:

Suji wrote:If at some point you want it to be web-based, PHP is really the way to go (or Perl).

This seems to be conventional wisdom, but I do not think it is true. Web pages can be generated in any language. For example, I use Common Lisp, Hunchentoot (a webserver in Common Lisp), and CL-WHO (HTML output library).

You can use any language for anything, sure. However, certain languages make certain things easier. I'm not saying Lisp is bad, but PHP or Perl makes interfacing with databases easy. I'm also not going to write a web page in C++ even though it can be done. For me, that's like putting a square peg in a round hole. I'd rather use HTML and PHP (or Perl) for web pages because I like to make things easy.

For you, programming in Lisp might be the easiest thing, or you feel really comfortable with Lisp. This is good, as I think programmers need a language they feel comfortable in. I also feel that programmers need to have a basic understanding of all major languages and know the advantages and disadvantages of each, so that, if needed, can program an application in the "correct" language. Example: an Android application in Java.

Granted, if you're programming for fun, the whole scenario changes and you can program in just about anything that you want.

There's my 2 cents worth.

If you like Lisp, try haskell!

To be honest, the only good side of PHP, IMHO, is the relatively low barrier to entry. It's really easy to get set up with PHP on a web server and get your hello world going. Other languages generally require more work to get going in a web environment. But once you start getting to a program of a significant size, the sort-comings of the language go from annoying to crippling.

So I would say, that PHP is the way to go if you want to develop some simple web app, and get it up and running quickly. Choose anything else for more serious application development.

I acknowledge that there are some complex web apps written in PHP, Wordpress, PHPbb, etc. but if you've ever developed in them (e.g. writing a plugin), you probably have noticed the weirdness that results as a project grows bigger and exposes PHP's warts.

I also feel that programmers need to have a basic understanding of all major languages and know the advantages and disadvantages of each, so that, if needed, can program an application in the "correct" language.

Really? Then why do you not know Lisp?

What I really wanted to say, though, is that the statement "for web development, Perl or PHP are the way to go" is not true. It is better to say "for web development, you need a web server library (or a way to run on/behind something like Apache), HTML generation, and often database interfacing. Choose a language where libraries for that exist."

Just my two cents --- if you want to learn programming the particular language used isn't important. But what is important is having a learning text that takes the "elementary data structures and their algorithms" approach.

The whole point of a language like C++ is that it provides the basic data structures and their operations built in. No need to roll your own but that isn't what you really need to learn. The real difficulty is at the higher level of program design, recognizing immediately at the start (for example) "the natural solution to this problem I am supposed to solve is two lists and a queue". By comparison having to once roll your own data definition for a list, a queue, and the function definitions of the operations valid on them is simple (once written, you have them somewhere in a library). The origignal C text had you do as exercises your own definitions of all the functions that came in the built in library. Similarly, were I writing a text for C++ might have as exercises "do your own version of one of the built in objects" --- for the simple reason that someday you will need something neither built in nor easily/efficintly buildable from what is.

In the shop where I spent my working days >95% of the programmers did not know the "elementary data structures" and the result was abominable code. The trick is to first design the solution to the problem in abstract terms and only then worry about implementation/coding.

Harleqin wrote:

I also feel that programmers need to have a basic understanding of all major languages and know the advantages and disadvantages of each, so that, if needed, can program an application in the "correct" language.

Really? Then why do you not know Lisp?

In many cases being somewhat familiar with different languages is enough to judge what is suited for a given purpose (I'm somewhat familiar with Java, C, C++, Fortran, Cobol, Pascal, Ada, Algol68, Oberon, different dialects of Basic, Forth, Scheme, Lisp, Prolog, PHP etc, but nowadays I only really know Java, if any)

Mike Novack wrote:Lots of [b]Irritating Silly Parentheses (sorry, that's a LISP joke)

That's partly why I tend to avoid LISP (after doing a great deal of research into the language). I have learned to think in terms of breaking up the idea itself, and translating that directly into code. So I have tended to avoid langauges which have a large amount of esoteric syntax. LISP in particular contains a large amount of such. For example, the ",@" syntax for adding a list as an element of another list. Being familiar with many computer languages and how they are implemented I find the decision to include such syntax as part of the language incomprehensible. Then again, it was groundbreaking in the days when LISP was released -- but that was over fifty years ago. LISP isn't revolutionary anymore, and we've made great strides in understanding since then. The main problem here is that you need to think in terms of LISP and not in terms of the actual problem you're trying to solve. I just don't like doing that. I don't believe that LISP has a monopoly on good thinking, as fine a language as it really is.

usagi wrote:

Mike Novack wrote:Lots of [b]Irritating Silly Parentheses (sorry, that's a LISP joke)

That's partly why I tend to avoid LISP (after doing a great deal of research into the language).

I do not think that your research can have been very thorough after reading what you wrote in the following. You have never written anything serious in Lisp. Also, it is spelt "Lisp" nowadays.

I have learned to think in terms of breaking up the idea itself, and translating that directly into code. So I have tended to avoid langauges which have a large amount of esoteric syntax. LISP in particular contains a large amount of such.

No, it does not. In fact, it has almost no syntax at all. In other languages, you have three or four kinds of parentheses, a lot of keywords, precedence rules, perhaps even "structure by indentation" so that the amount of whitespace becomes part of the syntax.

You directly write the abstract syntax tree. This has several important advantages that set Lisp apart. For example, instead of writing "2 + 3 * 4", which has to be translated into an abstract syntax tree through the use of precedence rules and the shunting yard algorithm, you write "(+ 2 (* 3 4))", which directly represents the abstract syntax tree.

For example, the ",@" syntax for adding a list as an element of another list.

No, that is not right. ",@" is just a part of the "backquote" syntactic sugar, which is mainly used for macros. Adding a list to another list is done with normal operators like list or append. To elaborate, you might want to define a macro "with-foo" that can be invoked like this:



which will be interpreted as:



This macro can be defined like this, closely resembling the intent through the use of the backquote syntax:



which is much more readable than the more elaborate form:



which, however, works just as well. This is what ",@" is good for, not for generic list manipulation.

Being familiar with many computer languages and how they are implemented I find the decision to include such syntax as part of the language incomprehensible.

I think you just had a bad introduction to the language, or none at all.

Then again, it was groundbreaking in the days when LISP was released -- but that was over fifty years ago. LISP isn't revolutionary anymore, and we've made great strides in understanding since then. The main problem here is that you need to think in terms of LISP and not in terms of the actual problem you're trying to solve. I just don't like doing that.

Au contraire, in Lisp, you usually shape the language to your problem domain and then only think in that.

I don't believe that LISP has a monopoly on good thinking, as fine a language as it really is.

Who said that Lisp had such a monopoly?

I think the best introduction to Lisp for programmers is "Practical Common Lisp" by Peter Seibel. It is freely available on the net. Go read it.

Harleqin wrote:

usagi wrote:

Mike Novack wrote:Lots of [b]Irritating Silly Parentheses (sorry, that's a LISP joke)

That's partly why I tend to avoid LISP (after doing a great deal of research into the language).

I do not think that your research can have been very thorough after reading what you wrote in the following. You have never written anything serious in Lisp. Also, it is spelt "Lisp" nowadays.

Thanks for the well-thought out response. I'm a computer guy, and understand the desire to code properly, so I'll listen carefully to what you have to say here and now.

Anyways, yes, you're right I've never written anything serious in Lisp. Who has? They don't have a compiler. Well, that isn't actually true, but no one has the libraries. Imagine "ls" written in lisp. How big is the binary? 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. 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?

Harleqin wrote:

I have learned to think in terms of breaking up the idea itself, and translating that directly into code. So I have tended to avoid langauges which have a large amount of esoteric syntax. LISP in particular contains a large amount of such.

No, it does not. In fact, it has almost no syntax at all. In other languages, you have three or four kinds of parentheses, a lot of keywords, precedence rules, perhaps even "structure by indentation" so that the amount of whitespace becomes part of the syntax.

You directly write the abstract syntax tree. This has several important advantages that set Lisp apart. For example, instead of writing "2 + 3 * 4", which has to be translated into an abstract syntax tree through the use of precedence rules and the shunting yard algorithm, you write "(+ 2 (* 3 4))", which directly represents the abstract syntax tree.

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. But that isn't as important as it was 50 years ago. Computers are much, much faster now and the general consensus is that making it easier to understand code is a better way to do things -- in general. There will always be specialist applications. There will always be reverse polish notation, for example -- because it's useful. But it will remain a kind of small, specialist knowledge forever. But I don't think beginners should be introduced to such as a first language, that would be wrong.

Harleqin wrote:

For example, the ",@" syntax for adding a list as an element of another list.

No, that is not right. ",@" is just a part of the "backquote" syntactic sugar, which is mainly used for macros. Adding a list to another list is done with normal operators like list or append. To elaborate, you might want to define a macro "with-foo" that can be invoked like this:

Code: Select all

(with-foo 3
  (do-something))

which will be interpreted as:

Code: Select all

(let ((foo 3))
  (do-something))

This macro can be defined like this, closely resembling the intent through the use of the backquote syntax:

Code: Select all

(defmacro with-foo (value &body body)
  `(let ((foo ,value))
     ,@body))

which is much more readable than the more elaborate form:

Code: Select all

(defmacro with-foo (value &rest body)
  (append
    (list (quote let)
          (list
            (list (quote foo) value)))
    body))

which, however, works just as well. This is what ",@" is good for, not for generic list manipulation.

Again I find the examples very difficult to follow. It's something of a maxim that the smaller the syntax the more difficult it is to understand -- just look at perl. But with Lisp it seems that the longer the syntax the more difficult it is to understand, and I think that is very odd. I almost want to say that it is because really the nested parentheses cause everything to be one expression and not multiple lines like how you've formatted it. Really and in truth, your program is this:


and that is simply incomprehensible to a beginner (even to me). 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. I mean, look at the above Lisp. No wonder they invented syntactic sugar. But when do you stop? Why don't you just write
and be DONE with it all? Finally and forever?

I guess it's part of the Lisp way of doing things, that somewhat makes sense, but could be improved upon in a language for beginners. Beginners don't need to learn assembly language anymore.

Harleqin wrote:

Being familiar with many computer languages and how they are implemented I find the decision to include such syntax as part of the language incomprehensible.

I think you just had a bad introduction to the language, or none at all.

That may be true, but including hardware kludges in software is an abomination, and Lisp shows it's age well with it's irregular syntax. Lisp's syntax was really designed to aid computer understanding and required "thinking in Lisp". In a funny sort of way, this made sense at the time (think, what were computers like in the late 50s), and enabled people to understand computers better. So I do understand the charm -- I programmed in assembly language for a long time. You know, back in the day. But each time I look at Lisp I have to ask myself, do I really want to learn all of that syntax? For what purpose? What does Lisp have to offer that any other modern language -- any at all -- does not? And I keep coming back with "Lisp is esoteric, and limited".

Harleqin wrote:

Then again, it was groundbreaking in the days when LISP was released -- but that was over fifty years ago. LISP isn't revolutionary anymore, and we've made great strides in understanding since then. The main problem here is that you need to think in terms of LISP and not in terms of the actual problem you're trying to solve. I just don't like doing that.

Au contraire, in Lisp, you usually shape the language to your problem domain and then only think in that.

Yeah I get what you're saying. But you can do that in any language.

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. 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


Makes brilliant sense, in a way, but looks weird and is not good for beginners because it is esoteric.

Many, many, many advances have been made over the years not only in readability but in syntax. What people found is that by making a language easier to understand to beginners, it actually became more robust and this turned out not only better programmers but better programs, in the long run. People began to understand that the point wasn't how elegant a language was -- at least, that was not the only concern. The point was how quickly you could wrap your head around the language and then code anything in it without having to think about the language anymore.

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.

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.

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.

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.

Harleqin wrote:

I don't believe that LISP has a monopoly on good thinking, as fine a language as it really is.

Who said that Lisp had such a monopoly?

I think the best introduction to Lisp for programmers is "Practical Common Lisp" by Peter Seibel. It is freely available on the net. Go read it.

Maybe no one said it. 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. As such I believe it is a poor introduction to programming. I'd never recommend it to a beginner. Again I think it is fine for specialist applications and I even think it should be learned by computer science students, maybe during a masters program.

And, please let me qualify what I've said. Compiler technology today, is frighteningly orders of magnitude more better than it was 10 years ago, the same could be said 10 years ago, of 20 years ago. Nowadays there is no reason at all to choose any particular language for it's machine readability (for it's syntax). Even C compilers can produce better assembly language than most assembly language programmers -- a fact that got me to finally stop programming in assembly language, and that was a long time ago. 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. 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.

Let's say we are going to design a brand new computer language that will solve all of the world's software engineering problems.

There you have it, nagano. real men create their own language and use that .