3 ms·

> More volume = more things to comprehend I disagree. It is not that simple. If volume is similar code, then sure. But if you are talking about different style

by vineet 14y ago

> More volume = more things to comprehend I disagree. It is not that simple. If volume is similar code, then sure. But if you are talking about different styles of coding then you have a lot of other things to consider. On top of this, if you have a language that has very few underlying primitive (such as parentheses in lisp as opposed to [,;.] in other languages) then you actually have a higher comprehension barrier as the reader will need have to examine the role of the primitive as well. Basically, the terser the language the harder it is comprehend a LOC in that language. On the research note, I do agree that most SW engineering research has focused on 'small problems'.

pnathan 14y ago
I disagree. :-) It is that simple, at base! More stuff = more things to wrap your head around. I posit that a well-written terse solution should say exactly the intrinsic needs of the problem at hand, and no more. The ideal language abstraction would explain exactly what needs to happen and no more. The key forms of the language (macros, functions, etc) should be built up to that point so that it is clear what is going on. There is - in my mind - little difference between (with-open-file (file-stream filename) (do-stuff (read file-stream))) and stuffDoer(fileObject(filename).read()); Both say (to me) exactly the same thing at approximately the same level of abstraction; one does it with Lisp syntax and one in traditional C++ syntax. The question starts to arise after a while - what abstraction tools does the language make available. At what point do you need functions, classes, closures, m4 macros, lisp macros? Well, at the point when you need them. :-) These are all just tools to say exactly what you mean in as much code as you need. If you have a social problem of a bunch of cowboys all whooping it up in your codebase, I don't think any technical solution is going to help you. :-)
- masklinn 14y ago
  > Both say (to me) exactly the same thing at approximately the same level of abstraction They don't, though: depending on the exact C-style language, you may have leaked a filehandle.

by vineet 14y ago

pnathan 14y ago

I disagree. :-) It is that simple, at base! More stuff = more things to wrap your head around. I posit that a well-written terse solution should say exactly the intrinsic needs of the problem at hand, and no more. The ideal language abstraction would explain exactly what needs to happen and no more. The key forms of the language (macros, functions, etc) should be built up to that point so that it is clear what is going on. There is - in my mind - little difference between (with-open-file (file-stream filename) (do-stuff (read file-stream))) and stuffDoer(fileObject(filename).read()); Both say (to me) exactly the same thing at approximately the same level of abstraction; one does it with Lisp syntax and one in traditional C++ syntax. The question starts to arise after a while - what abstraction tools does the language make available. At what point do you need functions, classes, closures, m4 macros, lisp macros? Well, at the point when you need them. :-) These are all just tools to say exactly what you mean in as much code as you need. If you have a social problem of a bunch of cowboys all whooping it up in your codebase, I don't think any technical solution is going to help you. :-)

masklinn 14y ago
> Both say (to me) exactly the same thing at approximately the same level of abstraction They don't, though: depending on the exact C-style language, you may have leaked a filehandle.