4 ms·

It's interesting to switch your example to "Hash Table" instead of "Array". C is the language I'm most familiar with, and lacks one as part of the core langua

by nkurz 12y ago

It's interesting to switch your example to "Hash Table" instead of "Array". C is the language I'm most familiar with, and lacks one as part of the core language. So in fact, C essentially does say "Oh, just use the (associative) array pattern here. Start by rolling your own..." Does this mean that a design pattern is not an absolute, but relative to a language? Or does it mean that there is no clear distinction between syntax and pattern? I don't think that being one excludes being the other. We build arrays into the language so that they are easy to recognize and the pattern becomes a primitive tool. If you have to keep rolling your own, you'll never get past that. It will never become primitive, and you will stagnate. That is what those who object to design patterns object to: by thinking of them as elements of design -- the work of day-to-day programmers -- we won't provide linguistic abstractions that allow them to become primitive tools. Rather than fearing that naming a concept will cause stagnation, I think the opposite: the failure to have a "shorthand" for a commonly used feature means it will continually be reinvented. Once named, the concept can be pushed down to syntax while remaining a design pattern. The surprise (to me) is that the gulf between being part of the language and being an easy to add library is so great. Why is there no standard hash table that gets used in C? Why is there such a difference between core and non-core? I don't know what it is, but don't think it's for lack of syntax.

Retra 12y ago
>Rather than fearing that naming a concept will cause stagnation, I think the opposite: the failure to have a "shorthand" for a commonly used feature means it will continually be reinvented. Once named, the concept can be pushed down to syntax while remaining a design pattern. This is exactly the problem with design patterns. Once you recognize a design pattern, you should abstract it away and just use it from a library. Sometimes that is very hard to do. (E.g., Model-View-Controller.) But just because it is hard doesn't mean it is impossible. That kind of activity is a prime measure of success in computer science. Of course, we have the internet, but we still don't write languages that expect to pull needed tools from the internet in a smart way. You have to manually look for a library and include it yourself. When you write some code, it isn't being compared against a database of online code with your IDE telling you "Hey, someone else wrote something like this and it runs way faster and uses less text, check it out maybe?"

by nkurz 12y ago

Retra 12y ago

>Rather than fearing that naming a concept will cause stagnation, I think the opposite: the failure to have a "shorthand" for a commonly used feature means it will continually be reinvented. Once named, the concept can be pushed down to syntax while remaining a design pattern. This is exactly the problem with design patterns. Once you recognize a design pattern, you should abstract it away and just use it from a library. Sometimes that is very hard to do. (E.g., Model-View-Controller.) But just because it is hard doesn't mean it is impossible. That kind of activity is a prime measure of success in computer science. Of course, we have the internet, but we still don't write languages that expect to pull needed tools from the internet in a smart way. You have to manually look for a library and include it yourself. When you write some code, it isn't being compared against a database of online code with your IDE telling you "Hey, someone else wrote something like this and it runs way faster and uses less text, check it out maybe?"