Simple Question

[Peer Reynders]

Originally posted by Ilja Preuss:
Which slide(s) do you get that from?

Well it was somewhat overstated, however:

(2) Design Patterns in Dynamic Languages

Study of the design patterns book: 16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern

Design Patterns in Dylan or Lisp

16 of 23 patterns are either invisible or simpler, due to:

First-class types(6): Abstract-Factory, Flyweight, Factory Method, State, Proxy, Chain-Of-Responsibility.

First-class functions(4): Command, Strategy, Template-Method, Visitor

Macros(2): Interpreter, Iterator

Method Combination (2): Mediator, Observer

Multimethods (1): Builder

Modules (1): Facade

Originally posted by Ilja Preuss:
I think the answer is in that a pattern is more than just a code template.

Well from Norvig's perspective the Strategy pattern simply addresses a "limitation of the implementation language". (Much in the same way that J2EE Patterns often address idiosyncrasies of the J2EE environment).

For the more complicated case of Abstract Factory he goes to point out:

Pattern: Abstract Factory

Dynamic versions needs only the Window classes. The classes themselves serve as factories. This works because classes are first-class values. We can say make(c).

And for Observer see "Observer with Method Combination".

Originally posted by Stan James:
If it's a one-line implementation, that's very cool.

However this probably highlights why some members of the Lisp community were a bit perplexed when the GoF patterns got the all that attention back in 1995: "What is all the fuss about? We've been doing this stuff since the 1960s with a handful lines of code."
[ March 13, 2007: Message edited by: Peer Reynders ]

[Ricky Clarkson]

I'm glad that my points kicked off this discussion, and that the negative tones turned out to be an illusion.

Ilja seems to confuse polymorphism, which is a type-based form of late binding, with late binding itself, which is not necessarily type-based.

For example, a C program that needs a shared library is using some late binding, but a Java program written to interfaces is using polymorphism, which is a specific kind of late binding. I haven't thought this through, but there might be no 'real' difference between polymorphism and any other kind of late binding. For example, if you call a shared library an object, then you can say that calling its functions is polymorphic. Wikipedia seems to define polymorphism as a type-based thing, whereas there is no type in a shared library function invocation. You could certainly pretend there is a type, or reason that there is an implicit type, in the same way that i==sqrt(-1).

The similarity of the two terms may mean that polymorphism logically equals late binding, but the common definition of polymorphism doesn't equal the common definition of late binding. In other words, Ilja might not be wrong, just be using the word 'polymorphism' in an atypical way.

Sounds to me like a Strategy-Factory then.

Not really - an object with references to two functions isn't actually a factory - it doesn't create anything, or appear to create anything.

I'm curious: when would a design pattern be worthy its name, in your opinion?

Before a suitable abstraction can be found to remove it. Taking patterns outside their usual context, Bridge is a pattern worthy of its name, in terms of the real-world constructs that get you over rivers. Performing some mental acrobatics, we can imagine that in the future we might construct roads in the sky unsupported. Calling part of that road a bridge just because it happens to go over a river would be odd; i.e., the Bridge pattern has been obsoleted.

In programming, such physical limitations don't exist in the same way. As long as an abstraction doesn't cost a significant amount more than the repeated pattern, there's always a good way of making a design pattern obsolete.

I think I said this earlier in the thread; I used to use GOSUB and RETURN to emulate functions before I knew what functions were. I was implementing the Gosub-And-Return-Emulating-Functions pattern. Now I use functions directly, I don't think about the Gosub-And-Return-Emulating-Functions pattern anymore. My abstraction level is higher. The pattern is gone. It would be absurd if I still thought in terms of GOSUB, just like it would be if a pilot flew his plane along the route marked out by a road, respecting the speed limits of the road. It would be similarly absurd for an experienced Lisp programmer to think in terms of a Strategy, or a Visitor.

And how many of the GoF patterns, for example, do you know?

Begin Sarcasm. Oh, I love this kind of question. End Sarcasm. I've, at various points, learned a little about all those patterns, and a lot about some. I suppose the next one is "Have you worked on any real-world projects?", to which the answer is "Yes", but nothing that's failed yet. I imagine that makes it difficult to answer those interview questions about what happens when things go wrong.

