View mode: basic / threaded / horizontal-split · Log in · Help
August 26, 2007
Re: Stroustrup's talk on C++0x
Reiner Pope wrote:
> Perhaps you mean that you can write
> 
> void Foo(T)(T* t) { ... }
> ...
> int x;
> Foo(&x);
> 
> Sure. But the following doesn't work:
> 
> void Foo(T)(T t) { ... }
> void Foo(T)(T* t) { /* different implementation for this specialisation 
>  */ }
> ...
> int x;
> Foo(x);
> Foo(&x); // ambiguous
> 
> and using template parameter specialisation, IFTI breaks.

You can write the templates as:

void Foo(T)(T t) { ... }
void Foo(T, dummy=void)(T* t) { /* different implementation for this 
specialisation
 */ }

Not so pretty, but it works.


> As to complicated predicates, I refer to the common idiom in D templates 
> which looks like the following:

Sean Kelly had a solution for that of the form:

> More often, I use an additional value parameter to specialize against:
> 
> template Foo(T, bool isValid : true = PassesSomeTest!(T)) {}
August 29, 2007
Re: Stroustrup's talk on C++0x
eao197 wrote:
> I know that you work very hard on D, but D 1.0 took almost 7 years. D 
> 2.0 started in 2007, so final D 2.0 could be in 2014?

It's very amusing to read how Walter described D 1.0, seven years ago. It wasn't 
going to have templates, for example.
August 29, 2007
Re: Stroustrup's talk on C++0x
On Wed, 29 Aug 2007 15:56:29 +0400, Don Clugston <dac@nospam.com.au> wrote:

> eao197 wrote:
>> I know that you work very hard on D, but D 1.0 took almost 7 years. D  
>> 2.0 started in 2007, so final D 2.0 could be in 2014?
>
> It's very amusing to read how Walter described D 1.0, seven years ago.  
> It wasn't going to have templates, for example.

Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. It  
looks as D have never been a stable language.

-- 
Regards,
Yauheni Akhotnikau
August 29, 2007
Re: Stroustrup's talk on C++0x
eao197 wrote:
> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. 
> It looks as D have never been a stable language.


I don't know any language in wide use that is stable (i.e. not 
changing). A stable language is a dead language.
August 29, 2007
Re: Stroustrup's talk on C++0x
Walter Bright wrote:
> eao197 wrote:
>> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year. 
>> It looks as D have never been a stable language.
> 
> 
> I don't know any language in wide use that is stable (i.e. not 
> changing). A stable language is a dead language.

I guess there's "stable" and there's "stable"? The history of Simula67 
illustrates what can happen when a language is nailed to the wall :)
August 30, 2007
Re: Stroustrup's talk on C++0x
On Wed, 29 Aug 2007 23:15:26 +0400, Walter Bright  
<newshound1@digitalmars.com> wrote:

> eao197 wrote:
>> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 year.  
>> It looks as D have never been a stable language.
>
>
> I don't know any language in wide use that is stable (i.e. not  
> changing). A stable language is a dead language.

I mean changes in languages which break compatibility with previous code.  
AFAIK, successful languages always had some periods (usually 2-3 years,  
sometimes more) when there were no additions to language and new major  
version didn't break existing code (for example: Java, C#, Ruby, Python,  
even C++ sometimes).

-- 
Regards,
Yauheni Akhotnikau
August 30, 2007
Re: Stroustrup's talk on C++0x
eao197 wrote:
> On Wed, 29 Aug 2007 23:15:26 +0400, Walter Bright 
> <newshound1@digitalmars.com> wrote:
> 
>> eao197 wrote:
>>> Unfortunately I see to D's evolution, perhabs, from 2002 or 2003 
>>> year. It looks as D have never been a stable language.
>>
>>
>> I don't know any language in wide use that is stable (i.e. not 
>> changing). A stable language is a dead language.
> 
> I mean changes in languages which break compatibility with previous 
> code. AFAIK, successful languages always had some periods (usually 2-3 
> years, sometimes more) when there were no additions to language and new 
> major version didn't break existing code (for example: Java, C#, Ruby, 
> Python, even C++ sometimes).

C++ has been around for 20+ years now. I'll grant that for maybe 2 of 
those years (10%) it was stable. C++ has the rather dubious distinction 
of it being very hard to get two different compilers to compile 
non-trivial code without some sort of code customization needed. As 
evidence of that, just browse the STL and Boost sources. While the C++ 
standard has been stable for a couple years (C++98, C++03), it being 
nearly impossible to implement has meant the implementations have been 
unstable.

For example, name lookup rules vary significantly *today* even among the 
major compilers. I regularly get bug reports that DMC++ does it wrong, 
even though it actually does it according to the Standard, and it's 
other compilers that get it wrong.

On the other hand, when C++ has been stable, it rapidly lost ground 
relative to other languages. The recent about face in rationale and 
flurry of core language additions to C++0x is evidence of that.

I haven't programmed long term in the other languages, so don't have a 
good basis for commenting on their stability.

