www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - why a part of D community do not want go to D2 ?

reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
hello,
I have a question (i would like understand), they are many important people of
D community who do not want go to D2, why ?

thanks for answer
Nov 06 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
bioinfornatics:


 hello,
 I have a question (i would like understand), they are many important people of
D community who do not want go to D2, why ?


There aren't good D2 compilers yet beside DMD, so they use what they can. And
D1 and D2 aren't equal, D1 is simpler (and quite less fussy regarding
immutability), so people that like D1 may not like D2 and people that like D2
may not like D1. Some features of D2 are not light (immutability) and some of
the other features are seen by some people as not so essential ( property and
other things). This is just speculation of mine, I don't know what they think.

Bye,
bearophile
Nov 06 2010
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
On Sat, Nov 6, 2010 at 6:11 PM, bioinfornatics <
bioinfornatics fedoraproject.org> wrote:


 hello,
 I have a question (i would like understand), they are many important people
 of D community who do not want go to D2, why ?

 thanks for answer


Large amount of bugs?

(That's one of the many reasons, I think).
Nov 06 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 07 Nov 2010 02:11:59 +0300, bioinfornatics  
<bioinfornatics fedoraproject.org> wrote:


 hello,
 I have a question (i would like understand), they are many important  
 people of D community who do not want go to D2, why ?

 thanks for answer


Many of the D2-only features are half-baked:
- pure, nothrow and inout are not implemented fully (barely usable as is)
- immutable and shared still have many issues
-  property is a no-op

D1 also has Tango which is still *a lot* better than D2 Phobos, but there  
is a work in this area, and it's being slowly improved.
Nov 07 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-07 10:50, Denis Koroskin wrote:

 On Sun, 07 Nov 2010 02:11:59 +0300, bioinfornatics
 <bioinfornatics fedoraproject.org> wrote:


 hello,
 I have a question (i would like understand), they are many important
 people of D community who do not want go to D2, why ?

 thanks for answer


 Many of the D2-only features are half-baked:
 - pure, nothrow and inout are not implemented fully (barely usable as is)
 - immutable and shared still have many issues
 -  property is a no-op

 D1 also has Tango which is still *a lot* better than D2 Phobos, but
 there is a work in this area, and it's being slowly improved.


Actually I think he wants to use D2 with Tango but wondering why nobody 
is interested in porting it.

-- 
/Jacob Carlborg
Nov 07 2010
parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
So D community will be split in 2. And D1 continue to evolve without D2
community, D1 frontend is open source and he coulb be used for improve and fix
D1
Nov 07 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/7/10 6:33 AM, bioinfornatics wrote:

 So D community will be split in 2. And D1 continue to evolve without
 D2 community, D1 frontend is open source and he coulb be used for
 improve and fix D1


The current situation and the dynamics are quite interesting, and I am
looking forward to witnessing how things will unfold.

There is a community for which D1's offering is just fine. They've used
D1 long enough to use it idiomatically and to derive better enjoyment
than from the likes of Java or C++. The gain in power, albeit marginal,
is present. That base has been understandably annoyed by D2 being
backwards incompatible with D1, and has a dim view of the advantages
brought about by D2's additions (mainly concurrency and its
paraphernalia - immutability and no default sharing). The fact that the
implementation of the newest features is incomplete fuels arguments
against D2. The immaturity of alternative back-ends (gdc, llvm for D2
are both quite young) contributes to the perception that D2 does not
offer a net advantage when compared with D1.

It is my perception (though I might be wrong) that the dichotomy has
become to some extent political. D2 offers little political incentive to
a Tango port. Tango is currently the de facto standard library for D1 as
the vast majority of D1 users use D1 and Tango in conjunction, which
precludes use of the underpowered Phobos1 (D1's de jure standard
library). Due to Sean's work on making druntime independently available,
porting to D2 would lower Tango's status from the standard library to
one of the libraries that may be used in conjunction with Phobos2.

So in the current equilibrium D1 and Tango form a bond: D1 is platform
offering Tango exclusivity as the standard library and Tango is the
library that makes D1 attractive. The risk assumed by that bond
(assuming the assumption above is correct) is isolation in a position
condemned to inevitable obsolescence.

As far as language proper is concerned, D1 has the option of becoming an
incompatible fork by choosing to evolve its own features independently
of dmd. That process could be greatly helped if a strong language
designer would decide to work on D1. I see that as a possible but
unlikely scenario (unlikely because a language designer would have to be
primarily politically motivated to make such a decision).

 From the D2 side, it all boils down to the question: are D2's additions
worthwhile or not? D2 places bets on concurrency, correctness, and
opt-out safety. Those bets looked much riskier two years ago than they
look now, but still carry a risk. Also, as I mentioned above, currently
the implementation of many new features is superficial. This is caused
by the current development model of the reference compiler - features
are implemented without a formal description. There is disproportionate
reliance on the compiler test suite to effectively define the language
by exercising all of its features and feature combinations. The test
suite is undeniably useful, which makes it even more difficult to
explain its problems. Some more complicated features are first
implemented to simply make a narrow test pass, and then spend a long
time in an "almost-well-defined" state in which bug reports are fixed
and added to the test suite. I believe that the informal language
development is curre
ntly the single most important liability of D. (That is, somewhat
ironically, a matter in which D2 is at an advantage to D1.)

The insufficient implementation of new features propagates the
perception that D2 is unstable, although the more conventional, D1-like
subset of D2 is as solid in both languages. But then the perception is
justified, because one would want to use D2 primarily for its new,
unique offerings. A longer term perception problem is that some might
think the _design_ of such features has unsolvable issues, which hurts
the image of the language. I know of no major design flaws, but that is
only an academic argument in wake of perennial implementation
insufficiencies.

TDPL's publication brought about a change of pace in D2 from design to
implementation. Currently there is strong focus on the 64-bit port,
which is a gating issue. Work on D2's standard library has increased in
intensity and scope. I have good reasons to believe that such
developments will continue growing at a robust pace for the foreseeable
future. Probably participation to the standard library will increase
faster than participation to the compiler implementation, mostly for the
obvious reason that library work is easier to parallelize.

Going forward, I see any adoption of D (be it D1 or D2) beneficial. I am
confident that most people who will get first acquainted with D1 will be
ultimately compelled to use D2. The community would be helped if
factionalism would subside, but for the political reasons mentioned
above I don't see that happening soon. Anyhow, I don't think that that
would impede the success of D in the long term. The problems that D is
currently facing are all solvable with quality implementation. To me it
seems that the talented and growing contributor base that can rise to
the challenge.


Andrei
Nov 08 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 A longer term perception problem is that some might
 think the _design_ of such features has unsolvable issues,


That's my fear (so it's problem, even if it's just a perceived imaginary
problem). But I am not in a rush, so I am not going away.



 I know of no major design flaws,


Uhm... For example the whole implementation of nonnullables in D2 is already
becoming a big design flaw. Library-based nonullables will be awful, quite
worse than the Rebindable hack. I think most people will not use them. We'll
see. Are they able to reduce bug count in the average D2 program?

Thank you for the long post of your current view of D world.

Bye,
bearophile
Nov 08 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/8/10 12:48 PM, bearophile wrote:

 Andrei:


 A longer term perception problem is that some might think the
 _design_ of such features has unsolvable issues,


 That's my fear (so it's problem, even if it's just a perceived
 imaginary problem). But I am not in a rush, so I am not going away.



 I know of no major design flaws,


 Uhm... For example the whole implementation of nonnullables in D2 is
 already becoming a big design flaw.


I think we have different definitions of what a design flaw is. C++
export was a design flaw. PHP also has several design flaws. The fact
that you can't implement non-nullable references in e.g. C++ or Java is
not a design flaw in those respective languages.

Generally I think the case of non-null references is overstated. It
doesn't deserve that much agitation. It's being mentioned as a life or
death matter in spite of the simple evidence that many mainstream
languages are doing well without it, and without a landslide popular
vote for adding it. (And it's not a flaw in their design that they don't
make non-null references implementable.)


 Library-based nonullables will be awful, quite worse than the
 Rebindable hack.


How did you reach that conclusion?


Andrei
Nov 08 2010
next sibling parent reply oldtimer <fart fart.fart> writes:
Mon, 08 Nov 2010 13:06:23 -0800, Andrei Alexandrescu wrote:


 On 11/8/10 12:48 PM, bearophile wrote:

 Andrei:


 A longer term perception problem is that some might think the _design_
 of such features has unsolvable issues,


 That's my fear (so it's problem, even if it's just a perceived
 imaginary problem). But I am not in a rush, so I am not going away.



 I know of no major design flaws,


 Uhm... For example the whole implementation of nonnullables in D2 is
 already becoming a big design flaw.


 
 I think we have different definitions of what a design flaw is. C++
 export was a design flaw. PHP also has several design flaws. The fact
 that you can't implement non-nullable references in e.g. C++ or Java is
 not a design flaw in those respective languages.
 
 Generally I think the case of non-null references is overstated. It
 doesn't deserve that much agitation. It's being mentioned as a life or
 death matter in spite of the simple evidence that many mainstream
 languages are doing well without it, and without a landslide popular
 vote for adding it. (And it's not a flaw in their design that they don't
 make non-null references implementable.)
 


For some members of the community D has been a learning process; D has
introduced the members to new features in language design. It has been an
informal trial and error process. Even Walter has learned a lot, which is nice.
This has caused at least two problems. The requirements have changed and
developers expect now more advanced functionality. The amount of suggested
design ideas has grown, but the development speed hasn't scaled as well. The
development process doesn't scale up since almost no documentation gets
written. The expectations may be unrealistically high. Sometimes the
expectations are realistic, but the combination of legacy design choices in D1
and D2, TDPL pressure, D2 stabilization pressure, and D2 schedule has brought a
suboptimal implementation.

The second problem is, the developers now expect more knowledge from the
language designer. It gets really frustating if we need to start teaching him
to get better features. This is universal - if your kids go to a really bad
public school, you might want to start teaching them at home or consider some
private school (= other language). If your lawmakers don't understand the laws
they pass, you might consider moving to another country (= other
language/platform). I can say I'm not really convinced. I'm probably not the
only one.

It's bad for the publicity that digitalmars can't articulate any kind of
official *written* roadmap for new features. You don't want to dedicate much
(financial) effort on projects using the cowboy coding paradigm. The project
has a trac page. Writing down: "1. 64-bit dmd (N months) 2. concurrency fixes
(M months) etc." shouldn't take too long. If my guess is right, you can even
copy'n'paste it straight away. But you also need to update it! This is basic
project management these days.

One reason why Python/Ruby are so popular is their terse syntax. The library
based solutions in D2 aren't that cute. Some developers value the beauty of
code. If the solutions are too ugly, people will switch to other languages.
Compare Pascal with C, the languages are quite similar modulo syntactic
changes. The other one won.

For commercial users of D the feature set matters a lot. If D2 can't deliver
the power of D1 & Tango, there's nothing you can do. A sane corporation would
not donate code to Phobos just because its quality is worse and it's an
empathetic thing to do. Corporations don't work this way. Those who are fixing
Phobos are individual zealots swimming against the stream. They have a very
long term technical agenda (D2 will beat comtemporary technologies in 10+
years), a religious agenda, nothing better to do, or some kind of mental
illness. Corporations aren't interested in very long term technical issues,
they care about short term solutions (1 to 36 months).

Some of us hoped D2 would solve the ugly corner cases of the language and unify
a lot of features. Unfortunately not any kind of macro system was implemented,
templates got even uglier, the alias this hack, snake oil template!X syntax
shortcut and all kinds of unnecessary features were added. Of course also good
features were added, but overall this just isn't good enough.
Nov 08 2010
next sibling parent so <so so.do> writes:
Why are you even here? D is a waste of time if you believe the half of the  
nonsense you have written.
It is much better for you to be part of that "stream", much safer.
Nov 08 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/8/10 2:07 PM, oldtimer wrote:

 Mon, 08 Nov 2010 13:06:23 -0800, Andrei Alexandrescu wrote:


 On 11/8/10 12:48 PM, bearophile wrote:

 Andrei:


 A longer term perception problem is that some might think the
 _design_ of such features has unsolvable issues,


 That's my fear (so it's problem, even if it's just a perceived
 imaginary problem). But I am not in a rush, so I am not going
 away.



 I know of no major design flaws,


 Uhm... For example the whole implementation of nonnullables in D2
 is already becoming a big design flaw.


 I think we have different definitions of what a design flaw is.
 C++ export was a design flaw. PHP also has several design flaws.
 The fact that you can't implement non-nullable references in e.g.
 C++ or Java is not a design flaw in those respective languages.

 Generally I think the case of non-null references is overstated.
 It doesn't deserve that much agitation. It's being mentioned as a
 life or death matter in spite of the simple evidence that many
 mainstream languages are doing well without it, and without a
 landslide popular vote for adding it. (And it's not a flaw in their
 design that they don't make non-null references implementable.)


 For some members of the community D has been a learning process; D
 has introduced the members to new features in language design. It has
 been an informal trial and error process. Even Walter has learned a
 lot, which is nice. This has caused at least two problems. The
 requirements have changed and developers expect now more advanced
 functionality. The amount of suggested design ideas has grown, but
 the development speed hasn't scaled as well. The development process
 doesn't scale up since almost no documentation gets written. The
 expectations may be unrealistically high. Sometimes the expectations
 are realistic, but the combination of legacy design choices in D1 and
 D2, TDPL pressure, D2 stabilization pressure, and D2 schedule has
 brought a suboptimal implementation.

 The second problem is, the developers now expect more knowledge from
 the language designer. It gets really frustating if we need to start
 teaching him to get better features. This is universal - if your kids
 go to a really bad public school, you might want to start teaching
 them at home or consider some private school (= other language). If
 your lawmakers don't understand the laws they pass, you might
 consider moving to another country (= other language/platform). I can
 say I'm not really convinced. I'm probably not the only one.

 It's bad for the publicity that digitalmars can't articulate any kind
 of official *written* roadmap for new features. You don't want to
 dedicate much (financial) effort on projects using the cowboy coding
 paradigm. The project has a trac page. Writing down: "1. 64-bit dmd
 (N months) 2. concurrency fixes (M months) etc." shouldn't take too
 long. If my guess is right, you can even copy'n'paste it straight
 away. But you also need to update it! This is basic project
 management these days.


All very good points. Walter is generally shy to put forth agenda that 
are difficult to estimate and meet. There have been, for example, 
unexpected (and unexpectedly long) setbacks of the 64-bit release due to 
seemingly minor hitches (e.g. C-style variadics). At any rate, I, too, 
think a sort of general agenda would be useful to keep updated.

One simple thing that I've recently done (my free time has been 
relatively scarce lately) was to work on bug reports starting from the 
oldest first. (I solved a bunch, too - it took me a couple of days to go 
through like 70.) The oldest non-enhancement non-lowpri unsolved bug is 
a metric that people will look at, and limiting the age of the oldest 
bug gives people a sense that all reports will be looked at in a fair 
manner.


 One reason why Python/Ruby are so popular is their terse syntax. The
 library based solutions in D2 aren't that cute. Some developers value
 the beauty of code. If the solutions are too ugly, people will switch
 to other languages. Compare Pascal with C, the languages are quite
 similar modulo syntactic changes. The other one won.


I agree in spirit, but beyond some point this all becomes a manner of 
taste. And library solutions scale in many ways much better than 
solutions built into the language - I mean look at Python's "print". I'd 
actually prefer NonNull!T over  T or  nonnull T etc. What I prefer even 
more about NonNull!T is that it uses general language facilities that 
can be used for NonZero!T or Bounded!T etc. as discussed.


 For commercial users of D the feature set matters a lot. If D2 can't
 deliver the power of D1&  Tango, there's nothing you can do.


What I can do is work on D and encourage others to do the same.


 A sane
 corporation would not donate code to Phobos just because its quality
 is worse and it's an empathetic thing to do. Corporations don't work
 this way. Those who are fixing Phobos are individual zealots swimming
 against the stream. They have a very long term technical agenda (D2
 will beat comtemporary technologies in 10+ years), a religious
 agenda, nothing better to do, or some kind of mental illness.
 Corporations aren't interested in very long term technical issues,
 they care about short term solutions (1 to 36 months).

 Some of us hoped D2 would solve the ugly corner cases of the language
 and unify a lot of features. Unfortunately not any kind of macro
 system was implemented, templates got even uglier, the alias this
 hack, snake oil template!X syntax shortcut and all kinds of
 unnecessary features were added. Of course also good features were
 added, but overall this just isn't good enough.


I was expecting a number of responses from under the cloak of anonymity 
(i.e. from people whose identity would immediately reveal their agenda), 
and as far as those go this post was surprisingly good up until the last 
paragraphs. Here is unfortunately where the tone of the discourse degrades.

Let's not forget that a lot of good work - including Tango itself - has 
been done by "zealots". It also seems that disingenuously attempting to 
frame D2 contributors as weirdos with a religious agenda, nothing better 
to do, or mentally ill is a display of an emotional position in the 
matter that instantly reduces the quality of any point made and that of 
the dialog in general. This all being told from under anonymity doesn't 
help either.

I understand you would have liked macros, dislike the paren-less 
shortcut notation A!B instead of A!(B), and dislike some untold features 
that you find as unnecessary. It would be great if you substantiated 
these points while leaving the subjective outside. For example, I am 
confused by the shortcut A!B being snake oil or alias this being a hack. 
The former is a mere convenience and the latter is a well-motivated feature.


Andrei
Nov 08 2010
prev sibling parent reply thank you oldtimer <nospam _._> writes:
oldtimer Wrote:

 Some of us hoped D2 would solve the ugly corner cases of the language and
unify a lot of features. Unfortunately not any kind of macro system was
implemented, templates got even uglier, the alias this hack, snake oil
template!X syntax shortcut and all kinds of unnecessary features were added. Of
course also good features were added, but overall this just isn't good enough.


Is it a coincidence that all the complaints seem to come from a single person?
Let's take a look at my killfile:

ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz, bjarne
yesterday, blaise pascal, cal, chmod+x, crap, darth tango, domino, ellis
peters, foobar, gareth charnock, gcc-lurker, girlprogrammer, godworshipper,
gryphon, her3tic, jameskan, jane doe, jarett billingsley, jer, languagefan,
larry coder, lars ivar douchesund, levenshtein, lurker, nobody, oldtimer, pipe
dream, pointing hand, retard, retard++, retarded.clear(), scott, steveh,
superdan, user, wah, william t. fnk, yoda, type<erasure>, uriel (reddit),
eternium (reddit), iliekcaeks (reddit), feepingcreature (reddit),
parametricpoly (reddit), nfxjfg (bugzilla), and many more!

Sometimes feels like this guy dresses up as bearophile just to waste our time
with stupid nonsense. In reality there's a single sick person opposing D2 and
it's probably the lead developer of Tango who wasn't invited (it's just one
freaking license change!). No wonder Tango for D2 gets ever done, the guy is
wasting time here posting this crap. Sad times. :-( Do us a favor, go and use

time}. Never come back. It's time to cut off this bullshit now. We're adults.
It's too late to change D in any radical way now. You either like it or hate
it. Trust me, those favorite languages of yours suit *you* much better, we
don't deserve that enlightenment TYVM. Go to movies, find a girlfriend, get a
job, buy a house, start living a normal life. Don't be an emo kid. So much time
is wasted on these stupid threads about totally irrelevant new features.

To not sound like a pathetic troll, something positive now: With that knowledge
of yours all kinds of *good* things could be done. Write applications, write
libraries, write languages, do language research, earn money! I challenge you
to write your own "clone" of D. Maybe fork D1 and make a D 1.5 as you "all"
wanted. Fix all the "relevant" issues and leave out template "bloat". Might
even attract small user base. Since you get your money elsewhere, you're not
tied to the old dmc/optlink backend. Use LLVM! Use modern project management
tools (Trac, Redmine, ...), use a modern SCM system (Git), invite all friends
in. The stage is yours! If you come up with something better than D, I might be
one of the first developers making the switch.
Nov 09 2010
next sibling parent Gour <gour atmarama.net> writes:
On Tue, 09 Nov 2010 05:27:22 -0500er wrote:

