4 ms·

I have seen things you people wouldn't believe. 500-line 7-deep plists off the shoulder of Orion. I watched CLOS glitter in the dark, unused, near the Tannhäuse

I have seen things you people wouldn't believe. 500-line 7-deep plists off the shoulder of Orion. I watched CLOS glitter in the dark, unused, near the Tannhäuser Gate. 28-clause typecase statements because the author didn't understand generic functions. All those moments will be lost in time, like tears in rain. And thank dog for that.

kazinator 6y ago
Such things are quantifiable. We can have an exact rule which says that you can use an ad-hoc list as a structure if (for instance): 1. No more than 17 functions handle this datum, spread among no more than three source files. 2. The structure contains no more than 8 conses. 3. In a long-running application under a typical production load, no more than 10,000 of these objects are freshly allocated in any five minute period. 4. A major software component (such as a library) can internally have at most three separate instances of such a data type, and they are not to be involved in the APIs between major software components. Okay, that's now a target we can enforce without wishy washy judgment calls.
- joshuamorton 6y ago
  > Such things are quantifiable. We can have an exact rule which says that you can use an ad-hoc list as a structure if (for instance): So what happens when you have a datum that is used in exactly 17 functions, but you need to add another feature? Or, what happens when people combine functions into larger ones to avoid having to define a real datatype, or... These concerns exist for each thing. "Don't use a list where you really have a struct" is much more concrete and quantifiable.
  - kazinator 6y ago
    > but you need to add another feature? You have to add your feature in such a way that the resulting code meets the rules. It's exactly the same like when you need to add something to a line that is already 79 characters long (maximum allowed by your coding convention). Or if you have to add lines of code into a function that is already 200 lines long (coding style max). Or if you need another argument in some API that already has the maximum of 8. You have to step back to some extent and change more of the surrounding program, than just shoving your intended change into it. > Or, what happens when people combine functions into larger ones to avoid having to define a real datatype If the code remains under the quantified limit for function size, then it is complying with the document. > "Don't use a list where you really have a struct" is much more concrete and quantifiable. There are two answers to "where do you really have a struct?" One is purely opinionated, and one is objective. The objective answer is: "you really have a struct in all situations where the list isn't a variable length container of items of the same type". So the concrete and quantifiable (and therefore the right) interpretation of the rule amounts to never using a fundamentally characteristic Lisp technique, in Lisp!
- dragonwriter 6y ago
  > Okay, that's now a target we can enforce without wishy washy judgment calls. Sure, you can have an exact set of rules like that, and feel free to have an automated enforcement of your own set of exact rules. There are good reasons coding style guides often include things which are not exact rules, and the target for them is often not automated enforcement but supporting human judgement that balances multiple factors. Yes, that results in fuzzy boundaries, but it's because experience has both shown that there is an issue but has not provided (yet) sufficient basis for a quantifiable boundary, because the set of factors being balanced is complex and multidimensional. Reducing the dimensionality for simplicity of automated enforcement is easier, but not necessarily better.
TeMPOraL 6y ago
I once won a huge performance win in a commercial project by discovering that some numerically-heavy computations on large vectors of numbers were actually using lists to keep those numbers. I replaced those universally with arrays, yielding some ridiculous efficiency benefit. The lists were fine when there were 5 numbers in the bag, but nobody noticed when the amount of numbers grew to thousands...
AndyMcConachie 6y ago
I love this post.
wrycoder 6y ago
I believe Alan Perlis said that Lisp programmers know the value of everything and the cost of nothing.

kazinator 6y ago

Such things are quantifiable. We can have an exact rule which says that you can use an ad-hoc list as a structure if (for instance): 1. No more than 17 functions handle this datum, spread among no more than three source files. 2. The structure contains no more than 8 conses. 3. In a long-running application under a typical production load, no more than 10,000 of these objects are freshly allocated in any five minute period. 4. A major software component (such as a library) can internally have at most three separate instances of such a data type, and they are not to be involved in the APIs between major software components. Okay, that's now a target we can enforce without wishy washy judgment calls.

joshuamorton 6y ago
> Such things are quantifiable. We can have an exact rule which says that you can use an ad-hoc list as a structure if (for instance): So what happens when you have a datum that is used in exactly 17 functions, but you need to add another feature? Or, what happens when people combine functions into larger ones to avoid having to define a real datatype, or... These concerns exist for each thing. "Don't use a list where you really have a struct" is much more concrete and quantifiable.
- kazinator 6y ago
  > but you need to add another feature? You have to add your feature in such a way that the resulting code meets the rules. It's exactly the same like when you need to add something to a line that is already 79 characters long (maximum allowed by your coding convention). Or if you have to add lines of code into a function that is already 200 lines long (coding style max). Or if you need another argument in some API that already has the maximum of 8. You have to step back to some extent and change more of the surrounding program, than just shoving your intended change into it. > Or, what happens when people combine functions into larger ones to avoid having to define a real datatype If the code remains under the quantified limit for function size, then it is complying with the document. > "Don't use a list where you really have a struct" is much more concrete and quantifiable. There are two answers to "where do you really have a struct?" One is purely opinionated, and one is objective. The objective answer is: "you really have a struct in all situations where the list isn't a variable length container of items of the same type". So the concrete and quantifiable (and therefore the right) interpretation of the rule amounts to never using a fundamentally characteristic Lisp technique, in Lisp!
dragonwriter 6y ago
> Okay, that's now a target we can enforce without wishy washy judgment calls. Sure, you can have an exact set of rules like that, and feel free to have an automated enforcement of your own set of exact rules. There are good reasons coding style guides often include things which are not exact rules, and the target for them is often not automated enforcement but supporting human judgement that balances multiple factors. Yes, that results in fuzzy boundaries, but it's because experience has both shown that there is an issue but has not provided (yet) sufficient basis for a quantifiable boundary, because the set of factors being balanced is complex and multidimensional. Reducing the dimensionality for simplicity of automated enforcement is easier, but not necessarily better.

TeMPOraL 6y ago

I once won a huge performance win in a commercial project by discovering that some numerically-heavy computations on large vectors of numbers were actually using lists to keep those numbers. I replaced those universally with arrays, yielding some ridiculous efficiency benefit. The lists were fine when there were 5 numbers in the bag, but nobody noticed when the amount of numbers grew to thousands...

AndyMcConachie 6y ago

I love this post.

wrycoder 6y ago

I believe Alan Perlis said that Lisp programmers know the value of everything and the cost of nothing.