March 01, 2006
Walter Bright wrote:
> 
> This suggests to me that RAII and try-finally are the wrong paradigms for doing transaction programming. I've attended Scott Meyer's insightful lecture on doing transaction programming in C++. There is no hope for it to be reliably done by anyone but experts.

This is actually my concern about C++ in general.  The language is becoming so complicated--including the recommended solutions to common problems--that I wonder if any but experts will be able to reliably write correct code.  And in my personal experience, C++ experts are few and far between.


Sean
March 01, 2006
"Sean Kelly" <sean@f4.ca> wrote in message news:du51tu$1lvh$1@digitaldaemon.com...
> Walter Bright wrote:
>>
>> This suggests to me that RAII and try-finally are the wrong paradigms for doing transaction programming. I've attended Scott Meyer's insightful lecture on doing transaction programming in C++. There is no hope for it to be reliably done by anyone but experts.
>
> This is actually my concern about C++ in general.  The language is becoming so complicated--including the recommended solutions to common problems--that I wonder if any but experts will be able to reliably write correct code.  And in my personal experience, C++ experts are few and far between.

True. I run into a lot of C++ programmers, but few who really enjoy it. They usually use C++ because they need the performance, not because they like it.

The leading edge of C++ thought is to use increasingly complex templates for everything. The new C++0x proposed features are aimed at more complex template support.

By doing this, C++ has opened the door wide for Java, Ruby, C#, etc. C++ is never going to go away, but it will increasingly marginalize itself as the C++ experts leave the average programmer further and further behind.


March 02, 2006
In article <du5cao$237b$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Sean Kelly" <sean@f4.ca> wrote in message news:du51tu$1lvh$1@digitaldaemon.com...
>> Walter Bright wrote:
>>>
>>> This suggests to me that RAII and try-finally are the wrong paradigms for doing transaction programming. I've attended Scott Meyer's insightful lecture on doing transaction programming in C++. There is no hope for it to be reliably done by anyone but experts.
>>
>> This is actually my concern about C++ in general.  The language is becoming so complicated--including the recommended solutions to common problems--that I wonder if any but experts will be able to reliably write correct code.  And in my personal experience, C++ experts are few and far between.
>
>True. I run into a lot of C++ programmers, but few who really enjoy it. They usually use C++ because they need the performance, not because they like it.
>
>The leading edge of C++ thought is to use increasingly complex templates for everything. The new C++0x proposed features are aimed at more complex template support.

I think this is C language history repeating itself.  A book called Principia Mathematica was once written, an attempt to build a minimal set of mathematical axioms from which all others could be proven.  It kept getting bigger and bigger, but never had enough axioms.  They wanted all necessary axioms, but none that were provable from the others.  Godel later proved that its impossible to build such a list.  But its a very magnetic idea for mathematicians.

C and C++ both strive to provide a sort of Principia for programming, a set of language features from which all possible other features could be derived via syntax, using macros, functions, and in C++, templates.  They never want to add anything that can already be defined with syntax.

The C language was kept simple, so if you wanted magic (as in, anything outside the 'physics' of the language), you used the macro system.  Like all magic, this was 50% style and 50% fakery...  If you poke at it, the illusion breaks down.

There were many "better" languages but nothing "better and committed in a big way to high-performance code", until C++.

In C++, the language designers still feel pressured to keep things simple - e.g. they try hard to avoid introducing keywords, and things like foreach are always done in the STL not in the language.  But they have a tendency to introduce features and concepts that multiply the complexity of using the language.  These can't be done with macros, so they belong in the set of axioms.  As they add these multipliers, the knowledge needed to use it gets worse geometrically.

So the C++ team adds hard-to-implement/use stuff to the language, and rarely adds easy-to-implement/use stuff, because the easy-to-implement stuff is doable with macros/template magic.  Macro/template language is much more powerful than macro-only magic.  But the illusion still breaks down ... everyone has an ITERATE macro that doesnt quite work seamlessly.

>By doing this, C++ has opened the door wide for Java, Ruby, C#, etc. C++ is never going to go away, but it will increasingly marginalize itself as the C++ experts leave the average programmer further and further behind.

The plethora of similar languages creates division, which causes tension.  The performance and low level abilities of C and C++ is not available in Ruby, C#, or Java.  I know the gap you mention creates tension on the programming teams I've been on.  The C++ wonks want the others to just do the right think (use all the advanced methods all the time).  The others just want the compiler to stop bugging them and get out of their way.

I think the crown might pass to any language that could fix C++ performance and syntax... once it declared for the throne.  D does very well syntactically and performance wise, but I think it still has the "not ready yet" label stuck on the front of the box, because of the sub-1.0 version and lack of ... (insert wishlist items).  (Question: What was the "trigger" that made people start adopting Java for projects?)

Kevin


March 02, 2006
Walter Bright wrote:

> RAII is for managing resources, which is different from managing state or transactions.

