4 ms·

A programmer complains that different programmers have different styles of programming in Scala ... and ... switches to a lisp. You know, languages that execut

by waps 12y ago

A programmer complains that different programmers have different styles of programming in Scala ... and ... switches to a lisp. You know, languages that execute code by rewriting the syntax tree of the running program ... This ought to be good. This is not meant to be disparaging against LISPs. I'm just alluding to the fact that while there are 5-10 ways to do the same thing in Scala, all looking very different, working subtly different, there's 5000 different ways to do the same thing in LISPs.

lostcolony 12y ago
Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity. Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between. It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.
- pekk 12y ago
  If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?
  - sls 12y ago
    Rarely isn't never. I'd join in the recommendation above to read pg's "On Lisp" to get a sense of the sort of things one can accomplish with a few small macros. But just as a sampler, if your language has a preprocessor phase where source code is manipulated by source code you provide, you can add control structures. Maybe your language has a loop construct but no way to iterate through a collection without explicit indices. You can add that, and it will be a first-class control structure that gets to control evaluation and everything. You do not have to file a feature request and drum up support and wait five years to get it.
  - lostcolony 12y ago
    To give an analogy (not a great one, but a reasonable one), think of reflection on the JVM. Is it something to use all the time (even if it was fast)? No. Is it incredibly powerful and incredibly useful for certain classes of problems? Yes. Is it a strong advantage for languages with reflection vs those that have nothing comparable? Yes.
- deleted 12y ago
  [deleted]
- lispm 12y ago
  > Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. Not really. This best practice is for beginners and mid-level programmers. They either write macros for the wrong purpose or in problematic ways. Thus they should avoid macros. Still they need to use macros, since languages like Common Lisp provide a lot of functionality through macros. To get past that stage a book like 'On Lisp' by Paul Graham helps. Many, but not all, advanced programmers will use and write a lot of macros.
  - nickik 12y ago
    Thats just not true in clojure. Good librarys in clojure have a data interface, function to produce that data and maybe a thin macro layer to make it a little more easy to use. While 'On Lisp' is a cool book, I rarly find the really advanced macro stuff usful. Once in awhile, you want to have something like a really good pattern matching compiler, and then your macros come in handy. But day to day, you dont need them much.
    - lispm 12y ago
      Let's look at some Common Lisp example: https://github.com/Wukix/LambdaLite/blob/master/lambdalite.lisp https://github.com/Wukix/LambdaLite/blob/master/lambdalite.l... This is a recent tiny in-core database. The code is using LOTS of macros. It also implements a few non-trivial macros. Half of the code is implemented as macros. Code like that is not unusual in Lisp.
    - deleted 12y ago
      [deleted]
  - lostcolony 12y ago
    Sure, if your code is only going to be touched by LISP experts, and/or has a sufficiently strong separation from that being touched by the novices/intermediates (i.e., like a library), macro away. There's a reason I qualified it with "generally" and "rarely".
- imanaccount247 12y ago
  >attempting to appeal to pure functional programmers in their academic ivory towers That's not where we live.
