Slashdot Mirror

(a) "Lisp". all uppercase "LISP" went out with flares. Sheesh.

(b) How does it compare to Edi Weitz' excellent http://www.weitz.de/hunchentoot/ ?

Well your other post said basically Lisp is for interesting people, all the other who cares about syntax doesn't matter, what do you expect me to answer to this??

Fair enough. I didn't mean to imply anything like that but perhaps I went to far when I mentioned 80s perms. ;-)

Lisp is probably very good for research as it free the researcher from syntax, but for the other 99% of developpers who don't do language research but who maintain existing programs in C, C++ or Java, I doubt that you would convince them that syntax doesn't matter.. That's why the next big programming language may be one of those: D, Scala, Ruby or Python but not Lisp.

Well, I am one of the bulk of those programmers maintaining an existing system. At least, that's what I do for my day job. And I doubt that is likely to change anytime even within the next decade, if I continue to stay with the same company. Our system is simply not going to be rewritten in any new language unless it is the first to introduce something amazing like a DWIM feature. In fact, if you listen to some of the pundits, the next big programming language just might be COBOL. Legacy inertia can often be the immovable object standing in the way of the unresistable force of the Next Big Thing. And I've personally gotten so sick of the YASL family breeding like rabits that I won't bother looking at another one unless it does something significantly different from all of its cousins.

But it seems I am guilty of having thrown another shovel full on the steaming pile of myth that Lisp is only good for research. Practical Common Lisp is full of excellent examples of using Lisp for "normal" problems. My personal favorite exmaple is the way he uses macros to help with the task of parsing ID3 tags in MP3 files. Having had to deal with things like ASN.1 compilers in the past, I immediately fell in love with the way he basically did the same thing as is done with ASN.1 but without ever leaving Lisp.

I currently use Common Lisp (mostly SBCL and sometimes Clisp) everyday for the kinds of tasks for which I would have reached for Perl in the past. An Emacs user, I'm merely a "M-x slime" away from wherever in Lisp I may want to be, including the entire mush of elisp floating out there in the tubes of the internets. CL-PPCRE already gives me in Lisp most of what I might have missed from Perl. Implemented entirely in Common Lisp, it even out performs Perl's regular expression engine for some benchmarks. But what I love about using Lisp for these kinds of "write once" "scripting" tasks is that I have full access to all of Lisp's features if I find it useful. For example, I've been able to use Allegro Prolog for an install script of somewhat limited intelligence. (I'll try posting code after this because I'm having problems with /. formatting rules.)

As for AOP, personnaly I've never liked it (seems like a mess for anything but logging), [...]

Okay, but the point wasn't so much AOP as it was how unnecessary it is introduce a whole new programming language tool to get the same functionality from Lisp. To introduce AOP into Java required mucking about with the core of the Java language. In Lisp, "all" one needs to do is crank out some macros and perhaps a few new meta-objects.

And so much of all of this is made possible by Lisp's macros which are, in turn, so useful because of the very syntax which is what so many people love to hate.

As a complete programming noob looking to get into web-related design and things of that nature, what languages are good to start with and to branch to other languages? Would that be like C-> PHP -> SQL? What other languages apply and/or in what order are languages needed to learn to start to bring things together for well designed websites?

It's amazing I got GTA Vice City to run under Wine but I can't get a simple little dialog-based application to run. It used to run but then a Ubuntu update killed it and now it gives runtime errors about loading the C runtime incorrectly.

I am very impressed by Wine, and this is coming from an old time Linux nerd since 1998, but unfortunately it still has a long ways to go before it will be recommendable to the casual Windows convert. There will always be little caveats like this.

My wife recently switched to Ubuntu after a Windows Update caused her computer to blue screen on boot. She does almost everything in Linux and VMware (two business applications she absolutely can't live without that are windows-only and wouldn't work with wine) but she kept a dual-boot for playing games.

