"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:aoko6l$k3m$1@digitaldaemon.com...
> Of course, this can be abused.  anon(){} should only be used for very
small
> functions -- putting a large function in such a place would make the code unreadable, and should use the standard "write a function and use the name
here"
> method.

One way to keep them simple is to only allow expressions, not statements, in the anonymous function. Any thoughts on this?

In article <ap1j97$1or0$1@digitaldaemon.com>, Walter says...
>"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:aoko6l$k3m$1@digitaldaemon.com...
>> Of course, this can be abused.  anon(){} should only be used for very
>small
>> functions -- putting a large function in such a place would make the code unreadable, and should use the standard "write a function and use the name
>here"
>> method.
>
>One way to keep them simple is to only allow expressions, not statements, in the anonymous function. Any thoughts on this?

Hmmm.  I think that my "this can be abused" comment was more of a style guideline kind of a thing.  I would prefer to allow anything that is valid in a function to be valid in an anonymous function.  Sometimes you need little loops or switches or other non-expression constructs, and can still fit them cleanly into place.  I suspect that the line between "nicely expressive" and "hideously contorted" is a matter of taste and highly context sensitive.  I think "proper" use of anon funcs will just require programmer experience -- newer programmers can either stay away from them until they have seen enough examples to learn a "good" balance, or can dive in and risk the wrath of fellow programmers (which is how most of us learn company style guidelines anyway).  I would expect that any attempt by the compiler or language to limit the capability of anon funcs would turn into a source of frustration (admittedly, one that could be worked around by making a real function, but still somewhat annoying).

Anything that is expressive enough to be useful can be abused.  Programmers should be taught not to misuse and abuse features.  One of my coworkers is having to maintain some old C code that the authors must have developed during the "gee, look how few lines of code it takes to do this" developmental stage. We've all seen the strcpy() implementation that looks like:

for (pSrc = Src, pDst = Dst; pSrc; *pDst++ = *pSrc++) {}

And that's fine, I suppose.  Since we've all seen it, we all recognize it and it isn't a problem.  But sometimes new programmers see things like that and the trinary operator ( ?: , which is perfectly useful when used responsibly) and wander off to create truly horrendous code segments, most of which would be serious competitors in the code obfuscation contests.

The expressiveness is not to blame, nor is the trinary operator, nor any other feature of the language.  They've just been used by an inexperienced programmer who, for some reason, thought that the shorter source code would translate into shorter/faster program executable code.

Mac

"Walter" <walter@digitalmars.com> wrote in news:ap1j97$1or0$1@digitaldaemon.com:
> One way to keep them simple is to only allow expressions, not statements, in the anonymous function. Any thoughts on this?
> 

I agree with Mac Reiter.  I don't think that expressions are enough.  I think it's just best to leave it up to time and usage to see what is a good convention here.  I will also say that I don't think that anonymous functions of 5 or 6 lines are even bad.  I think it's much more readable to have the code in place than to have to search for the named function.

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:ap1kvb$1qh3$1@digitaldaemon.com...
> Hmmm.  I think that my "this can be abused" comment was more of a style guideline kind of a thing.  I would prefer to allow anything that is valid
in a
> function to be valid in an anonymous function.  Sometimes you need little
loops
> or switches or other non-expression constructs, and can still fit them
cleanly
> into place.  I suspect that the line between "nicely expressive" and
"hideously
> contorted" is a matter of taste and highly context sensitive.  I think
"proper"
> use of anon funcs will just require programmer experience -- newer
programmers
> can either stay away from them until they have seen enough examples to
learn a
> "good" balance, or can dive in and risk the wrath of fellow programmers
(which
> is how most of us learn company style guidelines anyway).  I would expect
that
> any attempt by the compiler or language to limit the capability of anon
funcs
> would turn into a source of frustration (admittedly, one that could be
worked
> around by making a real function, but still somewhat annoying).

I think you're right. It would probably produce the same frustration as the base initializer syntax does in C++.