one-more-minute 12y ago
This may not be true for all Lisps, but the Clojure community has developed a very specific idea of what's idiomatic in the language and what isn't. The right way to do something is always the simplest, and there's almost always a single, obvious, simple approach to the problem. IMO, YMMV etc. of course.
deleted 12y ago
[deleted]
nickik 12y ago
I would suggest to you that Clojure has a very clear "the Clojure Way" I would say, more so then almost any other language. It goes beyond syntax to a pretty deep design level. Its not even all that unique to clojure, you could do 'the clojure way' in other languages, but they usally dont. Some of the importent keynotes from some of the early conjs are really importent, and they really went deep in the community, you can see it in almost every major library. Another commenter has mentioned the notion of 'simple' but thats not really all that clear. I not enougth of a writer to tell you about it, but I can give you the resources: - This classic got Clojure on the map for many people: Are We There Yet? - Rich Hickey www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey - Simple Made Easy - Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012 http://www.infoq.com/presentations/Simple-Made-Easy-QCon-Lon... - Simplicity Ain't Easy - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4 https://www.youtube.com/watch?v=cidchWg74Y4 - Ousterhout's Dichotomy Isn't (Part 2 of the Simplicity/Power/Focus Series) - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4 https://www.youtube.com/watch?v=cidchWg74Y4 - The Language of the System - Rich Hickey https://www.youtube.com/watch?v=ROor6_NGIWU https://www.youtube.com/watch?v=ROor6_NGIWU - Hammock Driven Development - Rich Hickey https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc In addition to these, there are many talk that are about people trying to run with these ideas. Datomic is a example of taking these ideas to the max, it really standas as a nice example. You can find others in talks by David Nolan for example, but there are tons of applied talks. - The Design of Datomic - Rich Hickey http://www.infoq.com/presentations/The-Design-of-Datomic http://www.infoq.com/presentations/The-Design-of-Datomic
Sean-Der 12y ago
Macros in good code bases are incredibly useful to abstract things away. Usually achieving things that functions can't. When working in large code bases with languages that don't have macros I find myself seeing people trying to accomplish the same task, but in subtly different ways. These are cases where a helper function usually would not reduce the LOC or complexity. As with everything, macros can be bad, but I wouldn't be so quick to ban them outright.
Morgawr 12y ago
The main difference is that no matter how much you re-write the syntax tree, you'll still be parsing S-Expressions, and those are as unambiguous as it gets. Keep a language simple, that's how I like it at least. It's not about how many ways are there to write X, it's more about how many times can I write the same X and have it do different things? (aka ambiguity) The answer in Lisp is exactly one: S-Exp, obviously there are exceptions like delayed evaluation, re-binding of symbols (not really recommended, at least in Clojure) and argument parsing in macros, but those are exactly that, exceptions. Take operator overloading in many programming languages or method overriding as a comparison, way too much ambiguity.
- waps 12y ago
  In LISP, I would argue that the syntax is defined only partially by the concept of S-Expressions, but by the number of different kinds of atoms that can occur as the first atom in a free S-Expression. Well, all functions only define a single syntax form, but all macros define a new syntax form that should be counted separately. Because of how LISP is structured, it is extremely tempting to have dozens of them for any reasonably-sized program. In practice, in all LISPs, this number of syntax forms is quite high. In clojure it's somewhat less, but still a lot more than in "average" programming languages.
  - lispm 12y ago
    That's right. S-expressions are a syntax for data. s-expressions are not the syntax of Lisp. Lisp syntax is defined on top of s-expressions. In Common Lisp there are basically four forms of syntax: * data * function calls * special forms, basic building blocks of the language. There are only a fixed number and actually very few of them. * macro forms. Many provided by the language and user extensible. The user can write new macros or extend some existing macros. The main differences between many languages and Lisp: the syntax is extensible via macros and most of the time it is relatively simple to see the implementation and the expansion of a macro. Larger Lisp systems can contain hundreds of macros or even thousands of them...

by waps 12y ago

lostcolony 12y ago

Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. And Clojure seems to have developed idioms around simplicity. Scala, on the other hand, has wildly diverging sets of best practices. The feature set is huge, attempting to appeal to pure functional programmers in their academic ivory towers, and the grizzled Java developers who believe OOP is the one true way, and everyone in between. It's easy to -say- that there are 5000 ways to do the same thing in a LISP, and only 5-10 ways to do the same thing in Scala (both statements being hyperbolic, presumably; there are infinitely many ways of doing each, after all), the meaningful variations you are likely to see in the wild are far, far lower in Clojure than Scala. And will likely be based on different understandings/expressions of the problem, rather than on different language subsets that the author prefers.

pekk 12y ago
If macros are agreed by all Lisp users to be a "use rarely" thing, then why is internet Lisp advocacy so strongly focused on macros as an advantage of Lisp over the rest of the world?
- sls 12y ago
  Rarely isn't never. I'd join in the recommendation above to read pg's "On Lisp" to get a sense of the sort of things one can accomplish with a few small macros. But just as a sampler, if your language has a preprocessor phase where source code is manipulated by source code you provide, you can add control structures. Maybe your language has a loop construct but no way to iterate through a collection without explicit indices. You can add that, and it will be a first-class control structure that gets to control evaluation and everything. You do not have to file a feature request and drum up support and wait five years to get it.
- lostcolony 12y ago
  To give an analogy (not a great one, but a reasonable one), think of reflection on the JVM. Is it something to use all the time (even if it was fast)? No. Is it incredibly powerful and incredibly useful for certain classes of problems? Yes. Is it a strong advantage for languages with reflection vs those that have nothing comparable? Yes.
deleted 12y ago
[deleted]
lispm 12y ago
> Every list of best practices, for every LISP, agrees that macro use is generally a "use rarely" thing. Not really. This best practice is for beginners and mid-level programmers. They either write macros for the wrong purpose or in problematic ways. Thus they should avoid macros. Still they need to use macros, since languages like Common Lisp provide a lot of functionality through macros. To get past that stage a book like 'On Lisp' by Paul Graham helps. Many, but not all, advanced programmers will use and write a lot of macros.
- nickik 12y ago
  Thats just not true in clojure. Good librarys in clojure have a data interface, function to produce that data and maybe a thin macro layer to make it a little more easy to use. While 'On Lisp' is a cool book, I rarly find the really advanced macro stuff usful. Once in awhile, you want to have something like a really good pattern matching compiler, and then your macros come in handy. But day to day, you dont need them much.
  - lispm 12y ago
    Let's look at some Common Lisp example: https://github.com/Wukix/LambdaLite/blob/master/lambdalite.lisp https://github.com/Wukix/LambdaLite/blob/master/lambdalite.l... This is a recent tiny in-core database. The code is using LOTS of macros. It also implements a few non-trivial macros. Half of the code is implemented as macros. Code like that is not unusual in Lisp.
  - deleted 12y ago
    [deleted]
