This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java long-term given that it's not abstracting away a majority of known design patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>

http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

BA

Brad Anderson wrote:
> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
> long-term given that it's not abstracting away a majority of known design
> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
> 
> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

I've found that when I translate straightforward C++ code into straightforward D code, the size of the (source) code drops 30%. That means that D *is* abstracting away commonly used C++ patterns.

On Wed, 13 Sep 2006 16:15:03 -0700, Walter Bright wrote:

> Brad Anderson wrote:
>> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java long-term given that it's not abstracting away a majority of known design patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
>> 
>> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
> 
> I've found that when I translate straightforward C++ code into straightforward D code, the size of the (source) code drops 30%. That means that D *is* abstracting away commonly used C++ patterns.

(Design Patterns) != (C++ patterns)

Yes, we all agree that D is a lot more efficient than C++ when it comes to source code density. However, that has very little, if anything, to do with "design patterns" as a programming paradigm.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
14/09/2006 9:45:13 AM

Derek Parnell wrote:
> On Wed, 13 Sep 2006 16:15:03 -0700, Walter Bright wrote:
> 
>> Brad Anderson wrote:
>>> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
>>> long-term given that it's not abstracting away a majority of known design
>>> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
>>>
>>> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
>> I've found that when I translate straightforward C++ code into straightforward D code, the size of the (source) code drops 30%. That means that D *is* abstracting away commonly used C++ patterns.
> 
> (Design Patterns) != (C++ patterns)
> 
> Yes, we all agree that D is a lot more efficient than C++ when it comes to
> source code density. However, that has very little, if anything, to do with
> "design patterns" as a programming paradigm.

I think it has a lot to do with it, but I think it's pointless to argue the issue. The issue to me (and hopefully to most programmers) is one of productivity. Are you getting your programs developed faster with D or not?

I know I'm getting a personal big productivity boost from D - and time is money.

On Wed, 13 Sep 2006 17:25:37 -0400, Brad Anderson <brad@dsource.org> wrote:

>This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java long-term given that it's not abstracting away a majority of known design patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
>
>http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

Eh!

I'm sure that languages will naturally get higher level over time, and that as a result the number and complexity of patterns needed to achieve any given result will get smaller. But you're missing three crucial points...

1.  As languages get higher level, software generally gets more
    complex. New, higher level patterns arise to cope with that
    complexity. So you need at least as many patterns, just different
    ones.

2.  There's not much to gain by adding compiler support for
    pre-existing patterns. Patterns exist because they are easy. If
    they were hard, people would find other patterns.

    The real complexity is in how patterns are combined to form an
    overall design.

3.  The most useful new language features are never based on
    pre-existing patterns anyway.

The final point is the most interesting. What were the most obvious big advances in programming languages? - well, just off the top of my head...

- Structured programming.
- Functional programming.
- Object oriented programming.
- Exceptions

NONE of these was a pattern prior to becoming a language feature.

Structured programming resulted from the observation that some programmers had a 'cleaner' style than others, and their code tended to be more reliable. But there were no hard 'if' or 'while' or similar patterns before then. People with a more structured style still invented whatever 'structure' suited each problem individually. The idea of having a predefined set of block structures was a language feature first. It only became popular to imitate those specific block structures in assembler when they were already popular in high level structured languages.

Functional programming can be considered a similar thing, also heavily influenced by math and computer science theory. A functional 'style' of programming has become more popular as a result of people using actual functional languages. To the extent that there was a choice in Lisp (which is strictly speaking an imperitive language) this was a general style thing, not a pattern to solve any specific problem.

As for object oriented programming, prior to Smalltalk (the first object oriented language) there was no such thing. The patterns for writing object oriented code in non-object languages came later - as hacks for getting C to work with object systems like COM, for instance.

Object oriented programming was originally a set of ideas and metaphors which were aimed at making a whole bunch of programming tasks easier. The nearest anyone had got to C++-style object orientation, for instance, was bunging a few related values into a parameter block with maybe a few function pointers for company. Virtual tables - no. Inheritance - no.

