5 ms·

I'm partial of the explanation of DP as missing language features. In fact, Design patterns all use the human compiler to check for correctness of implementatio

by Shorel 9y ago

I'm partial of the explanation of DP as missing language features. In fact, Design patterns all use the human compiler to check for correctness of implementation. PaulGraham said "Peter Norvig found that 16 of the 23 patterns in Design Patterns were 'invisible or simpler' in Lisp." With this mindset, functions (or subroutines) are language patterns in assembler. In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

pasabagi 9y ago
Isn't there a point where it's more desirable to have 'features' available through patterns, than through the language itself? The larger and more complex the language grows, the more cognitive overhead - so programmers of a hypothetical 'perfect' future language might still use patterns, simply so the language didn't grow out of reasonable proportions.
- sideshowb 9y ago
  If code is data then in principle you could implement them as libraries rather than language extensions. I don't use lisp or haskell enough to know whether someone has already done this. That said I'm also not convinced that it would help in many cases. What would you enforce about a wrapper for example other than it's constructed from one argument and returns a different type containing a reference to the original one? If you're not able to do that yourself then would a wrapper library really be any use?
larzang 9y ago
That's basically the role of frameworks. Any web application I build is going to need at least some subset of functionality common to all web applications, and implementing everything from first principles is absurd, so I use a framework. Someone else building something completely different with the same language doesn't need those things, so cooking my needs into the language itself is just going to add overhead or force unwanted design choices on to them, but there's probably a different framework for whatever they're doing too.
mikekchar 9y ago
Clearly having a language that makes it easy to implement common solutions to problems is a good thing. I don't think this means we should stop studying those solutions though. To take a notorious example, visitor pattern is just a work around for the lack of multiple dispatch. However, I do not have enough fingers to count the number of times I've had to explain the benefits of multiple dispatch to people. And perversely I can say the same about the number of times I've heard people conflate multiple dispatch with functional programming! The truth is that sometimes I have an extensible group of types with relatively static operations, and sometimes I have a relatively static group of types with extensible operations. The techniques I employ to write generic code in both cases is different. Another great example is the reactor pattern (a la Douglas Schmidt), which many people view as being the cost of using Node, rather than being a very useful technique for controlling real time processing.
HumanDrivenDev 9y ago
In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. I've heard people mention that a lot, but the only concrete example the ever give is "you don't need the strategy pattern because of first class functions", which is doesn't hold up when you examine it closely.
KKKKkkkk1 9y ago
Serious question. How many of YC's startups implement their products in Lisp? Is it > 0? Why so few?
- tome 9y ago
  Seems to be a nonsequitur.
ernst_klim 9y ago
>I'm partial of the explanation of DP as missing language features. It is a way to encode basic features in terms of simple standard building blocks: objects. However, I think that explaining everything in terms of objects is a terrible idea. Objects are extremely complex already, it is a bad idea to use them as a basic entity. Just compare lambda semantic rules (there are only three of them for untyped lambda calculus), and an object's semantic. Later is much more complex. I think that the complexity of objects led to the complexity of patterns, making them verbose and ugly. Just compare visitor and pattern matching, or command and higher order function. It is true that in more advanced languages having more features patterns become invisible, but I thing they also would become invisible if they were composed of more simple entities.
- mikekchar 9y ago
  An object is literally an encapsulation of state. Imagine having 3 functions which do something with points on a graphical plane. The first 2 parameters in each function represent the x and y positions of the point. You can make an OO "class" by simply grouping those three functions. You can make an object by partially applying x and y to the three functions. You can "respond to messages" by calling those functions. I agree with you that many OO languages add unnecessary syntax and lack features, but objects are not related. We need to encapsulate state and we like to group functions into cohesive modules that are related to the state that they are going to deal with. We do this whether we use object nomenclature or not.
geezerjay 9y ago
> I'm partial of the explanation of DP as missing language features. I find this argument to be rather disingenuous as it ignores the fundamental purpose of design patterns: communicate intent through a common language. I mean, 9 out of 10 patterns are nothing more than specific uses of inheritance and polymorphism. Technically, they don't require anything more than what inheritance and polymorphism already offet, and the only difference is precisely why and how inheritance and polymorphism are used in a specific problem. I mean, what's the fundamental difference between a state pattern and a strategy patern? Hell, isn't the strategy pattern a rather direct use of polymorphism? Is the language even missing anything at all? Of course not, because the purpose of using design patterns is to communicate intent and describe precisely what was the problem and more importantly how it was solved.
- loup-vaillant 9y ago
  The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Or direct expressions of those concepts? Communicating intent through a common language is all and good, but then why that language isn't formally encoded in the compiler? > Is the language even missing anything at all? This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem.
  - geezerjay 9y ago
    > The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Because they add or take nothing from the language. Arguing for the needless addition of these keywords makes as much sense as arguing in favour of camelCase or polish notation or "m_" and "s_" prefixes. They add nothing to the language, they are redundant and they are used to convey meaning alone. Therefore, what problem would be solved by adding useless keywords to a language, particularly when those making these claims come from a point of ignorance and lack of experience? > This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem. This makes no sense at all. Rather straigh-forward applications of polymorphism don't vanish if you call them by different names.

