2 ms·

Not every language gives you the ability to modify the syntax of the language at run-time[0]. I am sympathetic to the argument that one can write both crappy an

Not every language gives you the ability to modify the syntax of the language at run-time[0]. I am sympathetic to the argument that one can write both crappy and quality code in any language, but I am also convinced that certain language structures increase or decrease the odds of a code base being maintainable, all else being held equal. Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming. My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. The catch was that every single around method had to call the magic (call-next-function) function, otherwise the main function would not be called. Wondering why in the hell the function you just called isn't actually executing is quite a brainfuck, especially when it was caused by a bug in a completely different package. CL + Emacs was truly great though, best editor to language integration I've ever seen, period. [0] https://letoverlambda.com/index.cl/guest/chap4.html https://letoverlambda.com/index.cl/guest/chap4.html

Jach 8y ago
I also like the idea that languages impact code being maintainable. It's part of why I want to work in more dynamic languages again. My day job is mostly Java. Apart from your macro complaints (though some older devs have expressed similar complaints to me when faced with excited younger devs being a bit irresponsible with the new syntax of Java 8), I see the same things you're criticizing in Java. Java has public/private/protected/package-scope, but you can get around it trivially with reflection. (Java 9 I think "fixed" this, but you can override it at startup time.) Personally I'm in favor of Python's "we're all adults here" philosophy. Proxy patterns are common in large Java code bases, and various other things inspired by aspect-oriented programming. I've never thought to blame the language though because someone forgot to call (or decided not to call, e.g. because it got too smart with a cache) child.method() on the real object it is wrapping.
- kamaal 8y ago
  For me a far bigger irritation in Java is Design Pattern abuse. It makes code far more unreadable than any macro code I've seen so far. Its a big like what Larry Wall talks about code complexity(https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory). Basically if say a language X provides in built feature to do complex task Y, and it a little hard to understand. In another language Z which lacks the feature, the code that one has to write to achieve Y will be equally complicated and hard if not more.
flavio81 8y ago
>My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. Sounds like a not-so-appropriate way of doing it. I do this by wrapping my transactions... on a (with-transaction ) expression! Which is easily done using CLSQL (common lisp lib). This would do exactly what you want: exec the rollback, etc. Note that I speak from personal experience: this has worked perfectly on a commercial project. >Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming. CL is, mostly, for ideally experienced engineers. And i'm not being smug or elitist here. Ideally experienced engineers are able to leverage the full power of CL. >when deadlines are looming. And the reason to use CL is precisely to enable greater speed of development for complex stuff, so deadlines don't scare you so much (compared to using a lesser-featured language like Java for example)

Jach 8y ago

I also like the idea that languages impact code being maintainable. It's part of why I want to work in more dynamic languages again. My day job is mostly Java. Apart from your macro complaints (though some older devs have expressed similar complaints to me when faced with excited younger devs being a bit irresponsible with the new syntax of Java 8), I see the same things you're criticizing in Java. Java has public/private/protected/package-scope, but you can get around it trivially with reflection. (Java 9 I think "fixed" this, but you can override it at startup time.) Personally I'm in favor of Python's "we're all adults here" philosophy. Proxy patterns are common in large Java code bases, and various other things inspired by aspect-oriented programming. I've never thought to blame the language though because someone forgot to call (or decided not to call, e.g. because it got too smart with a cache) child.method() on the real object it is wrapping.

kamaal 8y ago
For me a far bigger irritation in Java is Design Pattern abuse. It makes code far more unreadable than any macro code I've seen so far. Its a big like what Larry Wall talks about code complexity(https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory). Basically if say a language X provides in built feature to do complex task Y, and it a little hard to understand. In another language Z which lacks the feature, the code that one has to write to achieve Y will be equally complicated and hard if not more.

flavio81 8y ago

>My personal favorite WTF from CL was the :around methods from CLOS. These allowed you to wrap a function with other functions, possibly from a completely different place in your code base, and handle any setup/teardown as needed. We typically used them for database transactions, along with the ability to catch exceptions and trigger a DB rollback. Sounds like a not-so-appropriate way of doing it. I do this by wrapping my transactions... on a (with-transaction ) expression! Which is easily done using CLSQL (common lisp lib). This would do exactly what you want: exec the rollback, etc. Note that I speak from personal experience: this has worked perfectly on a commercial project. >Lisp brings a lot of power to the table along with relatively weak code organization constructs. A great example of this is the concept of package privacy, something that can be ignored in CL by using a double colon instead of a single colon. Sure, ideally experienced engineers would not abuse this, but that sure is a dangerous tool to leave around when deadlines are looming. CL is, mostly, for ideally experienced engineers. And i'm not being smug or elitist here. Ideally experienced engineers are able to leverage the full power of CL. >when deadlines are looming. And the reason to use CL is precisely to enable greater speed of development for complex stuff, so deadlines don't scare you so much (compared to using a lesser-featured language like Java for example)