4 ms·

Design patterns, Smalltalk, and the lost art of reading code

33 points by tartoran 6y ago

ncmncm 6y ago
Generally speaking, most design patterns reveal weaknesses in the languages where they are found. Regularities that can be captured in libraries do not become design patterns because they end up expressed in one or a family of libraries, and just used. Others, heavily used, are often pulled into the core language. So, in a stronger language, fewer of the design patterns noticed in other languages are seen. The strongest languages show least use of common design patterns, and also the fewest of them pulled into the core language, because their ability to capture patterns in libraries is better. An example is the lowly hash table. In C, this is a design pattern, and there may be millions of more or less independent implementations of the pattern in the corpus of C programs and C libraries. A hash table library in C just cannot be made very widely useful. Many, many other languages provide hash tables, often called dictionaries, in the core language. It doesn't matter so much, then, that you can't usefully code one in the language, because the language fills that gap. It does mean that if you need a substantial variation on the basic hash table pattern, you are out of luck, but almost all small programs, and even most big ones, don't need anything fancier. A few languages, notably C++, the MLs, Haskell, D, and Rust among them, are strong enough to capture the pattern in libraries, and you find libraries in these languages implementing numerous variations on the hash table pattern. There are still patterns that cannot be captured in libraries even in these languages. That failure can help to guide development of useful new features in these languages. The most useful new features enable the language to capture more usage patterns in libraries, so they be coded just once (or a few times) and then used anywhere. Being able to capture a pattern in a library is much better than pulling it into the language core, because then you get not just the basic pattern, but as many variations on it as turn out to be worth coding a library for.
- jecel 6y ago
  It seems odd to talk about hash tables as design patterns. To me they are just a data type. It is true that other languages have a built-in implementations and yet others have a standard user level implementation while in C there are many. But I see design patterns as a framework level thing. What you wrote about them being different in different languages is true, however. When the book came out we had a thread in the mailing list for the Self programming language looking at the 23 patterns and nearly all of them took no special effort to use in Self. An object could be a Singleton, for example, by simply not having "traits clonable" as a parent like most objects did.
- ralphc 6y ago
  "Generally speaking, most design patterns reveal weaknesses in the languages where they are found" Here's a slide deck from Peter Norvig on this, Design Patterns in Dynamic Programming. He shows how many of the 23 design patterns aren't needed in languages such as Lisp or Dylan, both of which have multiple dispatch. No doubt you could apply the same philosophy to Julia today. https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf
  - musicale 6y ago
    I'd like to see Dylan-style multiple iterator syntax in more languages. Python's zip() isn't nearly as obvious, and I wish we could do something like this in java/c++: for (a:A, b:B, c:C) ...
dkarl 6y ago
In my job I do a lot of code review of client code, mostly in Java, and some of it is particularly terrible. In fact, there’s one problem I see that is endemic. That’s where the code is “supposedly” object-oriented, but in fact, it doesn’t take advantage of any of the features of object orientation (no inheritance, no method overrides, and few if any uses of type substitution). In particular I see tons of code where there are these static “data” objects (a misunderstanding of another pattern from Martin Fowler, called the Data Access Object) and these “processing” objects that are, for the most part, just bags of procedures that operate on the data objects. The author really loses me here. I cut my professional teeth on Java, read Design Patterns while I was working my first job, and wrote his preferred style of OO code for years. I still use those OO features in my code, because they're still useful for a lot of things, but over the years I've learned other techniques as well that have helped me make my code simpler to understand and maintain. In the early 2000s I did see bad C-style Java written by people who didn't yet know how OO could be used for good, and if the author had written this in 2000 or even 2010 I could give them the benefit of the doubt that that's what they're complaining about, but if the author is seeing Java code in 2020 that they think isn't OO enough, it isn't because people don't know the style. It's because they know there are different choices that can often produce better results. I still run into people in real life who criticize code for not being written in that old 1990s/early 2000s style, for tackling problems with techniques other than inheritance and polymorphism, for daring to have data without behavior, etc. If you're satisfied with that old style and want to spend the rest of your career solving problems with it -- fine. But when other people move on, don't criticize them as if they haven't caught up.
- ncmncm 6y ago
  Yes, it is ridiculous to criticize Java coders for "misusing" their OO mechanisms. Those mechanisms are all they have, to build everything, whether OO makes sense in that niche or doesn't. So, probably more often than not, they are obliged to cobble together a substitute for what they need from the limited toolkit at hand, making a hammer do a screwdriver's job, as best they can. You have to feel sorry for them, and even sometimes admire them, making the best of adversity in their impoverished language. Then think of the poor C coders, lacking even that.
