4 ms·

I disagree with this at a very fundamental level. I'm not sure how to express my disagreement. I'll pick a seemingly random point: > Pick a language that most

by hsn915 5y ago

I disagree with this at a very fundamental level. I'm not sure how to express my disagreement. I'll pick a seemingly random point: > Pick a language that most programmers consider weird but whose median user is smart, and then focus on the differences between this language and the intersection of popular languages. This heuristic used to apply to Python, but it no longer does. (Partly thanks to the the "Python Paradox" essay I suppose; most people now think learning Python will give you a nice career path). All this heuristic says is that this language has some novelty that attracts people who are interested in novelty. People who are interested in novelty in the field of computers tend to be smart people, but they are not reprsentative of the "population of smart people working with computers"; they are just a small slice of it. I might even go so far as to say, it's a slice of people who are just interested in things but not particularly interested in making finished products. Most of the people who work with or on various linux distributions also fall in this category: they are smart, but they are not interested in building a solid working desktop environment as much as they are interested in just playing around with things for fun. For them, their subject of interest is like a puzzle game that they spend their time exploring. There's no specific end goal. No specific product to be built. Nothin to be delivered to end users. That's also the appeal of weird languages: the novelty itself. This might be a matter of definitions, but to me a good language is one that allows you to deliver a solid reliable end product. Maybe something you write in 5 lines of lisp will take 30 lines in Go. But this is not an issue at all. The mental energy it takes to write the 30 lines of Go is probably lower than the mental energy is takes to write those 5 lines of lisp.

smnplk 5y ago
>> The mental energy it takes to write the 30 lines of Go is probably lower than the mental energy is takes to write those 5 lines of lisp. I would use more mental energy to write 30 lines of Go, than 5 in lisp. Also if you take into account that you have a true REPL and you can do REPL driven development, which spares you some extra mental energy. But to be fair, Paul is talking about macros, which Go doesn't even have.Macros are more complicated, but are often oversold and over hyped. Yes, they are great, you can extend the language and all, but macros are not that often used, you can probably pick a random lisp codebase and search for macros, I bet you won't find any or less than 2% of the entire codebase. If macros in lisp didn't exist I would still use it, because I love building expressions vs building statemets.
- lispm 5y ago
  > I bet you won't find any or less than 2% of the entire codebase One can look from another angle into some code bases: https://github.com/McCLIM/McCLIM/blob/master/Examples/stopwatch.lisp https://github.com/McCLIM/McCLIM/blob/master/Examples/stopwa... It uses a ton of complex macros: Built in macros: DEFPACKAGE, DEFMETHOD, MULTIPLE-VALUE-BIND, LOOP, ... Language extensions: WHEN-LET, ... Library macros: WITH-OUTPUT-AS-PRESENTATION, FORMATTING-TABLE, DEFINE-APPLICATION-FRAME, ... Even a generated macro: DEFINE-STOPWATCH-COMMAND (which was defined by DEFINE-APPLICATION-FRAME)
  - smnplk 5y ago
    There is only one custom macro definition in this code, 10 lines of code without docstring. Builtin macros are not an issue, why would that be an issue ? Those are just part of the language standard library. It's the same as when you use reserved words in other languages, like *import* statement in golang or *ns* macro in Clojure, it's just part of the language and you learn how to use it. I was talking about custom macros. Disclamer: My goto lisps are Clojure and Janet, so I am not very familiar with CL.
- hsn915 5y ago
  Go doesn't have macros but it culturally encourages code generation. I myself generate hundreds of lines of code that would otherwise be annoying and error-prone to maintain manually.
  - blacktriangle 5y ago
    This may be the first time I've ever seen code generation listed as a feature. Code generation may be the single biggest contributor to long-term maintainability problems I've ever seen, from `rails new` to create-react-app, over time it'll kill your momentum.

by hsn915 5y ago

smnplk 5y ago

>> The mental energy it takes to write the 30 lines of Go is probably lower than the mental energy is takes to write those 5 lines of lisp. I would use more mental energy to write 30 lines of Go, than 5 in lisp. Also if you take into account that you have a true REPL and you can do REPL driven development, which spares you some extra mental energy. But to be fair, Paul is talking about macros, which Go doesn't even have.Macros are more complicated, but are often oversold and over hyped. Yes, they are great, you can extend the language and all, but macros are not that often used, you can probably pick a random lisp codebase and search for macros, I bet you won't find any or less than 2% of the entire codebase. If macros in lisp didn't exist I would still use it, because I love building expressions vs building statemets.

lispm 5y ago
> I bet you won't find any or less than 2% of the entire codebase One can look from another angle into some code bases: https://github.com/McCLIM/McCLIM/blob/master/Examples/stopwatch.lisp https://github.com/McCLIM/McCLIM/blob/master/Examples/stopwa... It uses a ton of complex macros: Built in macros: DEFPACKAGE, DEFMETHOD, MULTIPLE-VALUE-BIND, LOOP, ... Language extensions: WHEN-LET, ... Library macros: WITH-OUTPUT-AS-PRESENTATION, FORMATTING-TABLE, DEFINE-APPLICATION-FRAME, ... Even a generated macro: DEFINE-STOPWATCH-COMMAND (which was defined by DEFINE-APPLICATION-FRAME)
- smnplk 5y ago
  There is only one custom macro definition in this code, 10 lines of code without docstring. Builtin macros are not an issue, why would that be an issue ? Those are just part of the language standard library. It's the same as when you use reserved words in other languages, like *import* statement in golang or *ns* macro in Clojure, it's just part of the language and you learn how to use it. I was talking about custom macros. Disclamer: My goto lisps are Clojure and Janet, so I am not very familiar with CL.
hsn915 5y ago
Go doesn't have macros but it culturally encourages code generation. I myself generate hundreds of lines of code that would otherwise be annoying and error-prone to maintain manually.
- blacktriangle 5y ago
  This may be the first time I've ever seen code generation listed as a feature. Code generation may be the single biggest contributor to long-term maintainability problems I've ever seen, from `rails new` to create-react-app, over time it'll kill your momentum.