This is a fantastic summary statement. I'd like to see it in the docs.
(In fact, error.html should have a link to exception-safe.html. Right now, error.html is (for a C++ programmer at least) a "motherhood"
statement that doesn't have any D-specific substance).

 try-catch is still needed, as on_scope doesn't catch
> exceptions. 

March 02, 2006
(Question: What was the "trigger" that made people start
>adopting Java for projects?)
>
>Kevin
>
>

About 1996 the web and serverside programming took off. The options were:
- c++ - complicated and not fast enough turn around time for average users.
- visual basic - big problems with vb runtime on the server and windows only.
- scripting languages
- perl - complex for prog in the large
- php - too simple for prog in the large
- others - not mature enough
- delphi - excellent but owned by borland
- java - originally for applets at which it proved to be fairly useless - found
a niche on the server by default. The prog model was simple and the package and
jar features enabled prog in the large.

The things i like a about D are:
- makes the same trades offs as delphi
- fast compiled language without pointers being so "in your face".
- stucts on the stack, objects on the heap
- parameter passing to functions does not require pointers
- has a standards based scripting language - DMDScript/ECMAScript - which is
written in D.
- generic/templates
Pity it was not available a few years ago.



March 02, 2006
In article <du68r5$7fa$1@digitaldaemon.com>, ianc says...
>
>(Question: What was the "trigger" that made people start
>>adopting Java for projects?)
>>
>>Kevin
>>
>>
>
>About 1996 the web and serverside programming took off. The options were:
>- c++ - complicated and not fast enough turn around time for average users.
>- visual basic - big problems with vb runtime on the server and windows only.
>- scripting languages
>- perl - complex for prog in the large
>- php - too simple for prog in the large
>- others - not mature enough
>- delphi - excellent but owned by borland
>- java - originally for applets at which it proved to be fairly useless - found
>a niche on the server by default. The prog model was simple and the package and
>jar features enabled prog in the large.
>
>The things i like a about D are:
>- makes the same trades offs as delphi
>- fast compiled language without pointers being so "in your face".
>- stucts on the stack, objects on the heap
>- parameter passing to functions does not require pointers
>- has a standards based scripting language - DMDScript/ECMAScript - which is
>written in D.
>- generic/templates
>Pity it was not available a few years ago.
>

/me hands Ianc a cigar :)

- EricAnderton at yahoo
March 02, 2006
A lot of excellent comments. Some more from me embedded:

"Kevin Bealer" <Kevin_member@pathlink.com> wrote in message news:du5hbu$2bag$1@digitaldaemon.com...
> So the C++ team adds hard-to-implement/use stuff to the language, and
> rarely
> adds easy-to-implement/use stuff, because the easy-to-implement stuff is
> doable
> with macros/template magic.  Macro/template language is much more powerful
> than
> macro-only magic.  But the illusion still breaks down ... everyone has an
> ITERATE macro that doesnt quite work seamlessly.

Yes, my thoughts exactly.

> I think the crown might pass to any language that could fix C++
> performance and
> syntax... once it declared for the throne.  D does very well syntactically
> and
> performance wise, but I think it still has the "not ready yet" label stuck
> on
> the front of the box, because of the sub-1.0 version and lack of ...
> (insert
> wishlist items).

The wishlist thing is an ever-growing thing. It's a problem, mostly my fault.

> (Question: What was the "trigger" that made people start
> adopting Java for projects?)

The initial trigger was the idea you could embed Java applets into a web page, coupled with the idea that it was a C++ like language that was, in contrast, easilly mastered.


March 02, 2006
Kevin Bealer wrote:
> In article <du5cao$237b$1@digitaldaemon.com>, Walter Bright says...
> 
<Snip comments I agree with>

> I think the crown might pass to any language that could fix C++ performance and
> syntax... once it declared for the throne.  D does very well syntactically and
> performance wise, but I think it still has the "not ready yet" label stuck on
> the front of the box, because of the sub-1.0 version and lack of ... (insert
> wishlist items).  (Question: What was the "trigger" that made people start
> adopting Java for projects?)
> 
> Kevin
> 
> 

Java launched for 3 reasons(outside of Suns marketing), IMO:

1. Server side web programming was just taking off. This was Java's killer app.  Case in point: Flash does most interactive embedded stuff today in web pages.

2. No pointers. No memory leaks eliminates large classes of errors. Even though it existed in other languages, coupled with #1 this made Java a much better C++.

3. A comprehensive set of tools and a company willing to support them. In getting business to adopt your tech they need support and Sun delivers(at least on Solaris and Win32 initially).

-DavidM
March 03, 2006
>
> Java launched for 3 reasons(outside of Suns marketing), IMO:
>
> 1. Server side web programming was just taking off. This was Java's killer app.  Case in point: Flash does most interactive embedded stuff today in web pages.
>
> 2. No pointers. No memory leaks eliminates large classes of errors. Even though it existed in other languages, coupled with #1 this made Java a much better C++.
>
> 3. A comprehensive set of tools and a company willing to support them. In getting business to adopt your tech they need support and Sun delivers(at least on Solaris and Win32 initially).
>

4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF in principle.

5. Extremely simple Java Native Interface mechanism - bridge to native code
for
mission crititcal pieces.

6. Extremely simple bytecode system. I know around 12 working
implementations
of Java VM.

7. ClassLoader as an entity. Killer thing, IMO.

8. Reflection as part of runtime.

------------------
Having said that Java has problems of course. It is good for some set of
tasks.
It is not an universal language.

But it is damned stable. Last 7 years or so it is working as it is.


March 03, 2006
Andrew Fedoniouk wrote:

<snip, some great additions to my list>

> Having said that Java has problems of course. It is good for some set of tasks.
> It is not an universal language.
> 
> But it is damned stable. Last 7 years or so it is working as it is.
> 
> 
It is reliable if not ugly.  I still feel like I type too much(both in the literal sense and the programming sense).

The generics add nothing useful besides Homogenous collections and removal of casts, at the expense of loads of complexity.

At the same time Sun *rejected* Design by Contract proposals for the language...disapointing.

I have a lot more fun with Groovy honestly.

-DavidM