"Walter" <walter@digitalmars.com> wrote in message news:ap1idi$1o0t$2@digitaldaemon.com...
>
> "anderson" <anderson@firestar.com.au> wrote in message news:aojcob$26m8$1@digitaldaemon.com...
> > D's more like Godel (pronounced go da hell).
> > * Left to bleed when the grant money ran out.
>
> There never was any grant money for D to begin with <g>.
>

Exactly, I didn't think you were it it for the money (like the inventors of
godel were).   They simply followed the money and when the money ran out for
godel they simply started a new language on more grant money (hopping that
godel would take off).
In "barzzaro world" D would probably be called godel.

"Walter" <walter@digitalmars.com> wrote in message news:ap1j0h$1oou$1@digitaldaemon.com...
> D is designed to be an evolutionary successor to C/C++, and so
necessarilly
> will look a lot like them. It is designed to appeal to C/C++ programmers
and
> minimize the learning curve to jump from them to D. If that were not true, not many people would even give D a chance.

I agree, you need to stick to the scope.

>I dont even think you want is what D is suposed to be. From the 'Overview' D is clearly meant to be a pragmatic language, you always seem to be putting the idealistic argument.
>
>chris


I want D to take the practical steps of learning from the mistakes of predecessor languages, while using design principles systematically -- instead of suffering through ad-hoc design techniques such as produced C.  And D's hope to fix C++ is severely hindered by its over-commitment to C++ syntax and semantics.  So I want it to loosen up.  These points are very pragmatic ones.

A good exercise would be to walk through the "C++??" critique and ask how D solves each problem.  Those it does not solve belong on our to-do list.

At the same time, Walter says Eiffel was an inspiration, yet also admits having too little knowledge of Eiffel to draw a comparison with D.  That strikes me as a pretty weak inspiration.  So I see a lot of fertile ground we can explore in the Eiffel language.

