The problem is not the ()))))), it's the 200 lines function which does 20 different things all at once. Split that into smart and readable function.. You identified a problem (Hard to get where that println goes), however, you came with the wrong solution.
But I need to say that you are right about the fact that many lisp code are really ugly.. Maybe it's because when programmers are coding in lisp they considere themselves hackers and don't think about coding cleanly.
"With great powers come great responsibility." Since Lisp is the most powerful language, people should learn to separate abstraction into separate function. I mean, it's not because you have lambda and you don't have to name function that you absolutely need to do it.
Often, for small function, lisp coder tends to put that in a lambda and inline it directly in the bigger function.. which in my opinion is not the way to go.
A friend of mine once told me he really liked lambda because he had difficulties to find good game for function and variable.. by stacking all lambda together, it was way faster and easier for him. The problem with that, of course, is when other programmers will actually try to read that code and understand what it does.
Flame me if you want but when I need to work on someone else project written in lisp code, I always know it will be a pain to understand it. However, when I need to read java or C++ code, even thought the syntax is uglier and more verbose, I know I will have no problem reading it.
So here's a small trick for you hackers:
- Don't be afraid to separate your code into many functions, even if you are using lisp.
- Don't be afraid to use (let) syntax to give a name to portion of codes.. it might be harder to write (finding good variable name is sometime really hard and takes more time), however, it will make the code so much readable.
You could extract a macro to create a ZipEntry, bind it to standard out, and execute some actions that write to the ZipEntry. Then the code starting with .putNextEntry and ending with .closeEntry becomes something like
(with-zip-entry out "META-INF/plexus/components.xml"
(xml-emit ...)
This macro should be useful other places where you are writing to zip files. And it should bring the println closer to the start of its containing scope, making it easier to tell at a glance the scope to which it belongs.
Forth programmers tend to chew their code into little digestible nuggets of seven words or less. Meanwhile in Lisp many of us (myself included) still tend to favor the Massive Wall O' Code approach, making us look like third-rate VB programmers in the process.
We have compilers that can open code (inline in C parlance) the subroutines that handle the fiddly bits in your big routine. No reason why these shouldn't be factored out in the name of clarity.
>Maybe it's because when programmers are coding in lisp they considere themselves hackers and don't think about coding cleanly.
I was taught and I consistently read that splitting into smaller functions is absolutely fundamental. I don't know where your programmers learned lisp.
am I mistaken in thinking that part of this problem is a desire to not pollute the namespace since most(all?) lisps are unable to properly privatize functions?
Yes. You can define functions locally with "flet" or "labels" and never touch the global namespace. This alone is enough so that you don't have to resort to lambdas to avoid polluting the global namespace. In addition Common Lisp provides both generic methods and packages, which both provide a means of managing the global namespace, so one should never use lambdas for that purpose.
You can also use (define) inside others (define) if you want private functions. And, because of closures, it makes it extremely powerful and flexible since you don't have to repeat parameters already given in the outer scope.
Perhaps this is true in CL, but Clojure makes it easy to define private functions.
In the case of the particular example he points to it's just a long function because many people contributed to that function over a period of several months.
But I need to say that you are right about the fact that many lisp code are really ugly.. Maybe it's because when programmers are coding in lisp they considere themselves hackers and don't think about coding cleanly.
"With great powers come great responsibility." Since Lisp is the most powerful language, people should learn to separate abstraction into separate function. I mean, it's not because you have lambda and you don't have to name function that you absolutely need to do it.
Often, for small function, lisp coder tends to put that in a lambda and inline it directly in the bigger function.. which in my opinion is not the way to go.
A friend of mine once told me he really liked lambda because he had difficulties to find good game for function and variable.. by stacking all lambda together, it was way faster and easier for him. The problem with that, of course, is when other programmers will actually try to read that code and understand what it does.
Flame me if you want but when I need to work on someone else project written in lisp code, I always know it will be a pain to understand it. However, when I need to read java or C++ code, even thought the syntax is uglier and more verbose, I know I will have no problem reading it.
So here's a small trick for you hackers:
- Don't be afraid to separate your code into many functions, even if you are using lisp.
- Don't be afraid to use (let) syntax to give a name to portion of codes.. it might be harder to write (finding good variable name is sometime really hard and takes more time), however, it will make the code so much readable.