The Death of D1. (Was Tango vs Phobos)

[Sean Kelly]

superdan wrote:
> Sean Kelly Wrote:
> 
>> superdan wrote:
>>> Sean Kelly Wrote:
>>>
>>>> Brian Price wrote:
>>>>> My take on the Tango vs Phobos situation is:
>>>>>
>>>>> For production use the only real choice is D1 (D2 being alpha) and it looks like
>>>>> there are going to be so many changes in the language that going from a D1 app to
>>>>> a D2 app is going to require more than a bit of work and thought.
>>>> It's also worth mentioning that whatever is decided, no changes are 
>>>> likely to occur with D1 / Phobos1 because that version of D is frozen. 
>>>> So from a practical standpoint I think Tango and Tangobos will continue 
>>>> to be the preferred approach for development under D1.
>>>>
>>>>> So, restricting the answer to D1, Tango seems to be a more full featured , robust,
>>>>> and maintained library than Phobos.  I'd expect that to change in D2 and expect
>>>>> the natural choice there will be Phobos (barring a ton of work by the Tango crew).
>>>> Pretty much.  Though having some sort of shared runtime /may/ affect how 
>>>> some of the features in tango.core are exposed.  I would obviously 
>>>> prefer if Phobos just built on top of Tango as with the Tango / Tangobos 
>>>> solution for D1, but that doesn't seem likely to happen.
>>> glad to hear that. there's quite a few of us who aren't quite fans of tango. i'd rather wait for bartosh walt & andrei to put their weight behind phobos2. 
>>>
>>>>> Regardless of the choice of library for use with D1, moving to D2 with either
>>>>> library looks like a chore since Phobos seems to be undergoing some (much needed)
>>>>> significant changes from D1 to D2 versions.
>>>> Yup.
>>>>
>>>>> As to the larger topic, D is potentially caught on the horns of a dilemma: D1 is
>>>>> not a significant enough advance on current languages to justify a move even if
>>>>> there were no library concerns; D2 may well be enough of a step forward to justify
>>>>> a move but there is the issue of timing.  My take is that if the upcoming C++
>>>>> standard makes it into compilers used in common production before D2 is ready for
>>>>> prime time that D may never gain a real foothold in mainstream use.  I'm hoping
>>>>> that the D2 team sets a deadline and leaves some things for a future D3 rather
>>>>> than miss the window of opportunity.
>>>> In my opinion, the benefits of D1 over comparable mainstream languages 
>>>> are quite substantial but difficult to quantify.  The elegance of the 
>>>> language tends to produce vastly more maintainable code than C++, for 
>>>> example, which is a huge win for team development.
>>>>
>>>> As far as D2 is concerned, I think it's really too early to say.  My 
>>>> current opinion is that the feature additions in D2 impact the syntax in 
>>>> such a way that they eliminate much of the advantage of D1--stemming 
>>>> from elegance and simplicity--in exchange for largely theoretical 
>>>> benefits.  But D2 is still in development so who knows.
>>> u realize if u don't want that to look like fud u better back that up. i mean we could be sittin' on our ass and muse on them theoretical & practical issues. or we could write d2 and bring real arguments to the table. so how much d2 code have you written.
>> A bit.  I ported the Tango runtime to D2 once.  The rest comes from 
>> parallels with C++.  For example, one of my major issues with D2 is the 
>> syntax of the const design.  It's theoretically pretty slick, but I'm 
>> not at all happy with the prospect of maintaining duplicate function 
>> implementations simply to overload on const.  This is one of the things 
>> that drove me crazy about C++, and D2 is even worse in this regard 
>> because it has not only 'const' but 'invariant' as well.  And don't say 
>> "don't like const, don't use it," because that isn't an option for me as 
>> a library developer.
> 
> not sure why you keep on sneaking that `theoretically' word in. duplicate code blows, theoretically and practically. yeah that pisses me off too. i managed to avoid duplication thru concepts. dont 4get u only need to do that when you want the qualifier in the return type. often you don't. you can also rely on auto because now it deduces the return type for you.
> 
> i recall walter promised he'll look into that. but i'm not holding my breath eh. constrained templates do the work for me no problem.
> 
>> Another issue is more to do with code portability than with D2 itself. 
>> That is, the meaning of 'const' has changed between D1 and D2, with 
>> 'invariant' effectively replacing what 'const' was used for in D1.  This 
>> makes it impossible to create code that has the same meaning in both 
>> versions of the language.  Eventually, D1 will be forgotten and no one 
>> will care about this any more, but for Tango right now this is a 
>> significant issue in my opinion.
> 
> look @ the full half. for tango right now it's an issue. tomorrow it won't.
> 
>> Much of the rest is cosmetic--the sort of thing Walter likes to call 
>> "barn door" issues.  I hate that we're stuck with 'enum' to signify 
>> manifest constants, for example.  Heck, I hate that D supports anonymous 
>> enums at all, but making this an official feature in D2 is just crazy 
>> IMO.  Maybe not a big deal to you, but what drew me to D in the first 
>> place were largely what I'd consider cosmetic improvements over C++.
> 
> it's a big issue to me just in the opposite direction. the c enum is brain damaged. even dennis ritchie so much as acknowledged it. (and he won't budge on the definition syntax. so i guess that does mean somethin'.) the c++ enum grew one lonely neuron. problem is we got just used to the wrong. we won't blink an eye at
> 
> enum { a = 1, b = 2 };
> 
> but we get pissed at
> 
> enum { a = 1.1, b = 2.5 };
> 
> i myself was pissed to no end there was no way to define true constants in c++. so im super happy walter fixed that. how others can actually have a problem with that is beyond me.
> 
> i had an old ford when i was a kid. it had a fidgety starter. only dad and i could start the car. just like in bttf. one day i'd opened it already so i fixed the starter. guess what. somehow i missed the old bad starter. i'd gotten used to it. but then i had a reason. now sis could start the car too.
> 
> enum ain't a problem. get over urself already.

My problem isn't with the concept, it's with the word.  That's why I 
said it's a "barn door" issue.  To me, the meaning of 'enum' is 
"enumerated type."  It has nothing to do with declaring manifest 
constants.  That's why I also think that anonymous enums should be 
illegal.  Just give us a new label for this stuff ("manifest" was 
proposed).  Or heck, make constants not addressable and eliminate 
storage for the altogether.  I can't think of a single instance in my 
time as a programmer where I actually wanted to take the address of a 
constant.  What's the point?  You can't modify it anyway.

>>  > i know i switched to d2 as soon as it was out. i have nuff freedom @
>>  > work to write at least part of my code in whatever. the more versions
>>  > arrive with new stuff the more d1 looks to me like an ass-backwards
>>  > neanderthal tool made of sticks bear claws and silex. could even go as
>>  > far as sayin' d1 ain't ever gonna make it to prime time. it's just a
>>  > cute lil language that has a few merits marred by its issues. all
>>> languages  are like that. d2... d2 feels different because it is
>>  > different. larger ambitions to address real problems in innovative
>>> ways.  and leave no shit behind like most languages do
>>  > in pursuit of the mother of all features.
>>  > and the new team has much more knowledge than walt alone. (sorry
>>  > walt. but i guess u'd agree.)
>>
>> Yeah, D1 is a cute little language, but it's eminently usable.  All D2 
>> really has going for it at the moment is the const stuff, and I quite 
>> honestly don't care about that.
> 
> you gotta be intercoursin' kiddin' me. hellooo. concepts. i came to the point where i call bullsolidwaste on unconstrained templates. all templates should be constrained. also destructors and the postblit business. now i can have automatic cleanup like in c++. better yet there's gc so i dun need to clean up a lot of stuff. only files'n stuff.

Concepts can be done in D1 as well.  The D2 stuff is just syntactic 
sugar for:

     void fn(T, bool cond : true = SomeTest!(T))( T val ) {}

I've been doing this sort of thing in Tango forever.  That isn't to say 
that I don't want real concept support--I totally do--it just isn't 
worth some of the other baggage in D2 right now.  Tell you the truth, 
what I probably want most from D2 is overload sets.  Function 
overloading in D1 just plain sucks and is a constant annoyance for me. 
Fixing this alone is enough to make me put up with a lot of other stuff 
I don't like.  But on the flip side I can't actually use it yet because 
Tango has to work on D1 as well.

> guess someone's not keepin' with'em news.

Nah.  I only care about features I can't fake in D1 already.

>>  This isn't because I don't work on 
>> projects large enough to require it--my last project was a few million 
>> lines of C++ maintained by a decent sized team--but rather because I 
>> feel that inelegant syntax is a greater issue for maintenance than 
>> language support for data mutability.  I'd simply rather have nothing 
>> than something that I think will produce unmaintainable code.
>>
>>> so sean. how much d2 did you write. hope you agree it's hard to claim it has no practical advantages if you haven't practically used it. the irony, eh.
>> Not enough to speak with experience, quite honestly.  Perhaps that will 
>> chance with this shared runtime business.
> 
> then quite honestly ur naysayin' is tenuous.

I said at the start that it's my current opinion and may change, so 
yeah, it's totally tenuous.


Sean