And there is a good solid reason why this is the case. Treating 'object oriented programming' as a pattern in a non-object language is an absurdity. It doesn't make life easier - it makes all kinds of things more complex and awkward, and far more error prone. Sure, it is a flexible and powerful technique - but that flexibility and power costs in terms of fiddly error-prone code overheads. The only serious reason to do it is because you have no choice, e.g. if you need to interface code in a non-object language with existing object-based code.

Exceptions were never a pattern before they were added to a language either. Dealing with stack unwinding manually would be a absurd - OK, there's the old C longjmp, but that was never used in a pattern that could be honestly compared with modern exception use. Exceptions were invented as a new and original idea, and added to a language as an experimental feature, and they worked.

So, creating genuinely useful new language features has never been a matter of just adding support for pre-existing patterns. And no surprise, really. As I said, the whole point of everyday patterns is that they are easy. If they were hard, people would find different patterns instead.

Add language support for pre-existing patterns one at a time, and you get a bloated dinosaur of a language with very few benefits to justify that bloat. And your style stagnates because of that huge commitment to always using those same patterns, which don't mix well with new ideas. And let's face it, use a compiler-supported pattern and you need to look up the right syntax and keywords out of the thousands in your every-single-pattern-gets-special-syntax language, instead of simply expressing the pattern using general purpose language features.

All you prove is that you have no creativity or problem-solving skills. That you can't spot the general themes in the problems that happen most often, or that you are unable to create new general purpose ideas that could simplify a wide range of problems.

A key goal of language design should always be to get the most bang for you buck. Having a full toolkit is a good thing, but each tool should give real value.


Actually, I don't see any reason to worry about this. Looking at what's happening now, I don't see any sign of a catastrophic change for the worse. After all...


The D 'scope' statement makes a whole bunch of cleanup tasks easier. It isn't the RAII pattern, but it can replace the RAII pattern in many cases and in others it can complement RAII, making it simpler and more reliable.

Aspect oriented languages (Aspect Java, Aspect C++) were created to solve problems with cross-cutting requirements. There's a lot of 'include this code at this point in every method matching this regular expression' kind of stuff. If Aspect oriented programming was ever done as a pattern, it was 'scattering similar fragments of code all over the place'. Aspect orientation as a pattern would be absurd, but aspect orientation as a language feature makes a lot of sense.

I could go on, but everyones bored. So I'll just say that if you really want better support for existing patterns, the obvious thing you should ask for is better template support. That can help automate many patterns, not just one or two.

-- 
Remove 'wants' and 'nospam' from e-mail.

Brad Anderson wrote:

> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
> long-term given that it's not abstracting away a majority of known design
> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
> 
> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
> 
> BA
Adding to Steve's lengthy post, I will say the anonymous delegates and the lazy eval stuff is way cool and will take some time to flesh out common idioms. (Not to mention the template magic tossed about around here).

So far I haven't missed C++ at all.

-DavidM

On Wed, 13 Sep 2006 17:14:46 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> On Wed, 13 Sep 2006 16:15:03 -0700, Walter Bright wrote:
>> 
>>> Brad Anderson wrote:
>>>> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java long-term given that it's not abstracting away a majority of known design patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
>>>>
>>>> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
>>> I've found that when I translate straightforward C++ code into straightforward D code, the size of the (source) code drops 30%. That means that D *is* abstracting away commonly used C++ patterns.
>> 
>> (Design Patterns) != (C++ patterns)
>> 
>> Yes, we all agree that D is a lot more efficient than C++ when it comes to source code density. However, that has very little, if anything, to do with "design patterns" as a programming paradigm.
> 
> I think it has a lot to do with it, but I think it's pointless to argue the issue. The issue to me (and hopefully to most programmers) is one of productivity. Are you getting your programs developed faster with D or not?
> 
> I know I'm getting a personal big productivity boost from D - and time is money.

Sorry Walter, I did it again ;-)

I wasn't arguing with you, just being a little pedantic. The concepts of 'design patterns' and 'programming language (syntax) patterns' are not the same thing, that's all.

And yes, D is definite productivity booster when compared to C++, as far as I can see.

I don't think there's much purpose in having direct language support for 'design patterns' as those are very high-level abstractions, however it would be easier to implement such patterns in D if its syntax patterns were improved. Such as improving templates and mixins, both in functionality and usability. Adding language support for full closures and co-routines would also help. But of course, these should not delay v1.0 ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
14/09/2006 10:49:03 AM

