> In Java, super calls are inside the method in question, any stupid decisions around super are right in front of you
The problem you mentioned was when the super call was missing. You have to find out which method gets called for the runtime object and then see that the super call is missing.
In CLOS I'd list the applicable methods and edit the first :around method.
True, CLOS is the much more complex system, with a meta-object protocol, generic functions, multi-methods, multiple-inheritance, meta-classes, method combinations, ...
Java was designed for the simple case and then promoted for the 'industrial programmer' - which explains part of its success - but it got complicated soon and people added for example Aspect Oriented Programming to it - which has similar features like CLOS :around methods.
> Macros like these are un-lispy
Not really. What you think as un-lispy is perfectly fine for many. There is a tendency to narrow down the language to simplify it, like Dylan or many others. Lisp is always more about freedom of design, experimentation, flexibility. Otherwise we wouldn't have widely different extension approaches in one language: format strings with loops, a whole complex language for printing code, macro like LOOP, ...
Sure you can just use macros to reorder arguments and make code more convenient, but at the same time you can use macros to add radical different sublanguages - that's one of the reasons I use Lisp - it allows me to do that and many have implemented very interesting language extensions on top of Lisp. Personally I think with some practice LOOP macros are relatively easy to write and I even prefer them over tail-recursive loops in Scheme - which are IMHO much harder to follow.
Haven't seen much danger with it in practice.
> In Java, super calls are inside the method in question, any stupid decisions around super are right in front of you
The problem you mentioned was when the super call was missing. You have to find out which method gets called for the runtime object and then see that the super call is missing.
In CLOS I'd list the applicable methods and edit the first :around method.
True, CLOS is the much more complex system, with a meta-object protocol, generic functions, multi-methods, multiple-inheritance, meta-classes, method combinations, ...
Java was designed for the simple case and then promoted for the 'industrial programmer' - which explains part of its success - but it got complicated soon and people added for example Aspect Oriented Programming to it - which has similar features like CLOS :around methods.
> Macros like these are un-lispy
Not really. What you think as un-lispy is perfectly fine for many. There is a tendency to narrow down the language to simplify it, like Dylan or many others. Lisp is always more about freedom of design, experimentation, flexibility. Otherwise we wouldn't have widely different extension approaches in one language: format strings with loops, a whole complex language for printing code, macro like LOOP, ...
Sure you can just use macros to reorder arguments and make code more convenient, but at the same time you can use macros to add radical different sublanguages - that's one of the reasons I use Lisp - it allows me to do that and many have implemented very interesting language extensions on top of Lisp. Personally I think with some practice LOOP macros are relatively easy to write and I even prefer them over tail-recursive loops in Scheme - which are IMHO much harder to follow.