For us to suppose that we can dream up better ideas than expert C++ critics or language authors like Eiffel's is a bit impractical!  I suggest standing on their shoulders to get a better view of things.  That's entirely practical and very smart.  With that vantage we can come up with *really* good ideas.  Without it, we will be lucky just to duplicate their insights (and don't stand a very good chance of even that much).

I think that D can be a successor to C++ without having to look a whole lot like it.  This is where I differ with Walter.  He is courageously willing to break C++ compatibility, but then turns yellow in thinking that C++-ness is required to attract users.  I believe the only way D can displace C++ (let alone Java, C#) is to offer something so far beyond C++ that adoption is a no-brainer.  By demanding such hard C++-ness we are shooting ourselves in the foot.

Mark

Hi Mark, have you been on Holiday? Havnt seen any posts from you lately.


"Mark Evans" <Mark_member@pathlink.com> wrote in message news:apqakn$2pio$1@digitaldaemon.com...
>
> >I dont even think you want is what D is suposed to be. From the
'Overview' D
> >is clearly meant to be a pragmatic language, you always seem to be
putting
> >the idealistic argument.
> >
> >chris
>
>
> I want D to take the practical steps of learning from the mistakes of predecessor languages, while using design principles systematically --
instead
> of suffering through ad-hoc design techniques such as produced C.  And D's
hope
> to fix C++ is severely hindered by its over-commitment to C++ syntax and semantics.  So I want it to loosen up.  These points are very pragmatic
ones.

Ok mabey some truth, but 'severly hindered' is way over the top.

> A good exercise would be to walk through the "C++??" critique and ask how
D
> solves each problem.  Those it does not solve belong on our to-do list.

Asuming you agree with all the critisims. And solving all those problems bring practical benefits.

Cant you do it? Its the second time you have sugested somting like this.

> At the same time, Walter says Eiffel was an inspiration, yet also admits
having
> too little knowledge of Eiffel to draw a comparison with D.  That strikes
me as
> a pretty weak inspiration.  So I see a lot of fertile ground we can
explore in
> the Eiffel language.

I think you are being unfair. I suspect he meant sombody who had experience using it would do a better comparison, or he just picked the bones for ideas? And You cant expect him to be an expert on Eiffel and every other language on the planet and write a compiler and asnwer questions in this newsgroup and feed his 17 children. I am feeling tired just thinking about it.

> For us to suppose that we can dream up better ideas than expert C++
critics or
> language authors like Eiffel's is a bit impractical!  I suggest standing
on
> their shoulders to get a better view of things.  That's entirely practical
and
> very smart.  With that vantage we can come up with *really* good ideas.
Without
> it, we will be lucky just to duplicate their insights (and don't stand a
very
> good chance of even that much).

I think Walters is doing great. The diversity of input from this newsgroup and Walters willingness to engage discusion is going to do far better than any other method i can think of.

As walter says it is a language for programers not academics. Thats why he has this newsgroup full of programers!

> I think that D can be a successor to C++ without having to look a whole
lot like
> it.  This is where I differ with Walter.  He is courageously willing to
break
> C++ compatibility, but then turns yellow in thinking that C++-ness is
required
> to attract users.  I believe the only way D can displace C++ (let alone
Java,
> C#) is to offer something so far beyond C++ that adoption is a no-brainer.
By
> demanding such hard C++-ness we are shooting ourselves in the foot.

Given the right airplay and backing i think D will easily take over from C++. simply because the transition from C++ will be fairly painless and it is 10 times better. Actualy i think Java->D or C#->D should be pretty painless aswell.

chris

>> A good exercise would be to walk through the "C++??" critique
>Asuming you agree with all the critisims. And solving all those problems bring practical benefits.

Everyone knows C++ has problems or there would be no D effort in the first place nor Java nor C#.  I would be happy to discuss any particular C++ criticism with which you disagree.  You seem to love the language like an ugly puppy -- just because it's yours.

The article shows case-by-case how Java and Eiffel address each problem (or don't).  How much more practical can you get.

There is a whole industry full of computer science and language experts.  The C++ critique is just one of their products.  If you don't like it, read B. Stroustroup himself -- he will tell you all about the flaws in C++ -- and he designed it!

The practical / academic argument is a false-choice fallacy.  You are saying that only C++-derived or D-newsgroup-inspired design ideas are "practical," a ludicrous position.  We can get pracical ideas from all kinds of sources.




>Cant you do it? Its the second time you have sugested somting like this.

A more enthusiastic reception might encourage me.



>I think you are being unfair.
>I think Walters is doing great. The diversity of input from this newsgroup
>and Walters willingness to engage discusion is going to do far better than
>any other method i can think of.

Walter is doing great but can do better.  So can we.  There are more resources to exploit than just our own imaginations.  Using them will get us to the final destination a lot faster.

It saves labor to get things right from a high-level design standpoint -- and also creates a better language.  You are missing that point in a big way.



>As walter says it is a language for programers not academics. Thats why he has this newsgroup full of programers!

There's the false-choice fallacy again.  It's stupidity to ignore the rest of the world.  Anyway, Walter is not doing that to the extent that you claim. Thankfully he does look at languages like Eiffel and Icon, and even hears a few academics.  Thank God we are not his only source of inspiration.

My major point is that D's over-commitment to C++-ness will prohibit the significant gains that would be possible in a breakthrough design.



>Given the right airplay and backing i think D will easily take over from C++. simply because the transition from C++ will be fairly painless and it is 10 times better. Actualy i think Java->D or C#->D should be pretty painless aswell.

Why will companies select D over Java, C#, or Eiffel?  Any of these languages could be called 10 times better than C++.  And all of them enjoy greater market share and maturity than D.

What we need is a language that is many times better than Java / C# / Eiffel, not just many times better than C++.  The only way I see that happening is to loosen the coupling with C++ and seek good ideas from any place we can get them. That is the practical approach.

Mark

> What we need is a language that is many times better than Java / C# /
Eiffel,
> not just many times better than C++.  The only way I see that happening is
to
> loosen the coupling with C++ and seek good ideas from any place we can get
them.
> That is the practical approach.
>
> Mark
>

Although I like the way D is going...

If you want to take D in a direction away from the C++ direction provide some good ideas.  They will probably be taken in and result in a C++ syntaxical form, however that's a start.  After all D is meant to be based on C not C++ but it does take alot of it's ideas from C++.

I think D has been developed to much for Walter to want to start on it again (and I see no need to).  If D was made radically differnt from it's present form, many of the programs that have already been written wouldn't work, and would need a re-write.