3 ms·

> This is to say: the language let's you express things in the exact fidelity that you think them. That's why it's so appealing. Different people think differe

> This is to say: the language let's you express things in the exact fidelity that you think them. That's why it's so appealing. Different people think differently. Having to decipher someone else's thoughts is less appealing that expressing your own. Some people are great thinkers, and their thoughts-made-code are elegant. But there is no guarantee that your colleague who started a project that you join three months later is one of them.

Zambyte 3y ago
People do think differently, so they should be allowed to. The problem of deciphering your colleagues thoughts should be solved by abstractions and modules. The goal of programming on Lisp is to define a new vocabulary to further build on. If you don't like the vocabulary defined by your colleague, you can easily use (or define) a different one at the same level of abstraction.
- kazinator 3y ago
  Programming in anything builds a new vocabulary. In Lisp, most of your vocabulary should be ordinary entities like functions, classes and methods. Not macros. It's not a goal of any reasonable Lisp developer to write as many macros as possible. What macros are written don't have to be earth shattering new languages; it's okay to just make some syntactic sugar needed only in one file and whatnot. I wrote an accounting system for my self-employed business activities. In the entire codebase, there is one macro: time.tl:43:(defmacro def-date-var (name . date-range-val-triplets) def-date-var defines a global variable whose value depends on the date. Not the current date, but the date established by context of a financial calculation. E.g. if we are adding a new transaction across the ledger, which represents an invoice to a customer, the code doing that would install the transaction's date as the date variable. Then all the date vars referenced will take on the value from that date. This is useful for things like tax rates and whatnot. Everything else in the program was done without custom macros. Of course macros from the programming language are used; you can't do anything without them. I could have made a mini language for, say, defining an invoice. But nope, it's just normal syntax for constructing a new object. You should almost never write a Lisp macro to do something a function can do. This is a FAQ for Common Lisp: https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/faq-doc-4.html https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/f... - Never use a macro instead of a function for efficiency reasons. Declaim the function as inline -- for example, (DECLAIM (INLINE ..)) This is *not* a magic bullet -- be forewarned that inline expansions can often increase the code size dramatically. INLINE should be used only for short functions where the tradeoff is likely to be worthwhile: inner loops, types that the compiler might do something smart with, and so on. [...] - Don't define a macro where a function definition will work just as well -- remember, you can FUNCALL or MAPCAR a function but not a macro.
  - robocat 3y ago
    The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. From: https://paulgraham.com/avg.html https://paulgraham.com/avg.html

Zambyte 3y ago

People do think differently, so they should be allowed to. The problem of deciphering your colleagues thoughts should be solved by abstractions and modules. The goal of programming on Lisp is to define a new vocabulary to further build on. If you don't like the vocabulary defined by your colleague, you can easily use (or define) a different one at the same level of abstraction.

kazinator 3y ago
Programming in anything builds a new vocabulary. In Lisp, most of your vocabulary should be ordinary entities like functions, classes and methods. Not macros. It's not a goal of any reasonable Lisp developer to write as many macros as possible. What macros are written don't have to be earth shattering new languages; it's okay to just make some syntactic sugar needed only in one file and whatnot. I wrote an accounting system for my self-employed business activities. In the entire codebase, there is one macro: time.tl:43:(defmacro def-date-var (name . date-range-val-triplets) def-date-var defines a global variable whose value depends on the date. Not the current date, but the date established by context of a financial calculation. E.g. if we are adding a new transaction across the ledger, which represents an invoice to a customer, the code doing that would install the transaction's date as the date variable. Then all the date vars referenced will take on the value from that date. This is useful for things like tax rates and whatnot. Everything else in the program was done without custom macros. Of course macros from the programming language are used; you can't do anything without them. I could have made a mini language for, say, defining an invoice. But nope, it's just normal syntax for constructing a new object. You should almost never write a Lisp macro to do something a function can do. This is a FAQ for Common Lisp: https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/faq-doc-4.html https://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part1/f... - Never use a macro instead of a function for efficiency reasons. Declaim the function as inline -- for example, (DECLAIM (INLINE ..)) This is *not* a magic bullet -- be forewarned that inline expansions can often increase the code size dramatically. INLINE should be used only for short functions where the tradeoff is likely to be worthwhile: inner loops, types that the compiler might do something smart with, and so on. [...] - Don't define a macro where a function definition will work just as well -- remember, you can FUNCALL or MAPCAR a function but not a macro.
- robocat 3y ago
  The source code of the Viaweb editor was probably about 20-25% macros. Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. So every macro in that code is there because it has to be. What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. From: https://paulgraham.com/avg.html https://paulgraham.com/avg.html