I'm a Lisper who's also programmed in Scala. (And for the record, I'm not a Lisp purist - in fact, there are a number of things I really like about Scala).
But I'm not sure how I feel about this change. Scala can already implement things like DSLs through creative use of type inference, etc.
> It's nice to use standard list operations in a macro instead of needing to learn AST magic.
The power of Lisp's macros come from it's homoiconicity, which is something I could never have appreciated before learning Lisp - in fact, I didn't even understand its significance until I wrote an implementation of a Lisp compiler for the first time. (For the record, it was a better learning experience than it was a compiler, but that was the whole point).
The best explanation I've seen of homoiconic macros is one written by a well-known Perl programmer. http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h...
(In a way, it makes sense that a Perl programmer would be the best at explaining what homoiconicity is, given that its extreme heteroiconicity is the underlying cause of many of the common criticisms of Perl to begin with).
That email is mostly accurate, and it includes this gem:
> Source code generation is unreliable and inadvisable in every language except Lisp.
This is where macros really shine. Macros allow you to generate source code reliably - or put another way, they let you refactor your code far more than you ever thought possible. (When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community![1])
But here's the catch - for the kind of reliability that MJD talks about, you need to have the internal representation of the language be a fundamental data structure in the language, not just the textual representation.
Why's that? It's simple:
> It's nice to use standard list operations in a macro instead of needing to learn AST magic.
In Lisp, the internal representation is a list. The AST is a list. There's no 'instead of' here... macros are simply AST magic made simple....!
But I'm not sure how I feel about this change.
Scala can already implement things like DSLs through
creative use of type inference, etc.
The way I see it:
(-) there are some god-awful DSLs available for Scala ; the presence of a macros system would allow the reuse of syntax instead of coming up with operators that look like random noise
(-) LINQ becomes possible - I don't know how many people here used LINQ, but it's really awesome to express a query in terms of filter, map and flatMap, and depending on the underlying collection to issue a database query or to submit some code to the GPU for processing.
And LINQ is an instance where static typing really shines.
When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community!
I think Lisp's success in early AI work had as much to do with its support for higher order functions, repl, dynamic dispatch etc as it did with the macro facilities. Lisp was way ahead in those respects.
But you don't see nearly as much use of Lisp in AI now that many other languages have learned all of Lisp's tricks except homoiconicity and that a lot of "AI" in the field these days is really statistics and linear algebra.
I very much agree with you. Even in Genetic programming, any language that has Algebraic Types and parser combinators gets only a very small additive constant with respect to lisp.
But if you want the best model for the GP language so that it can easily self modify, you will recreate a lisp (at least such was my case) because it looks like Lisp is the homoiconic language and is complete in the mathematical sense (how the reals are complete). If you look at stuff like decision trees, random forests and genetic programming; while implementation language doesn't matter, for execution they really come into their own in a language like lisp.
This has led me to believe that lisp is so far ahead of its time that it is not the language of humans but instead the natural tongue of AIs built on Turing machines.
When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community!
I don't know what counts as "AI" anymore but in the Machine Learning community, it looks like Matlab, R, Python and Java dominate in terms of use and cutting edge packages. This is due to two things: modern ML does not focus on areas where Lisp gives a clear advantage and 2) what everyone else is using and reduced learning overhead are most important in determining favorites.
I'm a Lisper who's also programmed in Scala. (And for the record, I'm not a Lisp purist - in fact, there are a number of things I really like about Scala).
But I'm not sure how I feel about this change. Scala can already implement things like DSLs through creative use of type inference, etc.
> It's nice to use standard list operations in a macro instead of needing to learn AST magic.
The power of Lisp's macros come from it's homoiconicity, which is something I could never have appreciated before learning Lisp - in fact, I didn't even understand its significance until I wrote an implementation of a Lisp compiler for the first time. (For the record, it was a better learning experience than it was a compiler, but that was the whole point).
The best explanation I've seen of homoiconic macros is one written by a well-known Perl programmer. http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... (In a way, it makes sense that a Perl programmer would be the best at explaining what homoiconicity is, given that its extreme heteroiconicity is the underlying cause of many of the common criticisms of Perl to begin with).
That email is mostly accurate, and it includes this gem:
> Source code generation is unreliable and inadvisable in every language except Lisp.
This is where macros really shine. Macros allow you to generate source code reliably - or put another way, they let you refactor your code far more than you ever thought possible. (When you realize how easy it is to write Lisp programs that recursively define other valid Lisp programs, it's not hard to see why it's such a favorite of the AI community![1])
But here's the catch - for the kind of reliability that MJD talks about, you need to have the internal representation of the language be a fundamental data structure in the language, not just the textual representation.
Why's that? It's simple:
> It's nice to use standard list operations in a macro instead of needing to learn AST magic.
In Lisp, the internal representation is a list. The AST is a list. There's no 'instead of' here... macros are simply AST magic made simple....!
[1] http://en.wikipedia.org/wiki/Technological_singularity