4 ms·

It's not so much scientists vs. programmers, it's more about experience. If you write a lot of software, hopefully you're getting better at it, learning new sk

by fleitz 12y ago

It's not so much scientists vs. programmers, it's more about experience. If you write a lot of software, hopefully you're getting better at it, learning new skills, applying that, etc. It's like abstraction is like calculus if you know it it greatly simplifies things, if you don't it mystifies things. More experienced software writers generally write at a higher level of abstraction.

fmstephe 12y ago
I think that Yossi's point was the the non-programmer writes at a very low level of abstraction and this is a great virtue. Although there is a great deal of nuance to this debate I fall more and more on his side of it. I think that one of the biggest problems with this debate are the numerous examples of exceptionally powerful and useful abstractions we used every day. Programming languages are a wonderful abstraction over assembly which is a marvelous abstraction over machine code. Compilers leverage this abstraction to produce exceptionally fast machine code that few humans could ever match. The file system is a fantastic abstraction over a broad range of very complex storage medium, you can even pretend a hard drive on another computer is part of your local file system. So abstraction is clearly the most powerful tool in our toolbox. It's what allows us to climb above the Roman Numerals of computing. I think the thing that is lost in this debate is the number of failed abstractions. Each of the abstractions listed above were hard won and are painstakingly maintained by dedicated developers. Even within their ranks there are countless failed examples, file systems that were unreliable and programming languages that made life harder than it needed to be. The other feature of those abstractions listed above is that there are few of them and we spend a large amount of time learning about them. As a Java developer I have invested a significant amount of time learning the details of Java garbage collections. Now there is a wonderful abstraction, that has some sharp spikey corner cases. We can look at some common abstractions, third party libraries. I will use Spring as an example. The list of abstractions explodes, each one appears unique and I know developers who swear by Spring and use it extensively and who struggle to answer concrete questions about it. Vast quantities of unreliable and very hard to read code has been built on top these kinds of abstractions. (I note reluctantly that plenty of reliable software has been built on top of Spring too, and there are developers who have a very good grasp of at least some of it). Finally lets survey a final category of abstraction. The ad hoc per project abstraction. This is what Yossi is actually talking about in his article. In enterprise Java these are typically a swirling mass of classes whose names are concatenations of various design patterns. These are typically of a very low quality, the programmer who wrote them had deadlines and has since moved on. They are 100% unfamiliar, they are 100% awkward and, like a man lost in the desert desperate for a drink of water, I find myself yearning for a concrete instantiation and a plain old method call. My personal feeling is that, yes abstractions are extraordinarily powerful, but only when they are good and only when we understand them. I think producing new and useful ones is always harder than we expect. It's good to remember that we didn't replace roman numerals with ten thousand unique numeral systems. YMMV :)
- mercurial 12y ago
  > My personal feeling is that, yes abstractions are extraordinarily powerful, but only when they are good and only when we understand them. Certainly. Saying "I have created an abstraction" only works in conjunction with "I actually understand the problem on an abstract level, and I am familiar enough with the existing codebase." However, thinking that "amateur code", with bad or no data structures ("I actually want to use a dictionary, but let's have a 15-cases if/ifelsif/else expression instead"), 5-screen long functions, badly named variables and functions, state all over the place is "better" is folly. It isn't, it's just as terrible if not worse, and usually extremely brittle. Not to mention usually impossible to unit-test properly.
  - ams6110 12y ago
    Dictionaries are a great example. They are a useful general-purpose abstraction. Often times programmers will develop a hierarchy of classes that once you get to the root of is just a dictionary with some window dressing to hide the fact that it's just a dictionary. Sometimes it's easier to expose the dictionary directly and code the special cases directly. The programmer may fret about tight coupling but if you know you're never going to replace the dictionary-based implementation, it can be a lot easier to understand, especially if it's one-off code. And when dictionaries are provided by your language/libraries, you don't have to unit test them at all; you assume they work.
    - mercurial 12y ago
      But now your program is weakly typed. Using the same logic, maybe your id is just an integer, but having an "ID" type will prevent bugs in the future, just like "dressing up" the dictionary with a meaningful name and exposing only the minimum amount of methods necessary will avoid people being tempted to, say, add things they shouldn't in your dictionary, not to mention that strong typing has a documentary value.
kyzyl 12y ago
I would amend you statement by saying that more experienced developers are generally proficient at writing at a higher level of abstraction, but are more importantly also better at choosing the correct level of abstraction for the job. I think that's really the key. When I peek into a well designed system that really fits the bill, the feeling I usually get is 'how sensible', not 'wow, this is a really great way to abstract the problem!' or 'this is kind of complicated, but very well designed!'. The same sentiment applies pretty much everywhere, though. Humans draw their intellectual power from the ability to generalize, and so we see the same phenomena across disciplines. Writing? Most really effective writing is carefully constructed to include just the right statements, using just the right words, and nothing more. Circuit design? Same thing. You can wire a circuit that will work (or not) in many, many ways. But when someone with experience runs across the work of an amateur, even if it's a functional circuit, it's very rare that he/she can't list off a bunch of ways the design could be fundamentally improved. Carpentry? Yup. You can hack and nail and drill and glue something together that will work. Or--and I've seen this a lot--you can get a mechanical engineer to produce a profoundly complicated and structurally sound deck made with laser cutters and brackets made on a 6-axis CNC mill, but a seasoned carpenter can produce a much more elegant solution using a skill saw, a drill and a pencil.
- fleitz 12y ago
  Yeah I think you hit it on the head... the right level of abstraction. This is why I'm convinced LOC is one of the best measures of design, if a given design results in less LOC for a given problem it's the winner.

