What's that saying? "Every non-trivial program includes a slow, buggy and poorly-written implementation of half of Common Lisp". With the corrolary: "Including Common Lisp". :-P

I need to mess with that stuff more; it's utterly wonderful, but only up to the point when I realize I don't have anything I'd actually want to make in it. Any game engines out there using Lisp?

Lisp is awesome. I've been writing a Lisp interpreter for quite some time now (adding some debugging facilities now) and it's been a great experience. I use my interpreter to create a website which allows me to play around and create a set of web sub languages. The first level of abstraction is of course xhtml so I can do something like this:

(xhtml-header    (body        (p (println "hello world!"))))

It only takes about an hour or two to create a sublanguage that represenets all important xhtml tags.

The next step is creating a more abstract language to represent some commonly used web components. Navigation menu is a candidate, perhaps a news component, etc. Additionally it's necessary to create an infrustructure that will map links to closures and/or continuations so clicking a link would be equivalent to a function call.

Another words, Lisp is great.

Quote:Original post by Icefox
Any game engines out there using Lisp?

Who cares? Few people appreciate the unique set of features that make Lisp a wonderful rapid development language that it is. Use it and have the competitive advantage over thousands of people and companies that didn't think of using it.

Quote:Original post by CoffeeMug

Quote:Original post by Icefox
Any game engines out there using Lisp?

Who cares? Few people appreciate the unique set of features that make Lisp a wonderful rapid development language that it is. Use it and have the competitive advantage over thousands of people and companies that didn't think of using it.

I haven't used common lisp myself, only scheme, for a class about programming languages where we had to write a simple interpreter. I don't know if all lisp dialects are like that, but the scheme variation we used made it for very hacked code, and was quite impractical. It was quick to write the interpreter, but I wouldn't say the result was neat and tidy. Its not something I see anyone writing real-world software with.

The point being. If its not practical for actual development, then you have no advantage at all. That doesn't mean it can't be good for research, or for experimenting around or developing and testing algorithms... But to me, Lisp is not very intuitive. It doesn't feel natural either. And no, its not just because I'm "used" to procedural programming, but because, in nature, humans are used to plan and execute actions step-by-step. Lisp works well for performing actions on lists, but as soon as things get mildly complicated, then you have to think of a way to make it work with the language without extreme complication. It also seems to me that whenever it comes to interfacing with the outside world, there is something lacking from Lisp.

I don't mean to diss Lisp. I'm just saying that there are reasons it hasn't really caught-on in the industry and in actual development while other procedural programming and scripting languages are gaining wide popularity. But by all means... If you think you can make your own 3D engine or operating system in Lisp and make it perform well, go ahead, if you succeeded at that, you could gain great popularity ;)

Quote:Original post by Max_Payne
The point being. If its not practical for actual development, then you have no advantage at all.

But it *is* practical. I'm not sure what exactly you've worked with but Lisp is suitable for very large, complicated systems that would perhaps be too complicated to write in languages like Java or C++. If your code was hacked up perhaps it was because your interpreter wasn't very well designed, or you didn't understand Lisp properly, or your professor didn't know how to explain it well, or any combination of these and others reasons. Real production systems are written in Lisp! Did you know that .NET CLR garbage collection rutines were written in Lisp and then ran through Lisp->C compiler?

Quote:Original post by Max_Payne
But to me, Lisp is not very intuitive. It doesn't feel natural either.

That's because you don't understand it. What do you mean by 'Lisp' anyway? If you don't like something about Lisp it has tremendous facilities to change itself. Don't like something about Lisp? Change it in Lisp itself.

Quote:Original post by Max_Payne
And no, its not just because I'm "used" to procedural programming, but because, in nature, humans are used to plan and execute actions step-by-step.

Lisp is not a functional language! If you don't like using functional paradigm, don't use it. Write procedural code, write OO code, write functional code, combine various approaches, whatever. With Lisp the floor is yours.

Quote:Original post by Max_Payne
It also seems to me that whenever it comes to interfacing with the outside world, there is something lacking from Lisp.

My interpreter is not any harder to extend than Python, for example. Could you be more specific?

Quote:Original post by CoffeeMug
But it *is* practical. I'm not sure what exactly you've worked with but Lisp is suitable for very large, complicated systems that would perhaps be too complicated to write in languages like Java or C++. If your code was hacked up perhaps it was because your interpreter wasn't very well designed, or you didn't understand Lisp properly, or your professor didn't know how to explain it well, or any combination of these and others reasons. Real production systems are written in Lisp! Did you know that .NET CLR garbage collection rutines were written in Lisp and then ran through Lisp->C compiler?

I'm talking about *complete* software products here. Do you have examples of *complete* and nontrivial software products written in Lisp that are available for the x86 platform ? (no, examples of exotic applications nobody has ever heard about don't count).

Quote:That's because you don't understand it. What do you mean by 'Lisp' anyway?

I mean any dialect of Lisp.

Quote:Lisp is not a functional language! If you don't like using functional paradigm, don't use it. Write procedural code, write OO code, write functional code, combine various approaches, whatever. With Lisp the floor is yours.

And what would be the point of using Lisp to "emulate" what procedural languages have been doing very well for decades?

Quote:My interpreter is not any harder to extend than Python, for example. Could you be more specific?

I'm talking about interfacing with the outside world. Writing a driver in Lisp, for example, or working with 3D graphics, or even doing sound processing. All that in an efficient manner. It seems the tools for doing that in Lisp are quite lacking.