thank> If you come up with something better than D, I might be one of
thank> the first developers making the switch.

+1

--=20

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------
Nov 09 2010
prev sibling next sibling parent Boris Wang <kona.ming gmail.com> writes:
++1

2010/11/9 thank you oldtimer <nospam _._>


 oldtimer Wrote:

 Some of us hoped D2 would solve the ugly corner cases of the language and


 unify a lot of features. Unfortunately not any kind of macro system was
 implemented, templates got even uglier, the alias this hack, snake oil
 template!X syntax shortcut and all kinds of unnecessary features were added.
 Of course also good features were added, but overall this just isn't good
 enough.

 Is it a coincidence that all the complaints seem to come from a single
 person? Let's take a look at my killfile:

 ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz, bjarne
 yesterday, blaise pascal, cal, chmod+x, crap, darth tango, domino, ellis
 peters, foobar, gareth charnock, gcc-lurker, girlprogrammer, godworshipper,
 gryphon, her3tic, jameskan, jane doe, jarett billingsley, jer, languagefan,
 larry coder, lars ivar douchesund, levenshtein, lurker, nobody, oldtimer,
 pipe dream, pointing hand, retard, retard++, retarded.clear(), scott,
 steveh, superdan, user, wah, william t. fnk, yoda, type<erasure>, uriel
 (reddit), eternium (reddit), iliekcaeks (reddit), feepingcreature (reddit),
 parametricpoly (reddit), nfxjfg (bugzilla), and many more!

 Sometimes feels like this guy dresses up as bearophile just to waste our
 time with stupid nonsense. In reality there's a single sick person opposing
 D2 and it's probably the lead developer of Tango who wasn't invited (it's
 just one freaking license change!). No wonder Tango for D2 gets ever done,
 the guy is wasting time here posting this crap. Sad times. :-( Do us a
 favor, go and use that

 time}. Never come back. It's time to cut off this bullshit now. We're
 adults. It's too late to change D in any radical way now. You either like it
 or hate it. Trust me, those favorite languages of yours suit *you* much
 better, we don't deserve that enlightenment TYVM. Go to movies, find a
 girlfriend, get a job, buy a house, start living a normal life. Don't be an
 emo kid. So much time is wasted on these stupid threads about totally
 irrelevant new features.

 To not sound like a pathetic troll, something positive now: With that
 knowledge of yours all kinds of *good* things could be done. Write
 applications, write libraries, write languages, do language research, earn
 money! I challenge you to write your own "clone" of D. Maybe fork D1 and
 make a D 1.5 as you "all" wanted. Fix all the "relevant" issues and leave
 out template "bloat". Might even attract small user base. Since you get your
 money elsewhere, you're not tied to the old dmc/optlink backend. Use LLVM!
 Use modern project management tools (Trac, Redmine, ...), use a modern SCM
 system (Git), invite all friends in. The stage is yours! If you come up with
 something better than D, I might be one of the first developers making the
 switch.
Nov 09 2010
prev sibling next sibling parent Boris Wang <kona.ming gmail.com> writes:
First, forgive my poor english.

we all known , Walter good at compiler writing, but not good at language
design and development management , if can't change this, just be silent.

I think, on language desgin, wisdom and leadership are more more important
than technology.

Ether continue working on D, or make D like clone,  if we can't do it like
APPLE, just give up ASAP,
because we can only save us by our selves.
.
.



2010/11/10 Boris Wang <kona.ming gmail.com>


 ++1

 2010/11/9 thank you oldtimer <nospam _._>

 oldtimer Wrote:

 Some of us hoped D2 would solve the ugly corner cases of the language


 and unify a lot of features. Unfortunately not any kind of macro system was
 implemented, templates got even uglier, the alias this hack, snake oil
 template!X syntax shortcut and all kinds of unnecessary features were added.
 Of course also good features were added, but overall this just isn't good
 enough.

 Is it a coincidence that all the complaints seem to come from a single
 person? Let's take a look at my killfile:

 ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz,
 bjarne yesterday, blaise pascal, cal, chmod+x, crap, darth tango, domino,
 ellis peters, foobar, gareth charnock, gcc-lurker, girlprogrammer,
 godworshipper, gryphon, her3tic, jameskan, jane doe, jarett billingsley,
 jer, languagefan, larry coder, lars ivar douchesund, levenshtein, lurker,
 nobody, oldtimer, pipe dream, pointing hand, retard, retard++,
 retarded.clear(), scott, steveh, superdan, user, wah, william t. fnk, yoda,
 type<erasure>, uriel (reddit), eternium (reddit), iliekcaeks (reddit),
 feepingcreature (reddit), parametricpoly (reddit), nfxjfg (bugzilla), and
 many more!

 Sometimes feels like this guy dresses up as bearophile just to waste our
 time with stupid nonsense. In reality there's a single sick person opposing
 D2 and it's probably the lead developer of Tango who wasn't invited (it's
 just one freaking license change!). No wonder Tango for D2 gets ever done,
 the guy is wasting time here posting this crap. Sad times. :-( Do us a
 favor, go and use that

 time}. Never come back. It's time to cut off this bullshit now. We're
 adults. It's too late to change D in any radical way now. You either like it
 or hate it. Trust me, those favorite languages of yours suit *you* much
 better, we don't deserve that enlightenment TYVM. Go to movies, find a
 girlfriend, get a job, buy a house, start living a normal life. Don't be an
 emo kid. So much time is wasted on these stupid threads about totally
 irrelevant new features.

 To not sound like a pathetic troll, something positive now: With that
 knowledge of yours all kinds of *good* things could be done. Write
 applications, write libraries, write languages, do language research, earn
 money! I challenge you to write your own "clone" of D. Maybe fork D1 and
 make a D 1.5 as you "all" wanted. Fix all the "relevant" issues and leave
 out template "bloat". Might even attract small user base. Since you get your
 money elsewhere, you're not tied to the old dmc/optlink backend. Use LLVM!
 Use modern project management tools (Trac, Redmine, ...), use a modern SCM
 system (Git), invite all friends in. The stage is yours! If you come up with
 something better than D, I might be one of the first developers making the
 switch.
Nov 09 2010
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
On Wed, Nov 10, 2010 at 2:19 AM, Boris Wang <kona.ming gmail.com> wrote:

 First, forgive my poor english.
 we all known , Walter good at compiler writing, but not good at language
 design and development management , if can't change this, just be silent.


If he isn't good at language design (in other words: D sucks): why do
you care about D? Why are you here?


 I think, on language desgin, wisdom and leadership are more more importan=


t

 than=A0technology.


Well, the development process of D could be better organized (having a
schedule and roadmap and such)..
But "wisdom and leadership" doesn't help much if nobody's there to
implement stuff. I think we're better of this way than having someone
who's "wiser" (what is that supposed to mean in this context anyway?)
and a better leader, but can't code.


 Ether continue working on D, or make D like clone, =A0if we can't do it l=


ike

 APPLE, just give up ASAP,
 because we can only save us by our selves.


Sorry, I can't make any sense of that sentence.
Nov 09 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/9/10 5:38 PM, Daniel Gibson wrote:

 On Wed, Nov 10, 2010 at 2:19 AM, Boris Wang<kona.ming gmail.com>  wrote:

 First, forgive my poor english.
 we all known , Walter good at compiler writing, but not good at language
 design and development management , if can't change this, just be silent.


 If he isn't good at language design (in other words: D sucks): why do
 you care about D? Why are you here?


 I think, on language desgin, wisdom and leadership are more more important
 than technology.


 Well, the development process of D could be better organized (having a
 schedule and roadmap and such)..
 But "wisdom and leadership" doesn't help much if nobody's there to
 implement stuff. I think we're better of this way than having someone
 who's "wiser" (what is that supposed to mean in this context anyway?)
 and a better leader, but can't code.


 Ether continue working on D, or make D like clone,  if we can't do it like
 APPLE, just give up ASAP,
 because we can only save us by our selves.


 Sorry, I can't make any sense of that sentence.


I think he meant "We should all either continue working on D or make a 
D-like clone. If we can't do it like Apple, we should just give up ASAP. 
Only the community can save the situation."

Andrei
Nov 09 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
On Wed, Nov 10, 2010 at 2:49 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 On 11/9/10 5:38 PM, Daniel Gibson wrote:

 On Wed, Nov 10, 2010 at 2:19 AM, Boris Wang<kona.ming gmail.com> =A0wrot=




e:

 First, forgive my poor english.
 we all known , Walter good at compiler writing, but not good at languag=






e

 design and development management , if can't change this, just be silen=






t.

 If he isn't good at language design (in other words: D sucks): why do
 you care about D? Why are you here?


 I think, on language desgin, wisdom and leadership are more more
 important
 than technology.


 Well, the development process of D could be better organized (having a
 schedule and roadmap and such)..
 But "wisdom and leadership" doesn't help much if nobody's there to
 implement stuff. I think we're better of this way than having someone
 who's "wiser" (what is that supposed to mean in this context anyway?)
 and a better leader, but can't code.


 Ether continue working on D, or make D like clone, =A0if we can't do it
 like
 APPLE, just give up ASAP,
 because we can only save us by our selves.


 Sorry, I can't make any sense of that sentence.


 I think he meant "We should all either continue working on D or make a
 D-like clone. If we can't do it like Apple, we should just give up ASAP.
 Only the community can save the situation."

 Andrei


What's meant with "do it like Apple"? Is that some kind of idiom I'm
not familiar with?
He certainly couldn't have meant that literally, because making D
overpriced and proprietary would certainly not help.
Nov 09 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/9/10 6:10 PM, Daniel Gibson wrote:

 On Wed, Nov 10, 2010 at 2:49 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

 On 11/9/10 5:38 PM, Daniel Gibson wrote:

 On Wed, Nov 10, 2010 at 2:19 AM, Boris Wang<kona.ming gmail.com>    wrote:

 First, forgive my poor english.
 we all known , Walter good at compiler writing, but not good at language
 design and development management , if can't change this, just be silent.


 If he isn't good at language design (in other words: D sucks): why do
 you care about D? Why are you here?


 I think, on language desgin, wisdom and leadership are more more
 important
 than technology.


 Well, the development process of D could be better organized (having a
 schedule and roadmap and such)..
 But "wisdom and leadership" doesn't help much if nobody's there to
 implement stuff. I think we're better of this way than having someone
 who's "wiser" (what is that supposed to mean in this context anyway?)
 and a better leader, but can't code.


 Ether continue working on D, or make D like clone,  if we can't do it
 like
 APPLE, just give up ASAP,
 because we can only save us by our selves.


 Sorry, I can't make any sense of that sentence.


 I think he meant "We should all either continue working on D or make a
 D-like clone. If we can't do it like Apple, we should just give up ASAP.
 Only the community can save the situation."

 Andrei


 What's meant with "do it like Apple"? Is that some kind of idiom I'm
 not familiar with?
 He certainly couldn't have meant that literally, because making D
 overpriced and proprietary would certainly not help.


My guess is "do it professionally and successfully".

Andrei
Nov 09 2010
parent Boris Wang <kona.ming gmail.com> writes:
Thanks.

Apple no sorry for it's fault, but the fans still aroud it and support it.
why ?



2010/11/10 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>


 On 11/9/10 6:10 PM, Daniel Gibson wrote:


 On Wed, Nov 10, 2010 at 2:49 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:


 On 11/9/10 5:38 PM, Daniel Gibson wrote:



 On Wed, Nov 10, 2010 at 2:19 AM, Boris Wang<kona.ming gmail.com>
  wrote:


 First, forgive my poor english.
 we all known , Walter good at compiler writing, but not good at
 language
 design and development management , if can't change this, just be
 silent.


 If he isn't good at language design (in other words: D sucks): why do
 you care about D? Why are you here?

  I think, on language desgin, wisdom and leadership are more more

 important
 than technology.


 Well, the development process of D could be better organized (having a
 schedule and roadmap and such)..
 But "wisdom and leadership" doesn't help much if nobody's there to
 implement stuff. I think we're better of this way than having someone
 who's "wiser" (what is that supposed to mean in this context anyway?)
 and a better leader, but can't code.

  Ether continue working on D, or make D like clone,  if we can't do it

 like
 APPLE, just give up ASAP,
 because we can only save us by our selves.


 Sorry, I can't make any sense of that sentence.


 I think he meant "We should all either continue working on D or make a
 D-like clone. If we can't do it like Apple, we should just give up ASAP.
 Only the community can save the situation."

 Andrei


 What's meant with "do it like Apple"? Is that some kind of idiom I'm
 not familiar with?
 He certainly couldn't have meant that literally, because making D
 overpriced and proprietary would certainly not help.


 My guess is "do it professionally and successfully".

 Andrei
Nov 09 2010
prev sibling next sibling parent reply Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 11/9/2010 5:27 AM, thank you oldtimer wrote:

 ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz, bjarne
yesterday, blaise pascal, cal, chmod+x, crap, darth tango, domino, ellis
peters, foobar, gareth charnock, gcc-lurker, girlprogrammer, godworshipper,
gryphon, her3tic, jameskan, jane doe, jarett billingsley, jer, languagefan,
larry coder, lars ivar douchesund, levenshtein, lurker, nobody, oldtimer, pipe
dream, pointing hand, retard, retard++, retarded.clear(), scott, steveh,
superdan, user, wah, william t. fnk, yoda, type<erasure>, uriel (reddit),
eternium (reddit), iliekcaeks (reddit), feepingcreature (reddit),
parametricpoly (reddit), nfxjfg (bugzilla), and many more!


If h3r3tic, jarett billingsley, retard*, superdan, bearophile, and 
feepingcreature are the same person, then that's quite an act.

h3r3tic has made some valuable contributions to phobos, Jarett made 
miniD (before leaving the D community), and while I don't agree with all 
of bearophile's suggestions, some of them are great.  I also appreciate 
that he takes the time to benchmark and create bug reports.  I hope he 
continues with all of these.
Nov 09 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 10/11/2010 02:53, Eric Poggel wrote:

 On 11/9/2010 5:27 AM, thank you oldtimer wrote:

 ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz,
 bjarne yesterday, blaise pascal, cal, chmod+x, crap, darth tango,
 domino, ellis peters, foobar, gareth charnock, gcc-lurker,
 girlprogrammer, godworshipper, gryphon, her3tic, jameskan, jane doe,
 jarett billingsley, jer, languagefan, larry coder, lars ivar
 douchesund, levenshtein, lurker, nobody, oldtimer, pipe dream,
 pointing hand, retard, retard++, retarded.clear(), scott, steveh,
 superdan, user, wah, william t. fnk, yoda, type<erasure>, uriel
 (reddit), eternium (reddit), iliekcaeks (reddit), feepingcreature
 (reddit), parametricpoly (reddit), nfxjfg (bugzilla), and many more!


 If h3r3tic, jarett billingsley, retard*, superdan, bearophile, and
 feepingcreature are the same person, then that's quite an act.

 h3r3tic has made some valuable contributions to phobos, Jarett made
 miniD (before leaving the D community), and while I don't agree with all
 of bearophile's suggestions, some of them are great. I also appreciate
 that he takes the time to benchmark and create bug reports. I hope he
 continues with all of these.


Dude, you're wasting your breath with such a serious reply: "thank you 
oldtimer" is effectively a troll, just like "oldtimer" himself. People 
should pay little to no attention to these posts made under random 
anonymous nicknames, especially if its the first posts made under such a 
name.
There seems to be a pattern where occasionally some troll identity will 
reply and argue against some other troll identity. It's a curious thing 
at best, I'm not sure what the intentions are (trying to make one troll 
post seem more respectable? Just messing with the heads of other D 
users?), but it's best to just not waste time on that.


-- 
Bruno Medeiros - Software Engineer
Nov 29 2010
parent troll <troll lol.lol> writes:
Bruno Medeiros Wrote:


 Dude, you're wasting your breath with such a serious reply: "thank you 
 oldtimer" is effectively a troll, just like "oldtimer" himself. People 
 should pay little to no attention to these posts made under random 
 anonymous nicknames, especially if its the first posts made under such a 
 name.


As one of these trolls, here's my short story: I only came here because the
religious zealotly of this community cannot be kept a secret anymore no matter
what you do. I found two other forums rather boring. They only discussed
language semantics and syntax and toolchain issues and language specifications
and all kinds of dead boring stuff, can you believe that? This is a great place
for me, unproductive environment full of bad software engineering practices.
Something to mock. You should know, as a new software engineer, how badly
organized this all is.


 There seems to be a pattern where occasionally some troll identity will 
 reply and argue against some other troll identity. It's a curious thing 
 at best, I'm not sure what the intentions are (trying to make one troll 
 post seem more respectable?


Where did you get that from? If this is true, it just means that this place is
infested with idiots not capable of even lacing their shoes if they didn't see
this earlier. Do we need a reminder on how that kind of lack of intelligence
affects language development quality or our marketing efforts?

* http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=123193
"Just messing with the heads of other D users?), but it's best to just not
waste time on that."

* http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=123245
"Fortunately the implementation effort is also very low, so let's just check
there is no unintended consequences, and move on."

You're in a hurry, Son? Were waisting time whole the time.
Nov 29 2010
prev sibling next sibling parent reply Led Zeppelin <highaboveu inthecloud.biz> writes:
"than you oldtimer" wrote:

[about his fantasies with trolls and forking D? (You are one sick
pup! Forking D!)]

D is a fantasy and the largest example of group think that I know
of. You know what happens when lot's of people start living real
close together: disease sets in and they whither and Die! BTW, what
does the "D" in D stand for? Let me see... could it be... SATAN?!!!

D will not pass Go will not collect $200.
Nov 09 2010
next sibling parent Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 11/9/2010 11:39 PM, Led Zeppelin wrote:

 You know what happens when lot's of people start living real
 close together: disease sets in and they whither and Die!


This is why the family unit is such a failure.  Maybe trolls come from 
broken families?
Nov 09 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 09 November 2010 20:39:48 Led Zeppelin wrote:

 D will not pass Go will not collect $200.


That post was definitely trolling, but I have to laugh at that last line.

- Jonathan M Davis
Nov 09 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"thank you oldtimer" <nospam _._> wrote in message 
news:ibb7ma$2fs3$1 digitalmars.com...

 oldtimer Wrote:

 Some of us hoped D2 would solve the ugly corner cases of the language and 
 unify a lot of features. Unfortunately not any kind of macro system was 
 implemented, templates got even uglier, the alias this hack, snake oil 
 template!X syntax shortcut and all kinds of unnecessary features were 
 added. Of course also good features were added, but overall this just 
 isn't good enough.



 Sometimes feels like this guy dresses up as bearophile just to waste our 
 time with stupid nonsense. In reality there's a single sick person 
 opposing D2 and it's probably the lead developer of Tango who wasn't 
 invited (it's just one freaking license change!). No wonder Tango for D2 
 gets ever done, the guy is wasting time here posting this crap. Sad times. 
 :-( Do us a favor, go and use that 

 time}. Never come back. It's time to cut off this bullshit now.


This bothers me. I don't think it's at all healthy for the D community to be 
antaginizing Tango, especially with such speculative accusations.


 We're adults.


Then can we please act like it, even in response to posts that happen to be 
critical of some aspects of D? It's not as if oldtimer's post was tossing 
personal insults or anything, or criticizing anything that hasn't already 
been criticized by upstanding members of the NG who just happened to 
disagree with a particular design.
Nov 11 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 I think we have different definitions of what a design flaw is. C++
 export was a design flaw. PHP also has several design flaws. The fact
 that you can't implement non-nullable references in e.g. C++ or Java is
 not a design flaw in those respective languages.


You are right. I am sorry.



 Generally I think the case of non-null references is overstated.


OK.

Bye,
bearophile
Nov 08 2010
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Andrei Alexandrescu schrieb:

 On 11/7/10 6:33 AM, bioinfornatics wrote:

 So D community will be split in 2. And D1 continue to evolve without
 D2 community, D1 frontend is open source and he coulb be used for
 improve and fix D1


 
 The current situation and the dynamics are quite interesting, and I am
 looking forward to witnessing how things will unfold.
 
 There is a community for which D1's offering is just fine. They've used
 D1 long enough to use it idiomatically and to derive better enjoyment
 than from the likes of Java or C++. The gain in power, albeit marginal,
 is present. 


You gain a lot of power by using D1 instead of Java/C++: Usable Templates with 
static if, slices, a GC, unsigned types, ..


 The fact that the
 implementation of the newest features is incomplete fuels arguments
 against D2. The immaturity of alternative back-ends (gdc, llvm for D2
 are both quite young) contributes to the perception that D2 does not
 offer a net advantage when compared with D1.


It's also the (at least felt) immaturity of DMD for D2, I guess. You read about 
problems in the NG all the time.
And the lack of 64bit support, of course (this will soon change, of course).


 
 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political incentive to
 a Tango port. Tango is currently the de facto standard library for D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). 