Well, I agree that design patterns can be language specific, and that some can be quite simple. I don't see how it directly follows that they don't have value, though.

The reason that they're language specific is that the language isn't flexible enough to handle the abstraction, so the pattern has to be implemented, repeatedly. If I designed a programming language that didn't support recursion, you could translate your recursive algorithms into iterative ones with a stack object, and you could give that a pattern name, but it doesn't mean that the pattern is worth its name, just that the language I designed isn't.

I don't know about special variables, but I have a very strong dislike for the Singleton pattern, anyway. They are just globals in disguise - with all their typical problems.

It's worth learning about special variables, because they are globals that you can temporarily change the value of. They remove some of the problems that globals have in other languages. Even if you never use that, you can at least appreciate that there is a kind of global that isn't retarded.

If examining a zillion Lisp programs would not reveal the GoF patterns, would it reveal a whole different set of patterns? Patterns are just common solutions to common problems. I'd rather expect to see Lisp gurus around the world solving similar problems in similar ways that could be written up in the GoF style pattern language. Do patterns show up a weakness in the language, or show off its strengths?

Examining all that code would certainly reveal patterns, because whenever a programmer comes up with an abstraction, he does not typically make it available as part of a globally-available library. Similarly, when a programmer starts to think of an abstraction, he implements it rather than looks for it in a globally-available library, quite often, unless it's non-trivial.

That is, a pattern that exists among developers is that of limited code-reuse. I'd like to see that change, but Intellectual Property rules make it a bit hard to change it. For example, I'd like a Java IDE to tell me that when I write a class called PersistentIndexList that implements List, that someone else has written a similar class, which passes the tests I just wrote, and here's the source..

We're still only partway towards getting rid of that pattern.

Or maybe some language has reached the place where every line of code sings of the business domain. I'd much rather write and read code about insurance and call centers than http sessions and strategy factories.

I think the best we can hope for at the moment is that the business code is all about the business domain, and that there is some bespoke other code to provide the abstractions that the business code needs, to stay so focussed.

Compare "can we use a Strategy there" with "can we pass in a function there that gets called inside the algorithm so that we can customize it?"

How about: "Can we use a callback there?"?

[Peer Reynders]

Originally posted by Ricky Clarkson:
For example, a C program that needs a shared library is using some late binding

Actually I think you are talking about dynamic linking here, not dynamic binding.

Douglas C. Schmidt: Dynamic Binding C++ (pdf)

Note, dynamic binding is orthogonal to dynamic linking...

Dynamic Linking is done by the operating system/loader. In C++ dynamic binding is accomplished with vtables; in Java the JVM is responsible for dynamic binding.
[ March 13, 2007: Message edited by: Peer Reynders ]

[Ricky Clarkson]

Wikipedia seems to agree with my use of late binding - http://en.wikipedia.org/wiki/Name_binding

[Ilja Preuss]

Originally posted by Ricky Clarkson:
Wikipedia seems to agree with my use of late binding - http://en.wikipedia.org/wiki/Name_binding

Well, it's probably true that a shared dll is an instance of late binding, although I don't see how the wikipedia article strongly supports that notion.

It's certainly *not* "extreme late binding", though...

[Ilja Preuss]

Originally posted by Peer Reynders:

Actually I think you are talking about dynamic linking here, not dynamic binding.

Is dynamic binding the same as late binding?

[Peer Reynders]

Originally posted by Ricky Clarkson:
Wikipedia seems to agree with my use of late binding

While wikipedia is a convenient resource, one should always read the contributions with a healthy dose of skepticism (true for anything you find on the net or even in print). Also you are using the term in two different contexts. Dynamic linking and dynamic binding may be used in a similar fashion when you are talking about the operating systems support for the use of shared libraries. The dynamic binding we were talking about is implemented as part of the programming language. Dynamic library binding and dynamic binding as implemented for a programming language are two entirely separate mechanisms.

In the context of strongly typed languages polymorphism and dynamic binding are often used interchangably since polymorphism is implemented with dynamic binding. In the context of dynamic languages which tend to be weakly typed, dynamic binding just happens to be normal way of doing things. So again, the context determines when you can use certain terms interchangably.

