Slashdot Mirror

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

It's no surprise that he feels future languages 'will be list-based' and 'arrays will be obsolete'.

He wrote another article in 2001 which declared Java a 'bad technology,' and not because he knew Java or had ever used it, but because his 'Hacker's radar' detected it.

Believe it or not, but there is a reason why Lisp users are more often also Lisp lovers than Java users are Java lovers: Lisp has very few primitives, and very many high-level tools built upon it. While you have a productive toolset from the beginning, you are always able ot change everything if it doesn't happen to fit your problem exactly, using the more basic tools.

For example, Lisp object systems are implemented in Lisp itself. Take that together with Lisps ability to redefine programs at runtime, you get something way more powerful that Java's object system. If you don't like an object system, change it until you do, or write your own. Everything in the language not only makes this approach of programming by language-tweaking possible, but encourages it - don't like the default way multiple inheritance is done in CLOS, the standard Lisp object system? Use the meta-object protocol to implement a metaclass that implements your weirdo inheritance rules.

Conventional languages like Java don't allow you to do this, instead they force you to think the way it's invetors wanted you to (which is not neccessarily the way they like to think themselves, as in the case of COBOL or Java). Lisp is not a single language - it is a toolkit to easily build a language that is perfect for your task.

Sure. A couple of good options are Lispworks and VisualWorks

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

The symbolics Lisp Machine user interface was based around this. For an impression of it looked like and worked, look at this movie. CLIM is available for the two major commercial Lisp implementations from Franz, Inc. and Xanalys; there is also a free implementation in the works. Here are some relevant links.

Well, I stayed a big Common Lisp* fan - one idea I've been toying with (i.e. I'll probably never actually do it and even if I started I'd probably never finish) is an APL-syntax parser for Common Lisp arrays, so one could write (apl-eval "...") and have it transform the APL in "..." into CL functions operating on arrays. And with CL, one could easily implement even the fancy stuff like function composition.

Would be quite cool, because one could then mix Maxima symbolic math stuff, APL numeric math stuff and Lisp... stuff... in the one program.

There's a paper which shows that a good CL compiler can be competitive with a fortran compiler for numerical processing.

* Beware that Scheme is rather different in many ways to Common Lisp - if you've investigated Scheme but decided it wasn't for you, but haven't investigated Common Lisp, then I suggest having a look at it.

Some posts further down recommend interpreted languages like Python and LISP (jeez!) for such applications. They must be joking.

Lisp is not an "interpreted language" (if there even is such a thing as a *language* which needs to be interpreted). In fact, most open-source Lisp systems, as well as all commerical Lisps are compiled into native code.

I find it hard to believe that many people seem to think that after 40+ years of existence, Lisp is still interpreted, as if Lisp users, developers, and researchers were incapable of doing any better.

Franz has some case studies of high-end solutions with CL.

more info can be found at XANALYS Lisp Works, which includes this comment:

"Advanced numeric types. The Common Lisp arithmetic package includes unlimited size integers, fractions, complex numbers, and a complete floating point library. Conversion between numeric types occurs automatically."

mp