igouy 6y ago
> The simple lesson they taught me was this: > Don’t start any new programming task from scratch — always look in the Smalltalk image first to see what’s available and what has been already done before you start building anything new. Exactly. '"Contrary to the idea that a computer is exciting because the programmer can create something from seemingly nothing, our users were shown that a computer is exciting because it can be a vast storehouse of already existing ideas (models) that can be retrieved and modified for the user's personal needs. Programming could be viewed and enjoyed as an evolutionary rather than a revolutionary act. The frustration of long hours of writing linear streams of code and then hoping to see some aspect of that code execute was replaced by incremental development. Emphasis was placed on learning how to make effective use of existing system components (objects in the Smalltalk sense).' page 354 "Is the Smalltalk-80 System for Children?" https://archive.org/details/byte-magazine-1981-08/page/n367/mode/1up https://archive.org/details/byte-magazine-1981-08/page/n367/...
- ncmncm 6y ago
  It is hard to imagine such a miserable experience, shaping things written to do one thing well into other things doing something else less well, and again, never working with code that is exactly right for its purpose because it was expediently pressed into service against its nature. After long enough, the overwhelming majority of code in the system is doing nothing it was designed for, just well enough to get by and get on.
  - igouy 6y ago
    Apparently it is hard for you to imagine, because your dismal description bears no relationship to actual experience.

33 points by tartoran 6y ago

Generally speaking, most design patterns reveal weaknesses in the languages where they are found. Regularities that can be captured in libraries do not become design patterns because they end up expressed in one or a family of libraries, and just used. Others, heavily used, are often pulled into the core language. So, in a stronger language, fewer of the design patterns noticed in other languages are seen. The strongest languages show least use of common design patterns, and also the fewest of them pulled into the core language, because their ability to capture patterns in libraries is better. An example is the lowly hash table. In C, this is a design pattern, and there may be millions of more or less independent implementations of the pattern in the corpus of C programs and C libraries. A hash table library in C just cannot be made very widely useful. Many, many other languages provide hash tables, often called dictionaries, in the core language. It doesn't matter so much, then, that you can't usefully code one in the language, because the language fills that gap. It does mean that if you need a substantial variation on the basic hash table pattern, you are out of luck, but almost all small programs, and even most big ones, don't need anything fancier. A few languages, notably C++, the MLs, Haskell, D, and Rust among them, are strong enough to capture the pattern in libraries, and you find libraries in these languages implementing numerous variations on the hash table pattern. There are still patterns that cannot be captured in libraries even in these languages. That failure can help to guide development of useful new features in these languages. The most useful new features enable the language to capture more usage patterns in libraries, so they be coded just once (or a few times) and then used anywhere. Being able to capture a pattern in a library is much better than pulling it into the language core, because then you get not just the basic pattern, but as many variations on it as turn out to be worth coding a library for.