Brad Anderson wrote:
> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
> long-term given that it's not abstracting away a majority of known design
> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
> 
> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
> 
> BA

Adding to Steve and David, I think the fundemental problem in the article's arguments is that "design patterns" are not complicated tasks that everone has to implement all the time.
Even if they were, it's still not neccessary to integrate them with the language itself if it's possible to implement them in the standard library.
For example, everyone needs to output text to the screen, but why should it be a part of the language itself when it could be implemented as a library function?
Do most people write containors and iterators by themselves all the time? Do they ever have to?

Comparing that with manually implementing subroutines in assembly is redeclious.

Brad Anderson wrote:
> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
> long-term given that it's not abstracting away a majority of known design
> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
> 
> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns

Excellent article, thanks, Brad!

I totally agree with the article.

In a larger context, that's exactly what Man has been doing all our history. Anytime there's an often enough recurring pattern, it is "made to go away", or at least made easier to accomplish. (Dragging major objects: invent the wheel, food too tough to chew or digest: invent cooking, too long to swim over: invent boat, too hard to figure out the needed field area for crop to feed the village: invent arithmetic, too much arithmetic to do: invent calculator, find yourself typing the same things: write a macro, etc.)

If we'd have been content with just executing the discovered patterns, we'd still hunt by running, kill with our bare hands, and flog with our own teeth.

Also, this is exactly how the brain works. Tasks composed of a number of discrete subtasks are glued together and automated so that they become a single task. Happens all the time. A child has a heck of a job producing a single phoneme ("a", "k", etc.) because they require the orchestrated cooperation of an incredible number of small muscles -- which he has to individually and simultaneously control. Later it becomes just automatic to say any single phoneme. Then he has to learn to say words, which he initially does by choosing and putting these into a sequence. Later the same happens with words to construct sentences.

A beginning programmer tediously chooses which iterating construct to use, carefully figures out the starting values and ending values, the choice of loop variable names, and whether the check is at the beginning or the end. And with the seasoned programmer, this entire task is both thought out and even typed into the source code "without a thought". It's become invisible.

And in one sense, programming itself is just doing this! The programmer creates custom routines so he avoids writing repeated code. And a very good programmer creates subroutines even for things he only uses once, so that he can manipulate that part of code as a single named entity in his head. Clarity of thinking gives clarity of code.

---

D has indeed come a long way further than C++ or C, and I believe it is exactly because it has followed the idea in that article.

I think there are two separate things a "better" language can do:

 - make those "patterns" go away
 - give the programmer tools so he can make his own patterns go away

The latter is needed because every programmer has to live in his own unique domain, with its unique possibilities and obstacles. No programming language can be expected to be perfect for every task, but the easier it is to make the patterns "go away", the more time the programmer has for the real issues at hand.

The expression power of the language is key in this. And a large part of it is the template system, which (congratulations, Walter, and thanks) actually has turned out just incredible.

Back to the former, that is achieved of course by syntax and semantics that obviate as much as possible the need to do "the mundane stuff". Another important part is well written, coherent and orthogonal libraries that are easy and efficient to use.

---

Reducing the number of design patterns one uses can not, and should not  be the goal. As we make existing patterns "go away", we find that we use the time won to do other things, and they invariably do contain patterns themselves, which we will in time discover. But if we keep on working like this, in the end we are able to produce both in quantity and in quality a lot more. And that should be the goal.

Brad Anderson wrote:
> This might be a bit OT, but I often wonder if D is going to succeed C/C++/Java
> long-term given that it's not abstracting away a majority of known design
> patterns.  Or, maybe that's just D 2.0 and we need to be patient.  <g>
> 
> http://newbabe.pobox.com/~mjd/blog/2006/09/11/#design-patterns
> 
> BA

Bah, an over-simplistic article with great claims and little substance.

Some design pattern are caused by flaw in the original language, in other language they will be invisible, that's quite obvious..

But claiming that *all* design pattern comes from language flaws as the author imply??

Uh? Show me the proof: big claims need strong proofs!

And in the article, there is no such proof, not even a beginning:
a waste of electrons.

Regards,
RenoX