I can't believe no one has mentioned The Regex Coach at http://weitz.de/regex-coach/. While I totally agree with the 11/10 rating for MRE (I have the first and second editions), The Regex Coach is an invaluable prototyping and debugging tool for PCRE (Perl Compatible Regular Expressions). It runs on Windows and Linux and is free (but not open source IIRC).

Both the book and the tool are 100% essential to anyone writing any regex more complicated than /^foo\s(\w+)\sbar$/.

You can try this:
http://weitz.de/cl-ppcre/#parse-tree-synonym

It's in lisp, but lisp is good to learn too.

The Regex Coach - The Regex Coach is a graphical application for Windows and Linux/x86 (also usable on FreeBSD) which can be used to experiment with (Perl-compatible) regular expressions interactively.

The Regulator - The Regulator is an advanced, free regular expressions testing and learning tool written by Roy Osherove. It allows you to build and verify a regular expression against any text input, file or web, and displays matching, splitting or replacement results within an easy to understand, hierarchical tree.

This tool, by the way, was written in Common Lisp, using Edi's own library

CL-PPCRE - portable Perl-compatible regular expressions for Common Lisp

A library which typically outperforms Perl's own regex engine.

I spoke about the "regex coach" tool from http://weitz.de/regex-coach/ on my podcast (shameless plug!) http://webdevradio.com/ - it's a great tool for helping visually walk through the regex creation process, especially for complex needs.

Making Windows Usable for Old Linux Farts

Still shows that making Windows workable is rather hard task.

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

There are quite a few regular expression tools available, with different capabilities and purposes. For the novice who doesn't want to learn more or doesn't have time, the best is probably txt2regex, which walks you through the construction of the regexp and generates output for 20 different programs and languages. It is one of the few tools that I know of that isn't specialized for a particular language or program. My own tool, Redet, provides an interface to 29 regular expression implementations. It is aimed at people who know something about regular expressions or are willing to spend some time learning but helps out by providing palettes showing the notation for each program and a history system, so that you can first construct the pieces of a complex regexp, then assemble them. It also has features aimed at providing a search environment that may be useful for people who need no help constructing their regular expressions.

regex-coach uses PERL-style regular expressions. Its particular virtue is that it can single-step through the match and show the parse tree, so it is useful if you want to understand the matching process in detail. Similar in that it helps to understand the implementation of regular expressions is re_graph, which given a regular expression draws the corresponding finite state automaton.

A couple of nice tools aimed at Python users are Kiki and Kodos.

These and some other tools and libraries are listed on this page.

I found this tool while doing my undergrad. Having this tool and playing with it showed me how to understand and how to sucessfully write regexs. 5 minutes of playing with it and you be enlightened.

http://www.weitz.de/regex-coach/

Regex Coach

This program assists you building regular expressions. I've never used it (real men code regexp at once and it works). But some friends recommend it.

Cliki, a wiki directory of "Links to and resources for free software implemented in Common Lisp and available on Unix-like systems."
CLOCC - the Common Lisp Open Code Collection"
common-lisp.net, providing hosting and remote repositories to dozens of Free Software Common Lisp applications.

This doesn't even touch SourceForge (which hosts another two dozen or so Lisp projects I'm aware of). When you consider how small the Lisp community is compared to the number of Perl hackers (easily in the range of 1000:1), and the number and quality of the code on just those repositories to CPAN, the productivity advantage of Lisp really does seem closer to 50x. According to your argument, all those Perl hackers should not have had any trouble in coming up with an efficient implementation by now. Yet, with less that a dozen regular hackers between them, the CMUCL and SBCL projects have produced compilers that outperform g++. At the very least, the Perl folks should not have had any trouble producing an efficient regular expression library, but here again, Lisp has them beat.

Of course, the above links point to software written in only one dialect of Lisp, Common Lisp. When you consider the software produced in other dialects, like Scheme, NewLisp, LUSH, XLISP, and Isis, the difference becomes even more apparent. To say nothing of commercial software, where none of the languages you mention can even boast a fraction of the number of large, successful systems delivered in Lisp.

