2 ms·

> Now, LISP does have the advantage of being easy to reason about (since the program is also data) Is this true? Could you (or someone else) elaborate? I would

> Now, LISP does have the advantage of being easy to reason about (since the program is also data) Is this true? Could you (or someone else) elaborate? I would assume that an editor trying to reason about Ruby or Python code would parse the source code into an abstract syntax tree, and that would be just as easy (or hard) to reason about as Lisp, since those languages are all dynamically typed. However, I'm pretty ignorant of how tools like Eclipse reason about Java code, so this is all just guessing.

sjs 16y ago
I guess it's easier to parse, but however NetBeans does it they have pretty decent Ruby support so I don't know if it's really that big of a disadvantage. Seems like you'd want a handful of really good, comprehensive parsers for any language and people would just use those rather than rolling a new one each time.
PaulHoule 16y ago
Well, the advantage of a language like Java or C# is that the IDE knows the types of objects, so, for instance, it can autocomplete method and property names. Because introspection is used rarely in static languages, IDEs can do automated refactoring operations and KNOW that they found all the (non-introspection) references that are affected. It's certainly possible to parse PHP, Python or Ruby into an abstract syntax tree (OK, Perl is a little harder) but practically very few people do metaprogramming at that level, even when it's officially supported. (C# and VB have had "expression trees" for a few years now and they're barely used.) Part of the appeal of LISP is that you can pretend Noam Chomsky was never born and never need to learn how to write parsers or deal with the data structures that they spit out. Any kind of extreme metaprogramming is going to defeat 'reasoning-in-code'. For instance, in LISP I can easily implement a new kind of control structure... Because 'understanding' a program in general (rather than running it) is an undecidable problem, it's clear that an IDE will ultimately get bogged down. I've written a lot of PHP lately in a metaprogramming-heavy framework that uses magic methods to 'create' new properties and methods. The way this is done is systematic, and an IDE could probably be loaded with rules that would help it 'understand' this usage, but so far as I do this kind of code analysis, it's going to be in command-line tools that are cheap to develop compared to GUI tools.
- spacemanaki 16y ago
  Hmm, I guess I was confused about what you meant when you said "LISP does have the advantage of being easy to reason about" I thought you meant easy for an IDE to reason about to support the kind of auto-complete Intellisense that Eclipse and VS offer.

sjs 16y ago

I guess it's easier to parse, but however NetBeans does it they have pretty decent Ruby support so I don't know if it's really that big of a disadvantage. Seems like you'd want a handful of really good, comprehensive parsers for any language and people would just use those rather than rolling a new one each time.

PaulHoule 16y ago

Well, the advantage of a language like Java or C# is that the IDE knows the types of objects, so, for instance, it can autocomplete method and property names. Because introspection is used rarely in static languages, IDEs can do automated refactoring operations and KNOW that they found all the (non-introspection) references that are affected. It's certainly possible to parse PHP, Python or Ruby into an abstract syntax tree (OK, Perl is a little harder) but practically very few people do metaprogramming at that level, even when it's officially supported. (C# and VB have had "expression trees" for a few years now and they're barely used.) Part of the appeal of LISP is that you can pretend Noam Chomsky was never born and never need to learn how to write parsers or deal with the data structures that they spit out. Any kind of extreme metaprogramming is going to defeat 'reasoning-in-code'. For instance, in LISP I can easily implement a new kind of control structure... Because 'understanding' a program in general (rather than running it) is an undecidable problem, it's clear that an IDE will ultimately get bogged down. I've written a lot of PHP lately in a metaprogramming-heavy framework that uses magic methods to 'create' new properties and methods. The way this is done is systematic, and an IDE could probably be loaded with rules that would help it 'understand' this usage, but so far as I do this kind of code analysis, it's going to be in command-line tools that are cheap to develop compared to GUI tools.

spacemanaki 16y ago
Hmm, I guess I was confused about what you meant when you said "LISP does have the advantage of being easy to reason about" I thought you meant easy for an IDE to reason about to support the kind of auto-complete Intellisense that Eclipse and VS offer.