Unofficial wish list status.(Jul 2008)

[superdan]

Yigal Chripun Wrote:

> Walter Bright wrote:
> > Sean Kelly wrote:
> >> Walter Bright wrote:
> >>> But, you said you didn't wish to mix functional and imperative
> >>> programming? I don't understand.
> >>
> >> Not in the same language.  One reason being the impact it will have on
> >> managing projects in D.  C++, for example, supports a sufficiently
> >> diverse set of programming methodologies that large projects in it
> >> tend to be a mess.
> > 
> > I agree that diverse paradigm support can lead to a mess. On the other
> > hand, to be a mainstream language I think one must support diverse
> > paradigms because programmers are diverse. Additionally, nobody really
> > knows yet which horse is the right one to back for multicore
> > programming, but functional certainly is a favorite.
> > 
> > I disagree that using multiple languages for one project is a good idea,
> > unless one language is hosted by the other (like emacs/elisp). Trying to
> > get two languages produced by different vendors to consistently work
> > together across platforms and differing upgrade schedules can be a
> > prescription for a lot of extra work. Is learning two different
> > languages really easier than learning two different paradigms in the
> > same language?
> > 
> > 
> >> Regarding the D mixed functional / imperative approach, another issue
> >> I have with it is that it's exactly the reverse of the Erlang / C
> >> model. While Erlang / C is functional for control structures and
> >> imperative for optimization points, D looks like it will be imperative
> >> for control and functional for optimization.  Plus, I really like the
> >> concurrency model in Erlang.
> > 
> > A side note: Everyone complains about feature bloat in Microsoft Word.
> > What the world needs is a lean, mean word processor. But the problem is,
> > customer Bill says: "That's great, but I need feature #543. Not having
> > it is a deal breaker for me." Customer Sue says: "I'd buy the lean &
> > mean one, but I need feature #1678. Everything I do is based on that."
> > And so on. Feature creep is the result of inexorable and unrelenting
> > pressure for them.
> 
> The word example is wrong in that, in your example, bill doesn't need
> feature #1678, and sue doesn't need #543. The answer to that is a model
> similar to eclipse: both sue and bill can use eclipse but since bill
> works with c/c++ he can get a pre-packaged version with CDT which is
> much smaller than the entire eclipse project, and sue can get her
> eclipse pre-packaged with JDT since she works with Java. This is why
> Eclipse is so popular and supported by many large companies like oracle,
> IBM, etc.. The same goes to the popular browser Firefox and its
> extensions. No need to bundle everything like Microsoft word does, it's
> much better to have a system to allow users to integrate features they
> require beyond the lean & mean core.

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.

> 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.

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. 

> 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.