Originally posted by Ilja Preuss:
Is dynamic binding the same as late binding?

In the discussion of polymorphism as implemented in a strongly typed language the two are usually used interchangeably. Once you remove that context all bets are off for the simple reason that dynamic binding doesn't have to be late.

As far as I can tell lazy binding is simply a variation of late binding in that it is trying to emphasize the idea of binding "at the latest possible moment". Again this term is used both in the context of shared libraries and programming languages even though the underlying mechanisms compare like apples and oranges.

PS: Why do you think lawyer's make such a profitable living in english speaking countries?
[ March 14, 2007: Message edited by: Peer Reynders ]

[Ilja Preuss]

Originally posted by Ricky Clarkson:
Ilja seems to confuse polymorphism, which is a type-based form of late binding, with late binding itself, which is not necessarily type-based.

It's not my impression that the term polymorphism is that well defined. Some people even call C++ templates "static polymorphism"...

But we could easily agree to the point that it's "extreme late binding" what I'm interested in, and that to me the core of OO is how to make use of it to manage code dependencies.

quote:
--------------------------------------------------------------------------------
Sounds to me like a Strategy-Factory then.
--------------------------------------------------------------------------------



Not really - an object with references to two functions isn't actually a factory - it doesn't create anything, or appear to create anything.

You are right, I misunderstood. But that really sounds like a plain Strategy to me, not like "not a pattern at all".

Taking patterns outside their usual context, Bridge is a pattern worthy of its name, in terms of the real-world constructs that get you over rivers. Performing some mental acrobatics, we can imagine that in the future we might construct roads in the sky unsupported. Calling part of that road a bridge just because it happens to go over a river would be odd; i.e., the Bridge pattern has been obsoleted.

True - unless in situations where for some reason we can't use those new roads (on Mars perhaps? ).

That analogy doesn't fully connect to what you said before, though - I understand you to say that we should be able to create the bridge once, and then use the same bridge again everywhere we need one. But as long as we need bridges, its probably best to adapt them to the situation at hand, to have every bridge look slightly different - even if we are able to use the same basic design idea, the same pattern.

I like that analogy. A book on building bridges probably has a number of examples of bridges in it. You are not supposed to exactly one of those bridges when you need to build a new one, though, you are supposed to take the ideas and translate them to a solution for your specific situation. The same is true for the books on patterns, and for the source code examples they contain.

And it wouldn't suprise me at all when while building a steel bridge, you wouldn't see much value in the patterns provided by a book on stone bridges. That doesn't mean that stone is a generally inferior building material, though, or that the patterns for building stone bridges don't have value.

In programming, such physical limitations don't exist in the same way. As long as an abstraction doesn't cost a significant amount more than the repeated pattern, there's always a good way of making a design pattern obsolete.

True. I don't support the notion that the costs are *always* insignificant, though. First, there surely is a cost in using a non-mainstream programming language - let alone if there is already a significant amount of code available in a different one. And second, there is a cost in using the predefined abstraction, namely loss of flexibility - and sometimes even increased complexity. (This is also true for the use of libraries and frameworks instead of homegrowing a solution.)

quote:
--------------------------------------------------------------------------------
And how many of the GoF patterns, for example, do you know?
--------------------------------------------------------------------------------



Begin Sarcasm. Oh, I love this kind of question. End Sarcasm.

I'm sorry if you read that question as belittling or something. I was seriously interested in your experience level with the GoF design patterns, simply because it changes how I can communicate about them with you. I should have been more explicite about my motivitation, I guess.

I've, at various points, learned a little about all those patterns, and a lot about some.

Cool!

I suppose the next one is "Have you worked on any real-world projects?"

Oh, I hate that question, too. After all, it doesn't even have any meaning - what are non-real-world projects?

I think, though, that knowing about the experience level of your communication partner can make it easier to, well, communicate.

The reason that they're language specific is that the language isn't flexible enough to handle the abstraction, so the pattern has to be implemented, repeatedly.

I see how that would be true for some of the design patterns. I could even see how it would be a useful heuristic, or a "language smell" - to make us think about how a language might be able to evolve.

A hard and fast rule, though - I'm far from convinced.

