All the Perl that's Practical to Extract and Report
use Perl Log In
Matts (1087)
(email not shown publicly)
I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.
Lisp
I think I've got the concept from what I've read so far of Paul Graham's "On Lisp".
Basically what lisp allows you to do is modify the language to suit your program, while building your program around that new framework. So for example, imagine you need constructs specifically for numeric processing - you can build them into the core language's syntax. This is like writing functions, but on steroids.
This sounds ideal for hacker types, and for proficient lispers. The problem with it is the same as if I came to work on some code someone had written using lots of new Perl syntax (say constructed with source filters). If I had to work on some perl 5 code that contained completely new constructs, I think it would be an awfully steep learning curve (even if it was really quick to develop initially for the developers).
Of course it's very different to perl and source filters, since in lisp, everything looks the same (braces with params). So it's not like you can invent a completely new syntax (or I haven't gotten that far into the book yet).
Still, when all's said and done, I think the syntax has been one of lisp's biggest downfalls. As kids we found basic easy to grasp (ok, we found logo easy to grasp - but we couldn't really build anything serious with it
Anyway, just some random thoughts on my recent readings. Hope you enjoyed them
--Larry Wall in stab.c from the perl source code
Lisp (Score:2, Interesting)
I've been playing with LISP a bit myself as well, I didn't find the syntax much of a problem once I was used to it, although it can sometimes be a right pain nesting things properly when you add something into the middle of an expression. I think with more time using it I'd stop doing that. Also the barrier to thought isn't provided by the syntax, the language itself is different and does require a new way of thinking.
It occured to me while I was toying with LISP that it was the first language I've lear
LISP Macros (Score:3, Interesting)
It's all about bottom-up programming, with the wrinkle that your notation for solving the problem is part of the API. (Imagine what GTK would look like if it wasn't full of varargs hacks...) I'm not sure how I feel about that though; it sounds like it's the origin of the Tcl problem -- dozens of dialects, all slightly different. May work well in the small, but don't know how it can possibly scale in the large. Perhaps Common Lisp is better suited for a CCLAN that contains lots of (reusable, interoperable) macros...don't know yet. I guess we'll find out when Perl6 hits the streets, or there are many more source filters for Perl5.
As to changing Lisp's lack of syntax, I do believe that's possible, depending on the macro system. There was some theory about partial evaluation with Scheme. The general idea was to do some rudimentary translation on some random syntax (Perl, Python, Java) and "compile that down" to Scheme, so all you would really need is a Scheme interpreter. Of course, the theory worked better in theory than in practice. :-)
Reply to This