by fleitz 12y ago

fmstephe 12y ago

I think that Yossi's point was the the non-programmer writes at a very low level of abstraction and this is a great virtue. Although there is a great deal of nuance to this debate I fall more and more on his side of it. I think that one of the biggest problems with this debate are the numerous examples of exceptionally powerful and useful abstractions we used every day. Programming languages are a wonderful abstraction over assembly which is a marvelous abstraction over machine code. Compilers leverage this abstraction to produce exceptionally fast machine code that few humans could ever match. The file system is a fantastic abstraction over a broad range of very complex storage medium, you can even pretend a hard drive on another computer is part of your local file system. So abstraction is clearly the most powerful tool in our toolbox. It's what allows us to climb above the Roman Numerals of computing. I think the thing that is lost in this debate is the number of failed abstractions. Each of the abstractions listed above were hard won and are painstakingly maintained by dedicated developers. Even within their ranks there are countless failed examples, file systems that were unreliable and programming languages that made life harder than it needed to be. The other feature of those abstractions listed above is that there are few of them and we spend a large amount of time learning about them. As a Java developer I have invested a significant amount of time learning the details of Java garbage collections. Now there is a wonderful abstraction, that has some sharp spikey corner cases. We can look at some common abstractions, third party libraries. I will use Spring as an example. The list of abstractions explodes, each one appears unique and I know developers who swear by Spring and use it extensively and who struggle to answer concrete questions about it. Vast quantities of unreliable and very hard to read code has been built on top these kinds of abstractions. (I note reluctantly that plenty of reliable software has been built on top of Spring too, and there are developers who have a very good grasp of at least some of it). Finally lets survey a final category of abstraction. The ad hoc per project abstraction. This is what Yossi is actually talking about in his article. In enterprise Java these are typically a swirling mass of classes whose names are concatenations of various design patterns. These are typically of a very low quality, the programmer who wrote them had deadlines and has since moved on. They are 100% unfamiliar, they are 100% awkward and, like a man lost in the desert desperate for a drink of water, I find myself yearning for a concrete instantiation and a plain old method call. My personal feeling is that, yes abstractions are extraordinarily powerful, but only when they are good and only when we understand them. I think producing new and useful ones is always harder than we expect. It's good to remember that we didn't replace roman numerals with ten thousand unique numeral systems. YMMV :)

mercurial 12y ago
> My personal feeling is that, yes abstractions are extraordinarily powerful, but only when they are good and only when we understand them. Certainly. Saying "I have created an abstraction" only works in conjunction with "I actually understand the problem on an abstract level, and I am familiar enough with the existing codebase." However, thinking that "amateur code", with bad or no data structures ("I actually want to use a dictionary, but let's have a 15-cases if/ifelsif/else expression instead"), 5-screen long functions, badly named variables and functions, state all over the place is "better" is folly. It isn't, it's just as terrible if not worse, and usually extremely brittle. Not to mention usually impossible to unit-test properly.
- ams6110 12y ago
  Dictionaries are a great example. They are a useful general-purpose abstraction. Often times programmers will develop a hierarchy of classes that once you get to the root of is just a dictionary with some window dressing to hide the fact that it's just a dictionary. Sometimes it's easier to expose the dictionary directly and code the special cases directly. The programmer may fret about tight coupling but if you know you're never going to replace the dictionary-based implementation, it can be a lot easier to understand, especially if it's one-off code. And when dictionaries are provided by your language/libraries, you don't have to unit test them at all; you assume they work.
  - mercurial 12y ago
    But now your program is weakly typed. Using the same logic, maybe your id is just an integer, but having an "ID" type will prevent bugs in the future, just like "dressing up" the dictionary with a meaningful name and exposing only the minimum amount of methods necessary will avoid people being tempted to, say, add things they shouldn't in your dictionary, not to mention that strong typing has a documentary value.

kyzyl 12y ago

I would amend you statement by saying that more experienced developers are generally proficient at writing at a higher level of abstraction, but are more importantly also better at choosing the correct level of abstraction for the job. I think that's really the key. When I peek into a well designed system that really fits the bill, the feeling I usually get is 'how sensible', not 'wow, this is a really great way to abstract the problem!' or 'this is kind of complicated, but very well designed!'. The same sentiment applies pretty much everywhere, though. Humans draw their intellectual power from the ability to generalize, and so we see the same phenomena across disciplines. Writing? Most really effective writing is carefully constructed to include just the right statements, using just the right words, and nothing more. Circuit design? Same thing. You can wire a circuit that will work (or not) in many, many ways. But when someone with experience runs across the work of an amateur, even if it's a functional circuit, it's very rare that he/she can't list off a bunch of ways the design could be fundamentally improved. Carpentry? Yup. You can hack and nail and drill and glue something together that will work. Or--and I've seen this a lot--you can get a mechanical engineer to produce a profoundly complicated and structurally sound deck made with laser cutters and brackets made on a 6-axis CNC mill, but a seasoned carpenter can produce a much more elegant solution using a skill saw, a drill and a pencil.

fleitz 12y ago
Yeah I think you hit it on the head... the right level of abstraction. This is why I'm convinced LOC is one of the best measures of design, if a given design results in less LOC for a given problem it's the winner.