- lostcolony 12y ago
  Sure, if your code is only going to be touched by LISP experts, and/or has a sufficiently strong separation from that being touched by the novices/intermediates (i.e., like a library), macro away. There's a reason I qualified it with "generally" and "rarely".
imanaccount247 12y ago
>attempting to appeal to pure functional programmers in their academic ivory towers That's not where we live.

one-more-minute 12y ago

This may not be true for all Lisps, but the Clojure community has developed a very specific idea of what's idiomatic in the language and what isn't. The right way to do something is always the simplest, and there's almost always a single, obvious, simple approach to the problem. IMO, YMMV etc. of course.

deleted 12y ago

[deleted]

nickik 12y ago

I would suggest to you that Clojure has a very clear "the Clojure Way" I would say, more so then almost any other language. It goes beyond syntax to a pretty deep design level. Its not even all that unique to clojure, you could do 'the clojure way' in other languages, but they usally dont. Some of the importent keynotes from some of the early conjs are really importent, and they really went deep in the community, you can see it in almost every major library. Another commenter has mentioned the notion of 'simple' but thats not really all that clear. I not enougth of a writer to tell you about it, but I can give you the resources: - This classic got Clojure on the map for many people: Are We There Yet? - Rich Hickey www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey - Simple Made Easy - Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012 http://www.infoq.com/presentations/Simple-Made-Easy-QCon-Lon... - Simplicity Ain't Easy - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4 https://www.youtube.com/watch?v=cidchWg74Y4 - Ousterhout's Dichotomy Isn't (Part 2 of the Simplicity/Power/Focus Series) - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4 https://www.youtube.com/watch?v=cidchWg74Y4 - The Language of the System - Rich Hickey https://www.youtube.com/watch?v=ROor6_NGIWU https://www.youtube.com/watch?v=ROor6_NGIWU - Hammock Driven Development - Rich Hickey https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc In addition to these, there are many talk that are about people trying to run with these ideas. Datomic is a example of taking these ideas to the max, it really standas as a nice example. You can find others in talks by David Nolan for example, but there are tons of applied talks. - The Design of Datomic - Rich Hickey http://www.infoq.com/presentations/The-Design-of-Datomic http://www.infoq.com/presentations/The-Design-of-Datomic

Sean-Der 12y ago

Macros in good code bases are incredibly useful to abstract things away. Usually achieving things that functions can't. When working in large code bases with languages that don't have macros I find myself seeing people trying to accomplish the same task, but in subtly different ways. These are cases where a helper function usually would not reduce the LOC or complexity. As with everything, macros can be bad, but I wouldn't be so quick to ban them outright.

Morgawr 12y ago

The main difference is that no matter how much you re-write the syntax tree, you'll still be parsing S-Expressions, and those are as unambiguous as it gets. Keep a language simple, that's how I like it at least. It's not about how many ways are there to write X, it's more about how many times can I write the same X and have it do different things? (aka ambiguity) The answer in Lisp is exactly one: S-Exp, obviously there are exceptions like delayed evaluation, re-binding of symbols (not really recommended, at least in Clojure) and argument parsing in macros, but those are exactly that, exceptions. Take operator overloading in many programming languages or method overriding as a comparison, way too much ambiguity.

waps 12y ago
In LISP, I would argue that the syntax is defined only partially by the concept of S-Expressions, but by the number of different kinds of atoms that can occur as the first atom in a free S-Expression. Well, all functions only define a single syntax form, but all macros define a new syntax form that should be counted separately. Because of how LISP is structured, it is extremely tempting to have dozens of them for any reasonably-sized program. In practice, in all LISPs, this number of syntax forms is quite high. In clojure it's somewhat less, but still a lot more than in "average" programming languages.
- lispm 12y ago
  That's right. S-expressions are a syntax for data. s-expressions are not the syntax of Lisp. Lisp syntax is defined on top of s-expressions. In Common Lisp there are basically four forms of syntax: * data * function calls * special forms, basic building blocks of the language. There are only a fixed number and actually very few of them. * macro forms. Many provided by the language and user extensible. The user can write new macros or extend some existing macros. The main differences between many languages and Lisp: the syntax is extensible via macros and most of the time it is relatively simple to see the implementation and the expansion of a macro. Larger Lisp systems can contain hundreds of macros or even thousands of them...