Many parts of Phobos2 are the same as Phobos1 and thus are still underpowered 
(e.g. networking and streams).


 Due to Sean's work on making druntime independently available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.
 


A port of Tango for D2 would be really helpful, because Phobos2, like Phobos1, 
is no fun to use..
A few months ago I started a D1 project and used Phobos, so porting my project 
to D2 in the future would be easier.
If a Tango2 would have been in the works I might have used Tango. Then I 
wouldn't have needed to clone phobos classes (Socket, Address (from socket), 
SocketStream and I also wrote a BufferedSocket because I didn't trust 
BufferedStream) in my own code to fix them.. (see bugreports: [1])


So I think it's not just political reasons (Tango fanboys) why people use D1, 
but also that D2's standard library isn't finished yet so, if you want to start 
a halfway serious project, you either use Tango or prepare to copy and fix 
Phobos :-/
Furthermore library-support for D1 is better (all that stuff at dsource for 
example).
Also compilers are an issue, of course, because the D2 support of alternative 
(free, 64bit capable, ...) compilers is not up to date..
Or rather *was* not up to date: Iain just brought GDC to version 2.047, so I 
guess that GDC will really soon be on par with DMD, version-wise.
Then some more testing and fixing and there will be a free (as in freedom), 
usable (as in relatively bugfree) up-to-date D2 compiler that supports a 
plethora of platforms \o/

Also people seem to work on LDC2 again.

Cheers,
- Daniel

[1] http://d.puremagic.com/issues/show_bug.cgi?id=4234 (std.socket issues)
     http://d.puremagic.com/issues/show_bug.cgi?id=5177 (std.socketstream
issues)
Nov 08 2010
parent reply Trass3r <un known.com> writes:
 You gain a lot of power by using D1 instead of Java/C++: Usable  
 Templates with static if, slices, a GC, unsigned types, ..


Yep, working with C++ again feels like being thrown back to the stone age.


 It's also the (at least felt) immaturity of DMD for D2, I guess. You  
 read about problems in the NG all the time.


Yet it's the only real option to go on Windoze :(


 A port of Tango for D2 would be really helpful, because Phobos2, like  
 Phobos1, is no fun to use..


Won't happen anyway.


 freedom), usable (as in relatively bugfree) up-to-date D2 compiler that  
 supports a plethora of platforms \o/


Well compiling it for Windoze is still a PITA.


 Also people seem to work on LDC2 again.


Yeah, they are at 2.050 but I don't know if it works yet.
http://bitbucket.org/prokhin_alexey/ldc2
Nov 08 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Trass3r schrieb:

 You gain a lot of power by using D1 instead of Java/C++: Usable 
 Templates with static if, slices, a GC, unsigned types, ..


 Yep, working with C++ again feels like being thrown back to the stone age.
 

 It's also the (at least felt) immaturity of DMD for D2, I guess. You 
 read about problems in the NG all the time.


 Yet it's the only real option to go on Windoze :(
 

 A port of Tango for D2 would be really helpful, because Phobos2, like 
 Phobos1, is no fun to use..


 Won't happen anyway.
 

 freedom), usable (as in relatively bugfree) up-to-date D2 compiler 
 that supports a plethora of platforms \o/


 Well compiling it for Windoze is still a PITA.


Shouldn't GDC work on windows with MinGW? Maybe someone could try that and
build 
an installer or something.


 

 Also people seem to work on LDC2 again.


 Yeah, they are at 2.050 but I don't know if it works yet.
 http://bitbucket.org/prokhin_alexey/ldc2


Already at 2.050? That was quick :-)
Nov 08 2010
parent reply Trass3r <un known.com> writes:
 Shouldn't GDC work on windows with MinGW? Maybe someone could try that  
 and build an installer or something.


Just try compiling it ;)
Nov 08 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Trass3r (un known.com)'s article

 Shouldn't GDC work on windows with MinGW? Maybe someone could try that
 and build an installer or something.


 Just try compiling it ;)


MinGW is just one of those pedantic systems. Requires building and installing
GMP;
MPFR before you can even think about unpacking the GCC source tree. As far as
testimonials go for D1, it's really been hit or miss. There have been reported
success, however I've never managed to do it myself (though I *know* the reason
is
because of a bad build environment, and not compiler).
Nov 08 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-08 20:55, Andrei Alexandrescu wrote:

 On 11/7/10 6:33 AM, bioinfornatics wrote:

 So D community will be split in 2. And D1 continue to evolve without
 D2 community, D1 frontend is open source and he coulb be used for
 improve and fix D1


 The current situation and the dynamics are quite interesting, and I am
 looking forward to witnessing how things will unfold.

 There is a community for which D1's offering is just fine. They've used
 D1 long enough to use it idiomatically and to derive better enjoyment
 than from the likes of Java or C++. The gain in power, albeit marginal,
 is present. That base has been understandably annoyed by D2 being
 backwards incompatible with D1, and has a dim view of the advantages
 brought about by D2's additions (mainly concurrency and its
 paraphernalia - immutability and no default sharing). The fact that the
 implementation of the newest features is incomplete fuels arguments
 against D2. The immaturity of alternative back-ends (gdc, llvm for D2
 are both quite young) contributes to the perception that D2 does not
 offer a net advantage when compared with D1.

 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political incentive to
 a Tango port. Tango is currently the de facto standard library for D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). Due to Sean's work on making druntime independently available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.


Here's the problem with that: since Sean basically forked the Tango 
runtime, removed any non DMD specific code and any code for a platform 
that DMD doesn't support. And stopped contributing to Tango while others 
improved the Tango runtime we're back at square one with two 
incompatiable runtimes and the Tango runtime still seems to be better. 
For this to work the Tango team and the druntime 
contributors/maintainers have collaborate and work together on a runtime.


 So in the current equilibrium D1 and Tango form a bond: D1 is platform
 offering Tango exclusivity as the standard library and Tango is the
 library that makes D1 attractive. The risk assumed by that bond
 (assuming the assumption above is correct) is isolation in a position
 condemned to inevitable obsolescence.

 As far as language proper is concerned, D1 has the option of becoming an
 incompatible fork by choosing to evolve its own features independently
 of dmd. That process could be greatly helped if a strong language
 designer would decide to work on D1. I see that as a possible but
 unlikely scenario (unlikely because a language designer would have to be
 primarily politically motivated to make such a decision).

  From the D2 side, it all boils down to the question: are D2's additions
 worthwhile or not? D2 places bets on concurrency, correctness, and
 opt-out safety. Those bets looked much riskier two years ago than they
 look now, but still carry a risk. Also, as I mentioned above, currently
 the implementation of many new features is superficial. This is caused
 by the current development model of the reference compiler - features
 are implemented without a formal description.


Exactly, they need a formal description. This is also a problem with no 
proper language specification. If you encounter a problem/bug you never 
no what to except: is it a design bug? An implementation bug? And then 
it's hard to figure that out because you never no what can to trust, the 
language specification? The reference compiler? TDPL?


 There is disproportionate reliance on the compiler test suite to effectively
define the language
 by exercising all of its features and feature combinations. The test
 suite is undeniably useful, which makes it even more difficult to
 explain its problems. Some more complicated features are first
 implemented to simply make a narrow test pass, and then spend a long
 time in an "almost-well-defined" state in which bug reports are fixed
 and added to the test suite. I believe that the informal language
 development is curre
 ntly the single most important liability of D. (That is, somewhat
 ironically, a matter in which D2 is at an advantage to D1.)

 The insufficient implementation of new features propagates the
 perception that D2 is unstable, although the more conventional, D1-like
 subset of D2 is as solid in both languages. But then the perception is
 justified, because one would want to use D2 primarily for its new,
 unique offerings. A longer term perception problem is that some might
 think the _design_ of such features has unsolvable issues, which hurts
 the image of the language. I know of no major design flaws, but that is
 only an academic argument in wake of perennial implementation
 insufficiencies.


There are still things in D1 that are not solid, just look at the bugs 
and newsgroups posts by bearophile. The module/import system, for example.


-- 
/Jacob Carlborg
Nov 09 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/9/10 1:42 AM, Jacob Carlborg wrote:

 On 2010-11-08 20:55, Andrei Alexandrescu wrote:

 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political incentive to
 a Tango port. Tango is currently the de facto standard library for D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). Due to Sean's work on making druntime independently available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.


 Here's the problem with that: since Sean basically forked the Tango
 runtime, removed any non DMD specific code and any code for a platform
 that DMD doesn't support. And stopped contributing to Tango while others
 improved the Tango runtime we're back at square one with two
 incompatiable runtimes and the Tango runtime still seems to be better.


It's not difficult to offer e.g. an incompatible C runtime that is 
slightly better than the standard one. People generally don't do that 
but instead add libraries on top of that because they understand the 
advantages of compatibility.

I wouldn't be surprised if Tango chose to turn away from compatibility 
for the second time (be it theoretical compatibility for now since there 
is no Tango for D2). The technical reasons are dwindling and became 
tenuous to argue for, but however weak they are, they could be used to 
promote a political motivation: a Tango/D2 offering would come again as 
an either-or proposition for a standard library that precludes usage of 
Tango2 and Phobos2 together. In my opinion that would be an extremely 
dangerous gambit.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a runtime.


That runtime is druntime. If there is no understanding of that at Tango, 
that is suicide.

[snip]

 The insufficient implementation of new features propagates the
 perception that D2 is unstable, although the more conventional, D1-like
 subset of D2 is as solid in both languages. But then the perception is
 justified, because one would want to use D2 primarily for its new,
 unique offerings. A longer term perception problem is that some might
 think the _design_ of such features has unsolvable issues, which hurts
 the image of the language. I know of no major design flaws, but that is
 only an academic argument in wake of perennial implementation
 insufficiencies.


 There are still things in D1 that are not solid, just look at the bugs
 and newsgroups posts by bearophile. The module/import system, for example.


Which ones? There are more than a few :o).


Andrei
Nov 09 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 On 11/9/10 1:42 AM, Jacob Carlborg wrote:

 On 2010-11-08 20:55, Andrei Alexandrescu wrote:

 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political incentive to
 a Tango port. Tango is currently the de facto standard library for D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). Due to Sean's work on making druntime independently available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.


 Here's the problem with that: since Sean basically forked the Tango
 runtime, removed any non DMD specific code and any code for a platform
 that DMD doesn't support. And stopped contributing to Tango while others
 improved the Tango runtime we're back at square one with two
 incompatiable runtimes and the Tango runtime still seems to be better.


 It's not difficult to offer e.g. an incompatible C runtime that is
 slightly better than the standard one. People generally don't do that
 but instead add libraries on top of that because they understand the
 advantages of compatibility.


There was a good "standard" library that you forked and never added back 
any changes to it.


 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


Clearly we don't see this in the same way. I see it like this, because 
Tango was first it's druntime that chose to turn away from compatibility.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


Apparently not, since Sean ripped out all that wasn't necessary for 
Phobos but is necessary for Tango. Why are you blaming everything on 
Tango all the time?


 [snip]

 The insufficient implementation of new features propagates the
 perception that D2 is unstable, although the more conventional, D1-like
 subset of D2 is as solid in both languages. But then the perception is
 justified, because one would want to use D2 primarily for its new,
 unique offerings. A longer term perception problem is that some might
 think the _design_ of such features has unsolvable issues, which hurts
 the image of the language. I know of no major design flaws, but that is
 only an academic argument in wake of perennial implementation
 insufficiencies.


 There are still things in D1 that are not solid, just look at the bugs
 and newsgroups posts by bearophile. The module/import system, for
 example.


 Which ones? There are more than a few :o).


 Andrei


You just helped to prove my point :)

-- 
/Jacob Carlborg
Nov 09 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/9/10 12:33 PM, Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 On 11/9/10 1:42 AM, Jacob Carlborg wrote:

 On 2010-11-08 20:55, Andrei Alexandrescu wrote:

 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political
 incentive to
 a Tango port. Tango is currently the de facto standard library for
 D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). Due to Sean's work on making druntime independently
 available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.


 Here's the problem with that: since Sean basically forked the Tango
 runtime, removed any non DMD specific code and any code for a platform
 that DMD doesn't support. And stopped contributing to Tango while others
 improved the Tango runtime we're back at square one with two
 incompatiable runtimes and the Tango runtime still seems to be better.


 It's not difficult to offer e.g. an incompatible C runtime that is
 slightly better than the standard one. People generally don't do that
 but instead add libraries on top of that because they understand the
 advantages of compatibility.


 There was a good "standard" library that you forked and never added back
 any changes to it.


This must be some confusion. I didn't fork anything. Besides, it's not 
useful to fall into the pattern of finger pointing.


 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 Clearly we don't see this in the same way. I see it like this, because
 Tango was first it's druntime that chose to turn away from compatibility.


That would be a tenuous point to make in more than one way. Druntime was 
a major effort to foster runtime standardization made by its author 
himself and with intentions that I consider most transparent. I'd find 
it very difficult to concoct a hypothesis in which Sean comes across as 
not acting in the best interest of the D community.

That very concern - the best interest of the D community - has 
unequivocally been the reason for which Sean and other chose to leave 
petty fights to others and join Phobos, which has no political agenda. 
That's supposed to tell someone something. You are gladly invited to 
attempt to convince me otherwise, but the sheer facts at hand would make 
it difficult for you to build a case. I mean it's possible - for any 
number of good reasons - to ignore mounting evidence for some time, but 
at some point the waking up and smelling of the coffee is inevitable.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 Apparently not, since Sean ripped out all that wasn't necessary for
 Phobos but is necessary for Tango. Why are you blaming everything on
 Tango all the time?


There's no reason to get up in arms. I didn't blame anything on anyone, 
just stated my view of the state of affairs. I'm hardly vested 
emotionally in the matter so I'm not interested in dramatic posturing, 
assigning blame, or drawing sweeping conclusions. One thing I would be 
interested in is improving things going forward. I think that will be 
possible once we all let bygones be bygones and see what we can do to 
push D forward.


Andrei
Nov 09 2010
next sibling parent reply Tobias Pfaff <nospam spam.no> writes:
Hi all,

before I start, let me introduce myself:
I'm Tobias, currently PhD student (Computer Graphics). I did some toy 
project in D back in the D1/Tango days. Recently I decided on trying out 
whether D2 will work for a new research project once a 64bit compiler is 
out (still hoping someone will make ldc2 work... was my favorite 
compiler for my last project). So far, so good.
Now let me summarize my impressions when I started to peek in the 
newsgroup again a few days ago. Major threads:

1. Bitter fighting about a possible non-nullable type for D3(!).
Discussion style: "Noone will take away my right to write unsafe code !" 
vs. "Down with the reckless cowboy coders". Are we discussing guns or 
coding here?
That, and purposedly overhearing the other's real point.

2. Tango vs. Phobos. Wow. I really really wished we were over that by 
now. It's been like two years since I last looked in here, and still the 
same thing.

So, while I like the language and will probably stick around here 
anyway, it might me a good thing to avoid this experience for other 
people interested in D peeking into the newsgroup. Also, with (2), I 
don't really get the point here. Whatever exactly happend between the 
tango/phobos fraction -- the best thing to do to get everyone on board 
again is probably to just to make phobos2 a library everyone enjoys to 
use. And avoid starting discussions on who did what wrong over and over.
And while still lacking a few of the high-level features of Tango 
(higher level network, streaming, etc.) it feels like the direction is 
right.

With all that been said, I'm looking forward to using D for a while, 
after fighting the C++ template code monster for the last years.

Cheers,
Tobias

On 11/09/2010 10:45 PM, Andrei Alexandrescu wrote:

 On 11/9/10 12:33 PM, Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 On 11/9/10 1:42 AM, Jacob Carlborg wrote:

 On 2010-11-08 20:55, Andrei Alexandrescu wrote:

 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political
 incentive to
 a Tango port. Tango is currently the de facto standard library for
 D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). Due to Sean's work on making druntime independently
 available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.


 Here's the problem with that: since Sean basically forked the Tango
 runtime, removed any non DMD specific code and any code for a platform
 that DMD doesn't support. And stopped contributing to Tango while
 others
 improved the Tango runtime we're back at square one with two
 incompatiable runtimes and the Tango runtime still seems to be better.


 It's not difficult to offer e.g. an incompatible C runtime that is
 slightly better than the standard one. People generally don't do that
 but instead add libraries on top of that because they understand the
 advantages of compatibility.


 There was a good "standard" library that you forked and never added back
 any changes to it.


 This must be some confusion. I didn't fork anything. Besides, it's not
 useful to fall into the pattern of finger pointing.


 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 Clearly we don't see this in the same way. I see it like this, because
 Tango was first it's druntime that chose to turn away from compatibility.


 That would be a tenuous point to make in more than one way. Druntime was
 a major effort to foster runtime standardization made by its author
 himself and with intentions that I consider most transparent. I'd find
 it very difficult to concoct a hypothesis in which Sean comes across as
 not acting in the best interest of the D community.

 That very concern - the best interest of the D community - has
 unequivocally been the reason for which Sean and other chose to leave
 petty fights to others and join Phobos, which has no political agenda.
 That's supposed to tell someone something. You are gladly invited to
 attempt to convince me otherwise, but the sheer facts at hand would make
 it difficult for you to build a case. I mean it's possible - for any
 number of good reasons - to ignore mounting evidence for some time, but
 at some point the waking up and smelling of the coffee is inevitable.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 Apparently not, since Sean ripped out all that wasn't necessary for
 Phobos but is necessary for Tango. Why are you blaming everything on
 Tango all the time?


 There's no reason to get up in arms. I didn't blame anything on anyone,
 just stated my view of the state of affairs. I'm hardly vested
 emotionally in the matter so I'm not interested in dramatic posturing,
 assigning blame, or drawing sweeping conclusions. One thing I would be
 interested in is improving things going forward. I think that will be
 possible once we all let bygones be bygones and see what we can do to
 push D forward.


 Andrei
Nov 09 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Tobias Pfaff wrote:

 1. Bitter fighting about a possible non-nullable type for D3(!).
 Discussion style: "Noone will take away my right to write unsafe code !" 
 vs. "Down with the reckless cowboy coders". Are we discussing guns or 
 coding here?
 That, and purposedly overhearing the other's real point.


I don't know that it's bitter, "spirited" might be a better term. I like 
spirited discussions.



 2. Tango vs. Phobos. Wow. I really really wished we were over that by 
 now. It's been like two years since I last looked in here, and still the 
 same thing.
 
 So, while I like the language and will probably stick around here 
 anyway, it might me a good thing to avoid this experience for other 
 people interested in D peeking into the newsgroup. Also, with (2), I 
 don't really get the point here. Whatever exactly happend between the 
 tango/phobos fraction -- the best thing to do to get everyone on board 
 again is probably to just to make phobos2 a library everyone enjoys to 
 use. And avoid starting discussions on who did what wrong over and over.
 And while still lacking a few of the high-level features of Tango 
 (higher level network, streaming, etc.) it feels like the direction is 
 right.


