On 7/4/2014 1:41 PM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
On Friday, 4 July 2014 at 20:28:36 UTC, Walter Bright wrote:
There's no such thing as done for a working language. C++, for example, is
constantly in flux. Every release by every vendor alters which parts of the
standard and draft standard it supports.
And no sane devs rely on those experimental parts unless g++ or clang commits
themselves to them. The C++ standard specs out things in advance at intervals
specified in years, not weeks.
As I said, C++ vendors often implement things far in advance of spec approval,
they do it piecemeal, and different vendors do things in different orders. C++
evangelists are constantly rewriting what C++ "best practices" are. To
characterize all this churn as "stablility" is awfully charitable.
Furthermore, the C/C++ Standards don't have much to say about how floating
point works - how is that of any help in writing professional, stable fp code?
You know that you are on your own and cannot make assumptions about conformance,
and address it with code (like ifdefs).
Uh-huh. And how much professional code have you seen that had #ifdef's for Vax
fp in it? IBM fp? Future CPUs that don't exist yet? How many developers have
access to a Vax to test their #ifdef's on?
Next, consider how much C++ code breaks when ported from 32 to 64 bits. It's
most of it, even mine, and I know what I'm doing. What you're implying is saying
that when a spec says "implementation defined" then voila! the code is portable!
Do we want to make the spec better? Yes.
Not make the spec better or bring it up to date with the implementation. Spec
out the language so people know what the missing bits are.
Please contribute to those areas of the spec you feel need improvement.
Non-specific statements like "bring it up to date" are not helpful.
Please, contribute to the things you care about, instead of suggesting in the
n.g. that others should do it. That would be far more helpful.
That would imply a fork. And yes, I think that might be the most likely outcome
that someone forks it.
A pull request does not imply a fork.
I don't believe in language design by a comittee.
The only alternative is you believe I need to do all the work. This is not
possible. I am not superman, nor am I expert at everything.
Sadly, this also implies that there are no computer languages you believe in.
You set an impossible standard. How can you possibly say you prefer C++, a
classic design by committee language?
I think the language designers
should spec out their vision. Let the community point out the flaws. Go back to
the drawing board. Do some rounds. Then commit to it.
I think that would attract more contribution to the core language development.
I'm asking you to contribute. These posts do not accomplish anything. Exhorting
me to do more (I already work on D 24/7) cannot work.
I am interested in contributing code to make a good spec come to life, not to
add noise to an endless contractual metamorphosis that never will lead to
anything consistent and coherent.
Nothing will improve if you and others remain on the sidelines. Get out in front
and make what you want to happen, happen.
