I was just thinking: isn't the next logical step in programming language design the creation of a language in which one can use design patterns by simply declaring that one wants to use a particular one. In other words don't we need a language that has design patterns built in? That way we would be able to write code so much quicker. I don't know if such a think would ever be possble but just throwing an idea around.
Personally I think this is over stepping the mark. Many IDEs have common pattern template built in if you want a way to shortcut writing the boiler plate code involved in a pattern. Its better in the IDE than in the language itself, especially since many patterns start out as a good way of doing things and quickly end up as anti-patterns. [ November 06, 2006: Message edited by: Paul Sturrock ]
A pattern isn't intended to be always implemented the same way. It is meant to be adapted to the situation at hand.
The value of a design pattern isn't in a code template, but in the relationship between the problem context, the solution idea, and the resulting context.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
My reaction isn't quite as negative as those of our colleagues here. I think that what you describe doesn't have a place in a systems programming language, but in a special-purpose language, it's not only possible and desirable, but already here. There are any number of Web and GUI frameworks that enforce a Model-View-Controller pattern as the primary structural pattern. Some of them enforce a Command pattern on top of that (Struts, for example). I think it might make sense to extend this idea even further, and (for example) further formalize the use of Observers, Decorators, and other patterns within these frameworks. Such a framework would not be suitable for every application, but Struts is a big deal already even though you can't write DOOM in it.
Let me give an example for this. I was looking at one of our early Java web projects. On this project the team wasn't allowed to use JSPs. So they wrote a set of Java classes which walked through a structure of domain objects, and produced the appropriate HTML for a particular domain object. They noticed they were getting duplication in the code for spitting out common HTML structures for fields, tables, etc. So they pulled all of the HTML spitting code out into a second utility class that had methods like renderField (String label). When they did this they noticed that they could make drastic changes to the entire web application's appearance just by altering code in the utility class.
Later on I saw a different project. They were using XSLT to turn XML into HTML pages, much as I do on this site. But they needed to support multiple organizations who wanted the same data displayed in their own format. So they split the transformation into two steps, first producing an intermediate XML with elements like field and table, with second stage actually producing the HTML. They would have a different second stage for each organization.
Although it seems obvious as I write it now, but when I first saw these two projects I sensed there was something similar in their approaches. However it took me several months to understand the key point - splitting a transformation into two steps: logical page and physical (HTML) page. This is the "core of the solution" which I wrote up as Two Step View. One of the great intellectual challenges of patterns is finding and isolating this core amongst all the surrounding stuff that's needed on real projects.
The two projects had the same pattern, very different code. What should a language support? You might be able to build some patterns into libraries and languages, but you'd never cover all the possible ways to apply a given pattern.
Still, there is another way to package patterns for reuse. Gregor Hohpe writes in his blog Patterns in the Wild about a couple vendors building components for his messaging patterns. Cool idea.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Ernest Friedman-Hill: I think it might make sense to extend this idea even further, and (for example) further formalize the use of Observers, Decorators, and other patterns within these frameworks.
Mhh, I might miss the obvious, but somehow I don't see how that would be similar to providing language support for *implementing* a design pattern.
As I think about it, a Design Pattern is a solution to a design problem that is inherent to a specific design approach - for example, the GoF design patterns all are OO design patterns. The next logical step in programming language design would probably try to solve those problems in a new way that would totally make go away the need for those patterns.
For example, in Assembler a common "design pattern" - as far as I know - was/is to use jump tables to provide flexibility in configuring what exact implementation of a subroutine to use at runtime. Higher level languages such as C provid function pointers to solve the same problem, and OO languages have polymorphism for the same. The languages didn't just evolve to ease the use of the pattern, but provided new abstractions in a way that we actually don't really know any longer what exactly the solution to the problem looks like (does Java use jump tables to implement polymorphism? Should I care?)
I guess something similar is happening with Aspect Oriented Programming. Many of the problems it solves I would conventionally solve by using the Proxy or Decorator pattern, for example. Aspects don't just make it easier to implement those patterns, they provide a whole new way to solve the problem in a (arguably) more elegant way - and they will probably lead to a whole new set of design problems, wich will cause the emergence of AO related design patterns.
Does that sound reasonable?
author and iconoclast
I've just been thinking some lately about what I'm starting to see as an inherent contradiction in the common choice of very flexible programming languages (Java, Python, Ruby) to solve the same mostly unvarying problem over and over again (writing CRUD applications.) The real purpose of Struts and other similar frameworks is to remove some of that flexibility, reducing complexity in the process. I'm wondering if the logical conclusion of that evolution would be a language in which you could express "use the Visitor pattern here" without being able to implement Visitor from scratch in the same language.
If you do this in a framework, it doesn't work. You just have a rigid framework that is hard to use with other frameworks. But what if it was the language itself that did this -- then all frameworks and libraries based on that language would interoperate smoothly without adapters.
Some problems need the flexibility of a general-purpose language. I posit that a large number of problems don't, though. In fact, I think much of the need for a general-purpose language behind many Web frameworks is that you need the general-purpose language to adapt between mismatched components. If there was only ONE WAY to implement pattern X, then you wouldn't need to do any adapting at all.
I'm not saying this would be the language of choice for all applications and all situations. It might, however, be exactly what you need for DrugCo's latest HR application -- and such is the majority of code being written today.
I think that, for example, the whole model-based programming movement can't succeed without a language like this; but with such a language, it makes a lot of sense.
Just me thinking out loud. Feel free to disparage me at will.
Joined: Jul 11, 2001
I think those languages exist, and they too do fully away with the need for those patterns.
For example, we have a product that (as far as I know - I'm not working on that project) generates a fully functional CRUD application from just an arbitrary XML Schema. Of course the default settings aren't perfect for every user, so you can use a meta language to influence the layout, validation, search options etc.
But I have yet to see a CRUD application that, when you take a closer look, didn't have some special cases that really only could reasonably be implemented using a general purpose programming language, where you really need the flexibility. In my experience, often the need for these features only arise after the customer actually uses a first version of the system. Your mileage may vary, of course...