If I designed a programming language that didn't support recursion, you could translate your recursive algorithms into iterative ones with a stack object, and you could give that a pattern name, but it doesn't mean that the pattern is worth its name, just that the language I designed isn't.

First, an example for a pattern that existed because of a language shortcoming doesn't really show that all patterns exist only because of language shortcomings.

Second, I'd guess that the pattern would have been worth its name if you had to work in a language that didn't support recursion.

It's worth learning about special variables, because they are globals that you can temporarily change the value of. They remove some of the problems that globals have in other languages. Even if you never use that, you can at least appreciate that there is a kind of global that isn't retarded.

It's an interesting concept. I have to admit, though, that to me as someone who is mostly used to the OO paradigm, it doesn't look very attractive. It sounds more like a road to maintenance hell to me, though that might be strongly biased by not being used to the functional style of programming in general.

That is, a pattern that exists among developers is that of limited code-reuse. I'd like to see that change, but Intellectual Property rules make it a bit hard to change it.

There are other reasons, too. Code-reuse doesn't come without a cost - and while I'm all for removing duplication and reusing code, blindly trying to drive code-reuse to the max wouldn't be economically sound, in my opinion.

quote:
--------------------------------------------------------------------------------
Compare "can we use a Strategy there" with "can we pass in a function there that gets called inside the algorithm so that we can customize it?"
--------------------------------------------------------------------------------



How about: "Can we use a callback there?"?

That doesn't say the same thing - a callback could be an implementation of a Strategy, an Abstract Factory, an Observer and probably a number of other patterns. It's missing the intent - it's simply less specific than a pattern name.

[Ilja Preuss]

Originally posted by Peer Reynders:
In the context of dynamic languages which tend to be weakly typed

That doesn't match my understanding of the terms. As far as I know, Smalltalk (for example) is dynamically, strongly typed, while C is statically weakly typed.

Static/dynamic typing refers to whether the type of a variable is checked at compile time (which often goes hand in hand with the need to declare the type).

Weak/strong typing is about whether the type of an "object" is checked at runtime.

[Mr. C Lamont Gilbert]

For clarity I prefer to say it like this

The private methods of a certain class can only be accessed by the following two categories :

A- Any method inside the same instance of the class.
B- Any method inside a different instance of the class.

This does not have anything to do with inner classes which do not violate this principle. That is, many consider static inner classes to be proper classes and not really true inner classes.

I think I wrote Java code for maybe 1-2 years before I realized B was allowed.

[Mr. C Lamont Gilbert]

I believe overloading is polymorphism, but is not an example of late/dynamic binding. I believe overriding is polymorphism, and is an example of late/dynamic binding. At least in Java.

[Peer Reynders]

Originally posted by Ilja Preuss:
Weak/strong typing is about whether the type of an "object" is checked at runtime.

I think you are correct - I should have used static/dynamic instead of strong/weak. It seems that some confusion exists around theses terms.

However once that is cleared up it seems that "productive programming langauges" tend to be dynamically typed, but strong typing doesn't seem to get in the way.

Ada static/strong/safe

C static/weak/unsafe

C++ static/strong/unsafe

Java static/strong/safe

Javascript dynamic/weak/safe

Lisp dynamic/strong/safe

Pascal static/strong/safe

Perl dynamic/weak/safe

PHP dynamic/weak/safe

Python dynamic/strong/safe

Ruby dynamic/strong/safe

[Peer Reynders]

Originally posted by Mr. C Lamont Gilbert:
I believe overloading is polymorphism.

Personally I think it was a big mistake when 'they' started to apply the term ad-hoc polymorphism to overloading. I can see that overloading can make an algorithm apply to a number of unrelated types but to call that (ad-hoc) polymorphism only serves to muddy the waters and dilutes yet another term towards relative uselessness. Overloading should just be just overloading; polymorphism should be about the liskov substitution principle.

[Frank Carver]

Ilja wrote: That analogy doesn't fully connect to what you said before, though - I understand you to say that we should be able to create the bridge once, and then use the same bridge again everywhere we need one. But as long as we need bridges, its probably best to adapt them to the situation at hand, to have every bridge look slightly different - even if we are able to use the same basic design idea, the same pattern.