I agree. The reasons for the Tango split long ago, whatever the merit of those 
reasons was, have long since passed. Producing another incompatible split with 
D2 will not be of an advantage to anyone, and will just give people reasons not 
to use D at all.

Jacob has recently decided to help out with improvements to druntime; I take 
that as a very welcome sign towards ending the differences.



 With all that been said, I'm looking forward to using D for a while, 
 after fighting the C++ template code monster for the last years.


Great!
Nov 09 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-10 00:00, Walter Bright wrote:

 Tobias Pfaff wrote:

 1. Bitter fighting about a possible non-nullable type for D3(!).
 Discussion style: "Noone will take away my right to write unsafe code
 !" vs. "Down with the reckless cowboy coders". Are we discussing guns
 or coding here?
 That, and purposedly overhearing the other's real point.


 I don't know that it's bitter, "spirited" might be a better term. I like
 spirited discussions.



 2. Tango vs. Phobos. Wow. I really really wished we were over that by
 now. It's been like two years since I last looked in here, and still
 the same thing.

 So, while I like the language and will probably stick around here
 anyway, it might me a good thing to avoid this experience for other
 people interested in D peeking into the newsgroup. Also, with (2), I
 don't really get the point here. Whatever exactly happend between the
 tango/phobos fraction -- the best thing to do to get everyone on board
 again is probably to just to make phobos2 a library everyone enjoys to
 use. And avoid starting discussions on who did what wrong over and over.
 And while still lacking a few of the high-level features of Tango
 (higher level network, streaming, etc.) it feels like the direction is
 right.


 I agree. The reasons for the Tango split long ago, whatever the merit of
 those reasons was, have long since passed. Producing another
 incompatible split with D2 will not be of an advantage to anyone, and
 will just give people reasons not to use D at all.

 Jacob has recently decided to help out with improvements to druntime; I
 take that as a very welcome sign towards ending the differences.


I don't want to increase any separation in the D community and would 
hope peoeple could agree more. I have no problems what so ever 
contributing both to Tango and Phobos/druntime. And I'm happy to license 
any of my code to whatever license would be need for a give D project.


 With all that been said, I'm looking forward to using D for a while,
 after fighting the C++ template code monster for the last years.


 Great!


-- 
/Jacob Carlborg
Nov 10 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Wed, 10 Nov 2010 11:56:18 +0100, Jacob Carlborg wrote:


 On 2010-11-10 00:00, Walter Bright wrote:

 I agree. The reasons for the Tango split long ago, whatever the merit
 of those reasons was, have long since passed. Producing another
 incompatible split with D2 will not be of an advantage to anyone, and
 will just give people reasons not to use D at all.

 Jacob has recently decided to help out with improvements to druntime; I
 take that as a very welcome sign towards ending the differences.


 
 I don't want to increase any separation in the D community and would
 hope peoeple could agree more. I have no problems what so ever
 contributing both to Tango and Phobos/druntime. And I'm happy to license
 any of my code to whatever license would be need for a give D project.


A dual licensing scheme for all code might help a bit (since both parties 
refuse to switch licensing). There are also

 - stylistic issues (OOP style structured Tango vs quick'n'dirty Phobos 
API) -> this causes annoying technical incompatibilities

 - psychological issues (Tango's charismatic leaders vs dull politically 
correct office persons and almost anynomous lone coders porting Boost 
code written in other languages). I believe strong personalities like Jon 
Harrop and Paul Graham actually have an overall positive effect. It's not 
a big secret that Andrei has boosted D's adoption quite a bit - this has 
more to do with the strong personality than technical issues.

 - project management issues (Tango uses trac heavily and the leaders 
have modern project management skills, Phobos developers have developed a 
new inefficient ad-hoc software process model without the big picture 
'planning' phase and without any communication between the team and the 
product owner)

 - platform issues (not everyone agrees D2 is a perfect upgrade route - 
how is this even surprising? Look at the number of people *not* using D, 
it shouldn't be a surprise that there are people who dislike D2, but like 
D1)

 - an axe fight between some key persons. I believe this can be solved if 
there weren't those other annoying problems.

These are all my subjective opinions. Feel free to throw the first rock, 
after all I'm just a stupid troll.

For me the technical issues have the greatest priority. If I want a full 
flexible Java style stream I/O interface and these kind of things, there's 
no way in hell I'll let you shove the Phobos style ideology down my 
throat. I'd have to create a "PhoTango" wrapper to actually use these.

The political issues aren't that interesting. If I'm coding in Java or 

But he left Oracle for political reasons..
Nov 10 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-11-10 12:43, retard wrote:

 Wed, 10 Nov 2010 11:56:18 +0100, Jacob Carlborg wrote:


 On 2010-11-10 00:00, Walter Bright wrote:

 I agree. The reasons for the Tango split long ago, whatever the merit
 of those reasons was, have long since passed. Producing another
 incompatible split with D2 will not be of an advantage to anyone, and
 will just give people reasons not to use D at all.

 Jacob has recently decided to help out with improvements to druntime; I
 take that as a very welcome sign towards ending the differences.


 I don't want to increase any separation in the D community and would
 hope peoeple could agree more. I have no problems what so ever
 contributing both to Tango and Phobos/druntime. And I'm happy to license
 any of my code to whatever license would be need for a give D project.


 A dual licensing scheme for all code might help a bit (since both parties
 refuse to switch licensing). There are also

   - stylistic issues (OOP style structured Tango vs quick'n'dirty Phobos
 API) ->  this causes annoying technical incompatibilities

   - psychological issues (Tango's charismatic leaders vs dull politically
 correct office persons and almost anynomous lone coders porting Boost
 code written in other languages). I believe strong personalities like Jon
 Harrop and Paul Graham actually have an overall positive effect. It's not
 a big secret that Andrei has boosted D's adoption quite a bit - this has
 more to do with the strong personality than technical issues.

   - project management issues (Tango uses trac heavily and the leaders
 have modern project management skills, Phobos developers have developed a
 new inefficient ad-hoc software process model without the big picture
 'planning' phase and without any communication between the team and the
 product owner)

   - platform issues (not everyone agrees D2 is a perfect upgrade route -
 how is this even surprising? Look at the number of people *not* using D,
 it shouldn't be a surprise that there are people who dislike D2, but like
 D1)

   - an axe fight between some key persons. I believe this can be solved if
 there weren't those other annoying problems.

 These are all my subjective opinions. Feel free to throw the first rock,
 after all I'm just a stupid troll.

 For me the technical issues have the greatest priority. If I want a full
 flexible Java style stream I/O interface and these kind of things, there's
 no way in hell I'll let you shove the Phobos style ideology down my
 throat. I'd have to create a "PhoTango" wrapper to actually use these.

 The political issues aren't that interesting. If I'm coding in Java or

 But he left Oracle for political reasons..


I basically agree with all this.

-- 
/Jacob Carlborg
Nov 10 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:

 A dual licensing scheme for all code might help a bit (since both parties 
 refuse to switch licensing). There are also


Releasing under the Boost license will make it compatible with both. Such is 
kinda the point with the Boost license, and why we chose it.



 It's not 
 a big secret that Andrei has boosted D's adoption quite a bit - this has 
 more to do with the strong personality than technical issues.


Maybe, but Andrei's technical contribution has been very large. So has his
book. 
Andrei's reputation in the programming community has been well earned through 
his technical contributions.
Nov 10 2010
prev sibling parent reply so <so so.do> writes:
  - platform issues (not everyone agrees D2 is a perfect upgrade route -
 how is this even surprising? Look at the number of people *not* using D,
 it shouldn't be a surprise that there are people who dislike D2, but like
 D1)


There are so many people love C and "hate" C++. We know it is the same  
language with one of them has some nifty extra tools.
Generic programming, namespaces, easier OOP, operator/function overloading  
and many more.
Now why would they hate C++?
. politics
. politics related to certain features like OOP, operator overloading, you  
name it.
. complexity
Could you tell me anything other than this, that make sense?


 These are all my subjective opinions. Feel free to throw the first rock,
 after all I'm just a stupid troll.


Not always but can't say that i never see you trolling :P


  - stylistic issues (OOP style structured Tango vs quick'n'dirty Phobos
 API) -> this causes annoying technical incompatibilities

 For me the technical issues have the greatest priority. If I want a full
 flexible Java style stream I/O interface and these kind of things,  
 there's
 no way in hell I'll let you shove the Phobos style ideology down my
 throat. I'd have to create a "PhoTango" wrapper to actually use these.


I am not comparing libraries and also not in a position to do that since  
didn't even see Tango.
But a question comes to mind. For library development (or just everything  
if that matters) is the top down OOP approach ideal/right way?
It is just an idiom that might have elegant solutions for certain tasks.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 10 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from so (so so.do)'s article

 But a question comes to mind. For library development (or just everything
 if that matters) is the top down OOP approach ideal/right way?
 It is just an idiom that might have elegant solutions for certain tasks.


Frankly, for a library, I hate it in most cases.  Libraries need to make the
simple use cases sufficiently simple that people aren't tempted to roll their
own.
 This means minimum boilerplate.  Don't make it a class if it can be a free
function.  Don't make me import/search through zillions of tiny modules when I'm
probably going to want to use most of them at the same time.  Don't make me
instantiate 15 layers of decorators just to read in a file line by line (*cough*
Java *cough).

When it comes to the more complicated use cases, trying to anticipate these is
rather difficult.  It's often not too hard to make complicated things possible
by
writing an OO wrapper on top of a designed-for-simplicity API.  OTOH, if you
need
to write a bunch of wrappers to avoid needing lots of boilerplate code in the
common cases, you've by definition failed at making simple things simple.
Nov 10 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to roll their
own.


Hear hear. For example, one of the goals with D strings was to make them so
good 
that people wouldn't invent their own string classes.
Nov 10 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Walter Bright Wrote:


 dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to roll their
own.


 
 Hear hear. For example, one of the goals with D strings was to make them so
good 
 that people wouldn't invent their own string classes.


And yet we still get those that want a class, or even limit the capability of
arrays so that a class is more appealing. (Had a friend that hated the idea
that D went back to array of characters, then he saw that arrays could actually
do stuff)
Nov 10 2010
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:

 Walter Bright Wrote:

 dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to roll
 their own.


 
 Hear hear. For example, one of the goals with D strings was to make them
 so good that people wouldn't invent their own string classes.


 
 And yet we still get those that want a class, or even limit the capability
 of arrays so that a class is more appealing. (Had a friend that hated the
 idea that D went back to array of characters, then he saw that arrays
 could actually do stuff)


Well, of course his first reaction was negative. Arrays suck in other languages 
in comparison to D. Having strings be arrays in C is horrible. I'd be annoyed
to 
have strings be arrays if you were using Java arrays, and they're a definite 
improvement over C - if nothing else because they know their length. Strings as 
arrays work in D precisely because D arrays are so awesome. I've never used 
another language which had arrays which were even close to as awesome as the 
ones in D.

- Jonathan M Davis
Nov 10 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Jonathan M Davis schrieb:

 On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:

 Walter Bright Wrote:

 dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to roll
 their own.


 Hear hear. For example, one of the goals with D strings was to make them
 so good that people wouldn't invent their own string classes.


 And yet we still get those that want a class, or even limit the capability
 of arrays so that a class is more appealing. (Had a friend that hated the
 idea that D went back to array of characters, then he saw that arrays
 could actually do stuff)


 
 Well, of course his first reaction was negative. Arrays suck in other
languages 
 in comparison to D. Having strings be arrays in C is horrible. I'd be annoyed
to 
 have strings be arrays if you were using Java arrays, and they're a definite 
 improvement over C - if nothing else because they know their length. Strings
as 
 arrays work in D precisely because D arrays are so awesome. I've never used 
 another language which had arrays which were even close to as awesome as the 
 ones in D.
 
 - Jonathan M Davis


The only possible source of confusion may be that slicing is only safe with 
dchar[]. (But still may work with char[] as long as you're only using ASCII 
characters, so the error may not be obvious)

Of course I don't want to propose to change that because it makes perfect sense 
the way it is, because in many situations you want to know, how long the string 
physically is (how many bytes), so any hack to splice by logical characters 
instead of physical characters would result in a terrible mess.

But this is something a string-class with .substring(beg, end), .logLength, 
.physLength and stuff like that could fix, because these differences were more 
obvious.

But then again, having the following functions in std.string may suffice:

size_t logLength(string s) // logical length in code points
string substring(string s, size_t beg, size_t end) // "logical slice" - from 
code point number beg to code point number end

On the other hand those wouldn't play nice with the existing functions like 
indexOf etc :/
Nov 11 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 9:25 AM, Daniel Gibson wrote:

 Jonathan M Davis schrieb:

 On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:

 Walter Bright Wrote:

 dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to
 roll
 their own.


 Hear hear. For example, one of the goals with D strings was to make
 them
 so good that people wouldn't invent their own string classes.


 And yet we still get those that want a class, or even limit the
 capability
 of arrays so that a class is more appealing. (Had a friend that hated
 the
 idea that D went back to array of characters, then he saw that arrays
 could actually do stuff)


 Well, of course his first reaction was negative. Arrays suck in other
 languages in comparison to D. Having strings be arrays in C is
 horrible. I'd be annoyed to have strings be arrays if you were using
 Java arrays, and they're a definite improvement over C - if nothing
 else because they know their length. Strings as arrays work in D
 precisely because D arrays are so awesome. I've never used another
 language which had arrays which were even close to as awesome as the
 ones in D.

 - Jonathan M Davis


 The only possible source of confusion may be that slicing is only safe
 with dchar[]. (But still may work with char[] as long as you're only
 using ASCII characters, so the error may not be obvious)

 Of course I don't want to propose to change that because it makes
 perfect sense the way it is, because in many situations you want to
 know, how long the string physically is (how many bytes), so any hack to
 splice by logical characters instead of physical characters would result
 in a terrible mess.

 But this is something a string-class with .substring(beg, end),
 .logLength, .physLength and stuff like that could fix, because these
 differences were more obvious.

 But then again, having the following functions in std.string may suffice:

 size_t logLength(string s) // logical length in code points


That would be walkLength.


 string substring(string s, size_t beg, size_t end) // "logical slice" -
 from code point number beg to code point number end


That's not implemented and I don't think it would be useful. Usually 
when I want a substring, the calculations up to that point indicate the 
code _unit_ I'm at.


 On the other hand those wouldn't play nice with the existing functions
 like indexOf etc :/


Hm, I just noticed a problem. std.algorithm.indexOf returns logical 
position because it uses the forward range interface, and 
std.string.indexOf returns the physical position :o(.


Andrei
Nov 11 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Andrei Alexandrescu schrieb:

 On 11/11/10 9:25 AM, Daniel Gibson wrote:

 Jonathan M Davis schrieb:

 On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:

 Walter Bright Wrote:

 dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to
 roll
 their own.


 Hear hear. For example, one of the goals with D strings was to make
 them
 so good that people wouldn't invent their own string classes.


 And yet we still get those that want a class, or even limit the
 capability
 of arrays so that a class is more appealing. (Had a friend that hated
 the
 idea that D went back to array of characters, then he saw that arrays
 could actually do stuff)


 Well, of course his first reaction was negative. Arrays suck in other
 languages in comparison to D. Having strings be arrays in C is
 horrible. I'd be annoyed to have strings be arrays if you were using
 Java arrays, and they're a definite improvement over C - if nothing
 else because they know their length. Strings as arrays work in D
 precisely because D arrays are so awesome. I've never used another
 language which had arrays which were even close to as awesome as the
 ones in D.

 - Jonathan M Davis


 The only possible source of confusion may be that slicing is only safe
 with dchar[]. (But still may work with char[] as long as you're only
 using ASCII characters, so the error may not be obvious)

 Of course I don't want to propose to change that because it makes
 perfect sense the way it is, because in many situations you want to
 know, how long the string physically is (how many bytes), so any hack to
 splice by logical characters instead of physical characters would result
 in a terrible mess.

 But this is something a string-class with .substring(beg, end),
 .logLength, .physLength and stuff like that could fix, because these
 differences were more obvious.

 But then again, having the following functions in std.string may suffice:

 size_t logLength(string s) // logical length in code points


 
 That would be walkLength.


Ok. I really should get familiar with std.algorithm and D2 in general :-)


 

 string substring(string s, size_t beg, size_t end) // "logical slice" -
 from code point number beg to code point number end


 
 That's not implemented and I don't think it would be useful. Usually 
 when I want a substring, the calculations up to that point indicate the 
 code _unit_ I'm at.
 

 On the other hand those wouldn't play nice with the existing functions
 like indexOf etc :/


 
 Hm, I just noticed a problem. std.algorithm.indexOf returns logical 
 position because it uses the forward range interface, and 
 std.string.indexOf returns the physical position :o(.
 


I'm glad to have accidentally revealed that inconsistency ;)
Probably something should be done about this, maybe by renaming one of the 
functions or something like that?


 
 Andrei


Cheers,
- Daniel
Nov 11 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/11/10 9:52 AM, Daniel Gibson wrote:

 Andrei Alexandrescu schrieb:

 On 11/11/10 9:25 AM, Daniel Gibson wrote:

 Jonathan M Davis schrieb:

 On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:

 Walter Bright Wrote:

 dsimcha wrote:

 Libraries need to make the
 simple use cases sufficiently simple that people aren't tempted to
 roll
 their own.


 Hear hear. For example, one of the goals with D strings was to make
 them
 so good that people wouldn't invent their own string classes.


 And yet we still get those that want a class, or even limit the
 capability
 of arrays so that a class is more appealing. (Had a friend that hated
 the
 idea that D went back to array of characters, then he saw that arrays
 could actually do stuff)


 Well, of course his first reaction was negative. Arrays suck in other
 languages in comparison to D. Having strings be arrays in C is
 horrible. I'd be annoyed to have strings be arrays if you were using
 Java arrays, and they're a definite improvement over C - if nothing
 else because they know their length. Strings as arrays work in D
 precisely because D arrays are so awesome. I've never used another
 language which had arrays which were even close to as awesome as the
 ones in D.

 - Jonathan M Davis


 The only possible source of confusion may be that slicing is only safe
 with dchar[]. (But still may work with char[] as long as you're only
 using ASCII characters, so the error may not be obvious)

 Of course I don't want to propose to change that because it makes
 perfect sense the way it is, because in many situations you want to
 know, how long the string physically is (how many bytes), so any hack to
 splice by logical characters instead of physical characters would result
 in a terrible mess.

 But this is something a string-class with .substring(beg, end),
 .logLength, .physLength and stuff like that could fix, because these
 differences were more obvious.

 But then again, having the following functions in std.string may
 suffice:

 size_t logLength(string s) // logical length in code points


 That would be walkLength.


 Ok. I really should get familiar with std.algorithm and D2 in general :-)


 string substring(string s, size_t beg, size_t end) // "logical slice" -
 from code point number beg to code point number end


 That's not implemented and I don't think it would be useful. Usually
 when I want a substring, the calculations up to that point indicate
 the code _unit_ I'm at.


 On the other hand those wouldn't play nice with the existing functions
 like indexOf etc :/


 Hm, I just noticed a problem. std.algorithm.indexOf returns logical
 position because it uses the forward range interface, and
 std.string.indexOf returns the physical position :o(.


 I'm glad to have accidentally revealed that inconsistency ;)
 Probably something should be done about this, maybe by renaming one of
 the functions or something like that?


Yah, this is worth a bug report. Thanks.

http://d.puremagic.com/issues/show_bug.cgi?id=5201


Andrei
Nov 11 2010
prev sibling parent reply spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 09:40:05 -0800
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 string substring(string s, size_t beg, size_t end) // "logical slice" -
 from code point number beg to code point number end =20


=20
 That's not implemented and I don't think it would be useful. Usually=20
 when I want a substring, the calculations up to that point indicate the=20
 code _unit_ I'm at.


Yes, but a code unit does not represent a character, instead a unicode "abs=
tract character".

void main() {
    dstring s =3D "\u0061\u0302\u006d\u0065"d;
    writeln(s);     // "=C3=A2me"
    assert(s[0..1] =3D=3D "a");
    assert(s.indexOf("=C3=A2") =3D=3D -1);
}

A "user-perceived character" (also strangely called "grapheme" in unicode d=
ocs) can be represented by an arbitrary number of code _units_ (up to 8 in =
their test data, but there is no actual limit). What a code unit represents=
 is, say, a "scripting mark". In "=C3=A2", there are 2 of them. For legacy =
reasons, UCS also includes "precombined characters", so that "=C3=A2" can a=
lso be represented by a single code, indeed. But the above form is valid, i=
t's even arguably the base form for "=C3=A2" (and most composite chars cann=
ot be represented by a single code).

