Unofficial wish list status.(Jul 2008)

[Sean Kelly]

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 agree.  In fact, I'd bet that imperative applications will dwindle 
over time because such code inherently resists parallelization.  But I 
very much believe that there is an ongoing need for systems languages, 
and I can't envision a functional systems language.  Such languages must 
allow mutable state.

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

It comes back to that semantic barrier I mentioned in my other post. 
With everything in a single language, I think in team programming it 
will be inevitable that imperative code will "bleed" into areas that are 
intended to be functional, purely as a result of the personal styles of 
the programmers involved.

As for learning multiple languages... web development already involves a 
ton of different protocols, technologies, and languages, so I think 
there's precedent that this isn't a huge obstacle for most teams.  I 
would personally rather have a set of specialized tools than one tool 
which can do everything but isn't really ideal for anything.

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

I'd say that the word processor should be modular and that the requested 
features should be sold as plug-ins.  Then customer A gets his lean mean 
word processor with exactly the features he wants, and the same for 
customers B and C.  This obviously isn't possible with a language 
however, so I'm inclined to say that this is a false analogy.


Sean