Unofficial wish list status.(Jul 2008)

[Sean Kelly]

superdan wrote:
> 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.

I wasn't making a logical argument, but rather stating an opinion.  The 
current trend indicates that we're hit a wall with performance scaling 
in a single CPU, and yet the demand for increased software performance 
continues.  I know that some tasks are difficult to execute in parallel, 
but if increased performance is desired then something has to give. 
Also, many client-facing applications are already somewhat parallel 
because they are event-driven.  Games can throw AI in one or more 
threads, etc.  They don't have to, but it's the best way to exploit 
current trends in hardware performance scaling.

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


Hardware transactional memory is awesome.  I'm not too fond of purely 
software transactional memory though.  The overhead tends to be too 
great in most instances

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

Yeah, but to cross these barriers casting is typically required.  And I 
hate casting :-)  But you're still right.

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

I'd argue that you're still using the drill for things it was intended 
to do.  After all, a drill is just a portable electric engine, really.

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

Works for me.


Sean