Unofficial wish list status.(Jul 2008)

[superdan]

Sean Kelly 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 agree.  In fact, I'd bet that imperative applications will dwindle 
> over time because such code inherently resists parallelization. 

this is a logical fallacy. you haven't shown that all or most code will need paralellization. you'd need to show that for your point to stand.

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

...on today's architectures. if hardware transactional memory makes it things will change quite a bit.

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

yeah and that will be documented in pure vs. impure functions and in invariant vs. const/mutable data. this is great. d is not a convention-based language like c++.

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

that again is a logical fallacy. i like messing with cars. i have an amazing 18V drill that i use for a ton of stuff - screws, bolts, holes, adjustments, rust removal, you name it. does that mean i'm only trying to use that tool for everything? sure not. but that doesn't make it less loveable.

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

i agree. let's drop this word parallel.