7 ms·

This is exactly what they mean.

kazinator 6y ago
I think it's perfectly fine to use a nested list object that gets picked apart with destructuring until the point that it becomes a maintenance or performance problem. (That point could arrive later that same day, or it might come never). This approach is one of the things that make Lisp Lisp; if it gives you an allergic reaction, use something else.
- reikonomusha 6y ago
  The purpose of code guidelines is to do exactly that: guide developers into a certain practice that’s consistent and broadly agreeable in a team setting. Using lists to fake objects isn’t good modern style, and it’s a reasonable guideline to suggest not doing that. I’m sure Googlers won’t gripe if you temporarily cons up a list to shuttle it around. I’m sure they will gripe if you’re doing SICP 101 style object definitions exclusively with lists. The latter easily gets out of hand in a language renowned for its several robust facilities for object definitions. MAXIMA (née MACSYMA) is known for lists-as-objects not only being depended upon, but also getting so out of hand it’s nearly impossible to refactor now. MAXIMA at least has the excuse of being very old software. I feel you’re interpreting this style guide as some kind of draconian law of writing Lisp code at Google, and making awful conclusions from it (e.g., “well if you’re allergic to objects as lists might as well not use Lisp” or “most of this can be summed up as writing Lisp like Java”).
  - kazinator 6y ago
    In my experience, these rules end up deployed in such a way that you cannot commit any change until they are obeyed to the letter. (That goes doubly so if they get encoded into an automated tool.) I don't disagree with that; a coding standard that is not enforceable without generous judgment calls is far less useful than a rigorous one. Make it exact, and then get everyone to stick to it.
    - aidenn0 6y ago
      I have the exact opposite experience; my job with the favorite coding standard explicitly had ways of allowing variances. The CEO came down hard on anyone who said that "The standard forbids X" and would tell them to reread the standard because it actually said something like "Don't do X without doing Y first." The basic mentality was if you couldn't responsibly follow the style guidelines after working there for a year, then you should be looking for work elsewhere.
- dreamcompiler 6y ago
  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!
- monadic2 6y ago
  For an alternative point of view, I write lisp for my day job and would not approve any code that just shoved a bunch of unrelated data in a list. Thinking about the destructuring code, especially if you don’t have access to pattern matching, is enough to give me a headache. You know that‘s not going to be documented, and if it is, people won’t be able to find the documentation. Just use records; every lisp has records, and it’s the point of records, and it’s not any less “elegant” or “beautiful” or “lispy” or whatever to have named fields and nice printing and accessors for free. The one exception I can think of is procedures with variadic arguments.
  - kazinator 6y ago
    Why don't you have access to pattern matching in your Lisp day job? (There is at least a coffee machine, health benefits, and a halfway ergonomic chair to sit on, hopefully.)
    - monadic2 6y ago
      > Why don't you have access to pattern matching in your Lisp day job? The lisp I use (scheme) does not have pattern-matching built-in and nobody has made a good enough case to add it as a special form.
      - oalae5niMiel7qu 6y ago
        > scheme There's your problem. Here's a nickel (toss). Get yourself a real Lisp.

I think it's perfectly fine to use a nested list object that gets picked apart with destructuring until the point that it becomes a maintenance or performance problem. (That point could arrive later that same day, or it might come never). This approach is one of the things that make Lisp Lisp; if it gives you an allergic reaction, use something else.

reikonomusha 6y ago
The purpose of code guidelines is to do exactly that: guide developers into a certain practice that’s consistent and broadly agreeable in a team setting. Using lists to fake objects isn’t good modern style, and it’s a reasonable guideline to suggest not doing that. I’m sure Googlers won’t gripe if you temporarily cons up a list to shuttle it around. I’m sure they will gripe if you’re doing SICP 101 style object definitions exclusively with lists. The latter easily gets out of hand in a language renowned for its several robust facilities for object definitions. MAXIMA (née MACSYMA) is known for lists-as-objects not only being depended upon, but also getting so out of hand it’s nearly impossible to refactor now. MAXIMA at least has the excuse of being very old software. I feel you’re interpreting this style guide as some kind of draconian law of writing Lisp code at Google, and making awful conclusions from it (e.g., “well if you’re allergic to objects as lists might as well not use Lisp” or “most of this can be summed up as writing Lisp like Java”).
- kazinator 6y ago
  In my experience, these rules end up deployed in such a way that you cannot commit any change until they are obeyed to the letter. (That goes doubly so if they get encoded into an automated tool.) I don't disagree with that; a coding standard that is not enforceable without generous judgment calls is far less useful than a rigorous one. Make it exact, and then get everyone to stick to it.
  - aidenn0 6y ago
    I have the exact opposite experience; my job with the favorite coding standard explicitly had ways of allowing variances. The CEO came down hard on anyone who said that "The standard forbids X" and would tell them to reread the standard because it actually said something like "Don't do X without doing Y first." The basic mentality was if you couldn't responsibly follow the style guidelines after working there for a year, then you should be looking for work elsewhere.
dreamcompiler 6y ago
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!
monadic2 6y ago
For an alternative point of view, I write lisp for my day job and would not approve any code that just shoved a bunch of unrelated data in a list. Thinking about the destructuring code, especially if you don’t have access to pattern matching, is enough to give me a headache. You know that‘s not going to be documented, and if it is, people won’t be able to find the documentation. Just use records; every lisp has records, and it’s the point of records, and it’s not any less “elegant” or “beautiful” or “lispy” or whatever to have named fields and nice printing and accessors for free. The one exception I can think of is procedures with variadic arguments.
- kazinator 6y ago
  Why don't you have access to pattern matching in your Lisp day job? (There is at least a coffee machine, health benefits, and a halfway ergonomic chair to sit on, hopefully.)
  - monadic2 6y ago
    > Why don't you have access to pattern matching in your Lisp day job? The lisp I use (scheme) does not have pattern-matching built-in and nobody has made a good enough case to add it as a special form.
    - oalae5niMiel7qu 6y ago
      > scheme There's your problem. Here's a nickel (toss). Get yourself a real Lisp.