I have been programming in C++ since 1987. It's pretty normal to take a 
C++ project from the past and have to dink around with it to get it to 
compile with a modern compiler. The odds of taking a few thousand lines 
of C++ pulled off the web that's set up to compile with C++ Brand X are 
about 0% for getting it to compile with C++ Brand Y without changes.
August 30, 2007
Re: Stroustrup's talk on C++0x
eao197 wrote:
> I mean changes in languages which break compatibility with previous 
> code. AFAIK, successful languages always had some periods (usually 2-3 
> years, sometimes more) when there were no additions to language and new 
> major version didn't break existing code (for example: Java, C#, Ruby, 
> Python, even C++ sometimes).

I rather think, that a "new major version" of any language that "doesn't
break existing code" could hardly justify it's new major version number.
A complete rewrite of the compiler, e.g., would justify a majer new
compiler version, but not even a teeny-minor new language version.

An D /does have/ a stable language version, D1.

Regards, Frank
August 30, 2007
D development process [was: Stroustrup's talk on C++0x]
Walter Bright, el 30 de agosto a las 00:07 me escribiste:
> >>dead language.
> >I mean changes in languages which break compatibility with previous code. AFAIK, successful 
> >languages always had some periods (usually 2-3 years, sometimes more) when there were no additions 
> >to language and new major version didn't break existing code (for example: Java, C#, Ruby, Python, 
> >even C++ sometimes).
> 
> C++ has been around for 20+ years now. I'll grant that for maybe 2 of those years (10%) it was 
> stable. C++ has the rather dubious distinction of it being very hard to get two different compilers 
> to compile non-trivial code without some sort of code customization needed. As evidence of that, 
> just browse the STL and Boost sources. While the C++ standard has been stable for a couple years 
> (C++98, C++03), it being nearly impossible to implement has meant the implementations have been 
> unstable.
> 
> For example, name lookup rules vary significantly *today* even among the major compilers. I 
> regularly get bug reports that DMC++ does it wrong, even though it actually does it according to 
> the Standard, and it's other compilers that get it wrong.
> 
> On the other hand, when C++ has been stable, it rapidly lost ground relative to other languages. 
> The recent about face in rationale and flurry of core language additions to C++0x is evidence of 
> that.
> 
> I haven't programmed long term in the other languages, so don't have a good basis for commenting on 
> their stability.

Forget about C++ for a second. Try with Python. It is an stable, or at
least *predictable* language. It's evolution is well structured, so you
know you will have no suprises, and you know the language will evolve.

Python is *really* community driven (besides the BDFL[1] ;). It has a
formal proposal system to make changes to the language: PEPs[2]. When a
PEP is aproved, it's included in the next version and can be used
*optionally* (if it could break backward compatibility). For example, you
can use now the "future" behavoir of division:
>>> 10/3
3
>>> from __future__ import division
>>> 10/3
3.3333333333333335

In the next python version, the new feature is included without need to
import __future__, and the old behavior is deprecated (for example, with
libraries, when something changes, in the first version you can ask for
the new feature, in the second the new feature is the default but you can
fallback to the old behavior, and in the third version teh old behavior is
completely removed).

[1] http://en.wikipedia.org/wiki/BDFL
[2] http://www.python.org/dev/peps/

> I have been programming in C++ since 1987. It's pretty normal to take a C++ project from the past 
> and have to dink around with it to get it to compile with a modern compiler. The odds of taking a 
> few thousand lines of C++ pulled off the web that's set up to compile with C++ Brand X are about 0% 
> for getting it to compile with C++ Brand Y without changes.

You are talking about 20 years. D evolves in a daily basis and the worst
is that this evolution is without any formal procedure. Forking D 2.0 was
a huge improvement in this matter, but I think there's is more work to be
done so D can success as a long term language (or at least to be trusted).

Another good step forward this could be to maintain phobos (or whatever
the standard library would be :P) as an open source project. You can
create a repository (please use git! :) so people can track its
development and send patches easier. Same for the D frontend. It's almost
impossible for someone who is used to colaborate in open source projects
to do it with D. And that's a shame...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
.------------------------------------------------------------------------,
 \  GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05 /
  '--------------------------------------------------------------------'
Pa' ella cociné, pa' ella lavé, pa' ella soñe
Paella completa, $2,50
Pero, la luz mala me tira, y yo? yo soy ligero pa'l trote
La luz buena, está en el monte, allá voy, al horizonte
August 30, 2007
Re: Stroustrup's talk on C++0x
On Thu, 30 Aug 2007 15:44:25 +0400, 0ffh <spam@frankhirsch.net> wrote:

> eao197 wrote:
>> I mean changes in languages which break compatibility with previous  
>> code. AFAIK, successful languages always had some periods (usually 2-3  
>> years, sometimes more) when there were no additions to language and new  
>> major version didn't break existing code (for example: Java, C#, Ruby,  
>> Python, even C++ sometimes).
>
> I rather think, that a "new major version" of any language that "doesn't
> break existing code" could hardly justify it's new major version number.
> A complete rewrite of the compiler, e.g., would justify a majer new
> compiler version, but not even a teeny-minor new language version.

Java 1.5 (with generics) and C# 2.0 ware major versions, but didn't break  
old code.

>
> An D /does have/ a stable language version, D1.

http://d.puremagic.com/issues/show_bug.cgi?id=302  -- very strange bag for  
_stable_ version.

Try to imagine _stable_ Eiffel with broken DesignByContract support :-/

-- 
Regards,
Yauheni Akhotnikau
1 2 3 4
Top | Discussion index | About this forum | D home