Unofficial wish list status.(Jul 2008)

[Yigal Chripun]

superdan wrote:
> 
> good point, i was thinking of firefox and thunderbird too. then i
> realized the reality is, both ff and tb ended up integrating the most
> popular extensions in their core. why? because there is pressure,
> hence walter's point.
> 
The devil's in the details - Firefox integrated extensions as features
of the browser itself only when the extension "fixed" problems in the
core itself and/or the feature is general enough that it should have
been designed as part of the core. the Tab implementation for example
benefited from integrating functionally from extensions and the session
feature was added since it is general and useful for all FF users.

let's look again to eclipse to see this difference:
eclipse 3.4 added a new update manager with lots of new features. this
makes sense as part of the SDK of eclipse itself since all users of
eclipse will benefit from this. on the other hand, JDT will not ever be
needed by a c++ programmer (unless he decides to move to Java). same
goes for CDT, PDT, etc..
some features should be added to the core, and some will not ever be
general to be part of the core.
another example, the delicious extension will always be only useful for
delicious subscribers and should never be part of Firefox itself.

>> here's my educated guess: Sean uses erlang + D to get the same
>> benefits. he can have the feature sets of both languages with their
>> own lean & mean syntaxes that are geared toward their respective
>> feature sets. while if he had used one language with both feature
>> sets, than the syntax of that language would be much more
>> complicated in order to support all the features. C++ as an
>> example: its syntax is horrible due to the fact that it can do so
>> much.
> 
> no. its syntax is horrible because it has a shitty design. bjarne has
> made the tactical mistake of ignoring theoretical syntax matters and
> also compiler construction costs, in favor of what greedily looked
> most usable at the moment for the feature being designed. he is known
> for shooing away all those who opposed additions on grounds of
> syntactic and implementation difficulties. he pushed the fucking
> angle brackets over the dead body of pennello and the fucking export
> and two-phase lookup shit over everybody's dead body. what does that
> have to do with c++ being multiparadigm? nothing? correct!
> congratulations, you won a plasma tv set.
> 

Even with that in mind, that's not enough.
think of this this way:
what's the best way to design GUI?
probably to draw it in a visual designer and not using some API.
what's the best way to write a database query? probably SQL is the most
concise way to express that. etc, etc..
there's a whole paradigm of Language Oriented Programming that you
should look at. (MPS by jetbrains is a good example of that, I think)
the point is - when you restrict yourself to a specific domain you can
design the best way to express in that domain that may conflict with
other domains in a general language ( you probably wouldn't want to draw
all your "code" with a visual designer, while that's the best way to
express gui..)


> bjarne was strong on strategy and extremely weak in tactics. that can
> be clearly seen today as frozen into the language. walter is ok in
> both. his only problem is that he looks too much at c++, both up and
> down. when in doubt he does what c++ does, for example why the hell
> is this a pointer? makes no sense. well it is in c++. and so on.
> thank god const is not the same. in fact i could see a more definite
> break with c++'s shitty parts once walter got those new aides bartosz
> and andrei and i forgot the rest.

I totally agree with that point about C++. Walter always looks at C++
when unsure, and that isn't good IMHO. D is a new language that should
draw on the good stuff from all designs and languages instead of just
looking at C++. I disagree about const those. it is a departure from C++
 but not a big enough departure.
> 
>> if I only do OOP, I'll prefer a syntax like Ruby or Smalltalk or
>> something like that. if I want to do procedural code I'll prefer C 
>> syntax instead, but I definitely do not want to have a compromise
>> of both syntaxes in one language (we all know that a programing
>> language is an agreed upon compromise) that will not allow me to
>> express my OOP code in a concise OOP way and also will not allow me
>> to express my procedural code in a concise procedural way.
>> 
>> an everything-including-the-kitchen-sink language cannot provide
>> concise syntax for any of the paradigms it supports.
> 
> good language design is not about the kitchen sink as much as
> harmoniously accommodating multiple styles. nobody has shown that
> that can't be done.

Since a language is a compromise that's only true to an extent. Some
features are conflicting and you cannot design a language with all
features because of that. You cannot design a language both static and
dynamic ( At least to my knowledge ) since these two approaches are
conflicting designs. And both ways have cons and pros. Can you design a
language with the benefits of both, without the drawbacks of both?