In my views, there is a missing level of abstraction in common UString proc=
essing libs and types. How to count the "=C3=A2"s in a text? How to find on=
e? Above, indexOf fails because my editor uses a precombined code, while th=
e source (here literal) uses another form.
To be able to produce meaningful results, and to use simple routines like i=
ndex, find, count..., the way we used to with single-length character sets,=
 there should be a grouping phase on top of decoding; we would then process=
 arrays of "stacks" representing characters, not of codes. ITo search, it's=
 also necessary to have all characters normalised form, so that both "=C3=
=A2" would match: another phase.
Unicode provides algorithms for those phases in constructing string represe=
ntations -- but everyone seems to ignore the issues... s[0..1] would then r=
eturn the first character, not the first code of the "stack" representing t=
he first character.


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 11 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
spir schrieb:

 On Thu, 11 Nov 2010 09:40:05 -0800
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 

 string substring(string s, size_t beg, size_t end) // "logical slice" -
 from code point number beg to code point number end  


 That's not implemented and I don't think it would be useful. Usually 
 when I want a substring, the calculations up to that point indicate the 
 code _unit_ I'm at.


 
 Yes, but a code unit does not represent a character, instead a unicode
"abstract character".
 
 void main() {
     dstring s = "\u0061\u0302\u006d\u0065"d;
     writeln(s);     // "âme"
     assert(s[0..1] == "a");
     assert(s.indexOf("â") == -1);
 }
 
 A "user-perceived character" (also strangely called "grapheme" in unicode
docs) can be represented by an arbitrary number of code _units_ (up to 8 in
their test data, but there is no actual limit). What a code unit represents is,
say, a "scripting mark". In "â", there are 2 of them. For legacy reasons, UCS
also includes "precombined characters", so that "â" can also be represented by
a single code, indeed. But the above form is valid, it's even arguably the base
form for "â" (and most composite chars cannot be represented by a single code).
 


OMG, this is worse than I thought O_O
I thought "ok, for UTF-8 one code unit is one byte and one 'real', visible 
character is called a code point and consists of 1-4 code units" - but having 
"user-perceived characters" that consist of multiple code units is sick.
Unicode has a way to tell if a sequence of code units (bytes) belongs together 
or not, so identifying code points isn't too hard.
But is there a way to identify "graphemes"? Other then a list of rules like "a 
sequence of the two code points <foo> and <bar> make up one "grapheme" <foobar>?
Nov 11 2010
parent reply spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 22:40:47 +0100
Daniel Gibson <metalcaedes gmail.com> wrote:


 spir schrieb:

 On Thu, 11 Nov 2010 09:40:05 -0800
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
=20

 string substring(string s, size_t beg, size_t end) // "logical slice"=








 -

 from code point number beg to code point number end =20


 That's not implemented and I don't think it would be useful. Usually=20
 when I want a substring, the calculations up to that point indicate th=






e=20

 code _unit_ I'm at.


=20
 Yes, but a code unit does not represent a character, instead a unicode =




"abstract character".

=20
 void main() {
     dstring s =3D "\u0061\u0302\u006d\u0065"d;
     writeln(s);     // "=C3=A2me"
     assert(s[0..1] =3D=3D "a");
     assert(s.indexOf("=C3=A2") =3D=3D -1);
 }
=20
 A "user-perceived character" (also strangely called "grapheme" in unico=




de docs) can be represented by an arbitrary number of code _units_ (up to 8=
 in their test data, but there is no actual limit). What a code unit repres=
ents is, say, a "scripting mark". In "=C3=A2", there are 2 of them. For leg=
acy reasons, UCS also includes "precombined characters", so that "=C3=A2" c=
an also be represented by a single code, indeed. But the above form is vali=
d, it's even arguably the base form for "=C3=A2" (and most composite chars =
cannot be represented by a single code).

=20


=20
 OMG, this is worse than I thought O_O
 I thought "ok, for UTF-8 one code unit is one byte and one 'real', visibl=


e=20

 character is called a code point and consists of 1-4 code units" - but ha=


ving=20

 "user-perceived characters" that consist of multiple code units is sick.


Most people, even programmers that deal with unicode everyday, think the sa=
me. This is due to several factors: (1) unicode's misleading use of "abstra=
ct character" (wonder whether it was done in purpose?) (2) string processin=
g tools simply ignore all of that (3) most texts we deal with today only ho=
ld common characters that have a single-code representation.
So that everybody plays with strings as if (1 code <--> 1 char).


 Unicode has a way to tell if a sequence of code units (bytes) belongs tog=


ether=20

 or not, so identifying code points isn't too hard.
 But is there a way to identify "graphemes"? Other then a list of rules li=


ke "a=20

 sequence of the two code points <foo> and <bar> make up one "grapheme" <f=


oobar>?
=20
There is an algorithm, indeed, and not too complicated. But you won't find =
any information in the string of codes itself that tells you about it (mean=
ing, you cannot synchronise at start/end of "grapheme" without knowledge of=
 the whole algorithm).
Accordingly, when picking _some_ code points (eg the one 'a' above), there =
is no way to tell whether it's a standalone code that happens to represent =
a whole character ("a"), or the just the start of it. These are the base "m=
arks": they have the same code when meaning a whole char and as start of "s=
tack" (substring representing a whole char). But combining marks have 2 cod=
es: one when combined, one when used alone like in "in portuguese, '~' is u=
sed to denote a nasal vowel".
(Hope I'm clear.)

The whole set of UCS (the charset) issues, over Unicode ones, is imo:
1. Actual characters are represented by an arbitrary number of codes.
2. The same character can be represented by different strings of codes...
3. including strings of the same length, but in different order ;-)
The first issue is actually good: it would be stupid to try and give a code=
 to every possible combination, and even impossible. also, the present sche=
me allows _creating_ character for our use, that will be rndered correctly =
(yes!). (But I would kill any designer collegue that would allow for points=
 2. and 3. ;-)

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 11 2010
parent reply retard <re tard.com.invalid> writes:
Thu, 11 Nov 2010 23:59:36 +0100, spir wrote:


 (3) most texts we deal with
 today only hold common characters that have a single-code
 representation. So that everybody plays with strings as if (1 code <-->
 1 char).


That might be true for many americans. But even then the single byte 
can't express all characters you need in everyday communication. There 
are countless people with é or ë or ü in their last name. ” and “ are 
probably not among the first 128-256 codes. Using e instead of ë or é 
might work to some extent, but ü and u are pronounced differently. Some 
use ue instead.
Nov 11 2010
parent reply spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 23:17:05 +0000 (UTC)
retard <re tard.com.invalid> wrote:


 Thu, 11 Nov 2010 23:59:36 +0100, spir wrote:
=20

 (3) most texts we deal with
 today only hold common characters that have a single-code
 representation. So that everybody plays with strings as if (1 code <-->
 1 char).


=20
 That might be true for many americans. But even then the single byte=20
 can't express all characters you need in everyday communication. There=20
 are countless people with =C3=A9 or =C3=AB or =C3=BC in their last name. =


=E2=80=9D and =E2=80=9C are=20

 probably not among the first 128-256 codes. Using e instead of =C3=AB or =


=C3=A9=20

 might work to some extent, but =C3=BC and u are pronounced differently. S=


ome=20

 use ue instead.


I meant _codes_ (code points). Not code _unit_ and even less bytes.

The character <I with dot above and dot below> (if ever you want to use it =
;-) needs 2 or 3 code _points_ for representation in memory or storage. Try:
	writeln (""); // --> I=CC=87=CC=A3
If your output system is sufficiently capable, then you get an I with dot a=
bove and dot below! (I recommand the DejaVu font series). And, as you see, =
the type dstring is used, meaning each element is a dchar holding a whole c=
ode point. Right? But it's a single character requiring 3 codes.
Ebven more troubling: if I choose a lowercase 'i' instead, then since <i wi=
th dot below> exists as a precombined code, I have the choice between 2 or =
3 codes.

An "abstract character", as introduced by UCS and represented by a code, is=
 *not* what we think as "character". It is an abstract "mark", such as the =
'I', the combining dot above, the combining dot below, all inside "I=CC=87=
=CC=A3".
Also, it's important to realise that there is no formal definition of "char=
acter", and even less a universal one. A character is what people using a s=
cripting system consider as such.
I know, UCS / Unicode terminology is misleading. It does not help, instead =
it increases confusion.

What you are evoking is a lower-level issue, namely the encoding of code po=
ints themselves (here, 3) into code units, and then bytes, in a concrete fo=
rm (say, in file). Depending on the encoding (here I consider only utf8/16/=
32 ones), there may be 1, 1 or 2, 1 to 4, code units per code point.


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 12 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
spir wrote:

 An "abstract character", as introduced by UCS 