Quote:Original post by Max_Payne
I'm talking about *complete* software products here.

Emacs. AutoCAD uses Lisp heavily. Just take a look at this.

Quote:Original post by Max_Payne
no, examples of exotic applications nobody has ever heard about don't count

Why not? People that write 'exotic' applications like telco switches, air traffic control, etc. tend to be really smart. They use Lisp. People that tend to write usual business software and user applications tend to be average. They don't use Lisp. What does that mean, if anything at all?

Quote:Original post by Max_Payne
And what would be the point of using Lisp to "emulate" what procedural languages have been doing very well for decades?

You wouldn't emulate it. You'd use it naturally because it *is* a part of Lisp. The point of using it is because traditional languages (I don't want to say procedural since Lisp is as procedural as any language could be) are not doing it well. I'm at work coding a client for a trading system right now. I start it up. Wait. Log in. Wait. Get to whatever part I am modifying. Play around there. If something doesn't work I close it. Change the code. Repeat. Hundreds of times. With Lisp I get to the point I am interested in. Play around. Change the code. Play around. Change the code. Play around. Nice, no? I can use advanced constructs like continatuions and closures and multimethods without jumping through hoops of various patterns. I can use macros to design domain specific code. I cannot do that in traditional languages. What kind of argument is that anwyay? Why create anything new? What's the point of using Python if traditional languages do it well enough?

Quote:Original post by Max_Payne
Writing a driver in Lisp, for example, or working with 3D graphics, or even doing sound processing.

Lisp is not designed for writing drivers. For that you're better off using C. Other things you mentioned are at least as good as traditional languages. Oh and Lisp is very efficient. Far more efficient than Java or Python.

Quote:Original post by CoffeeMug
Emacs. AutoCAD uses Lisp heavily. Just take a look at this.

From what I see, those products are "using lisp", they were not made completely in lisp, or even primarily in lisp.

Quote:Why not? People that write 'exotic' applications like telco switches, air traffic control, etc. tend to be really smart. They use Lisp. People that tend to write usual business software and user applications tend to be average. They don't use Lisp. What does that mean, if anything at all?

Writing software for a telco switch strikes me as not very complex. Its something someone could easily do in C. Air traffic control is probably a better example of good applications. However, the reason I don't really care about exotic applications is because they don't really show that lisp is a qualified language when it comes to creating applications for the everyday world, that take an important part in everyone's life.

Lisp has been around for quite a while now. Longer than C++ has. Yet its not really catching on when it comes to professional software development. Don't tell me its because people are "resistant to progress" either, or anything of that kind. I constantly see people ranting about the latest and most efficient programming techniques and languages. Languages like Lisp and OCaml have had plenty of times to prove their usefulness, yet they are still only present in a handful of useful applications, and some extremely specialized solutions designed by I-don't-know-who with special constraints in mind.

Quote:Change the code. Repeat. Hundreds of times. With Lisp I get to the point I am interested in. Play around. Change the code. Play around. Change the code. Play around. Nice, no? I can use advanced constructs like continatuions and closures and multimethods without jumping through hoops of various patterns. I can use macros to design domain specific code. I cannot do that in traditional languages. What kind of argument is that anwyay? Why create anything new? What's the point of using Python if traditional languages do it well enough?

I have been using python for some time. My personal experience is that it works O.K. Its main advantage is portability (to some degree). Thats about it. It is more portable than C++ for sure. But other than that, its also much slower, and not as powerful or nicely constructed in some areas. The main thing I like about it is that it has some easy to use libraries. Things are done in a simpler manner. However, this is not really a C++ problem: its a library design problem. Many C and C++ libraries make things much more complex than they really need to be. The reason people like C# is mostly for winforms, because, lets face it, the win32 API is simply backwards.

As for playing around. I can't modify code while its running. At least not with current compilers, because the code is compiled. But from my experience, its easier to debug C++ code than lisp code. Because of its typeless nature, lisp will allow errors to slip many levels deep, and when the problem arises, it can be very hard to track the source, but then, I might be biased, because the DrScheme debugger sucked. But again, my point is not to diss lisp here. My point is that debugging in C++ is not really an issue, nor is recompilation.

Quote:Lisp is not designed for writing drivers. For that you're better off using C. Other things you mentioned are at least as good as traditional languages. Oh and Lisp is very efficient. Far more efficient than Java or Python.

Well, it should be possible to write drivers in lisp. With a flexible language like C++, you can do pretty much anything in a reasonable manner. From game engines to operating systems to server-side scripting for websites.

As for the efficiency... Efficiency in terms of development time, or running time, or something else? If you mean speed... Faster than python? Possible. Python is entirely interpreted. Faster than java? Well... Considering java is JIT compiled, and still quite fast (easily millions of function calls per second on a modern CPU), I'm not sure. Lisp is bound to require more overhead for its special features (functions as first-class objects, for example). Faster than a language like C or C++, I don't think so. C++ is designed to easily map to hardware features, which makes it hard to beat in terms of speed, no matter what kind of fancy runtime optimization that hardly applies to the real world you use.

If you mean efficiency in terms of development time, I would have to see. And someone would have to tell me what makes it faster, really. Because most of the time I spend working on software is spent in designing the program and algorithmic details, not actually sitting and coding. The "You can code faster in this!" argument is of very little value to me.