"Dmitry A. Kazakov" <·······@dmitry-kazakov.de> wrote:
>> Hmmm. There could be something to this. We need Visitor because we
>> don't have multiple dispatch. We need Command because we don't have
>> closures. Etc, etc.
>>
>> On the other hand, I refuse to believe that the perfect language ought
>> to be defined as one in which there are no repeating structures. I
>> think every language will always be composable into patterns of use.
>
>Once old patterns became features of the programming languages new ones
>would appear at a higher abstraction level of new features...
>
>There will be an ever-growing hierarchy of languages of increasing power
>with some patterns on top of it.
For the most part, I agree with much of what people have said in this
thread. A repeating pattern often indicates a design flaw *somewhere*.
However, is it a flaw in the language, or is it the lack of using a
generalized framework that handles this pattern elegantly for you?
In many cases, I think it is the latter. Therefore, repeating the pattern
may be entirely wrong, but solving the pattern by creating generalized
frameworks may be a perfectly reasonable alternative than adding a feature
to the language that solves the problem. Anytime you're adding a feature to
the language, I think you are starting to counter yourself in that now
you've created something language specific which is not general, and you're
heading in the wrong direction.
I believe in making languages as powerful and flexible as possible, in such
a way that the fault should always lie with the frameworks, and not the
language. With languages like Smalltalk and Lisp, I think we are getting
much closer to that mark than some other languages.
I agree that patterns is an indication that there are design flaws
somewhere, but I don't think the fault is always with the language, but
often with frameworks or the lack of use of a generalized framework.
Perhaps sometimes it is a fault with the language, but not because it's
missing a feature to directly address the problem, but it's missing
something else fundamental *and general* that enables you to create a
framework that solves this pattern in an elegant way.
So the goal is this:
Design a language that is incredibly simple and yet ultimately powerful,
with the *minimum* amount of capabilities itself, whereby all the
capabilities lie in the frameworks. Then create some frameworks that are
again incredibly simple yet ultimately powerful, with the minimum amount of
code and complexity.
Perhaps it's harder we might think, because with adding of every feature to
address a problem, you're increasing the complexity and countering your
end-goal. This I think, becomes much more of a fine art than it is pure
logic, and everyone seems to have their own subjective take on what meets
those goals and what doesn't.
Ian
---
http://www.upright.net/ian/