Oh gosh, another in the never ending menagerie of Unicode terms. :-(
Nov 12 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 spir wrote:

 An "abstract character", as introduced by UCS


 Oh gosh, another in the never ending menagerie of Unicode terms. :-(


If Unicode is not complicated, what is an abstract basic multilingual plane
multibyte code unit and when's the last time you needed one?
Nov 12 2010
parent so <so so.do> writes:
On Sat, 13 Nov 2010 00:59:05 +0200, dsimcha <dsimcha yahoo.com> wrote:


 == Quote from Walter Bright (newshound2 digitalmars.com)'s article

 spir wrote:

 An "abstract character", as introduced by UCS


 Oh gosh, another in the never ending menagerie of Unicode terms. :-(


 If Unicode is not complicated, what is an abstract basic multilingual  
 plane
 multibyte code unit and when's the last time you needed one?


How can they not know it? Don't we call it shortly ABMPMCU? :)

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 12 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
spir wrote:

 In my views, there is a missing level of abstraction in common UString
processing libs and types. How to count the "â"s in a text? How to find one?
Above, indexOf fails because my editor uses a precombined code, while the
source (here literal) uses another form.
 To be able to produce meaningful results, and to use simple routines like
index, find, count..., the way we used to with single-length character sets,
there should be a grouping phase on top of decoding; we would then process
arrays of "stacks" representing characters, not of codes. ITo search, it's also
necessary to have all characters normalised form, so that both "â" would
match: another phase.
 Unicode provides algorithms for those phases in constructing string
representations -- but everyone seems to ignore the issues... s[0..1] would
then return the first character, not the first code of the "stack" representing
the first character.




http://www.digitalmars.com/d/2.0/phobos/std_utf.html
Nov 11 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Walter Bright schrieb:

 spir wrote:

 In my views, there is a missing level of abstraction in common UString 
 processing libs and types. How to count the "â"s in a text? How to 
 find one? Above, indexOf fails because my editor uses a precombined 
 code, while the source (here literal) uses another form.
 To be able to produce meaningful results, and to use simple routines 
 like index, find, count..., the way we used to with single-length 
 character sets, there should be a grouping phase on top of decoding; 
 we would then process arrays of "stacks" representing characters, not 
 of codes. ITo search, it's also necessary to have all characters 
 normalised form, so that both "â" would match: another phase.
 Unicode provides algorithms for those phases in constructing string 
 representations -- but everyone seems to ignore the issues... s[0..1] 
 would then return the first character, not the first code of the 
 "stack" representing the first character.


 
 
 
 http://www.digitalmars.com/d/2.0/phobos/std_utf.html


If I'm not mistaken, those functions don't handle these "graphemes", i.e. 
something that appears like one character on the screen, but consists of 
multiple code *points*. Like spir's "â" that, in UTF-8, is encoded with the 
following bytes: 0x61 (=='a'), 0xCC, 0x82. (Or \u0061\u0302 in UTF-32).

Also, a function returning the physical position (i.e. pos in arrray of chars
or 
wchars) of logical char #logPos may be useful, e.g. for fixed width printing
stuff:
   size_t getPhysPos(char[] str, size_t logPos)

Cheers,
- Daniel
Nov 11 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Daniel Gibson wrote:

 If I'm not mistaken, those functions don't handle these "graphemes", 


Probably not, since I don't know what the **** a grapheme is. I think the
person 
who thought unicode should be divided up into characters, bytes, code points, 
code units, glyphs, combining characters, composite characters, and graphemes 
(and whatever new complexity they dream up this week) should be taken out and 
screened by the TSA.

Unicode is a simple idea, made absurdly complex.

Furthermore, I think that Phobos handles Unicode in a straightforward manner. 
All this other crazy stuff should be handled by some 3rd party 100Mb add-on, so 
none of the rest of us have to suffer under it.
Nov 11 2010
parent reply spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 18:09:44 -0800
Walter Bright <newshound2 digitalmars.com> wrote:


 Daniel Gibson wrote:

 If I'm not mistaken, those functions don't handle these "graphemes",=20


=20
 Probably not, since I don't know what the **** a grapheme is. I think the=


 person=20

 who thought unicode should be divided up into characters, bytes, code poi=


nts,=20

 code units, glyphs, combining characters, composite characters, and graph=


emes=20

 (and whatever new complexity they dream up this week) should be taken out=


 and=20

 screened by the TSA.


I think about the same.


 Unicode is a simple idea, made absurdly complex.


Yes, for sure. The added, non-functional, complexity was introduced (people=
 say) to keep some kind of superficial compatibility with legacy charset, i=
n the (hopeless) hope that this would boost initial adoption of UCS. Thus, =
we have characters like an (a with circumflex) which is represented in UCS =
(I'm talking of the higher-level not of encoding, what Unicode addresses):
* basically, with 2 code _points_, which is good, because this scheme allow=
s economically representing all possible combinations,
* but also with a single "precombined" code point, to cope with legacy char=
sets of the latin-N series, which id bad.
In addition to that, characters represented by more than 2 code points suff=
er another issue, namely that the additional "combining" codes cna be put i=
n any order ;-) There is a normal one (and an algorithm to restore it), but=
 it is not imposed.

These supposed trade-offs helped nothing concretely, because legacy texts r=
equire decoding anyway; mapping to two unicode code points instead of one i=
s nothing for software, and needs to be done once only. For this initial "a=
dvantage", we suffer undue complication for the rest of the standard's life=
time.
The consequence in terms of computing is a huge loss:
	*** the mapping 1 character <--> 1 representation does not hold anymore ***
And it's even broken in several ways. Instead, we have
	1 character <--> n representations -- where n is unpredictable
I guess you can imagine the logical suites...


 Furthermore, I think that Phobos handles Unicode in a straightforward man=


ner.=20

 All this other crazy stuff should be handled by some 3rd party 100Mb add-=


on, so=20

 none of the rest of us have to suffer under it.


All right. Maybe I'll write one day a library or type that deals with "UTex=
t" at the high level (the user level) I try to explain here. Then, one can =
index, slice, search, count, replace, match... like with plain ASCII. I've =
done it once in Lua (unfinished, but worked).

The key point to understand is that an array of code points (read, a dstrin=
g) is still not a logical string. Reason why I introduce the notion of stac=
k (ripped the word from a unicode doc). Below each c is a code:

 c c c c       physical sequence of codes
 a ^ m e       <--> sequence of "marks"

 c
 c c c         logical sequence of "stacks"
 =C3=A2 m e         <--> sequence of characters

One "stack" holds one place in the (horizontal) logical sequence, thus the =
name.

This requires, for any source text or text slice (eg a substring to be sear=
ched):
* decoding, properly speaking --> array of code in source charset (eg latin=
-3)
* code mapping --> array of unicode code ~=3D dstring
  (unecessary if source encoding is utfN, ascci, or latin-1, since code map=
s are identical)
* grouping code units representing single chars --> array of "stacks" (mini=
-dstring)
* normalising to decomposed form, called NFD (eg "=C3=A2" is 2 codes)
* sorting codes inside stack
Actually, the 3 last step can be done in one go (but it's not a big gain, i=
f any).

Then, we have restored the sensible bi-univoque mapping 1 character <--> 1 =
representation. (Like in ASCII, latin-1, and all charsets that represent ch=
aracters with single-length forms). Thus, we can safely perform any kind of=
 process.


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 12 2010
parent Daniel Gibson <metalcaedes gmail.com> writes:
spir schrieb:

 Furthermore, I think that Phobos handles Unicode in a straightforward manner. 
 All this other crazy stuff should be handled by some 3rd party 100Mb add-on,
so 
 none of the rest of us have to suffer under it.


 
 All right. Maybe I'll write one day a library or type that deals with "UText"
at the high level (the user level) I try to explain here. Then, one can index,
slice, search, count, replace, match... like with plain ASCII. I've done it
once in Lua (unfinished, but worked).
 


That'd be great :-)
Nov 12 2010
prev sibling parent spir <denis.spir gmail.com> writes:
On Fri, 12 Nov 2010 01:00:18 +0100
Daniel Gibson <metalcaedes gmail.com> wrote:


 http://www.digitalmars.com/d/2.0/phobos/std_utf.html =20


=20
 If I'm not mistaken, those functions don't handle these "graphemes", i.e.=


=20

 something that appears like one character on the screen, but consists of=


=20

 multiple code *points*. Like spir's "=C3=A2" that, in UTF-8, is encoded w=


ith the=20

 following bytes: 0x61 (=3D=3D'a'), 0xCC, 0x82. (Or \u0061\u0302 in UTF-32=


).

You are right, Daniel. As far as I understand it superficially (haven't use=
d it yet), the current utf library deals with the lower-level issues of enc=
oding code point into code units, and bytes.


 Also, a function returning the physical position (i.e. pos in arrray of c=


hars or=20

 wchars) of logical char #logPos may be useful, e.g. for fixed width print=


ing stuff:

    size_t getPhysPos(char[] str, size_t logPos)


See my reply to Walter's next post.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 12 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"spir" <denis.spir gmail.com> wrote in message 
news:mailman.283.1289507692.21107.digitalmars-d puremagic.com...
On Thu, 11 Nov 2010 09:40:05 -0800

A "user-perceived character" (also strangely called
"grapheme" in unicode docs) can be represented by an
arbitrary number of code _units_ (up to 8 in their test data, but
there is no actual limit). What a code unit represents is, say, a
"scripting mark". In "", there are 2 of them. For legacy
reasons, UCS also includes "precombined characters", so that
"" can also be represented by a single code, indeed. But the
above form is valid, it's even arguably the base form for
"" (and most composite chars cannot be represented by a
single code).


Minor rant:

Sometimes I'm nostalgic for for utter simplicity of ASCII and look at all 
the complexity of all the international symbols out there and think "Well, 
ok, so Unicode's not as simple, but it is necessary. It can't be as simple 
as ASCII and still work. And code-units/code-points, and UTF8 vs UTF16 vs 
UTF32 really aren't all *that* bad, all things considered."

Then something comes along and reminds me that Unicode decided to toss in 
multiple ways to represent the same damn character in a *single* encoding 
scheme, and then I just want to slap them. Like the precombined vs 
non-precombined characters. And how they responded to the \n vs \r\n mess by 
adding *another* newline character (Really? That's supposed to help? 
REALLY?!?).
Nov 11 2010
prev sibling parent reply Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 11/10/2010 3:16 PM, dsimcha wrote:

 Don't make it a class if it can be a free
 function.


I agree with most of the others except for this one.

I can type "Math." and instantly see my choices.  It also helps 
namespace conflicts without having to do selective imports or use the 
slightly longer std.math.log
Nov 10 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-11-10 21:42, Eric Poggel wrote:

 On 11/10/2010 3:16 PM, dsimcha wrote:

 Don't make it a class if it can be a free
 function.


 I agree with most of the others except for this one.

 I can type "Math." and instantly see my choices. It also helps namespace
 conflicts without having to do selective imports or use the slightly
 longer std.math.log


You can have renamed imports: import Math = std.math; and the you can 
use Math. as you want.

-- 
/Jacob Carlborg
Nov 10 2010
prev sibling next sibling parent so <so so.do> writes:
 I agree with most of the others except for this one.

 I can type "Math." and instantly see my choices.  It also helps  
 namespace conflicts without having to do selective imports or use the  
 slightly longer std.math.log


You can get the same thing with a namespace/module named math, after all  
it is an IDE feature.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 10 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Eric Poggel:


 On 11/10/2010 3:16 PM, dsimcha wrote:

 Don't make it a class if it can be a free
 function.


 
 I agree with most of the others except for this one.


Object oriented programming is a way to think about code, so it may come more
natural to you, or less natural, according to the way you think (often your
first language matters a lot. If your first language was OOP then probably
objects are more natural for you).

But in the end OOP was invented to face problems present in larger programs. OO
is infrastructure that adds some complexity to reduce complexity in larger
programs. It's not wise to add complexity unless it's necessary. So using a
class where a free functions is enough may be over-engineering.

Bye,
bearophile
Nov 10 2010
next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Wed, Nov 10, 2010 at 4:00 PM, bearophile <bearophileHUGS lycos.com>wrote:


 Eric Poggel:


 On 11/10/2010 3:16 PM, dsimcha wrote:

 Don't make it a class if it can be a free
 function.


 I agree with most of the others except for this one.


 Object oriented programming is a way to think about code, so it may come
 more natural to you, or less natural, according to the way you think (often
 your first language matters a lot. If your first language was OOP then
 probably objects are more natural for you).

 But in the end OOP was invented to face problems present in larger
 programs. OO is infrastructure that adds some complexity to reduce
 complexity in larger programs. It's not wise to add complexity unless it's
 necessary. So using a class where a free functions is enough may be
 over-engineering.



One thought here:
If Tango is still useful in the D world but there isn't too much enthusiasm
about porting it to D2, why not break its functionality (that isn't already
in Phobos 2) down into a set of supplemental libraries that can be included
as needed? This would seem to give the best of both worlds because there is
no longer a runtime split, the functionality and APIs provided by Tango is
still available as needed, and porting becomes something that can easily be
done incrementally.
Thoughts? Criticisms? Denunciations?
Nov 10 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Andrew Wiley schrieb:

 
 One thought here:
 If Tango is still useful in the D world but there isn't too much 
 enthusiasm about porting it to D2, why not break its functionality (that 
 isn't already in Phobos 2) down into a set of supplemental libraries 
 that can be included as needed? 


Or just put it in one library and call it "Tango2" or something like that ;)

(To allow porting of all kinds of Tango programs, about every Tango class would 
have to be ported to D2 anyway, so one could just as well do a proper port. 
Because of druntime it could coexist with Phobos2 - which was really the point 
of druntime for D2. Unfortunately nobody wanted to do this hitherto).
Nov 10 2010
next sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson <metalcaedes gmail.com>wrote:


 Andrew Wiley schrieb:



 One thought here:
 If Tango is still useful in the D world but there isn't too much
 enthusiasm about porting it to D2, why not break its functionality (that
 isn't already in Phobos 2) down into a set of supplemental libraries that
 can be included as needed?


 Or just put it in one library and call it "Tango2" or something like that
 ;)

 (To allow porting of all kinds of Tango programs, about every Tango class
 would have to be ported to D2 anyway, so one could just as well do a proper
 port. Because of druntime it could coexist with Phobos2 - which was really
 the point of druntime for D2. Unfortunately nobody wanted to do this
 hitherto).


Well, with Phobos 2, it may be that the cost of porting Tango no longer
outweighs the benefits of the extra functionality. My point was that it
doesn't have to be one large library that replaces Phobos, it could just be
a set of libraries ported as needed that provide the APIs that were most
useful in Tango.
Nov 10 2010
prev sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson <metalcaedes gmail.com>wrote:


 Andrew Wiley schrieb:



 One thought here:
 If Tango is still useful in the D world but there isn't too much
 enthusiasm about porting it to D2, why not break its functionality (that
 isn't already in Phobos 2) down into a set of supplemental libraries that
 can be included as needed?


 Or just put it in one library and call it "Tango2" or something like that
 ;)

 (To allow porting of all kinds of Tango programs, about every Tango class
 would have to be ported to D2 anyway, so one could just as well do a proper
 port. Because of druntime it could coexist with Phobos2 - which was really
 the point of druntime for D2. Unfortunately nobody wanted to do this
 hitherto).


It's also worthy of note that I wasn't addressing the porting of Tango
programs specifically. The modular approach does lose there.
Nov 10 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Andrew Wiley schrieb:

 
 
 On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson <metalcaedes gmail.com 
 <mailto:metalcaedes gmail.com>> wrote:
 
     Andrew Wiley schrieb:
 
 
         One thought here:
         If Tango is still useful in the D world but there isn't too much
         enthusiasm about porting it to D2, why not break its
         functionality (that isn't already in Phobos 2) down into a set
         of supplemental libraries that can be included as needed?
 
 
     Or just put it in one library and call it "Tango2" or something like
     that ;)
 
     (To allow porting of all kinds of Tango programs, about every Tango
     class would have to be ported to D2 anyway, so one could just as
     well do a proper port. Because of druntime it could coexist with
     Phobos2 - which was really the point of druntime for D2.
     Unfortunately nobody wanted to do this hitherto).
 
 
 It's also worthy of note that I wasn't addressing the porting of Tango 
 programs specifically. The modular approach does lose there. 
 


I thought with "[...] the functionality and APIs provided by Tango is still 
available as needed, and porting becomes something that can easily be done 
incrementally."
you meant porting Tango programs to D2, I'm sorry if I misunderstood.

I guess having some Tango modules (e.g. for Streams or XML) for D2 may be 
useful, until there are an adequate alternatives in Phobos.. but it would most 
probably harm the acceptance of these alternatives, once they're ready.
Nov 10 2010
next sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Wed, Nov 10, 2010 at 5:43 PM, Daniel Gibson <metalcaedes gmail.com>wrote:


 Andrew Wiley schrieb:


 On Wed, Nov 10, 2010 at 5:27 PM, Daniel Gibson <metalcaedes gmail.com<mailto:
 metalcaedes gmail.com>> wrote:

    Andrew Wiley schrieb:


        One thought here:
        If Tango is still useful in the D world but there isn't too much
        enthusiasm about porting it to D2, why not break its
        functionality (that isn't already in Phobos 2) down into a set
        of supplemental libraries that can be included as needed?


    Or just put it in one library and call it "Tango2" or something like
    that ;)

    (To allow porting of all kinds of Tango programs, about every Tango
    class would have to be ported to D2 anyway, so one could just as
    well do a proper port. Because of druntime it could coexist with
    Phobos2 - which was really the point of druntime for D2.
    Unfortunately nobody wanted to do this hitherto).


 It's also worthy of note that I wasn't addressing the porting of Tango
 programs specifically. The modular approach does lose there.


 I thought with "[...] the functionality and APIs provided by Tango is still
 available as needed, and porting becomes something that can easily be done
 incrementally."
 you meant porting Tango programs to D2, I'm sorry if I misunderstood.

 I guess having some Tango modules (e.g. for Streams or XML) for D2 may be
 useful, until there are an adequate alternatives in Phobos.. but it would
 most probably harm the acceptance of these alternatives, once they're ready.


Well, my assumption was that Phobos 2 was pretty much complete. If more
functionality is planned, then that's definitely a higher priority because
long term, that's a much better solution than any supplemental library.

And yes, D arrays are awesome. The best (solid) evidence I've seen of that
was the performance comparison on XML parsing where Tango utterly destroyed
every other major library.
I can also recall once when I was working on a Java project with the guy
that first introduced me to D, and he had a mysterious class called DArray
in his Java code with strange methods like "slice." A month or so later, I
wound up making a similar class in another project.
Nov 10 2010
parent reply klickverbot <see klickverbot.at> writes:
On 11/11/10 2:53 AM, Andrew Wiley wrote:

 Well, my assumption was that Phobos 2 was pretty much complete. […]


Hell, no – there currently isn't even a reliable way to load shared 
libraries in Phobos 2. std.loader doesn't count, it's almost unusable in 
practice (ExeModule being a scope class – what the …?!) and nowhere 
solid, idiomatic D.
Nov 11 2010
parent Sean Kelly <sean invisibleduck.org> writes:
klickverbot Wrote:


 On 11/11/10 2:53 AM, Andrew Wiley wrote:

 Well, my assumption was that Phobos 2 was pretty much complete. […]


 
 Hell, no – there currently isn't even a reliable way to load shared 
 libraries in Phobos 2. std.loader doesn't count, it's almost unusable in 
 practice (ExeModule being a scope class – what the …?!) and nowhere 
 solid, idiomatic D.


Runtime.loadLibrary() is meant to handle the basics.  If there's something it
should do that it currently does not, please file a bug report.  There should
still be a easy to use API in Phobos though.  Having never used std.loader, I
couldn't say whether it fits the bill or not.
Nov 11 2010
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 10, 2010 17:53:08 Andrew Wiley wrote:

 Well, my assumption was that Phobos 2 was pretty much complete. If more
 functionality is planned, then that's definitely a higher priority because
 long term, that's a much better solution than any supplemental library.


Goodness, no. Phobos is nowhere near complete. Whole modules such as std.json, 
std.xml, and std.stream are planned for deprecation in favor of newer 
implementations (which haven't been done yet). New modules are on the way -
such 
as std.datetime and std.parallelism. std.container has almost nothing in it - 
SList and Array. It's supposed to get pretty much every container which would
be 
considered fairly standard, but those implementations haven't been completed 
yet. std.algorithm continues to get tweaked all the time. Phobos is changing
all 
the time.

Phobos is way better than it was, but it's far from done. There's plenty of
work 
left to do on it. Eventually, what's there will likely stabilize to the point 
that even its ABI won't generally change (except presumably for major releases 
when necessary or when outright new functionality is added), but it's still in 
quite a bit of flux. The general API isn't even yet stable (though a lot of it 
doesn't change often). I fully expect that once Phobos is fully mature, it will 
rival Tango in every respect. But there's still a lot of work to be done on it.

- Jonathan M Davis
Nov 10 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 10 Nov 2010 21:04:08 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 std.container has almost nothing in it -
 SList and Array. It's supposed to get pretty much every container which  
 would be
 considered fairly standard, but those implementations haven't been  
 completed
 yet.


red black tree is complete, and has been submitted to Andrei for inclusion.

-Steve
Nov 11 2010
prev sibling parent reply spir <denis.spir gmail.com> writes:
On Thu, 11 Nov 2010 00:43:33 +0100
Daniel Gibson <metalcaedes gmail.com> wrote:


 I guess having some Tango modules (e.g. for Streams or XML) for D2 may be=


=20

 useful, until there are an adequate alternatives in Phobos.. but it would=


 most=20

 probably harm the acceptance of these alternatives, once they're ready.


But why not design from the start new Phobos libs with inspiration from kno=
wn-to-be-good Tango ones?

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 11 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
spir <denis.spir gmail.com> wrote:


 But why not design from the start new Phobos libs with inspiration from  
 known-to-be-good Tango ones?


We got kinda spooked by the incident with SHOO and std.time. It likely
was not as bad as it seemed, but it brought some bad blood.

-- 
Simen
Nov 11 2010
prev sibling parent Justin Johansson <no spam.com> writes:
On 11/11/10 09:10, Andrew Wiley wrote:

 On Wed, Nov 10, 2010 at 4:00 PM, bearophile <bearophileHUGS lycos.com
 <mailto:bearophileHUGS lycos.com>> wrote:

 One thought here:
 If Tango is still useful in the D world but there isn't too much
 enthusiasm about porting it to D2, why not break its functionality (that
 isn't already in Phobos 2) down into a set of supplemental libraries
 that can be included as needed? This would seem to give the best of both
 worlds because there is no longer a runtime split, the functionality and
 APIs provided by Tango is still available as needed, and porting becomes
 something that can easily be done incrementally.




 Thoughts? Criticisms? Denunciations?


You forgot Excommunication :-)



btw. interesting results on google for: define: excommunication
Nov 11 2010
prev sibling parent Justin Johansson <no spam.com> writes:
On 11/11/10 09:00, bearophile wrote:

 But in the end OOP was invented to face problems present in larger programs.
 OO is infrastructure that adds some complexity to reduce complexity 


in larger programs.
It's not wise to add complexity unless it's necessary.
So using a class where a free functions is enough may be over-engineering.

Well said.  Maintain the rage against OOP for *everything*.
Nov 11 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:

 I don't want to increase any separation in the D community and would 
 hope peoeple could agree more. I have no problems what so ever 
 contributing both to Tango and Phobos/druntime. And I'm happy to license 
 any of my code to whatever license would be need for a give D project.


This is great news! Thank you!
Nov 10 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-11-10 18:16, Walter Bright wrote:

 Jacob Carlborg wrote:

 I don't want to increase any separation in the D community and would
 hope peoeple could agree more. I have no problems what so ever
 contributing both to Tango and Phobos/druntime. And I'm happy to
 license any of my code to whatever license would be need for a give D
 project.


 This is great news! Thank you!


No no no, thank YOU. You have been very generous in licensing your 
software. Many of the files in druntime are Public Domain and the rest, 
including all of Phobos, have the Boost license. You often grant 
permission to distribute DMD when people ask. Lately gave the permission 
to put online a repository of DMD including the backend for experimental 
work with Objective-C. And the last thing you took the initiative and 
continued the process of integrating GDC as an official part of GCC, 
giving the copyright of (a fork of) the DMD frontend to FSF.

Thank You.

-- 
/Jacob Carlborg
Nov 11 2010
prev sibling parent reply klickverbot <see klickverbot.at> writes:
On 11/10/10 12:00 AM, Walter Bright wrote:

[…] Producing another incompatible split with D2 will not be of an
 advantage to anyone, and will just give people reasons not to use D
 at all.


I probably wouldn't get the problem anyway, and I have been using both 
D1/Tango and, recently, D2/Phobos, and I never understood the reasons 
for the recent clash in the first place (besides, to me, slightly … 
childish … behavior on both sides), but:

Has anyone actually proposed that? If not, I fear that comments like 
this just help spreading FUD around the current situation of D, not 
unlike the (in my eyes) exaggeration of licensing issues…
Nov 10 2010
parent klickverbot <see klickverbot.at> writes:
On 11/10/10 1:38 PM, klickverbot wrote:

 I probably wouldn't get the problem anyway, and[…]


Whoops, s/and/as/ there…
Nov 10 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-11-09 22:45, Andrei Alexandrescu wrote:

 On 11/9/10 12:33 PM, Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 On 11/9/10 1:42 AM, Jacob Carlborg wrote:

 On 2010-11-08 20:55, Andrei Alexandrescu wrote:

 It is my perception (though I might be wrong) that the dichotomy has
 become to some extent political. D2 offers little political
 incentive to
 a Tango port. Tango is currently the de facto standard library for
 D1 as
 the vast majority of D1 users use D1 and Tango in conjunction, which
 precludes use of the underpowered Phobos1 (D1's de jure standard
 library). Due to Sean's work on making druntime independently
 available,
 porting to D2 would lower Tango's status from the standard library to
 one of the libraries that may be used in conjunction with Phobos2.


 Here's the problem with that: since Sean basically forked the Tango
 runtime, removed any non DMD specific code and any code for a platform
 that DMD doesn't support. And stopped contributing to Tango while
 others
 improved the Tango runtime we're back at square one with two
 incompatiable runtimes and the Tango runtime still seems to be better.


 It's not difficult to offer e.g. an incompatible C runtime that is
 slightly better than the standard one. People generally don't do that
 but instead add libraries on top of that because they understand the
 advantages of compatibility.


 There was a good "standard" library that you forked and never added back
 any changes to it.


 This must be some confusion. I didn't fork anything. Besides, it's not
 useful to fall into the pattern of finger pointing.


Ok, "you" wasn't not a good word in this case and I apologize. What I 
meant with "you" was "you" as a group consisting of the people working 
on Phobos and druntime and/or the people that agreed (I'm assuming it 
was more than one person) we should build a new runtime for D2 based on 
the Tango runtime. I guess I just should have written "Sean".


 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 Clearly we don't see this in the same way. I see it like this, because
 Tango was first it's druntime that chose to turn away from compatibility.


 That would be a tenuous point to make in more than one way. Druntime was
 a major effort to foster runtime standardization made by its author
 himself and with intentions that I consider most transparent. I'd find
 it very difficult to concoct a hypothesis in which Sean comes across as
 not acting in the best interest of the D community.


Yes, I also think that Sean acted in the best interest of the D community.


 That very concern - the best interest of the D community - has
 unequivocally been the reason for which Sean and other chose to leave
 petty fights to others and join Phobos, which has no political agenda.
 That's supposed to tell someone something. You are gladly invited to
 attempt to convince me otherwise, but the sheer facts at hand would make
 it difficult for you to build a case. I mean it's possible - for any
 number of good reasons - to ignore mounting evidence for some time, but
 at some point the waking up and smelling of the coffee is inevitable.


I can agree with most of this and I think it's ridiculous that some 
Tango contributors don't want to contribute their code to 
Phobos/druntime. But I don't agree that it's the best interest of the D 
community that Sean stopped conributing to Tango. That's basically why 
we have this problem he never folded back any changes to Tango (as far 
as I know).


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 Apparently not, since Sean ripped out all that wasn't necessary for
 Phobos but is necessary for Tango. Why are you blaming everything on
 Tango all the time?


 There's no reason to get up in arms. I didn't blame anything on anyone,
 just stated my view of the state of affairs. I'm hardly vested
 emotionally in the matter so I'm not interested in dramatic posturing,
 assigning blame, or drawing sweeping conclusions. One thing I would be
 interested in is improving things going forward. I think that will be
 possible once we all let bygones be bygones and see what we can do to
 push D forward.


 Andrei


That's good, I also want to push D forward. It's just that sometimes I'm 
having a hard time to believe what you're writing above (last 
section/paragraph) when reading other posts by you.

-- 
/Jacob Carlborg
Nov 10 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 
 Clearly we don't see this in the same way. I see it like this, because 
 Tango was first it's druntime that chose to turn away from compatibility.


Sorry, that is completely false. druntime was created specifically to 
allow Phobos and Tango to co-exist. At the time, almost all of the code 
in druntime was written by Sean, and he was leading the Tango runtime 
development. The expectation was that Tango would continue to use Sean's 
runtime, it was just in a separate project.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a 
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 
 Apparently not, since Sean ripped out all that wasn't necessary for 
 Phobos but is necessary for Tango. Why are you blaming everything on 
 Tango all the time?


Sean took all the code he had written. The other minor contributors did 
not yet give permission for their code to be used, so of course it could 
not be included.
Nov 09 2010
next sibling parent reply so <so so.do> writes:
 Sean took all the code he had written. The other minor contributors did  
 not yet give permission for their code to be used, so of course it could  
 not be included.


This is the single big thing on this tango vs phobos issue i never  
understand.
What are the reasons/motives behind this other than stupid politics? Why  
wouldn't they give permission?

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 09 2010
next sibling parent Jesse Phillips <jessekphillips+D gmail.com> writes:
so Wrote:


 Sean took all the code he had written. The other minor contributors did  
 not yet give permission for their code to be used, so of course it could  
 not be included.


 
 This is the single big thing on this tango vs phobos issue i never  
 understand.
 What are the reasons/motives behind this other than stupid politics? Why  
 wouldn't they give permission?
 
 -- 
 Using Opera's revolutionary email client: http://www.opera.com/mail/


Well, I think some people could not be contacted. Otherwise it is just stupid
politics, and it is their code.
Nov 09 2010
prev sibling parent reply Don <nospam nospam.com> writes:
so wrote:

 Sean took all the code he had written. The other minor contributors 
 did not yet give permission for their code to be used, so of course it 
 could not be included.


 
 This is the single big thing on this tango vs phobos issue i never 
 understand.
 What are the reasons/motives behind this other than stupid politics? Why 
 wouldn't they give permission?


Nobody knows, apart from the people involved. They've made no statement 
(not even privately).
Nov 10 2010
parent reply lurker #5 <un available.com> writes:
As a long time lurker I witnessed the last, rather infamous event when this
topic
was brought up.
The way I see it the situation has only deteriorated further since then.
There are still resources spent on managing the "political" situation, to avoid
license infringement, supporting two libraries, duplicating code because of
license issues, not to mention the time spent on just discussing the situation.
Since the developers of the "alternative" standard library obviously have
ulterior
motives, the only solution is to cut them out of the D ecosystem. This can be
easily achieved if Walter stopped showing this compassionate attitude toward
them,
and started to officially "not recommend" the use of that library, in any public
forum where the issue is brought up. After a year of this their high attitude
would probably sink to the level where is belongs.
This would not undo the damage they had already done, but at least it would
neutralize any threat they represent to D2.
Nov 10 2010
parent Daniel Gibson <metalcaedes gmail.com> writes:


 As a long time lurker I witnessed the last, rather infamous event when this
topic
 was brought up.
 The way I see it the situation has only deteriorated further since then.
 There are still resources spent on managing the "political" situation, to avoid
 license infringement, supporting two libraries, duplicating code because of
 license issues, not to mention the time spent on just discussing the situation.
 Since the developers of the "alternative" standard library obviously have
ulterior
 motives, the only solution is to cut them out of the D ecosystem. This can be
 easily achieved if Walter stopped showing this compassionate attitude toward
them,
 and started to officially "not recommend" the use of that library, in any
public
 forum where the issue is brought up. After a year of this their high attitude
 would probably sink to the level where is belongs.
 This would not undo the damage they had already done, but at least it would
 neutralize any threat they represent to D2.


Yeah right, that's gonna help. Walter acting like a douche will certainly 
attract people to use D2.
Nov 10 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-11-09 23:04, Don wrote:

 Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 Clearly we don't see this in the same way. I see it like this, because
 Tango was first it's druntime that chose to turn away from compatibility.


 Sorry, that is completely false. druntime was created specifically to
 allow Phobos and Tango to co-exist. At the time, almost all of the code
 in druntime was written by Sean, and he was leading the Tango runtime
 development. The expectation was that Tango would continue to use Sean's
 runtime, it was just in a separate project.


Of course that would be the preferred way, there should have been some 
kind of agreement for this (maybe there was but never fulfilled?) But 
you also have to look at it from Tangos point of view. Why would Tango 
drop support for anything that isn't DMD 32bit? Or should Tango keep 
half of it's runtime in it's own repository and for the other half use 
druntime.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 Apparently not, since Sean ripped out all that wasn't necessary for
 Phobos but is necessary for Tango. Why are you blaming everything on
 Tango all the time?


 Sean took all the code he had written. The other minor contributors did
 not yet give permission for their code to be used, so of course it could
 not be included.


I really think it's a shame they couldn't/wanted to give permission for 
their code to be used.

-- 
/Jacob Carlborg
Nov 10 2010
next sibling parent reply Gour <gour atmarama.net> writes:
On Wed, 10 Nov 2010 11:51:19 +0100

 "Jacob" =3D=3D Jacob Carlborg wrote:












Jacob> Of course that would be the preferred way, there should have
Jacob> been some kind of agreement for this (maybe there was but never
Jacob> fulfilled?) But you also have to look at it from Tangos point of
Jacob> view. Why would Tango drop support for anything that isn't DMD
Jacob> 32bit? Or should Tango keep half of it's runtime in it's own
Jacob> repository and for the other half use druntime.

It is very disappointing to see how many people in D community are
(still) behaving like a little children pointing fingers at each other
saying "You did that to me!!"

I am probably more happy just arriving here recently and I can
understand that some mistakes were done and (some) people may feel
hurt...

However, I'm sure that D community is not the only place in the
universe where people might get hurt, but if you cannot go over it,
it's shame...

Forgive, stay and contribute to push D(2) forward.

Otherwise, if the above is not possible, stop whining and find a
better language/community to contribute to.

(Recently I did not agree with some steps done in one CMS community,
complained, became banned from the forums..andn ow I am enjoying a new
CMS community without burning too much brain cycles over the past experienc=
e.)
This constant crying over the spilled milk does not make sense for
adult people. The time won't be brought back. Let's learn the lesson
and move forward. Take it or leave it...


Sincerely,
Gour

 --=20

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
----------------------------------------------------------------
Nov 10 2010
parent piotrek <starpit tlen.pl> writes:
On Wed, 10 Nov 2010 12:55:01 +0100, Gour wrote:


 On Wed, 10 Nov 2010 11:51:19 +0100

 "Jacob" == Jacob Carlborg wrote:












 [...]
 However, I'm sure that D community is not the only place in the universe
 where people might get hurt, but if you cannot go over it, it's shame...
 
 Forgive, stay and contribute to push D(2) forward.
 
 Otherwise, if the above is not possible, stop whining and find a better
 language/community to contribute to.
 [...]
 Sincerely,
 Gour
 
  --
 
 Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA
 ----------------------------------------------------------------


These words I strongly agree with ;) 


If only deeds don't require imprisonment there's always a place for 
agreement or peaceful farewell.

Cheers
Piotrek
Nov 11 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 10 Nov 2010 05:51:19 -0500, Jacob Carlborg <doob me.com> wrote:


 Of course that would be the preferred way, there should have been some  
 kind of agreement for this (maybe there was but never fulfilled?) But  
 you also have to look at it from Tangos point of view. Why would Tango  
 drop support for anything that isn't DMD 32bit? Or should Tango keep  
 half of it's runtime in it's own repository and for the other half use  
 druntime.


I think this is the whole point of Jacob's that is being missed -- Tango  
supports LDC, GDC, and DMD, and druntime supports only DMD.  When druntime  
first was developed, it was a clone of Tango's runtime, but only with dmd  
support.  I can't remember why support for the other compilers was  
removed, but I don't think it was malicious in nature, I think it was a  
point of maintenance or lack of ownership.  I would expect that if someone  
wanted to support druntime for Tango (BTW, the D1 branch is still in  
druntime, just 2 years old) with LDC and GDC support, I don't think Sean  
would object.  But I can't speak for Sean...

But this aside, there was never any point for Tango to adopt druntime --  
phobos 1 was not going to adopt it, and Tango is not going to be ported to  
D2.  Compatibility is an academic pipe dream that will never occur.

-Steve
Nov 10 2010
prev sibling next sibling parent reply Moritz Warning <moritzwarning web.de> writes:
On Sat, 06 Nov 2010 23:11:59 +0000, bioinfornatics wrote:


 hello,
 I have a question (i would like understand), they are many important
 people of D community who do not want go to D2, why ?
 
 thanks for answer


- D2 trades complexity for more features
- D2 has a lot of compiler bugs
Nov 07 2010
parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 7-nov-10, at 13:05, Moritz Warning wrote:


 On Sat, 06 Nov 2010 23:11:59 +0000, bioinfornatics wrote:


 hello,
 I have a question (i would like understand), they are many important
 people of D community who do not want go to D2, why ?

 thanks for answer


 - D2 trades complexity for more features
 - D2 has a lot of compiler bugs


Personally I am not "against" D2, in fact there are several features  
that I would like to use (like real closures and template  
constraints), some that could be useful, but are not critical (const/ 
pure), but for me D1 works better.
It is just about wanting to do a project *now*, D1 offers more  
guarantees, like several working compilers, good support for 64 bit,  
relatively stable libraries (tango).
I know that when looking for a new language one wants to go for the  
latest and greatest, but I think that a largish project has more  
chances of having success in D1 at the moment.
It does not mean that it is not possible to use D2 successfully,  
others here are doing that, and with the recent focus of W & co on  
stabilizing the toolchain and general interest in D2 the situation  
might change, but it is not there yet.

Fawzi
Nov 07 2010
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 06/11/2010 23:11, bioinfornatics wrote:

 hello,
 I have a question (i would like understand), they are many important people of
D community who do not want go to D2, why ?

 thanks for answer


Sick of waiting for D1 to be finished.
So many differences between D1 and D2 now that it's a nightmare making 
libraries compatible with both.

Stewart.
Nov 07 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 07/11/2010 20:48, Stewart Gordon wrote:

 On 06/11/2010 23:11, bioinfornatics wrote:

 hello,
 I have a question (i would like understand), they are many important
 people of D community who do not want go to D2, why ?

 thanks for answer


 Sick of waiting for D1 to be finished.
 So many differences between D1 and D2 now that it's a nightmare making
 libraries compatible with both.

 Stewart.


Did you mean D2, in "Sick of waiting for D1 to be finished." ?

-- 
Bruno Medeiros - Software Engineer
Nov 29 2010
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/11/2010 18:30, Bruno Medeiros wrote:

 On 07/11/2010 20:48, Stewart Gordon wrote:

 On 06/11/2010 23:11, bioinfornatics wrote:

 hello,
 I have a question (i would like understand), they are many important
 people of D community who do not want go to D2, why ?

 thanks for answer


 Sick of waiting for D1 to be finished.
 So many differences between D1 and D2 now that it's a nightmare making
 libraries compatible with both.

 Stewart.


 Did you mean D2, in "Sick of waiting for D1 to be finished." ?


I don't know what you mean....

Another possible contributing factor: a feeling that D is losing its 
elegance.

Stewart.
Nov 30 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 30/11/2010 14:08, Stewart Gordon wrote:

 On 29/11/2010 18:30, Bruno Medeiros wrote:

 On 07/11/2010 20:48, Stewart Gordon wrote:

 On 06/11/2010 23:11, bioinfornatics wrote:

 hello,
 I have a question (i would like understand), they are many important
 people of D community who do not want go to D2, why ?

 thanks for answer


 Sick of waiting for D1 to be finished.
 So many differences between D1 and D2 now that it's a nightmare making
 libraries compatible with both.

 Stewart.


 Did you mean D2, in "Sick of waiting for D1 to be finished." ?


 I don't know what you mean....

 Another possible contributing factor: a feeling that D is losing its
 elegance.

 Stewart.


I meant: did you mean "Sick of waiting for D2 to be finished." instead 
of "Sick of waiting for D1 to be finished." ?
Otherwise I don't quite get it, D1 is quite stable (as a language), it's 
D2 that is getting a lot of changes.

-- 
Bruno Medeiros - Software Engineer
Nov 30 2010
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/11/2010 14:13, Bruno Medeiros wrote:

 On 30/11/2010 14:08, Stewart Gordon wrote:

 On 29/11/2010 18:30, Bruno Medeiros wrote:




<snip>

 Did you mean D2, in "Sick of waiting for D1 to be finished." ?


 I don't know what you mean....




<snip>

 I meant: did you mean "Sick of waiting for D2 to be finished." instead
 of "Sick of waiting for D1 to be finished." ?
 Otherwise I don't quite get it, D1 is quite stable (as a language), it's
 D2 that is getting a lot of changes.


I guess it was really a question of why you meant it rather than what 
you meant.

D1 may be "quite stable", but that's very different from "finished".
http://www.digitalmars.com/d/archives/digitalmars/D/When_will_D1_be_finished_89749.html
http://d.puremagic.com/issues/show_bug.cgi?id=677

The point is that D1 should have been finished ages ago.  Development of 
D2 has detracted from this, and so people are fighting against this by 
not supporting the D2 project.

Stewart.
Nov 30 2010
next sibling parent reply so <so so.do> writes:
 D1 may be "quite stable", but that's very different from "finished".
 http://www.digitalmars.com/d/archives/digitalmars/D/When_will_D1_be_finished_89749.html
 http://d.puremagic.com/issues/show_bug.cgi?id=677


What is a "finished" language, is it something like "that is it guys, we  



 The point is that D1 should have been finished ages ago.  Development of  
 D2 has detracted from this, and so people are fighting against this by  
 not supporting the D2 project.


I believe their reasons are political.
If their reason is really D1 being not finished then we are better off  
with them.
"Quite stable" and "stable" is the state we should be after, am i wrong?

Thank you.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Dec 01 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 01/12/2010 12:17, so wrote:

 D1 may be "quite stable", but that's very different from "finished".
 http://www.digitalmars.com/d/archives/digitalmars/D/When_will_D1_be_finished_89749.html

 http://d.puremagic.com/issues/show_bug.cgi?id=677


 What is a "finished" language, is it something like "that is it guys, we



<snip>

In this context, I mean it being a completely and consistently defined 
language that third parties can implement.

Stewart.
Dec 01 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 30/11/2010 19:02, Stewart Gordon wrote:

 On 30/11/2010 14:13, Bruno Medeiros wrote:

 On 30/11/2010 14:08, Stewart Gordon wrote:

 On 29/11/2010 18:30, Bruno Medeiros wrote:




 <snip>

 Did you mean D2, in "Sick of waiting for D1 to be finished." ?


 I don't know what you mean....




 <snip>

 I meant: did you mean "Sick of waiting for D2 to be finished." instead
 of "Sick of waiting for D1 to be finished." ?
 Otherwise I don't quite get it, D1 is quite stable (as a language), it's
 D2 that is getting a lot of changes.


 I guess it was really a question of why you meant it rather than what
 you meant.

 D1 may be "quite stable", but that's very different from "finished".
 http://www.digitalmars.com/d/archives/digitalmars/D/When_will_D1_be_finished_89749.html

 http://d.puremagic.com/issues/show_bug.cgi?id=677

 The point is that D1 should have been finished ages ago. Development of
 D2 has detracted from this, and so people are fighting against this by
 not supporting the D2 project.

 Stewart.


Given what you meant by finished (consistently defined language, etc.), 
then yeah, D1 isn't really finished. But what do you mean "D1 should 
have been finished ages ago"? As far as I know, Walter never expressed 
the intention of making D1 "finished", that is, to flesh out and 
formalize the language spec. Rather, the creation of D2 was to make D1 
"stable" (to not introduce backwards incompatible changes to the 
language, and to reduce bugs in the D1 compiler).

If you mean "should" as in, that should have been the intention, well, 
that's arguable. If one wanted at that point for D to stop evolving (in 
a non backwards-compatible way), then yes, you'd want the main focus of 
attention to be D1, and in finishing it. But that wasn't the desire with 
many (probably most) in the community, including Walter himself, so D2 
became the main focus of development. And with this decision, fleshing 
out the D1 spec was never going to be important (as in, important enough 
to dedicate time to it in a significant way).