by Shorel 9y ago

pasabagi 9y ago

Isn't there a point where it's more desirable to have 'features' available through patterns, than through the language itself? The larger and more complex the language grows, the more cognitive overhead - so programmers of a hypothetical 'perfect' future language might still use patterns, simply so the language didn't grow out of reasonable proportions.

sideshowb 9y ago
If code is data then in principle you could implement them as libraries rather than language extensions. I don't use lisp or haskell enough to know whether someone has already done this. That said I'm also not convinced that it would help in many cases. What would you enforce about a wrapper for example other than it's constructed from one argument and returns a different type containing a reference to the original one? If you're not able to do that yourself then would a wrapper library really be any use?

larzang 9y ago

That's basically the role of frameworks. Any web application I build is going to need at least some subset of functionality common to all web applications, and implementing everything from first principles is absurd, so I use a framework. Someone else building something completely different with the same language doesn't need those things, so cooking my needs into the language itself is just going to add overhead or force unwanted design choices on to them, but there's probably a different framework for whatever they're doing too.

mikekchar 9y ago

Clearly having a language that makes it easy to implement common solutions to problems is a good thing. I don't think this means we should stop studying those solutions though. To take a notorious example, visitor pattern is just a work around for the lack of multiple dispatch. However, I do not have enough fingers to count the number of times I've had to explain the benefits of multiple dispatch to people. And perversely I can say the same about the number of times I've heard people conflate multiple dispatch with functional programming! The truth is that sometimes I have an extensible group of types with relatively static operations, and sometimes I have a relatively static group of types with extensible operations. The techniques I employ to write generic code in both cases is different. Another great example is the reactor pattern (a la Douglas Schmidt), which many people view as being the cost of using Node, rather than being a very useful technique for controlling real time processing.

HumanDrivenDev 9y ago

In the other extreme, if you use a sufficient advanced language, all your language patterns are actually checked by the compiler and/or interpreter, instead of the programmer. They stop being patterns and are just language features. I've heard people mention that a lot, but the only concrete example the ever give is "you don't need the strategy pattern because of first class functions", which is doesn't hold up when you examine it closely.

KKKKkkkk1 9y ago

Serious question. How many of YC's startups implement their products in Lisp? Is it > 0? Why so few?

tome 9y ago
Seems to be a nonsequitur.

ernst_klim 9y ago

>I'm partial of the explanation of DP as missing language features. It is a way to encode basic features in terms of simple standard building blocks: objects. However, I think that explaining everything in terms of objects is a terrible idea. Objects are extremely complex already, it is a bad idea to use them as a basic entity. Just compare lambda semantic rules (there are only three of them for untyped lambda calculus), and an object's semantic. Later is much more complex. I think that the complexity of objects led to the complexity of patterns, making them verbose and ugly. Just compare visitor and pattern matching, or command and higher order function. It is true that in more advanced languages having more features patterns become invisible, but I thing they also would become invisible if they were composed of more simple entities.

mikekchar 9y ago
An object is literally an encapsulation of state. Imagine having 3 functions which do something with points on a graphical plane. The first 2 parameters in each function represent the x and y positions of the point. You can make an OO "class" by simply grouping those three functions. You can make an object by partially applying x and y to the three functions. You can "respond to messages" by calling those functions. I agree with you that many OO languages add unnecessary syntax and lack features, but objects are not related. We need to encapsulate state and we like to group functions into cohesive modules that are related to the state that they are going to deal with. We do this whether we use object nomenclature or not.

geezerjay 9y ago

> I'm partial of the explanation of DP as missing language features. I find this argument to be rather disingenuous as it ignores the fundamental purpose of design patterns: communicate intent through a common language. I mean, 9 out of 10 patterns are nothing more than specific uses of inheritance and polymorphism. Technically, they don't require anything more than what inheritance and polymorphism already offet, and the only difference is precisely why and how inheritance and polymorphism are used in a specific problem. I mean, what's the fundamental difference between a state pattern and a strategy patern? Hell, isn't the strategy pattern a rather direct use of polymorphism? Is the language even missing anything at all? Of course not, because the purpose of using design patterns is to communicate intent and describe precisely what was the problem and more importantly how it was solved.

loup-vaillant 9y ago
The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Or direct expressions of those concepts? Communicating intent through a common language is all and good, but then why that language isn't formally encoded in the compiler? > Is the language even missing anything at all? This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem.
- geezerjay 9y ago
  > The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Because they add or take nothing from the language. Arguing for the needless addition of these keywords makes as much sense as arguing in favour of camelCase or polish notation or "m_" and "s_" prefixes. They add nothing to the language, they are redundant and they are used to convey meaning alone. Therefore, what problem would be solved by adding useless keywords to a language, particularly when those making these claims come from a point of ignorance and lack of experience? > This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem. This makes no sense at all. Rather straigh-forward applications of polymorphism don't vanish if you call them by different names.