Is there anything mainstream, other than emacs (and considering emacs mainstream is a stretch at that), that uses Lisp as the implementation/macro language?

Google can help you. Some stuff is on the server side. As a programmer you certainly know The Regex Coach

It takes me longer to write working Lisp code - primarily because I have to translate how my mind normally thinks in a structured/object oriented way, into a functional realm.

Are you sure you have tried Common Lisp? It's not a functional language. It's a multi-paradigm language. Heck, you can even have a GOTO! :-) And yes, Common Lisp is object oriented.

Any decent language has full PCRE support these days. Perls days as regular expression king are in the past.

You're right. There are other implementations of regular expressions which are faster.

Any decent language has full PCRE support these days. Perls days as regular expression king are in the past.

You're right. There are other implementations of regular expressions which are faster.

But then I discovered The Regex Coach.

My problem with Perl is the ubiquitous use of the regular expressions.

It's true that people writing in Perl tend to use regular expressions in places where they're not necessarily appropriate. For instance, algorithmically speaking, subsequence matches are faster than regular-expression matches. (This is why Python has the .startswith and .endswith string methods, and the in operator.) However, the Perl regular-expression engine (PCRE) is optimized to heck and its raw speed can usually overcome this.

That said, the traditional regular-expression syntax is rather arcane. The only real alternative I've seen is the S-expression syntax of cl-ppcre -- the Common Lisp PCRE implementation. This allows you to write complex regular expressions as tree structure rather than as strings of character glyphs.

For instance, in place of the regex string "(?:foo)|(?:bar)|(?:b(a|(?:uz))z)" you can write:

(:alternation "foo" "bar" (:sequence "b" (:alternation "a" "uz") "z"))

Now, that might not be any clearer to you if you don't know Lisp, but it gets better as the regex gets more complicated. (I've been a little tricky by putting a lot of ?: in the original regex string. That's the code for "I want to do grouping, but I don't want to capture groups into variables." In the Lisp syntax, you have to mark when you do want capture, not when you don't. People writing in Perl usually let their groups get captured even when they don't make any use of the resulting variables.)

Interestingly enough, the authors of cl-ppcre claim that it outperforms Perl -- a remarkable claim, but they seem to have pretty comprehensive statistics as to when it does and when it doesn't. It's odd to think that even though many people think Lisp is slow, compiled Lisp can really be quite speedy for tasks that people usually use a specialized language for.

My problem with Perl is the ubiquitous use of the regular expressions.

It's true that people writing in Perl tend to use regular expressions in places where they're not necessarily appropriate. For instance, algorithmically speaking, subsequence matches are faster than regular-expression matches. (This is why Python has the .startswith and .endswith string methods, and the in operator.) However, the Perl regular-expression engine (PCRE) is optimized to heck and its raw speed can usually overcome this.

That said, the traditional regular-expression syntax is rather arcane. The only real alternative I've seen is the S-expression syntax of cl-ppcre -- the Common Lisp PCRE implementation. This allows you to write complex regular expressions as tree structure rather than as strings of character glyphs.

For instance, in place of the regex string "(?:foo)|(?:bar)|(?:b(a|(?:uz))z)" you can write:

(:alternation "foo" "bar" (:sequence "b" (:alternation "a" "uz") "z"))

Now, that might not be any clearer to you if you don't know Lisp, but it gets better as the regex gets more complicated. (I've been a little tricky by putting a lot of ?: in the original regex string. That's the code for "I want to do grouping, but I don't want to capture groups into variables." In the Lisp syntax, you have to mark when you do want capture, not when you don't. People writing in Perl usually let their groups get captured even when they don't make any use of the resulting variables.)

Interestingly enough, the authors of cl-ppcre claim that it outperforms Perl -- a remarkable claim, but they seem to have pretty comprehensive statistics as to when it does and when it doesn't. It's odd to think that even though many people think Lisp is slow, compiled Lisp can really be quite speedy for tasks that people usually use a specialized language for.

Regex Coach is a great free tool for learning about regular expressions and constructing them interactively. Both Linux and Windows versions are available.