jecel 6y ago
It seems odd to talk about hash tables as design patterns. To me they are just a data type. It is true that other languages have a built-in implementations and yet others have a standard user level implementation while in C there are many. But I see design patterns as a framework level thing. What you wrote about them being different in different languages is true, however. When the book came out we had a thread in the mailing list for the Self programming language looking at the 23 patterns and nearly all of them took no special effort to use in Self. An object could be a Singleton, for example, by simply not having "traits clonable" as a parent like most objects did.
ralphc 6y ago
"Generally speaking, most design patterns reveal weaknesses in the languages where they are found" Here's a slide deck from Peter Norvig on this, Design Patterns in Dynamic Programming. He shows how many of the 23 design patterns aren't needed in languages such as Lisp or Dylan, both of which have multiple dispatch. No doubt you could apply the same philosophy to Julia today. https://norvig.com/design-patterns/design-patterns.pdf https://norvig.com/design-patterns/design-patterns.pdf
- musicale 6y ago
  I'd like to see Dylan-style multiple iterator syntax in more languages. Python's zip() isn't nearly as obvious, and I wish we could do something like this in java/c++: for (a:A, b:B, c:C) ...

dkarl 6y ago

In my job I do a lot of code review of client code, mostly in Java, and some of it is particularly terrible. In fact, there’s one problem I see that is endemic. That’s where the code is “supposedly” object-oriented, but in fact, it doesn’t take advantage of any of the features of object orientation (no inheritance, no method overrides, and few if any uses of type substitution). In particular I see tons of code where there are these static “data” objects (a misunderstanding of another pattern from Martin Fowler, called the Data Access Object) and these “processing” objects that are, for the most part, just bags of procedures that operate on the data objects. The author really loses me here. I cut my professional teeth on Java, read Design Patterns while I was working my first job, and wrote his preferred style of OO code for years. I still use those OO features in my code, because they're still useful for a lot of things, but over the years I've learned other techniques as well that have helped me make my code simpler to understand and maintain. In the early 2000s I did see bad C-style Java written by people who didn't yet know how OO could be used for good, and if the author had written this in 2000 or even 2010 I could give them the benefit of the doubt that that's what they're complaining about, but if the author is seeing Java code in 2020 that they think isn't OO enough, it isn't because people don't know the style. It's because they know there are different choices that can often produce better results. I still run into people in real life who criticize code for not being written in that old 1990s/early 2000s style, for tackling problems with techniques other than inheritance and polymorphism, for daring to have data without behavior, etc. If you're satisfied with that old style and want to spend the rest of your career solving problems with it -- fine. But when other people move on, don't criticize them as if they haven't caught up.

ncmncm 6y ago
Yes, it is ridiculous to criticize Java coders for "misusing" their OO mechanisms. Those mechanisms are all they have, to build everything, whether OO makes sense in that niche or doesn't. So, probably more often than not, they are obliged to cobble together a substitute for what they need from the limited toolkit at hand, making a hammer do a screwdriver's job, as best they can. You have to feel sorry for them, and even sometimes admire them, making the best of adversity in their impoverished language. Then think of the poor C coders, lacking even that.

igouy 6y ago

> The simple lesson they taught me was this: > Don’t start any new programming task from scratch — always look in the Smalltalk image first to see what’s available and what has been already done before you start building anything new. Exactly. '"Contrary to the idea that a computer is exciting because the programmer can create something from seemingly nothing, our users were shown that a computer is exciting because it can be a vast storehouse of already existing ideas (models) that can be retrieved and modified for the user's personal needs. Programming could be viewed and enjoyed as an evolutionary rather than a revolutionary act. The frustration of long hours of writing linear streams of code and then hoping to see some aspect of that code execute was replaced by incremental development. Emphasis was placed on learning how to make effective use of existing system components (objects in the Smalltalk sense).' page 354 "Is the Smalltalk-80 System for Children?" https://archive.org/details/byte-magazine-1981-08/page/n367/mode/1up https://archive.org/details/byte-magazine-1981-08/page/n367/...

ncmncm 6y ago
It is hard to imagine such a miserable experience, shaping things written to do one thing well into other things doing something else less well, and again, never working with code that is exactly right for its purpose because it was expediently pressed into service against its nature. After long enough, the overwhelming majority of code in the system is doing nothing it was designed for, just well enough to get by and get on.
- igouy 6y ago
  Apparently it is hard for you to imagine, because your dismal description bears no relationship to actual experience.