I think this analogy will bear a bit more depth.

Just as with design patterns, you can get pre-built bridges, re-usable bridge components ( http://www.baileybridge.com/ ), and even transport whole bridges from one context to another ( http://en.wikipedia.org/wiki/London_Bridge_%28Lake_Havasu_City%29 ).

However, none of those solutions provide a specially good fit for any particular crossing problem. Each feature to be spanned presents different characteristics: width, depth, possible locations for pillars or supports, height difference at either side, local weather and other geographical problems etc.. Similarly, the needs of the crossing vary just as much: load capacity, breadth/number of lanes, desired lifespan, cost constraints, available skills and materials, even as far as aqueducts for carrying water or bridges which need to be high enough (or lift/swing/move) to allow tall objects to pass underneath.

To my mind the position of design patterns in software is still analogous. The term "bridge" encompases a wide range of problems and solutions. Any specific implementation of a bridge, however flexible and/or simple its design, can only solve a subset of the problem range. Even if you culvert all the rivers and roll flat all the hills and canyons in your local area so that you no longer need bridges, the concept of a bridge still has merit. You may not ever need a bridge, but someone else, in a different situation might.

One key aspect stressed very heavily by the original design patterns community is that a particular approach or piece of code is only considered to be a pattern once it has been observed "in the wild" at least three times. This implies that the pattern has at least seemed to be a useful solution to th eproblems faced by several different people. Each pattern also has a detailled description of the situations in which it is applicable, and the situations in which it is not applicable.

So the bridge analogy still holds. In the reportedly wonderful, flat and even, land of Lisp there may be no use for a bridge, but for it to be recognized as a pattern there must be a use elsewhere.

Likewise, I'm sure there are patterns specific to the land of Lisp. For example in the reportedly wonderful, flat and even, midwest of the USA it's common to see patterns such as long straight roads, straight county and state boundaries, subdivisions and city blocks etc., none of which are at all common here in Europe. I could make the bold claim that if you "simply" align all your roads and boundaries with geographical features there is no need for any of those patterns, but that would be to foolishly ignore the situation elsewhere.

I guess my analogies have rambled a little, but my point is that a pattern is still a pattern, and can still be useful and valuable, even if you never personally encounter a use for it.

[Stan James]

Now you're just making me misty eyed for Nebraska and Kanasas. The roads are so straight that they have corrections (jogs) for the curvature of the earth.

Aside from that I'm mostly standing behind you and nodding in agreement.
[ March 15, 2007: Message edited by: Stan James ]

[Peer Reynders]

Originally posted by Frank Carver:
In the reportedly wonderful, flat and even, land of Lisp there may be no use for a bridge, but for it to be recognized as a pattern there must be a use elsewhere.

The "Design Pattern" status of the "Bridge Pattern" was never challenged, neither in this thread nor in Norvig's presentation. 16 of the remaining 22 were challenged. There is still the notion out there that design should be independent of the implementation (language). Personally I think that point of view becomes unrealistic once you have to make design decisions that can be realistically constrained by your 'choice' of implementation environment. However with some the notion still exists that design should transcend implementation.

Originally posted by Frank Carver:
One key aspect stressed very heavily by the original design patterns community is that a particular approach or piece of code is only considered to be a pattern once it has been observed "in the wild" at least three times.

Maybe these "observations" need to be in sufficiently different contexts. Seen it three times in C++; C++ pattern maybe but not necessarily a design pattern. Seen it once in C++, twice in Java; it might be a useful pattern in the C family of languages, maybe even in object-oriented languages, so we might be getting closer to a "design pattern" but then again we might not. Also seen it in Smalltalk? - we might have a winner here.

I�m sure that there are many patterns that are tremendously useful to specific communities � however at what point should a useful pattern deserve to be called a �design pattern�? Or maybe a new classification is needed to emphasize the general applicability of patterns like the �Bridge Pattern�.

Another thought: While GoF didn�t use UML as such (but something like it), both the GoF and UML are decidedly Object-Oriented. So the use of OO Design Patterns and OO Modeling/Notation could conceivably constrain us into OO solutions.

[Ilja Preuss]

Originally posted by Peer Reynders:
The "Design Pattern" status of the "Bridge Pattern" was never challenged, neither in this thread nor in Norvig's presentation.

I understood Frank to refer to the bridge analogy here, not to the GoF Bridge pattern.

There is still the notion out there that design should be independent of the implementation (language).

In my not so humble opinion, that's just plain illogical. Designing is about structuring code so that we can work effectively with it. It seems obvious to me that how we structure code would depend on what tools the language supports to structure the code.

I�m sure that there are many patterns that are tremendously useful to specific communities � however at what point should a useful pattern deserve to be called a �design pattern�?

When it is a pattern for a design problem, in my opinion. I wouldn't have any problems with design patterns that only make sense in functional languages, for example.

Another thought: While GoF didn�t use UML as such (but something like it), both the GoF and UML are decidedly Object-Oriented. So the use of OO Design Patterns and OO Modeling/Notation could conceivably constrain us into OO solutions.

Only if we constrain ourselves to using those tools, or so it seems to me.

[Frank Carver]

Does anyone remember "algorithms" ? They are a bit out of fashion these days, but it could be argued that an algorithm is a design pattern for imperative/procedural languages.

Most of the famous algorithms don't make use of any object-oriented features, but they are still useful even in an OO language. At its heart the Quicksort in the Java standard APIs is still a quicksort. A Quicksort in Forth or Lisp would likely look pretty different to the Java one, but it would still be a Quicksort though.

And, just like Design Patterns, a lot of the value is in the name. Even though hardly anyone needs to actually code a Quicksort these days, giving it a name enables us to discuss it, look up its properties, advantages and disadvantages, and so on.

[Peer Reynders]

Originally posted by Ilja Preuss:
Only if we constrain ourselves to using those tools, or so it seems to me.

Have we just come full circle here?

A: Why should I learn about X?
B: Because without knowledge of X you will be constraining your ability to solve problems in an effective manner.

Otherwise 'A' could easily end up with Worse-is-Better solutions. Worse because the solution isn't as effective in one or more aspects as it could be and better because 'A' doesn't have to leave the paradigm that 'A' is familiar/comfortable with. Worse-is-better solutions aren't always good enough.

Originally posted by Ilja Preuss:
In my not so humble opinion, that's just plain illogical. Designing is about structuring code so that we can work effectively with it. It seems obvious to me that how we structure code would depend on what tools the language supports to structure the code.

Ilja, I agree with you - but just a few months ago I had to listen to someone who has been working in software development for many years declaring quite sincerely that it would be perfectly reasonable to design an extension to a legacy system in a full-blown object-oriented manner while the implementation environment was restricted to "business logic in PL/SQL" and some aging 4GL GUI tool that barely supports single class inheritance. And this was only the latest incidence. Over the years I've had this type of experience repeatedly - usually from people who should know better. In retrospect I would have to conclude that they were only aware of a narrow spectrum of highly similar implementation environments - in which case it would not matter which implementation environment was chosen for their design. Maybe "design is independent from the implementation" is one of those myths.

Originally posted by Frank Carver:
And, just like Design Patterns, a lot of the value is in the name.

I don't think anybody can disagree with that. Any pattern or idiom name with a common meaning within the community gives you the power of abstraction - it makes communication more efficient and it creates the opportunity to express relatively complex constructs in more simple terms on a higher level.


Peter Norvig: Teach Yourself Programming in Ten Years
Eric Steven Raymond: How to become a Hacker
[ March 16, 2007: Message edited by: Peer Reynders ]

[Pj Murray]

Originally posted by Frank Carver:
Does anyone remember "algorithms" ?

Good question......

What have algorithms gone out of fashion?

[Peer Reynders]

Originally posted by PJ Murray:
What have algorithms gone out of fashion?

Well, "algorithm" may have lost its buzz-word status. However the GoF writeup of the strategy design pattern uses "algortihm" all over the place, simply because its one of the more straight-forward applications of the Strategy pattern (i.e. providing replacable implementations of the same algorithm or even different algorithms for the same task).

Algorithms are also quite common in Generic Programming - there it is possible to implement an algorithm once against an implicit interface. Of course in Java you can do the same by using an explicit interface.