-- 
Bruno Medeiros - Software Engineer
Dec 02 2010
parent retard <re tard.com.invalid> writes:
Thu, 02 Dec 2010 13:21:57 +0000, Bruno Medeiros wrote:


 On 30/11/2010 19:02, Stewart Gordon wrote:

 On 30/11/2010 14:13, Bruno Medeiros wrote:

 On 30/11/2010 14:08, Stewart Gordon wrote:

 On 29/11/2010 18:30, Bruno Medeiros wrote:




 <snip>

 Did you mean D2, in "Sick of waiting for D1 to be finished." ?


 I don't know what you mean....




 <snip>

 I meant: did you mean "Sick of waiting for D2 to be finished." instead
 of "Sick of waiting for D1 to be finished." ? Otherwise I don't quite
 get it, D1 is quite stable (as a language), it's D2 that is getting a
 lot of changes.


 I guess it was really a question of why you meant it rather than what
 you meant.

 D1 may be "quite stable", but that's very different from "finished".
 http://www.digitalmars.com/d/archives/digitalmars/D/




When_will_D1_be_finished_89749.html

 http://d.puremagic.com/issues/show_bug.cgi?id=677

 The point is that D1 should have been finished ages ago. Development of
 D2 has detracted from this, and so people are fighting against this by
 not supporting the D2 project.

 Stewart.


 
 Given what you meant by finished (consistently defined language, etc.),
 then yeah, D1 isn't really finished. But what do you mean "D1 should
 have been finished ages ago"? As far as I know, Walter never expressed
 the intention of making D1 "finished", that is, to flesh out and
 formalize the language spec. Rather, the creation of D2 was to make D1
 "stable" (to not introduce backwards incompatible changes to the
 language, and to reduce bugs in the D1 compiler).
 
 If you mean "should" as in, that should have been the intention, well,
 that's arguable. If one wanted at that point for D to stop evolving (in
 a non backwards-compatible way), then yes, you'd want the main focus of
 attention to be D1, and in finishing it. But that wasn't the desire with
 many (probably most) in the community, including Walter himself, so D2
 became the main focus of development. And with this decision, fleshing
 out the D1 spec was never going to be important (as in, important enough
 to dedicate time to it in a significant way).


Even if Walter refused to work on D1 anymore, some believe that the 
language should be finished in any case. This means that the community 
continues the work (writing specs, developing build tools etc.) Why is 
this surprising? This has happened with almost all languages. It's open 
source, you're free to work on it. That's the price you pay. You can't 
force people to work on D2 instead.
Dec 02 2010
prev sibling next sibling parent reply Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 11/6/2010 7:11 PM, bioinfornatics wrote:

 hello,
 I have a question (i would like understand), they are many important people of
D community who do not want go to D2, why ?

 thanks for answer


D1+Tango is working well enough for my project (Yage), but I like the 
direction of D2.  I figure the longer I wait, the more stable it will 
become and the easier my job will be.
Nov 07 2010
parent ponce <spam spam.org> writes:
 D1+Tango is working well enough for my project (Yage), but I like the 
 direction of D2.  I figure the longer I wait, the more stable it will 
 become and the easier my job will be.


Pretty much the same here, except I use D1 + Phobos.
To me there is little doubt that D2 is better.
Nov 09 2010
prev sibling next sibling parent Bane <branimir.milosavljevic gmail.com> writes:
ponce Wrote:


 D1+Tango is working well enough for my project (Yage), but I like the 
 direction of D2.  I figure the longer I wait, the more stable it will 
 become and the easier my job will be.


 
 Pretty much the same here, except I use D1 + Phobos.
 To me there is little doubt that D2 is better.


Same thing here. It has all I need so far. Tried to switch to D2 couple months
ago as a test, but it was painfull and unsucessfull attempt, mostly because of
bugs.
Nov 09 2010
prev sibling next sibling parent reply FeepingCreature <default_357-line yahoo.de> writes:
thank you oldtimer Wrote:


 oldtimer Wrote:
 
 Is it a coincidence that all the complaints seem to come from a single person?
Let's take a look at my killfile:
 
 ankh, anonymous troll, another lurker, anton smith, arnoldsschwartz, bjarne
yesterday, blaise pascal, cal, chmod+x, crap, darth tango, domino, ellis
peters, foobar, gareth charnock, gcc-lurker, girlprogrammer, godworshipper,
gryphon, her3tic, jameskan, jane doe, jarett billingsley, jer, languagefan,
larry coder, lars ivar douchesund, levenshtein, lurker, nobody, oldtimer, pipe
dream, pointing hand, retard, retard++, retarded.clear(), scott, steveh,
superdan, user, wah, william t. fnk, yoda, type<erasure>, uriel (reddit),
eternium (reddit), iliekcaeks (reddit), feepingcreature (reddit),
parametricpoly (reddit), nfxjfg (bugzilla), and many more!
 


Wow.

I must be INSANELY productive.

Maybe you should listen to me.
Nov 10 2010
parent superman <sm krypton.org> writes:
== Quote from FeepingCreature (default_357-line yahoo.de)'s article

 thank you oldtimer Wrote:

 oldtimer Wrote:

 Is it a coincidence that all the complaints seem to come from a




single person? Let's take a look at my killfile:

 ankh, anonymous troll, another lurker, anton smith,




