Language is very important. Bad code in python is at least still python. Bad code in lisp can be an inpenetrable eldritch abomination where the only option is to rewrite from scratch. I believe this is actually the primary reason google build go. You can't write good code. But you also can't write really bad code.
Why do you believe it impossible for Python to be impenetrable?
A Common Lisp will likely be much more introspectable and debuggable than your average CPython.
I think Google designed Golang to be a small language for implementing network services that will tie newcomers to programming hard to that specific language and then also Google. Hence the syntactic quirks and the err spectre. That it enables development of CLI applications was likely an unexpected bonus.
@cess11 on Golang, no, rather Ken Thompson and colleagues designed a language stripped off things they find as an unnecessary cruft and they could finally get back to the fun they had before Java and OO.
Yeah that's ok for you to think like that, at the same time it's fun for the creators and for a number of users, including me. Btw there so many languages with sum types (and almost none that fixed data races) that everybody can choose.
The point is, I was aiming to refute one cummenter's claim that Go was created to lure specific people into Google as devs. Highly unlikely, Go's adoption in Google wasn't bad but also wasn't exactly a bed of roses.
It's not impossible. But rather much less likely. And even less likely to do by accident. Lisp by itself basically encourages programming deviating from standard practices. That the entire reason it's so powerful. It takes a real genius in addition to strong restraint to keep writing good code in that environment.
He means he once read an article written by a web developer with no Lisp development experience called "The Lisp Curse", and that's his entire Lisp development experience.
Right, yeah, seems likely. Such comparisons are usually pretty weird, putting non-hygienic macros against ordinary programming in some other language, rather than macros against the metaprogramming used there.
Experience with macros and their footguns arguably prepared me pretty well for using JAXB and reflection professionally.
Lisp Macros are encouraged. In most other language you can't even write syntactical extensions. Such things are, generally, horrendous for readability. Like I said you can wield them effectively. But the average developer won't be able to.
Google Lisp style guide: Use macros when appropriate, which is often. Define macros when appropriate, which is seldom.
Heinrich Taube's "Lisp Style Tips for the Beginner": Beware of macros. They are a very important feature of Lisp but a poorly implemented macro can cause bugs that are very difficult for a beginner to solve. Avoid writing macros until you understand how the Lisp reader and evaluator work. Never write a macro to make things "more efficient".
Guy Steele and Kent Pitman, "Tutorial on Good Lisp Programming Style" [1993]: Decide if a macro is really necessary. [...] Don't use a macro where a function would suffice.*
Carnegie-Mellon Lisp FAQ: Never use a macro instead of a function for efficiency reasons. [...] 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.
I've never seen a book, tutorial or style guide document saying that Lisp coders should be writing lots of macros, and constantly looking for any excuse to write another macro or some such advice.
> In most other language you can't even write syntactical extensions.
C? C++? Rust? Erlang? Scala? Julia? R?
> Such things are, generally, horrendous for readability. Like I said you can wield them effectively. But the average developer won't be able to.
Macros actually are widely used to improve readability. In Lisp that's one of its main purposes. It leads to more compact, declarative, domain specific code. Large programs usually benefit the most. Programs can be much short and more readable.
Take for example in Common Lisp the Common Lisp Object System. It has three layers: an object-layer at the bottom, then a functional layer and on the top is the macro layer. The macro layer is what the typical developer uses, which is compact and which shields the developer from the details of the lower layers.
The Common Lisp Object System blends seamlessly into the rest of the language and the usual basics can be easily learned.
If you disagree that Lisp has a tendency to become unreadable then maybe the typical developer might have a "neurodevelopmental deficit" compared to you. bindings don't change the language that's executing. That's the entire point why Macros can quickly make code unreadable.
Macros do not change the language that is executing (as in self-modifying code).
Self-modifying code is possible to express by other means in traditional Lisps that have a quote operator.
In Common Lisp, it is undefined behavior to modify a quoted part of the program.
E.g. this wold be undefined:
(defun counter () (inc (car '(1))))
The function is referring to a piece of its own syntax (1) which initially holds the integer 1 and incrementing that. This may have the expected effect under some circumstances. Or it could have the expected effect, plus some unexpected effect, or not have the expected effect at all. It may signal an error, also.
I happen to agree with your underlying point, but expressing it in the form of a personal attack is the worst thing you could do here. It destroys everything that we're trying for on HN, and also reinforces the worst clichés about Lisp on a social level.
Do you think this is a good faith way to communicate with other people? No where in my comments did I attack anyone or accuse people of lying. Yet you suddenly come out of the gate swinging. Why?
"I believe this is actually the primary reason google build go." Well the actual quiet part is that they built Go to reduce costs of paying those highly trained software engineers and replace them with moderately trained monkeys.
Actually it was because some engenieers take pride in creating complex solutions for problems that a moderately trained monkey could solve in a managed language.
