2 ms·

I spent quite a bit of effort seeking Lisp Enlightenment (TM) because of the happy people using Lisp that you mention[0]. The fact that Lisp is not used more co

I spent quite a bit of effort seeking Lisp Enlightenment (TM) because of the happy people using Lisp that you mention[0]. The fact that Lisp is not used more commonly for practical applications is actually a great source of frustration for me now, and I think I share that experience with many other people who enjoy using Lisp. The thing about Lisp is that when you get used to it, you realize how needlessly obtuse so much of programming is today. So much effort has been spent making programming harder and harder to understand. At this point I truly think that if Lisp had won, the world would be quite a different place for the better. We live in a world where the average person thinks that a terminal emulator is an error window, and coding is something they identify as not being able to do. Lisp is so nice because when you understand the (extremely simple!) grammar, any vocabulary is correct. You just have to make sure that an implementation of that vocabulary is defined in terms of the vocabulary provided by the system. 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. I think that if Lisp had won, general programming would be as approachable as using a graphing calculator. [0] FWIW I found it in the SICP lectures.

PaulHoule 3y ago
I have met so many programmers who travel from job to job looking for functional programming enlightenment like an itinerant martial artist from a manga, never finding it. I've seen cults around Lisp and Haskell lead so many coders into the wilderness.
- __MatrixMan__ 3y ago
  reflects on all that code written for a paycheck Someone please lead me into the wilderness.
Viliam1234 3y ago
> 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.
kazinator 3y ago
I've committed most of my errors in a terminal window, so yes, it is an error window.

PaulHoule 3y ago

I have met so many programmers who travel from job to job looking for functional programming enlightenment like an itinerant martial artist from a manga, never finding it. I've seen cults around Lisp and Haskell lead so many coders into the wilderness.

__MatrixMan__ 3y ago
reflects on all that code written for a paycheck Someone please lead me into the wilderness.

Viliam1234 3y ago

> 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.

kazinator 3y ago

I've committed most of my errors in a terminal window, so yes, it is an error window.