arnoldsschwartz, bjarne yesterday, blaise pascal, cal, chmod+x,
crap, darth tango, domino, ellis peters, foobar, gareth charnock,
gcc-lurker, girlprogrammer, godworshipper, gryphon, her3tic,
jameskan, jane doe, jarett billingsley, jer, languagefan, larry
coder, lars ivar douchesund, levenshtein, lurker, nobody, oldtimer,
pipe dream, pointing hand, retard, retard++, retarded.clear(),
scott, steveh, superdan, user, wah, william t. fnk, yoda,
type<erasure>, uriel (reddit), eternium (reddit), iliekcaeks
(reddit), feepingcreature (reddit), parametricpoly (reddit), nfxjfg
(bugzilla), and many more!


 Wow.
 I must be INSANELY productive.
 Maybe you should listen to me.


Or ME!



 Nov 11 2010



prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org>  writes:


Jacob Carlborg Wrote:


 On 2010-11-09 23:04, Don wrote:

 Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 Clearly we don't see this in the same way. I see it like this, because
 Tango was first it's druntime that chose to turn away from compatibility.


 Sorry, that is completely false. druntime was created specifically to
 allow Phobos and Tango to co-exist. At the time, almost all of the code
 in druntime was written by Sean, and he was leading the Tango runtime
 development. The expectation was that Tango would continue to use Sean's
 runtime, it was just in a separate project.


 
 Of course that would be the preferred way, there should have been some 
 kind of agreement for this (maybe there was but never fulfilled?) But 
 you also have to look at it from Tangos point of view. Why would Tango 
 drop support for anything that isn't DMD 32bit? Or should Tango keep 
 half of it's runtime in it's own repository and for the other half use 
 druntime.


I maintained a D1 branch of druntime for ages thinking that it might be a good
transition point for Tango, but no one ever used it.  I was also very careful
to avoid creating any incompatibilities with the Tango runtime for quite a
while, but finally had to choose between letting the library stagnate in
anticipation of an event that would likely never happen and moving forward.  I
do still try to avoid changing existing user-facing code though.  Also, if you
compare the two now, I think you'll find that the Tango runtime has diverged
from the original design far more than druntime, so there's little apparent
interest there in facilitating a merge.  Either way, as there's been little
apparent effort in porting Tango to D2, this whole discussion is moot.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 Apparently not, since Sean ripped out all that wasn't necessary for
 Phobos but is necessary for Tango. Why are you blaming everything on
 Tango all the time?


 Sean took all the code he had written. The other minor contributors did
 not yet give permission for their code to be used, so of course it could
 not be included.


 
 I really think it's a shame they couldn't/wanted to give permission for 
 their code to be used.


There was another simpler reason as well, which was that I didn't want to
speculatively maintain code for various compilers or whatever just in case they
decided to use druntime one day.  It's far less effort to simply add whatever's
needed when that day comes.  Also, I do still feel that the druntime SVN
shouldn't have to be the repository used for every compiler runtime or garbage
collector implementation.  That was necessary in Tango because Tango was an
alternative library, so for any hope of Tango being used we had to do all the
work ourselves.  It's far from being an optimal workflow however.



 Nov 10 2010



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2010-11-10 22:26, Sean Kelly wrote:

 Jacob Carlborg Wrote:


 On 2010-11-09 23:04, Don wrote:

 Jacob Carlborg wrote:

 On 2010-11-09 17:43, Andrei Alexandrescu wrote:

 I wouldn't be surprised if Tango chose to turn away from compatibility
 for the second time (be it theoretical compatibility for now since there
 is no Tango for D2). The technical reasons are dwindling and became
 tenuous to argue for, but however weak they are, they could be used to
 promote a political motivation: a Tango/D2 offering would come again as
 an either-or proposition for a standard library that precludes usage of
 Tango2 and Phobos2 together. In my opinion that would be an extremely
 dangerous gambit.


 Clearly we don't see this in the same way. I see it like this, because
 Tango was first it's druntime that chose to turn away from compatibility.


 Sorry, that is completely false. druntime was created specifically to
 allow Phobos and Tango to co-exist. At the time, almost all of the code
 in druntime was written by Sean, and he was leading the Tango runtime
 development. The expectation was that Tango would continue to use Sean's
 runtime, it was just in a separate project.


 Of course that would be the preferred way, there should have been some
 kind of agreement for this (maybe there was but never fulfilled?) But
 you also have to look at it from Tangos point of view. Why would Tango
 drop support for anything that isn't DMD 32bit? Or should Tango keep
 half of it's runtime in it's own repository and for the other half use
 druntime.


 I maintained a D1 branch of druntime for ages thinking that it might be a good
transition point for Tango, but no one ever used it.  I was also very careful
to avoid creating any incompatibilities with the Tango runtime for quite a
while, but finally had to choose between letting the library stagnate in
anticipation of an event that would likely never happen and moving forward.  I
do still try to avoid changing existing user-facing code though.  Also, if you
compare the two now, I think you'll find that the Tango runtime has diverged
from the original design far more than druntime, so there's little apparent
interest there in facilitating a merge.  Either way, as there's been little
apparent effort in porting Tango to D2, this whole discussion is moot.


I can really understand that this can be very frustrating. I don't have 
any answers on why Tango didn't adopt druntime. Although as I said 
earlier I can think some reasons like no support for other compilers.


 For this to work the Tango team and the druntime
 contributors/maintainers have collaborate and work together on a
 runtime.


 That runtime is druntime. If there is no understanding of that at Tango,
 that is suicide.


 Apparently not, since Sean ripped out all that wasn't necessary for
 Phobos but is necessary for Tango. Why are you blaming everything on
 Tango all the time?


 Sean took all the code he had written. The other minor contributors did
 not yet give permission for their code to be used, so of course it could
 not be included.


 I really think it's a shame they couldn't/wanted to give permission for
 their code to be used.


 There was another simpler reason as well, which was that I didn't want to
speculatively maintain code for various compilers or whatever just in case they
decided to use druntime one day.  It's far less effort to simply add whatever's
needed when that day comes.  Also, I do still feel that the druntime SVN
shouldn't have to be the repository used for every compiler runtime or garbage
collector implementation.  That was necessary in Tango because Tango was an
alternative library, so for any hope of Tango being used we had to do all the
work ourselves.  It's far from being an optimal workflow however.


I you don't think that support for other compilers should be in druntime 
what do you suggest?

-- 
/Jacob Carlborg



 Nov 11 2010



  parent  Daniel Gibson <metalcaedes gmail.com>  writes:


Jacob Carlborg schrieb:

 On 2010-11-10 22:26, Sean Kelly wrote:

 There was another simpler reason as well, which was that I didn't want 
 to speculatively maintain code for various compilers or whatever just 
 in case they decided to use druntime one day.  It's far less effort to 
 simply add whatever's needed when that day comes.  Also, I do still 
 feel that the druntime SVN shouldn't have to be the repository used 
 for every compiler runtime or garbage collector implementation.  That 
 was necessary in Tango because Tango was an alternative library, so 
 for any hope of Tango being used we had to do all the work ourselves.  
 It's far from being an optimal workflow however.


 
 I you don't think that support for other compilers should be in druntime 
 what do you suggest?
 


That every compiler ships it's own version of druntime?
If druntime needs to be adjusted for any compiler anyway, the compiler-devs can 
do that themselves (probably they know better how to do that, anyway).
This has the merit the compiler devs can make changes on the compiler without 
being afraid of breaking druntime - because they can adjust their version of 
druntime accordingly.

Cheers,
- Daniel



 Nov 11 2010



prev sibling  parent  Bernard Helyer <b.helyer gmail.com>  writes:


On Wed, 10 Nov 2010 16:26:52 -0500, Sean Kelly wrote:

 Also, I do still feel
 that the druntime SVN shouldn't have to be the repository used for every
 compiler runtime or garbage collector implementation.


I am attempting to write a compiler in D2 (github.com/bhelyer/SDC), and I 
can't help but feel that rewriting druntime, or picking out the 
relatively benign parts would be a difficult, bug filled task. I don't 
see a realistic alternative to druntime compatibility.  I also feel that 
having all implementations share the GC implementation means that 
improvements there will improve everywhere else. If I weren't to use 
druntime's GC, then I would use the Boehm collector, but I feel using 
druntime is more beneficial than not.



 Nov 11 2010



prev sibling next sibling parent reply Sam Hu <samhudotsamhu gmail.com>  writes:


Boris Wang Wrote:


 First, forgive my poor english.
 
 we all known , Walter good at compiler writing, but not good at language
 design and development management , if can't change this, just be silent.
 
 I think, on language desgin, wisdom and leadership are more more important
 than technology.
 
 Ether continue working on D, or make D like clone,  if we can't do it like
 APPLE, just give up ASAP,
 because we can only save us by our selves.
 .
 .
 
 
 
 2010/11/10 Boris Wang <kona.ming gmail.com>


Is printing Chinese font in the console under windows now workable?If yes,which
function under which module should I use?If not,when is it supposed to be?

Is it workable writing a DLL under windows in D2 now?

I read from previous thread that std.xml is supposed to be replace by another
better one,when?

In TDPL,chap 01,

1.import std.stdio, std.string;   
2.void main()    
3.{   
4.    uint[string] dictionary;   
5.    foreach (line; stdin.byLine())    
6.    {   
7.        // Break sentence into words   
8.        // Add each word in the sentence to the vocabulary   
9.        foreach (word; splitter(strip(line)))    
10.        {   
11.            if (word in dictionary) continue; // Nothing to do   
12.            auto newlD = dictionary.length;   
13.            dictionary[word] = newlD;   
14.            writeln(newlD, word);   
15.        }   
16.     }   
17.}  


The above code is supposed to print each word one time,but after testing by
myself and my friends on different machine both under windows,it does not.It
prints some of the words several times,but some are ok.One of my friend
suggested to modify the code as below:

1.foreach(line;stdin.byLine())     
2.{   
3.    line = line.dup;   // <-------------------------- here   
4.    foreach(word;splitter(strip(line)))     
5.    {     
6.        if(word in dictionary) continue;     
7.        auto newID=dictionary.length;     
8.        dictionary[word]=newID;     
9.        writeln(newID,'\t',word);     
10.    }     
11.}   

Still it behaves different on different machine under windows.



 Nov 10 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/10/10 10:12 PM, Sam Hu wrote:

 Boris Wang Wrote:


 First, forgive my poor english.

 we all known , Walter good at compiler writing, but not good at language
 design and development management , if can't change this, just be silent.

 I think, on language desgin, wisdom and leadership are more more important
 than technology.

 Ether continue working on D, or make D like clone,  if we can't do it like
 APPLE, just give up ASAP,
 because we can only save us by our selves.
 .
 .



 2010/11/10 Boris Wang<kona.ming gmail.com>


 Is printing Chinese font in the console under windows now workable?If
yes,which function under which module should I use?If not,when is it supposed
to be?

 Is it workable writing a DLL under windows in D2 now?

 I read from previous thread that std.xml is supposed to be replace by another
better one,when?

 In TDPL,chap 01,

 1.import std.stdio, std.string;
 2.void main()
 3.{
 4.    uint[string] dictionary;
 5.    foreach (line; stdin.byLine())
 6.    {
 7.        // Break sentence into words
 8.        // Add each word in the sentence to the vocabulary
 9.        foreach (word; splitter(strip(line)))
 10.        {
 11.            if (word in dictionary) continue; // Nothing to do
 12.            auto newlD = dictionary.length;
 13.            dictionary[word] = newlD;
 14.            writeln(newlD, word);
 15.        }
 16.     }
 17.}


 The above code is supposed to print each word one time,but after testing by
myself and my friends on different machine both under windows,it does not.It
prints some of the words several times,but some are ok.One of my friend
suggested to modify the code as below:

 1.foreach(line;stdin.byLine())
 2.{
 3.    line = line.dup;   //<-------------------------- here
 4.    foreach(word;splitter(strip(line)))
 5.    {
 6.        if(word in dictionary) continue;
 7.        auto newID=dictionary.length;
 8.        dictionary[word]=newID;
 9.        writeln(newID,'\t',word);
 10.    }
 11.}

 Still it behaves different on different machine under windows.


I am ashamed to reply that this is due to a major dmd bug that is not 
yet fixed:

http://d.puremagic.com/issues/show_bug.cgi?id=2954

Apologies. I will do what I can to have this fixed asap.


Andrei



 Nov 11 2010



prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org>  writes:


Jacob Carlborg Wrote:

 
 I you don't think that support for other compilers should be in druntime 
 what do you suggest?


They should be in their own SVN repository somewhere.  I think one could even
argue that the DMD compiler runtime (src/rt in druntime) should be maintained
separately.  It's quite convenient to have the druntime repository produce a
fully functional runtime however, and what better compiler to support than the
reference compiler?

To be clear, I'm not vehemently opposed to other compiler runtimes living in
the druntime repository.  It's simply proven to be a bad model.  In Tango, when
a new DMD version was released I merged changes into the Tango runtime (a task
which wouldn't admittedly exist with druntime), and then I speculatively made
the same changes to the other runtimes as well.  In places where compiler
support was needed, I left the new code versioned out with a comment to deal
with it when that compiler was updated.  All in all, it meant a lot of work for
me, and it was difficult to maintain a fully functional source tree.  I know
the alternative is that each compiler team may have to sync with changes to
druntime (at least core/* and gc/*), but this is a rather small and stable set
of modules compared to the D1 Phobos arrangement.

From a functional perspective, the other issue is that the compiler doesn't
like something having a module name of "rt.blah" but living in ldcrt/blah.d. 
This is a problem with maintaining multiple GCs as well.  Symlinks are an
option on Posix, but as far as I know that isn't possible on Windows, so files
would have to be copied around during the build process depending on which
compiler or GC was selected.



 Nov 11 2010



 next sibling parent  "Vladimir Panteleev" <vladimir thecybershadow.net>  writes:


On Thu, 11 Nov 2010 21:28:47 +0200, Sean Kelly <sean invisibleduck.org>  
wrote:


 They should be in their own SVN repository somewhere.


Nitpicking and off-topic, but probably not SVN - a DVCS would make  
maintaining a fork much easier.


 Symlinks are an option on Posix, but as far as I know that isn't  
 possible on Windows,


NTFS has had junction points for quite a while now, which behave almost  
exactly like directory symlinks. The last OS to not support them was  
Windows XP, if it was installed to a FAT32 partition.

-- 
Best regards,
  Vladimir                            mailto:vladimir thecybershadow.net



 Nov 11 2010



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2010-11-11 20:28, Sean Kelly wrote:

 Jacob Carlborg Wrote:

 I you don't think that support for other compilers should be in druntime
 what do you suggest?


 They should be in their own SVN repository somewhere.  I think one could even
argue that the DMD compiler runtime (src/rt in druntime) should be maintained
separately.  It's quite convenient to have the druntime repository produce a
fully functional runtime however, and what better compiler to support than the
reference compiler?

 To be clear, I'm not vehemently opposed to other compiler runtimes living in
the druntime repository.  It's simply proven to be a bad model.  In Tango, when
a new DMD version was released I merged changes into the Tango runtime (a task
which wouldn't admittedly exist with druntime), and then I speculatively made
the same changes to the other runtimes as well.  In places where compiler
support was needed, I left the new code versioned out with a comment to deal
with it when that compiler was updated.  All in all, it meant a lot of work for
me, and it was difficult to maintain a fully functional source tree.  I know
the alternative is that each compiler team may have to sync with changes to
druntime (at least core/* and gc/*), but this is a rather small and stable set
of modules compared to the D1 Phobos arrangement.

  From a functional perspective, the other issue is that the compiler doesn't
like something having a module name of "rt.blah" but living in ldcrt/blah.d. 
This is a problem with maintaining multiple GCs as well.  Symlinks are an
option on Posix, but as far as I know that isn't possible on Windows, so files
would have to be copied around during the build process depending on which
compiler or GC was selected.


Ok, thanks for explaining.

-- 
/Jacob Carlborg



 Nov 12 2010



prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org>  writes:


Bernard Helyer Wrote:


 On Wed, 10 Nov 2010 16:26:52 -0500, Sean Kelly wrote:

 Also, I do still feel
 that the druntime SVN shouldn't have to be the repository used for every
 compiler runtime or garbage collector implementation.


 
 I am attempting to write a compiler in D2 (github.com/bhelyer/SDC), and I 
 can't help but feel that rewriting druntime, or picking out the 
 relatively benign parts would be a difficult, bug filled task. I don't 
 see a realistic alternative to druntime compatibility.  I also feel that 
 having all implementations share the GC implementation means that 
 improvements there will improve everywhere else. If I weren't to use 
 druntime's GC, then I would use the Boehm collector, but I feel using 
 druntime is more beneficial than not.


I absolutely believe that druntime should be used by D2 compilers.  The only
issue is staying in sync with the main druntime repository.  Perhaps a
different VCS would make this easier though.  Maybe git?  Functionally, all
you'd need to do is replace src/object_.d and src/rt/* with your own code,
assuming that you didn't want to use the DMD stuff as-is.



 Nov 11 2010



  parent reply Russel Winder <russel russel.org.uk>  writes:


On Thu, 2010-11-11 at 14:34 -0500, Sean Kelly wrote:
[ . . ]

 I absolutely believe that druntime should be used by D2 compilers.
 The only issue is staying in sync with the main druntime repository.
 Perhaps a different VCS would make this easier though.  Maybe git?
 Functionally, all you'd need to do is replace src/object_.d and
 src/rt/* with your own code, assuming that you didn't want to use the
 DMD stuff as-is.


Using Git is certainly better than using Subversion, but Bazaar and
Mercurial are the tools of choice for the discerning developer.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Nov 11 2010



 next sibling parent  bioinfornatics <bioinfornatics fedoraproject.org>  writes:


git is better for managing branch



 Nov 11 2010



prev sibling  parent  klickverbot <see klickverbot.at>  writes:


On 11/11/10 8:52 PM, Russel Winder wrote:

 Using Git is certainly better than using Subversion, but Bazaar and
 Mercurial are the tools of choice for the discerning developer.


Oh, so you really want to start that discussion/flamewar again? -.-

As you noted yourself in the thread over at d.D.announce, »[…]
no-one to date has objective data so all statements on this are 
opinion«, so could we please leave it at that, at least for the time being?



 Nov 11 2010



prev sibling  parent reply Sam Hu <samhudotsamhu gmail.com>  writes:


Andrei Alexandrescu Wrote:

 The above code is supposed to print each word one time,but after testing by
myself and my friends on different machine both under windows,it does not.It
prints some of the words several times,but some are ok.One of my friend
suggested to modify the code as below:


 Still it behaves different on different machine under windows.




 
 I am ashamed to reply that this is due to a major dmd bug that is not 
 yet fixed:
 
 http://d.puremagic.com/issues/show_bug.cgi?id=2954
 
 Apologies. I will do what I can to have this fixed asap.
 
 
 Andrei


Thank you so much for your time to reading my post!

So many times I felt D is so great,so beautiful and decided to focus on it,so
many times I encountered problems,some weird,like this sample;some are known
issue but it seems never ever got attention,like Chinese font print to
console,and some others ,which make me feel bad,and can not go on the learning.

Hope apprent issues get fixed asap,a workable workspace is available very soon.



 Nov 11 2010



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 11/11/10 5:17 PM, Sam Hu wrote:

 Andrei Alexandrescu Wrote:

 The above code is supposed to print each word one time,but after testing by
myself and my friends on different machine both under windows,it does not.It
prints some of the words several times,but some are ok.One of my friend
suggested to modify the code as below:


 Still it behaves different on different machine under windows.




 I am ashamed to reply that this is due to a major dmd bug that is not
 yet fixed:

 http://d.puremagic.com/issues/show_bug.cgi?id=2954

 Apologies. I will do what I can to have this fixed asap.


 Andrei


 Thank you so much for your time to reading my post!

 So many times I felt D is so great,so beautiful and decided to focus on it,so
many times I encountered problems,some weird,like this sample;some are known
issue but it seems never ever got attention,like Chinese font print to
console,and some others ,which make me feel bad,and can not go on the learning.

 Hope apprent issues get fixed asap,a workable workspace is available very soon.


Walter fixed this bug today: 
http://www.dsource.org/projects/dmd/changeset/749

If it's not urgent, you may want to wait for the next release.


Andrei



 Nov 11 2010