digitalmars.D - Re: OT: on IDEs and code writing on steroids

Yigal Chripun:

 first, typos - eclipse has a built-in spell checker so all those 
 "lenght" will be underlined with an orange squiggly line.


A much better solution is to use "size" (or even "len") everywhere in D, that
avoids such typos in the first place.
An IDE is useful, but it's better to improve the language first, so later you
don't use the IDE to write boilerplate or fix typos.

-----------------

If we ignore this fact D will become another niche academic language that no
one uses.<


Unfortunately I think the academy isn't much interested in D. So if D doesn't
succeed, it will just be a dead language.
Currently there are only few things that make D better than C#4 (and F#, that
is different). Note that in C#4 there are ways to generate code on the fly,
this is done much less often than template programming in D, but it's doable.


second, D needs to update its stone age compilation model copied from C++.<


Yes. Eventually Walter will need to take a look at way people write C#, and
update D.
"moons" files that bundle modules, built-in bud-like functionality, DDLs and
more. Things to think about.

Bye,
bearophile

May 18 2009

davidl <davidl nospam.org> writes:

�� Mon, 18 May 2009 16:01:56 +0800��bearophile <bearophileHUGS lycos.com>
д��:

Yigal Chripun:

first, typos - eclipse has a built-in spell checker so all those
"lenght" will be underlined with an orange squiggly line.

A much better solution is to use "size" (or even "len") everywhere in D,
that avoids such typos in the first place.
An IDE is useful, but it's better to improve the language first, so
later you don't use the IDE to write boilerplate or fix typos.

-----------------

If we ignore this fact D will become another niche academic language
that no one uses.<

Unfortunately I think the academy isn't much interested in D. So if D
doesn't succeed, it will just be a dead language.
Currently there are only few things that make D better than C#4 (and F#,
that is different). Note that in C#4 there are ways to generate code on
the fly, this is done much less often than template programming in D,
but it's doable.

second, D needs to update its stone age compilation model copied from
C++.<

Yes. Eventually Walter will need to take a look at way people write C#,
and update D.
"moons" files that bundle modules, built-in bud-like functionality, DDLs
and more. Things to think about.

Bye,
bearophile

From a commercial basis for Walter, it may be easier to glue a C# frontend
against the DMD backend to create a native C# compiler. Waiting D to be a
successful language requires a longer time. And people needs higher cost
to move to D. Reusing current .Net codebase is a very strong selling point.
C# does many correct decisions, better identifier resolve. Its frontend is
considered to be written very high quality. Adding stuff on top of C#
frontend may be an easier approach.
Some people want to compile C# source to native either with the purpose of
closing their source and obtaining higher performance.
C# gets much bigger code base than D code base. Most importantly, you can
not ignore the brilliance of the .Net framework.

--
ʹ�� Opera �����Եĵ����ʼ��ͻ�����: http://www.opera.com/mail/

May 18 2009

"Tim Matthews" <tim.matthews7 gmail.com> writes:

On Tue, 19 May 2009 00:37:21 +1200, davidl <davidl nospam.org> wrote:


  From a commercial basis for Walter, it may be easier to glue a C#  
 frontend against the DMD backend to create a native C# compiler. Waiting  
 D to be a successful language requires a longer time. And people needs  
 higher cost to move to D. Reusing current .Net codebase is a very strong  
 selling point.
 C# does many correct decisions, better identifier resolve. Its frontend  
 is considered to be written very high quality. Adding stuff on top of C#  
 frontend may be an easier approach.
 Some people want to compile C# source to native either with the purpose  
 of closing their source and obtaining higher performance.
 C# gets much bigger code base than D code base. Most importantly, you  
 can not ignore the brilliance of the .Net framework.



A project in the making that uses D language compiled to cil and can  
therefore call .net base framework code. http://the-free-meme.blogspot.com/

May 18 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

davidl wrote:
 �� Mon, 18 May 2009 16:01:56 +0800��bearophile 
 <bearophileHUGS lycos.com> д��:
 
 Yigal Chripun:

 first, typos - eclipse has a built-in spell checker so all those
 "lenght" will be underlined with an orange squiggly line.


 A much better solution is to use "size" (or even "len") everywhere in 
 D, that avoids such typos in the first place.
 An IDE is useful, but it's better to improve the language first, so 
 later you don't use the IDE to write boilerplate or fix typos.

 -----------------

 If we ignore this fact D will become another niche academic language 
 that no one uses.<


 Unfortunately I think the academy isn't much interested in D. So if D 
 doesn't succeed, it will just be a dead language.
 Currently there are only few things that make D better than C#4 (and 
 F#, that is different). Note that in C#4 there are ways to generate 
 code on the fly, this is done much less often than template 
 programming in D, but it's doable.


 second, D needs to update its stone age compilation model copied from 
 C++.<


 Yes. Eventually Walter will need to take a look at way people write 
 C#, and update D.
 "moons" files that bundle modules, built-in bud-like functionality, 
 DDLs and more. Things to think about.

 Bye,
 bearophile


  From a commercial basis for Walter, it may be easier to glue a C# 
 frontend against the DMD backend to create a native C# compiler. Waiting 
 D to be a successful language requires a longer time. And people needs 
 higher cost to move to D. Reusing current .Net codebase is a very strong 
 selling point.
 C# does many correct decisions, better identifier resolve. Its frontend 
 is considered to be written very high quality. Adding stuff on top of C# 
 frontend may be an easier approach.
 Some people want to compile C# source to native either with the purpose 
 of closing their source and obtaining higher performance.
 C# gets much bigger code base than D code base. Most importantly, you 
 can not ignore the brilliance of the .Net framework.


I've repeatedly failed to figure out the coolness of C#, and would 
appreciate a few pointers. Or references. Or delegates :o).


Andrei

May 18 2009

BCS <ao pathlink.com> writes:

Reply to Andrei,

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).
 


The coolness of c# is that (in order, IMHO) 1) the tools are world class, 
2) the support is back by MS, 3) the docs are great, and 4) the language 
is highly consistent and conservative, e.i. nothing is added until they've 
got it right.

Aside from #4, the *language* isn't anything to write home about.

 Andrei

May 18 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

BCS wrote:
 Reply to Andrei,
 
 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 The coolness of c# is that (in order, IMHO) 1) the tools are world 
 class, 2) the support is back by MS, 3) the docs are great, and 4) the 
 language is highly consistent and conservative, e.i. nothing is added 
 until they've got it right.
 
 Aside from #4, the *language* isn't anything to write home about.


Have you seen Linq? That's *amazing*!

You can deal with expression ASTs and do really cool stuff with that. 
Like doing:

var results = someObjectsThatAreGoingToBeTakenFromTheDb.Where(o => 
o.Name == "Foo");
foreach(var result in results) {
   // There, the previous condition with the given expression has been
   // translated to SQL and executed.
}

I find C# a really nice language.

May 18 2009

BCS <ao pathlink.com> writes:

Reply to Ary,

 BCS wrote:
 
 Reply to Andrei,
 
 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).
 


 class, 2) the support is back by MS, 3) the docs are great, and 4)
 the language is highly consistent and conservative, e.i. nothing is
 added until they've got it right.
 
 Aside from #4, the *language* isn't anything to write home about.
 


 


LINQ is the only thing c# has the is a notable language feature, but I don't 
think it adds anything that puts it much above the rest of the crowd in any 
way. 

 You can deal with expression ASTs and do really cool stuff with that.
 Like doing:
 
 var results = someObjectsThatAreGoingToBeTakenFromTheDb.Where(o =>
 o.Name == "Foo");


I think this will work:

int delegate(int delegate(ref T)) Where(T[] array, bool delegate(T) dg)
{
    struct Ret
    {
        T[] Array;
        bool delegate(T) Dg;

        int opApply(int delegate(ref T) idg)
        {
            foreach(ref T t; Array)
               if(Dg(t)) if(int ret = idg) return ret;
            return ret;
        }
        return &(Ret(array,dg)).opApply;
    }
}

If not, a little tweeking shloudl cover it.

There is a lib I played around with a whole back that showed that D can do 
AST manipulation with expressions.

 foreach(var result in results) {
 // There, the previous condition with the given expression has been
 // translated to SQL and executed.
 }
 I find C# a really nice language.
 


I do  to, but mostly because of the tools

May 18 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

BCS wrote:
 Reply to Ary,
 
 BCS wrote:

 Reply to Andrei,

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 class, 2) the support is back by MS, 3) the docs are great, and 4)
 the language is highly consistent and conservative, e.i. nothing is
 added until they've got it right.

 Aside from #4, the *language* isn't anything to write home about.




 LINQ is the only thing c# has the is a notable language feature, but I 
 don't think it adds anything that puts it much above the rest of the 
 crowd in any way.
 You can deal with expression ASTs and do really cool stuff with that.
 Like doing:

 var results = someObjectsThatAreGoingToBeTakenFromTheDb.Where(o =>
 o.Name == "Foo");


 I think this will work:
 
 int delegate(int delegate(ref T)) Where(T[] array, bool delegate(T) dg)
 {
    struct Ret
    {
        T[] Array;
        bool delegate(T) Dg;
 
        int opApply(int delegate(ref T) idg)
        {
            foreach(ref T t; Array)
               if(Dg(t)) if(int ret = idg) return ret;
            return ret;
        }
        return &(Ret(array,dg)).opApply;
    }
 }
 
 If not, a little tweeking shloudl cover it.


This is for filtering an array. What this does in C# is to translate 
that code into this (more or less, this is just the idea!):

SqlConnection conn = ...;
conn.executeQuery("select * from SomeTable Where Name = 'Foo'");

What the "Where" method does it to receieve an expression tree for "o => 
o.Name = 'Foo'", and using a visitor it converts it to an SQL statement. 
In D you don't have expression trees. The best you could do it to give 
it a string, but then you loose autocompletion, refactoring, nice 
compiler error messages and probably many other things.

The best thing about this is that the expression is represented using a 
class, say Func<From, To>. So you could say:

Func<From, bool> predicate = (From f) => f.Name == "Foo";

Now you can do:

From[] array = ...;
array.Where(predicate);

or:

DbObjects.Where(predicate);

In the first case, the predicate will be executed at run-time for each 
object in the array, much like your D example does. In the second case, 
however, predicate will be translated to SQL.

May 18 2009

BCS <ao pathlink.com> writes:

Reply to Ary,

 BCS wrote:
 
 Reply to Ary,
 
 Have you seen Linq? That's *amazing*!
 


 I don't think it adds anything that puts it much above the rest of
 the crowd in any way.
 
 You can deal with expression ASTs and do really cool stuff with
 that. Like doing:
 
 var results = someObjectsThatAreGoingToBeTakenFromTheDb.Where(o =>
 o.Name == "Foo");
 


 
 int delegate(int delegate(ref T)) Where(T[] array, bool delegate(T)
 dg)
 {
 struct Ret
 {
 T[] Array;
 bool delegate(T) Dg;
 int opApply(int delegate(ref T) idg)
 {
 foreach(ref T t; Array)
 if(Dg(t)) if(int ret = idg) return ret;
 return ret;
 }
 return &(Ret(array,dg)).opApply;
 }
 }
 If not, a little tweeking shloudl cover it.
 


 that code into this (more or less, this is just the idea!):
 
 SqlConnection conn = ...;
 conn.executeQuery("select * from SomeTable Where Name = 'Foo'");


Only for LINQ to SQL (or the like)

all LINQ is is a set of standard nameing conventions and sugar. I Add a "Where" 
function to some SQL tabel object and you get the above as well.

 What the "Where" method does it to receieve an expression tree for "o
 => o.Name = 'Foo'", and using a visitor it converts it to an SQL
 statement. In D you don't have expression trees. The best you could do
 it to give it a string, but then you loose autocompletion,
 refactoring, nice compiler error messages and probably many other
 things.


I can see a Where!("Name","Age>")(someName,someAge) being not to hard to 
implement. Heck with prepared statements it might even be trivial, maybe 
even non templated.

 
 The best thing about this is that the expression is represented using
 a class, say Func<From, To>. So you could say:
 
 Func<From, bool> predicate = (From f) => f.Name == "Foo";
 
 Now you can do:
 
 From[] array = ...;
 array.Where(predicate);
 or:
 
 DbObjects.Where(predicate);
 
 In the first case, the predicate will be executed at run-time for each
 object in the array, much like your D example does. In the second
 case, however, predicate will be translated to SQL.
 


OK you've got me convinced that c# has a cool feature: not LINQ (it's still 
ho-hum) but AST reflection.

May 18 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

BCS wrote:
 Reply to Ary,
 
 BCS wrote:

 Reply to Ary,

 Have you seen Linq? That's *amazing*!


 I don't think it adds anything that puts it much above the rest of
 the crowd in any way.

 You can deal with expression ASTs and do really cool stuff with
 that. Like doing:

 var results = someObjectsThatAreGoingToBeTakenFromTheDb.Where(o =>
 o.Name == "Foo");



 int delegate(int delegate(ref T)) Where(T[] array, bool delegate(T)
 dg)
 {
 struct Ret
 {
 T[] Array;
 bool delegate(T) Dg;
 int opApply(int delegate(ref T) idg)
 {
 foreach(ref T t; Array)
 if(Dg(t)) if(int ret = idg) return ret;
 return ret;
 }
 return &(Ret(array,dg)).opApply;
 }
 }
 If not, a little tweeking shloudl cover it.


 that code into this (more or less, this is just the idea!):

 SqlConnection conn = ...;
 conn.executeQuery("select * from SomeTable Where Name = 'Foo'");


 Only for LINQ to SQL (or the like)
 
 all LINQ is is a set of standard nameing conventions and sugar. I Add a 
 "Where" function to some SQL tabel object and you get the above as well.
 
 What the "Where" method does it to receieve an expression tree for "o
 => o.Name = 'Foo'", and using a visitor it converts it to an SQL
 statement. In D you don't have expression trees. The best you could do
 it to give it a string, but then you loose autocompletion,
 refactoring, nice compiler error messages and probably many other
 things.


 I can see a Where!("Name","Age>")(someName,someAge) being not to hard to 
 implement. Heck with prepared statements it might even be trivial, maybe 
 even non templated.
 
 The best thing about this is that the expression is represented using
 a class, say Func<From, To>. So you could say:

 Func<From, bool> predicate = (From f) => f.Name == "Foo";

 Now you can do:

 From[] array = ...;
 array.Where(predicate);
 or:

 DbObjects.Where(predicate);

 In the first case, the predicate will be executed at run-time for each
 object in the array, much like your D example does. In the second
 case, however, predicate will be translated to SQL.


 OK you've got me convinced that c# has a cool feature: not LINQ (it's 
 still ho-hum) but AST reflection.


Yes, sorry. Sometimes I mix both things. It's AST reflection that's nice 
about C#. Linq is just a nice usage example of it. :-)

May 18 2009

Lutger <lutger.blijdestijn gmail.com> writes:

BCS wrote:

...
 
 all LINQ is is a set of standard nameing conventions and sugar. I Add a
"Where" 
 function to some SQL tabel object and you get the above as well.
 



Not really, LINQ is 'sugar' for the underlying libraries that implements
querying. Instead of
calling it just sugar, it is more proper to call it a language in it's own
right.

LINQ to SQL is just one thing, the power of LINQ is that you separate queries
from source of data.
You can write one query (ideally) that works with SQL, XML or plain Arrays.
It's not only that you
don't have to write SQL queries anymore, a lot of messy for/while/etc. loops
can be totally replaced 
with LINQ queries too.

May 19 2009

BCS <ao pathlink.com> writes:

Reply to Lutger,

 BCS wrote:
 
 ...
 
 all LINQ is is a set of standard nameing conventions and sugar. I Add
 a "Where" function to some SQL tabel object and you get the above as
 well.
 


 
 Not really, LINQ is 'sugar' for the underlying libraries that


As far as language features go, I'm even less impressed with sugar for
libraries.

 implements querying. Instead of calling it just sugar, it is more
 proper to call it a language in it's own right.
 


I still don't think it's anything to spectacular. The AST stuff on the other 
hand...

May 19 2009

"Tim Matthews" <tim.matthews7 gmail.com> writes:

On Wed, 20 May 2009 05:40:37 +1200, BCS <ao pathlink.com> wrote:

 Reply to Lutger,

 BCS wrote:
  ...

 all LINQ is is a set of standard nameing conventions and sugar. I Add
 a "Where" function to some SQL tabel object and you get the above as
 well.


  Not really, LINQ is 'sugar' for the underlying libraries that


 As far as language features go, I'm even less impressed with sugar for  
 libraries.

 implements querying. Instead of calling it just sugar, it is more
 proper to call it a language in it's own right.


 I still don't think it's anything to spectacular. The AST stuff on the  
 other hand...


LINQ's syntactic sugar is not bad in my opinion. With .net its more  
acceptable to have syntactic sugar for a library that it depends on as it  
is all part of the base framework that is going to be there but with D I  
think we could all agree that a LINQ like query just doesnt fit in too  
well (for now at least)

May 19 2009

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, May 18, 2009 at 1:47 PM, BCS <ao pathlink.com> wrote:

 I think this will work:

 int delegate(int delegate(ref T)) Where(T[] array, bool delegate(T) dg)
 {
 =A0 struct Ret
 =A0 {
 =A0 =A0 =A0 T[] Array;
 =A0 =A0 =A0 bool delegate(T) Dg;

 =A0 =A0 =A0 int opApply(int delegate(ref T) idg)
 =A0 =A0 =A0 {
 =A0 =A0 =A0 =A0 =A0 foreach(ref T t; Array)
 =A0 =A0 =A0 =A0 =A0 =A0 =A0if(Dg(t)) if(int ret =3D idg) return ret;
 =A0 =A0 =A0 =A0 =A0 return ret;
 =A0 =A0 =A0 }
 =A0 =A0 =A0 return &(Ret(array,dg)).opApply;
 =A0 }
 }

 If not, a little tweeking shloudl cover it.


Using that, however, looks pretty ugly:

array.Where((SomeObject o) { return o.name =3D=3D "foo"; });

D could really use some sugar for delegate literals, especially tiny
'predicate' literals like this.

array.Where(\o -> o.name =3D=3D "foo");

May 18 2009

Christopher Wright <dhasenan gmail.com> writes:

BCS wrote:
 Reply to Andrei,
 
 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 The coolness of c# is that (in order, IMHO) 1) the tools are world 
 class, 2) the support is back by MS, 3) the docs are great, and 4) the 
 language is highly consistent and conservative, e.i. nothing is added 
 until they've got it right.
 
 Aside from #4, the *language* isn't anything to write home about.


I'd say C#2 is Java with the top 10 or so feature requests implemented, 
and another 5 or so major feature requests implemented each major 
version. That isn't a bad state to be in, really. It's good enough, with 
a billion dollars in corporate backing, to make you the Current Big 
Language.

May 18 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Christopher Wright wrote:
 BCS wrote:
 Reply to Andrei,

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 The coolness of c# is that (in order, IMHO) 1) the tools are world 
 class, 2) the support is back by MS, 3) the docs are great, and 4) the 
 language is highly consistent and conservative, e.i. nothing is added 
 until they've got it right.

 Aside from #4, the *language* isn't anything to write home about.


 I'd say C#2 is Java with the top 10 or so feature requests implemented, 


I can confirm straight from the source (important person, name 
undisclosed to protect the innocent) that it is true that C# was without 
any buts and ands Microsoft's direct response to Java.

 and another 5 or so major feature requests implemented each major 
 version. That isn't a bad state to be in, really. It's good enough, with 
 a billion dollars in corporate backing, to make you the Current Big 
 Language.


I have the feeling that C#, for all its features, lacks some pretty 
essential capabilities.


Andrei

May 18 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Andrei Alexandrescu escribi�:
 Christopher Wright wrote:
 BCS wrote:
 Reply to Andrei,

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 The coolness of c# is that (in order, IMHO) 1) the tools are world 
 class, 2) the support is back by MS, 3) the docs are great, and 4) 
 the language is highly consistent and conservative, e.i. nothing is 
 added until they've got it right.

 Aside from #4, the *language* isn't anything to write home about.


 I'd say C#2 is Java with the top 10 or so feature requests implemented, 


 I can confirm straight from the source (important person, name 
 undisclosed to protect the innocent) that it is true that C# was without 
 any buts and ands Microsoft's direct response to Java.
 
 and another 5 or so major feature requests implemented each major 
 version. That isn't a bad state to be in, really. It's good enough, 
 with a billion dollars in corporate backing, to make you the Current 
 Big Language.


 I have the feeling that C#, for all its features, lacks some pretty 
 essential capabilities.


Like...?

May 18 2009

"Nick Sabalausky" <a a.a> writes:

"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:gusps3$87l$1 digitalmars.com...
 Andrei Alexandrescu escribi�:
 I have the feeling that C#, for all its features, lacks some pretty 
 essential capabilities.


 Like...?


Templates that don't suck.

May 19 2009

Robert Fraser <fraserofthenight gmail.com> writes:

Steven Schveighoffer wrote:
 The IDE is excellent.  The docs are reasonable once you figure out how 
 they are laid out.


I really don't get what's so great about VS. After using JDT (Eclipse 
Java), I find Vs kind of lacking. IMO, MS invests a lot of resources in 
areas to sell VS to companies rather than programmers. Automatic 
checking against UML models... okay, that's a cool feature, but I'd 
rather it could highlight my semantic errors without my having to click 
"build" or have more than 5 refactorings or have quick-fixes for errors, 
or...

May 18 2009

davidl <davidl nospam.org> writes:

�� Tue, 19 May 2009 00:14:50 +0800��BCS <ao pathlink.com> д��:

 Reply to Andrei,

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 The coolness of c# is that (in order, IMHO) 1) the tools are world  
 class, 2) the support is back by MS, 3) the docs are great, and 4) the  
 language is highly consistent and conservative, e.i. nothing is added  
 until they've got it right.

 Aside from #4, the *language* isn't anything to write home about.

 Andrei




The fact is MS has paven the way for getting people who uses C# open their  
source by default(lot of code can be disassembled). Reusing them itself is  
a very strong selling point. The market has a will to both reusing C# code  
while keeping the commercial secret. They don't want the others  
disassemble the app and tweak a little bit and rebuild the app(this is  
always possible if you don't strip the IL by only obfuscating it. For  
native cases, you would have a much higher barrier to rebuild others' app).

The first 3 points can be shared with MS if we keep at a reasonable  
consistency with MS stuff.
If we have the C# frontend and major .Net framework API, the tools can be  
built immediately by compiling SharpDevelop, which is also considered to  
be high quality to use.


-- 
ʹ�� Opera �����Եĵ����ʼ��ͻ�����: http://www.opera.com/mail/

May 18 2009

"Nick Sabalausky" <a a.a> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would 
 appreciate a few pointers. Or references. Or delegates :o).


Outside of this group, I think most of the people considering C# really cool 
are people who are unaware of D and are coming to C# from Java. What's 
"cool" about C# is that it's like a less-shitty version of Java (and *had* 
good tools, although the newer versions of VS are almost as much of a 
bloated unresponsive mess as Eclipse - Which come to think of it, makes me 
wonder - If Java has gotten so fast as many people claim, why is Eclipse 
still such a sluggish POS?).

Compare C# to D though and most of the coolness fades, even though there are 
still a handful of things I think D could still learn from C# (but there's 
probably more than a handful that C# could learn from D).

May 19 2009

BCS <none anon.com> writes:

Hello Nick,

 If Java has gotten so fast as many
 people claim, why is Eclipse still such a sluggish POS?).
 


for the same reason that anything is slow, people more than make up for any 
gains in perf with more features (and shoddy code)

May 19 2009

Christopher Wright <dhasenan gmail.com> writes:

Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gus0lu$1smj$2 digitalmars.com...
 
 I've repeatedly failed to figure out the coolness of C#, and would 
 appreciate a few pointers. Or references. Or delegates :o).


 Outside of this group, I think most of the people considering C# really cool 
 are people who are unaware of D and are coming to C# from Java. What's 
 "cool" about C# is that it's like a less-shitty version of Java (and *had* 
 good tools, although the newer versions of VS are almost as much of a 
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me 
 wonder - If Java has gotten so fast as many people claim, why is Eclipse 
 still such a sluggish POS?).
 
 Compare C# to D though and most of the coolness fades, even though there are 
 still a handful of things I think D could still learn from C# (but there's 
 probably more than a handful that C# could learn from D). 


Generics and reflection. Generics just hide a lot of casts, usually, but 
that's still quite useful. And autoboxing is convenient, though not 
appropriate for D.

May 19 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Christopher Wright (dhasenan gmail.com)'s article
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 Outside of this group, I think most of the people considering C# really cool
 are people who are unaware of D and are coming to C# from Java. What's
 "cool" about C# is that it's like a less-shitty version of Java (and *had*
 good tools, although the newer versions of VS are almost as much of a
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me
 wonder - If Java has gotten so fast as many people claim, why is Eclipse
 still such a sluggish POS?).

 Compare C# to D though and most of the coolness fades, even though there are
 still a handful of things I think D could still learn from C# (but there's
 probably more than a handful that C# could learn from D).


 that's still quite useful. And autoboxing is convenient, though not
 appropriate for D.


What the heck do you need generics for when you have real templates?  To me,
generics seem like just a lame excuse for templates.

May 19 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 == Quote from Christopher Wright (dhasenan gmail.com)'s article
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 are people who are unaware of D and are coming to C# from Java. What's
 "cool" about C# is that it's like a less-shitty version of Java (and *had*
 good tools, although the newer versions of VS are almost as much of a
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me
 wonder - If Java has gotten so fast as many people claim, why is Eclipse
 still such a sluggish POS?).

 Compare C# to D though and most of the coolness fades, even though there are
 still a handful of things I think D could still learn from C# (but there's
 probably more than a handful that C# could learn from D).


 that's still quite useful. And autoboxing is convenient, though not
 appropriate for D.


 What the heck do you need generics for when you have real templates?  To me,
 generics seem like just a lame excuse for templates.


I agree. Then, templates aren't easy to implement and they were 
understandably already busy implementing the using statement.

Andrei

May 19 2009

Lutger <lutger.blijdestijn gmail.com> writes:

Andrei Alexandrescu wrote:

...
 What the heck do you need generics for when you have real templates?  To me,
 generics seem like just a lame excuse for templates.


 I agree. Then, templates aren't easy to implement and they were 
 understandably already busy implementing the using statement.
 
 Andrei


While I don't fully understand how generics work under the hood in .NET, there
are some benefits to how it is done. For example, you can use runtime
reflection on generic types. And the jit compiler 
instantiates them at runtime. They may serve a different purpose than templates:

"Anders Hejlsberg: To me the best way to understand the distinction between C#
generics and C++ templates is this: C# generics are really just like classes,
except they have a type parameter. C++ templates 
are really just like macros, except they look like classes." 

It seems that lack of structural typing is seen as a feature:

"When you think about it, constraints are a pattern matching mechanism. You
want to be able to say, "This type parameter must have a constructor that takes
two arguments, implement operator+, have this 
static method, has these two instance methods, etc." The question is, how
complicated do you want this pattern matching mechanism to be?
There's a whole continuum from nothing to grand pattern matching. We think it's
too little to say nothing, and the grand pattern matching becomes very
complicated, so we're in- between."  

From: http://www.artima.com/intv/genericsP.html

May 19 2009

"Nick Sabalausky" <a a.a> writes:

"Lutger" <lutger.blijdestijn gmail.com> wrote in message 
news:gv090o$225$1 digitalmars.com...
 Andrei Alexandrescu wrote:

 ...
 What the heck do you need generics for when you have real templates?  To 
 me,
 generics seem like just a lame excuse for templates.


 I agree. Then, templates aren't easy to implement and they were
 understandably already busy implementing the using statement.

 Andrei


 While I don't fully understand how generics work under the hood in .NET, 
 there are some benefits to how it is done. For example, you can use 
 runtime reflection on generic types. And the jit compiler
 instantiates them at runtime. They may serve a different purpose than 
 templates:

 "Anders Hejlsberg: To me the best way to understand the distinction 
 between C# generics and C++ templates is this: C# generics are really just 
 like classes, except they have a type parameter. C++ templates
 are really just like macros, except they look like classes."

 It seems that lack of structural typing is seen as a feature:

 "When you think about it, constraints are a pattern matching mechanism. 
 You want to be able to say, "This type parameter must have a constructor 
 that takes two arguments, implement operator+, have this
 static method, has these two instance methods, etc." The question is, how 
 complicated do you want this pattern matching mechanism to be?
 There's a whole continuum from nothing to grand pattern matching. We think 
 it's too little to say nothing, and the grand pattern matching becomes 
 very complicated, so we're in- between."

 From: http://www.artima.com/intv/genericsP.html


I can see certain potential benefits to the general way C# does generics, 
but until the old (and I do mean old) issue of "There's an IComparable, so 
why the hell won't MS give us an IArithmetic so we can actually use 
arithmetic operators on generic code?" gets fixed (and at this point I'm 
convinced they've never had any intent of ever fixing that), I don't care 
how valid the reasoning behind C#'s general approach to generics is, the 
actual state of C#'s generics still falls squarely into the categories of 
"crap" and "almost useless".

May 20 2009

Christopher Wright <dhasenan gmail.com> writes:

Nick Sabalausky wrote:
 I can see certain potential benefits to the general way C# does generics, 
 but until the old (and I do mean old) issue of "There's an IComparable, so 
 why the hell won't MS give us an IArithmetic so we can actually use 
 arithmetic operators on generic code?" gets fixed (and at this point I'm 
 convinced they've never had any intent of ever fixing that), I don't care 
 how valid the reasoning behind C#'s general approach to generics is, the 
 actual state of C#'s generics still falls squarely into the categories of 
 "crap" and "almost useless". 


IArithmetic is impossible in C# because operator overloads are static 
methods, and interfaces cannot specify static methods.

May 20 2009

"Nick Sabalausky" <a a.a> writes:

"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:gv0p4e$uvv$1 digitalmars.com...
 Nick Sabalausky wrote:
 I can see certain potential benefits to the general way C# does generics, 
 but until the old (and I do mean old) issue of "There's an IComparable, 
 so why the hell won't MS give us an IArithmetic so we can actually use 
 arithmetic operators on generic code?" gets fixed (and at this point I'm 
 convinced they've never had any intent of ever fixing that), I don't care 
 how valid the reasoning behind C#'s general approach to generics is, the 
 actual state of C#'s generics still falls squarely into the categories of 
 "crap" and "almost useless".


 IArithmetic is impossible in C# because operator overloads are static 
 methods, and interfaces cannot specify static methods.


Then how does IComparable work?

May 20 2009

Christopher Wright <dhasenan gmail.com> writes:

Nick Sabalausky wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:gv0p4e$uvv$1 digitalmars.com...
 Nick Sabalausky wrote:
 I can see certain potential benefits to the general way C# does generics, 
 but until the old (and I do mean old) issue of "There's an IComparable, 
 so why the hell won't MS give us an IArithmetic so we can actually use 
 arithmetic operators on generic code?" gets fixed (and at this point I'm 
 convinced they've never had any intent of ever fixing that), I don't care 
 how valid the reasoning behind C#'s general approach to generics is, the 
 actual state of C#'s generics still falls squarely into the categories of 
 "crap" and "almost useless".


 methods, and interfaces cannot specify static methods.


 Then how does IComparable work? 


It uses a member function instead.

May 20 2009

"Nick Sabalausky" <a a.a> writes:

"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:gv29vn$7a0$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:gv0p4e$uvv$1 digitalmars.com...
 Nick Sabalausky wrote:
 I can see certain potential benefits to the general way C# does 
 generics, but until the old (and I do mean old) issue of "There's an 
 IComparable, so why the hell won't MS give us an IArithmetic so we can 
 actually use arithmetic operators on generic code?" gets fixed (and at 
 this point I'm convinced they've never had any intent of ever fixing 
 that), I don't care how valid the reasoning behind C#'s general 
 approach to generics is, the actual state of C#'s generics still falls 
 squarely into the categories of "crap" and "almost useless".


 methods, and interfaces cannot specify static methods.


 Then how does IComparable work?


 It uses a member function instead.


And they can't do the same for arithmetic?

May 20 2009

Christopher Wright <dhasenan gmail.com> writes:

Nick Sabalausky wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:gv29vn$7a0$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message 
 news:gv0p4e$uvv$1 digitalmars.com...
 Nick Sabalausky wrote:
 I can see certain potential benefits to the general way C# does 
 generics, but until the old (and I do mean old) issue of "There's an 
 IComparable, so why the hell won't MS give us an IArithmetic so we can 
 actually use arithmetic operators on generic code?" gets fixed (and at 
 this point I'm convinced they've never had any intent of ever fixing 
 that), I don't care how valid the reasoning behind C#'s general 
 approach to generics is, the actual state of C#'s generics still falls 
 squarely into the categories of "crap" and "almost useless".


 methods, and interfaces cannot specify static methods.






 And they can't do the same for arithmetic? 


I believe the rationale for using static functions is so that you can 
add null to something. (The indexing operator, mind you, is a member 
property, so this doesn't always hold.) Additionally, this gets rid of 
opX_r.

In practice, I doubt anyone uses that. But it's too late to make that 
change.

May 21 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Lutger wrote:
 Andrei Alexandrescu wrote:
 
 ...
 What the heck do you need generics for when you have real templates?  To me,
 generics seem like just a lame excuse for templates.


 understandably already busy implementing the using statement.

 Andrei


 While I don't fully understand how generics work under the hood in .NET, there
are some benefits to how it is done. For example, you can use runtime
reflection on generic types. And the jit compiler 
 instantiates them at runtime. They may serve a different purpose than
templates:
 
 "Anders Hejlsberg: To me the best way to understand the distinction between C#
generics and C++ templates is this: C# generics are really just like classes,
except they have a type parameter. C++ templates 
 are really just like macros, except they look like classes." 
 
 It seems that lack of structural typing is seen as a feature:
 
 "When you think about it, constraints are a pattern matching mechanism. You
want to be able to say, "This type parameter must have a constructor that takes
two arguments, implement operator+, have this 
 static method, has these two instance methods, etc." The question is, how
complicated do you want this pattern matching mechanism to be?
 There's a whole continuum from nothing to grand pattern matching. We think
it's too little to say nothing, and the grand pattern matching becomes very
complicated, so we're in- between."  
 
 From: http://www.artima.com/intv/genericsP.html


Oh, so Wal^H^H^Ha friend of mine I was talking to was right: there's 
some missing of the point point going on. The code generation aspect of 
templates is a blind spot of the size of Canada.

Andrei

May 20 2009

Yigal Chripun <yigal100 gmail.com> writes:

Andrei Alexandrescu wrote:
 Lutger wrote:
 Andrei Alexandrescu wrote:

 ...
 What the heck do you need generics for when you have real 
 templates?  To me,
 generics seem like just a lame excuse for templates.


 understandably already busy implementing the using statement.

 Andrei


 While I don't fully understand how generics work under the hood in 
 .NET, there are some benefits to how it is done. For example, you can 
 use runtime reflection on generic types. And the jit compiler 
 instantiates them at runtime. They may serve a different purpose than 
 templates:

 "Anders Hejlsberg: To me the best way to understand the distinction 
 between C# generics and C++ templates is this: C# generics are really 
 just like classes, except they have a type parameter. C++ templates 
 are really just like macros, except they look like classes."
 It seems that lack of structural typing is seen as a feature:

 "When you think about it, constraints are a pattern matching 
 mechanism. You want to be able to say, "This type parameter must have 
 a constructor that takes two arguments, implement operator+, have this 
 static method, has these two instance methods, etc." The question is, 
 how complicated do you want this pattern matching mechanism to be?
 There's a whole continuum from nothing to grand pattern matching. We 
 think it's too little to say nothing, and the grand pattern matching 
 becomes very complicated, so we're in- between." 
 From: http://www.artima.com/intv/genericsP.html


 Oh, so Wal^H^H^Ha friend of mine I was talking to was right: there's 
 some missing of the point point going on. The code generation aspect of 
 templates is a blind spot of the size of Canada.
 
 Andrei


I think you miss the point here.
Generics and code generation are two separate and orthogonal features 
that where conflated together by C++.

while you can do powerful stuff with templates it smells of trying to 
write Haskel code with the C pre-proceesor.
if you want to see a clean solution to this issue look at Nemerle.
essentially, their AST Macro system provides multi-level compilation.

c++ templates are a horrible hack designed to ween off C programmers 
from using the pre-processor and the D templates provide mostly cosmetic 
  changes to this. they do not solve the bigger design issue.

May 20 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Yigal Chripun wrote:
 I think you miss the point here.
 Generics and code generation are two separate and orthogonal features 
 that where conflated together by C++.


It's kind of odd, then, that for example the Generative Programming book 
(http://www.generative-programming.org) chose to treat the two notions 
in conjunction.

 while you can do powerful stuff with templates it smells of trying to 
 write Haskel code with the C pre-proceesor.
 if you want to see a clean solution to this issue look at Nemerle.
 essentially, their AST Macro system provides multi-level compilation.
 
 c++ templates are a horrible hack designed to ween off C programmers 
 from using the pre-processor and the D templates provide mostly cosmetic 
  changes to this. they do not solve the bigger design issue.


What is the bigger design issue?


Andrei

May 20 2009

"Nick Sabalausky" <a a.a> writes:

"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.151.1242855932.13405.digitalmars-d puremagic.com...
 On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 Yigal Chripun wrote:
 I think you miss the point here.
 Generics and code generation are two separate and orthogonal features 
 that
 where conflated together by C++.


 It's kind of odd, then, that for example the Generative Programming book
 (http://www.generative-programming.org) chose to treat the two notions in
 conjunction.


 Yeh, there's definitely a overlap.  Orthogonal isn't quite the right word 
 there.

 I'm reading a bit on C++/CLI right now, which is C++ extended to
 inter-operate with CLR.
 C++/CLI has *both* classic C++ templates and CLR generics:

  template<typename T> ...    // all code specializations generated at
 compile-time (if at all)
  generic<typename T> ... // code generated at compiletime
 unconditionally, specialized at run-time.

 I'm not clear on exactly what happens at runtime in the generic<>
 case.  I had been thinking it was simply that the compiler does some
 type checking at compile time and the VM code then just manipulates
 pointers to Object from there.  That may be what happens in Java
 generics, but in CLR generics at least you can specialize on
 non-Object value types and that apparently does not result in
 everything getting boxed.  So it seems like there's a little something
 extra going on.

 I think the main reason for having Generics is that they're the best
 anyone currently knows how to do at the IL bytecode level.  Generics
 give you a way to define generic parameterized types that work across
 all the languages that target a given VM's bytecode.  But that doesn't
 preclude any language that targets that VM from *also* implementing
 compile-time templates, or code generators, or AST macros at the
 source code level.

 But the problem with source-level code generation is that you then
 need the source code in order to use the library.  I think they were
 trying to avoid that with C#.   If you have a compiled C# assembly,
 then you have everything you need to use it.   Period.   (I think.)
 At any rate, a tech that requires inclusion of source code is not very
 interesting to Microsoft, because Microsoft doesn't generally like to
 let people see their source code in the first place, and they know
 that many of their biggest customers don't like to either.  They're
 nervous enough about just putting de-compileable bytecode out there.


Maybe this is naive, but what about an AST-level template/generic? Couldn't 
that provide for the best of both worlds?

For instance, suppose (purely hypothetically) that the .NET assembly system 
were changed to allow the source for a D/C++ style of source-level template 
to be embedded into the assembly. Then they'd be able to do D/C++ style 
source-level template/code-generation. Right? Now obviously the big problem 
with that is it would only be usable in the same language it was originally 
written in. So, instead of getting that cross-language support by going all 
the way down to the IL bytecode level to implement generics (which, as you 
said, would somehow prevent the flexibility that the D/C++ style enjoys) 
suppose it only went down as far as a language-agnostic AST?

I suppose that might make reverse-engineering easier which MS might not 
like, but I'm not suggesting this as something that MS should like or should 
even do, but rather suggesting it as (business issues completely aside) 
something that would possibly gain the benefits of both styles.

May 20 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Nick Sabalausky wrote:
 ...
 
 Maybe this is naive, but what about an AST-level template/generic? Couldn't 
 that provide for the best of both worlds?
 
 For instance, suppose (purely hypothetically) that the .NET assembly system 
 were changed to allow the source for a D/C++ style of source-level template 
 to be embedded into the assembly. Then they'd be able to do D/C++ style 
 source-level template/code-generation. Right? Now obviously the big problem 
 with that is it would only be usable in the same language it was originally 
 written in. So, instead of getting that cross-language support by going all 
 the way down to the IL bytecode level to implement generics (which, as you 
 said, would somehow prevent the flexibility that the D/C++ style enjoys) 
 suppose it only went down as far as a language-agnostic AST?
 
 ...


What I've always thought might be an interesting experiment would be to
change templates in LDC so that instead of generating an AST, they
generate code that generates code.

So when you use A!(T), what happens is that at runtime the template is
"run" with T as an argument.  This generates a chunk of LLVM bitcode
which LLVM then assembles to machine code and links into the program.

This alleviates the problem with using source in that if you embed the
template's actual source, then you suddenly ALSO have to embed the
standard library's source and the source of any other libraries you
happened to compile with.

Oh, and the same version of the compiler.

  -- Daniel

May 20 2009

Yigal Chripun <yigal100 gmail.com> writes:

Nick Sabalausky wrote:
 
 Maybe this is naive, but what about an AST-level template/generic? Couldn't 
 that provide for the best of both worlds?
 
 For instance, suppose (purely hypothetically) that the .NET assembly system 
 were changed to allow the source for a D/C++ style of source-level template 
 to be embedded into the assembly. Then they'd be able to do D/C++ style 
 source-level template/code-generation. Right? Now obviously the big problem 
 with that is it would only be usable in the same language it was originally 
 written in. So, instead of getting that cross-language support by going all 
 the way down to the IL bytecode level to implement generics (which, as you 
 said, would somehow prevent the flexibility that the D/C++ style enjoys) 
 suppose it only went down as far as a language-agnostic AST?
 
 I suppose that might make reverse-engineering easier which MS might not 
 like, but I'm not suggesting this as something that MS should like or should 
 even do, but rather suggesting it as (business issues completely aside) 
 something that would possibly gain the benefits of both styles. 
 
 


that's the exact opposite of a good solution.
I already mentioned several times before the language Nemerle which 
provide the correct solution.
important fact - Nemerle is a .NET language and it does _NOT_ need to 
modify the underlining system.

The way it works in Nemerle is pretty simple:
the language has a syntax to compose/decompose AST.
a Macro in nemerle is just a plain old function that uses the same 
syntax you'd use at run-time and this "function" can use APIs to access 
the compiler's internal data structures (the AST) and manipulate it.
you "connect" it to your regular code by either just calling it like a 
regular function or by using attributes.

let's compare to see the benefits:
in D:
tango.io.Stdout("Hello World").newline; // prints at run-time
pragma(msg, "Hello World"); // prints at compile-time

in Nemerle:
macro m () {
   Nemerle.IO.printf ("compile-time\n");
   <[ Nemerle.IO.printf ("run-time\n") ]>;
}
// and you call it like this:
m();
Nemerle.IO.printf ("run-time\n");

notice how both use the same code, the same printf function?
the only change is that the second line inside the macro is enclosed 
inside <[ ]> which means output (return) the AST for this code instead 
of actually running the code and returning the result of the call.

Macros in Nemerle need to be compiled since they are regular Nemerle 
code and they need to be loaded by the compiler (added to the command 
line) in order to compile the code the calls the macros.

essentially these are just plugins for the compiler.

compared to the elegance of this solution, templates are just a crude 
copy-paste mechanism implemented inside the compiler.

May 21 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Yigal Chripun wrote:
 Nick Sabalausky wrote:
 I suppose that might make reverse-engineering easier which MS might 
 not like, but I'm not suggesting this as something that MS should like 
 or should even do, but rather suggesting it as (business issues 
 completely aside) something that would possibly gain the benefits of 
 both styles.


 that's the exact opposite of a good solution.
 I already mentioned several times before the language Nemerle which 
 provide the correct solution.
 important fact - Nemerle is a .NET language and it does _NOT_ need to 
 modify the underlining system.
 
 The way it works in Nemerle is pretty simple:
 the language has a syntax to compose/decompose AST.
 a Macro in nemerle is just a plain old function that uses the same 
 syntax you'd use at run-time and this "function" can use APIs to access 
 the compiler's internal data structures (the AST) and manipulate it.
 you "connect" it to your regular code by either just calling it like a 
 regular function or by using attributes.
 
 let's compare to see the benefits:
 in D:
 tango.io.Stdout("Hello World").newline; // prints at run-time
 pragma(msg, "Hello World"); // prints at compile-time
 
 in Nemerle:
 macro m () {
   Nemerle.IO.printf ("compile-time\n");
   <[ Nemerle.IO.printf ("run-time\n") ]>;
 }
 // and you call it like this:
 m();
 Nemerle.IO.printf ("run-time\n");
 
 notice how both use the same code, the same printf function?
 the only change is that the second line inside the macro is enclosed 
 inside <[ ]> which means output (return) the AST for this code instead 
 of actually running the code and returning the result of the call.
 
 Macros in Nemerle need to be compiled since they are regular Nemerle 
 code and they need to be loaded by the compiler (added to the command 
 line) in order to compile the code the calls the macros.
 
 essentially these are just plugins for the compiler.
 
 compared to the elegance of this solution, templates are just a crude 
 copy-paste mechanism implemented inside the compiler.


Nemerle's interesting, but it has its own issues. The largest one is 
that it will have to beat history: languages with configurable syntax 
have failed in droves in the 1970s.

Before I got into D, I was working on Enki. Enki was my own programming 
language and of course made D look like a piece of crap. In Enki, you 
had only very few primitives related to macro expansion, and you could 
construct all language elements - if, while, for, structures, classes, 
exceptions, you name it, from those primitive elements.

There were two elements that convinced me to quit Enki. One was that I'd 
got word of a language called IMP72. IMP72 embedded the very same ideas 
Enki had, with two exceptions: (1) it was created in 1972, and (2) 
nobody gave a damn ever since. IMP72 (and there were others too around 
that time) started with essentially one primitive and then generated 
itself with a bootstrap routine, notion that completely wowed me and I 
erroneously thought would have the world wowed too.

The second reason was that I've had many coffees and some beers with 
Walter and he convinced me that configurable syntax is an idea that 
people just don't like. Thinking a bit more, I realized that humans 
don't operate well with configurable syntax. To use the hackneyed 
comparison, no natural language or similar concoction has configurable 
syntax. Not even musical notation or whatnot. There's one syntax for 
every human language. I speculated that humans can learn one syntax for 
a language and then wire their brains to just pattern match semantics 
using it. Configurable syntax just messes with that approach, and 
besides makes any program hugely context-dependent and consequently any 
large program a pile of crap.

That being said, I have no idea whether or not Nemerle will be 
successful. I just speculate it has an uphill battle to win.


Andrei

May 21 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 Before I got into D, I was working on Enki. Enki was my own programming
 language and of course made D look like a piece of crap. In Enki, you
 had only very few primitives related to macro expansion, and you could
 construct all language elements - if, while, for, structures, classes,
 exceptions, you name it, from those primitive elements.
 There were two elements that convinced me to quit Enki. One was that I'd
 got word of a language called IMP72. IMP72 embedded the very same ideas
 Enki had, with two exceptions: (1) it was created in 1972, and (2)
 nobody gave a damn ever since. IMP72 (and there were others too around
 that time) started with essentially one primitive and then generated
 itself with a bootstrap routine, notion that completely wowed me and I
 erroneously thought would have the world wowed too.
 The second reason was that I've had many coffees and some beers with
 Walter and he convinced me that configurable syntax is an idea that
 people just don't like. Thinking a bit more, I realized that humans
 don't operate well with configurable syntax. To use the hackneyed
 comparison, no natural language or similar concoction has configurable
 syntax. Not even musical notation or whatnot. There's one syntax for
 every human language. I speculated that humans can learn one syntax for
 a language and then wire their brains to just pattern match semantics
 using it. Configurable syntax just messes with that approach, and
 besides makes any program hugely context-dependent and consequently any
 large program a pile of crap.
 That being said, I have no idea whether or not Nemerle will be
 successful. I just speculate it has an uphill battle to win.
 Andrei


This is pretty much a special case of a more general statement about
customizability.  Customizability is good as long as there are also sane
default/de facto standard ways of doing things and simple things are still made
simple.  Take EMacs or vi, for example.  I absolutely despise both because they
have very annoying, idiosynchratic ways of doing basic stuff like saving a file,
navigating through a file, etc.  The backspace, delete, home, etc. keys don't
always do what I've come to expect them to do out of the box.  I know all this
stuff is customizable, but the barrier to entry of learning how to configure all
this stuff is much higher than the barrier to just using a simple GUI text
editor
like gedit or Notepad++ instead.  I don't care how powerful these programs are,
they're still not special enough that violating such basic conventions is
acceptable.

Bringing this analogy back to language design, if you make a language very
highly
configurable and don't provide good defaults, the barrier to entry will just be
too high.  If people have to understand a whole bunch of intricacies of the
macro
system to do anything more complex than "Hello, world", the language will be
confined to a highly devoted niche.  On the other hand, if you do provide strong
conventions and sane defaults, people will probably avoid violating them because
doing so would make their code no longer portable from programmer to programmer,
and would probably break a whole bunch of library code, etc. that relies on the
convention.  In other words, they would feel like they were creating a whole new
language, and for all practical purposes they would be.  Thus, the purpose of
this
customizability would be defeated.

As I've said before in various places, my favorite thing about D is that it
takes
a level headed, pragmatic view on so many issues that other languages fight holy
wars about.  These include performance vs. simplicity, safety vs. flexibility,
etc.  This is just another one to add to the list.  Having a sane subset that's
something like a hybrid between Java and Python, but then putting D's template
system on top of it for when the sane subset just doesn't cut it is a pragmatic,
level-headed solution to the holy war between meta-languages that let (force?)
you
to customize everything and don't have a well-defined sane, simple subset and
excessively rigid static languages that sometimes don't make complex things
possible.

(Note:  Don't get me wrong, IMHO, parts of the template system have actually
earned a rightful place in the sane subset, just not the more advanced
metaprogramming stuff.)

May 21 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 Bringing this analogy back to language design, if you make a language very
highly
 configurable and don't provide good defaults, the barrier to entry will just be
 too high.  If people have to understand a whole bunch of intricacies of the
macro
 system to do anything more complex than "Hello, world", the language will be
 confined to a highly devoted niche.  On the other hand, if you do provide
strong
 conventions and sane defaults, people will probably avoid violating them
because
 doing so would make their code no longer portable from programmer to
programmer,
 and would probably break a whole bunch of library code, etc. that relies on the
 convention.  In other words, they would feel like they were creating a whole
new
 language, and for all practical purposes they would be.  Thus, the purpose of
this
 customizability would be defeated.


The symptom is visible: even with good defaults and all, such languages 
invariably come with the advice "don't use our best feature". That's 
terrible. It's a bad anguage design to put in power that can do more 
harm than good, to the extent that you openly unrecommend usage of the 
feature. Like you have a car with a very powerful engine but not a 
clutch to match (there are many, Subaru Impreza comes to mind). Then you 
have this awesome power on paper, but invariably the mechanic tells you: 
don't seal the pedal to the metal if you want to have a car.

I therefore much prefer D's templates which I use and also recommend to 
non-advanced users, plus the occasional string mixin that is a 
seldom-used feature instrumental to only a minority of idioms.


Andrei

May 21 2009

"Nick Sabalausky" <a a.a> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gv3ubr$2ul$1 digitalmars.com...
 Yigal Chripun wrote:

 Nemerle's interesting, but it has its own issues. The largest one is that 
 it will have to beat history: languages with configurable syntax have 
 failed in droves in the 1970s.

 Before I got into D, I was working on Enki. Enki was my own programming 
 language and of course made D look like a piece of crap. In Enki, you had 
 only very few primitives related to macro expansion, and you could 
 construct all language elements - if, while, for, structures, classes, 
 exceptions, you name it, from those primitive elements.

 There were two elements that convinced me to quit Enki. One was that I'd 
 got word of a language called IMP72. IMP72 embedded the very same ideas 
 Enki had, with two exceptions: (1) it was created in 1972, and (2) nobody 
 gave a damn ever since. IMP72 (and there were others too around that time) 
 started with essentially one primitive and then generated itself with a 
 bootstrap routine, notion that completely wowed me and I erroneously 
 thought would have the world wowed too.


There are many possible reasons for a failed language's failure. One of the 
biggest is lack of visibility. Who has ever heard of IMP72? Sure, that lack 
of visibility could have been because people hated that particular aspect of 
the language, but it could also have been from any one of a number of other 
reasons.

 The second reason was that I've had many coffees and some beers with 
 Walter and he convinced me that configurable syntax is an idea that people 
 just don't like. Thinking a bit more, I realized that humans don't operate 
 well with configurable syntax. To use the hackneyed comparison, no natural 
 language or similar concoction has configurable syntax. Not even musical 
 notation or whatnot. There's one syntax for every human language. I 
 speculated that humans can learn one syntax for a language and then wire 
 their brains to just pattern match semantics using it. Configurable syntax 
 just messes with that approach, and besides makes any program hugely 
 context-dependent and consequently any large program a pile of crap.


So I take it AST Macros are no longer on the table for D3?

May 21 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick Sabalausky wrote:
 There are many possible reasons for a failed language's failure. One of the 
 biggest is lack of visibility. Who has ever heard of IMP72? Sure, that lack 
 of visibility could have been because people hated that particular aspect of 
 the language, but it could also have been from any one of a number of other 
 reasons.


As I said, there were many languages with configurable syntax created 
during that period. None was even remembered. But then, correlation is 
not causation :o).

 The second reason was that I've had many coffees and some beers with 
 Walter and he convinced me that configurable syntax is an idea that people 
 just don't like. Thinking a bit more, I realized that humans don't operate 
 well with configurable syntax. To use the hackneyed comparison, no natural 
 language or similar concoction has configurable syntax. Not even musical 
 notation or whatnot. There's one syntax for every human language. I 
 speculated that humans can learn one syntax for a language and then wire 
 their brains to just pattern match semantics using it. Configurable syntax 
 just messes with that approach, and besides makes any program hugely 
 context-dependent and consequently any large program a pile of crap.


 So I take it AST Macros are no longer on the table for D3?


AST macros can be implemented to not allow configurable syntax.


Andrei

May 21 2009

Georg Wrede <georg.wrede iki.fi> writes:

--- Disclaimer: this is a bit long. Read it later. ---

Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Macros in Nemerle need to be compiled since they are regular Nemerle 
 code and they need to be loaded by the compiler (added to the command 
 line) in order to compile the code the calls the macros.

 essentially these are just plugins for the compiler.

 compared to the elegance of this solution, templates are just a crude 
 copy-paste mechanism implemented inside the compiler.


 Nemerle's interesting, but it has its own issues. The largest one is 
 that it will have to beat history: languages with configurable syntax 
 have failed in droves in the 1970s.


This actually raises a larger issue.

IMHO, it's not about configurable syntax, OOP, or any single paradigm.

What really matters for a language is, the continuum that the 
newbie--to--guru programmer faces during his ascent through the language.

A *perfect* language should be reasonably usable by the newbie. While he 
advances, he will encounter both needs and solutions for his 
increasingly advanced/complex programming projects. Now, *any* serious 
discontinuity, or forced change of paradigm, will constitute a hurdle. 
And each such hurdle only serves as a point where this programmer (maybe 
momentarily, but still), considers other alternatives. If such a point 
is conspicuous or steep enough, he'll most probably venture to another 
language.

A programming language that has this in mind, will work like Windows: 
there's always an obvious (who said good?? it's Windows, for crying out 
loud) way to go, and for you to feel you're advancing on your career.

 Before I got into D, I was working on Enki. Enki was my own programming 
 language and of course made D look like a piece of crap. In Enki, you 
 had only very few primitives related to macro expansion, and you could 
 construct all language elements - if, while, for, structures, classes, 
 exceptions, you name it, from those primitive elements.


Lisp, Forth, anyone???

 There were two elements that convinced me to quit Enki. One was that I'd 
 got word of a language called IMP72. IMP72 embedded the very same ideas 
 Enki had, with two exceptions: (1) it was created in 1972, and (2) 
 nobody gave a damn ever since. IMP72 (and there were others too around 
 that time) started with essentially one primitive and then generated 
 itself with a bootstrap routine, notion that completely wowed me and I 
 erroneously thought would have the world wowed too.


Yeah, the academic honey pot. Always looks seductive in TeX formatted 
papers!

 The second reason was that I've had many coffees and some beers with 
 Walter and he convinced me that configurable syntax is an idea that 
 people just don't like.


You must forgive him, he's almost as old as I am!!! :O  [1]

 Thinking a bit more, I realized that humans don't operate well with
 configurable syntax.


Actually, it's not only about that. Configurable syntax is of course a 
major issue. But there's an other one. And that's redundancy.

In any Real-Life language, there's some amount of redundancy. For 
example, in many languages, both the predicate and the object are (is 
this the word) inflected (?), in unison. This gives the ability for the 
listener to skip (or not hear because of background noise) the ending of 
either word, and then understand the sentence as a whole.

In a similar vein, verbs have a different ending with plural and single, 
even though the "number" is still available from the rest of the 
sentence, or simply even the context.

Redundancy lets people receive oral communication without undue fixation 
on single-phoneme differences in the utterance. One might consider that 
as a form of error checking, like 9-bit parity memory chips.


(Something you might want to remember when people ask for compulsory 
empty parenthesis at the end of functions and methods.) ((See my next 
paragraph.))

 To use the hackneyed comparison, no natural language or similar
 concoction has configurable syntax. Not even musical notation or
 whatnot. There's one syntax for every human language. I speculated
 that humans can learn one syntax for a language and then wire their
 brains to just pattern match semantics using it. Configurable syntax
 just messes with that approach, and besides makes any program hugely
 context-dependent and consequently any large program a pile of crap.


We may have a continuum here. At the one end is the configurable syntax, 
at the other end the cast-in-stone regular syntax (which often comes 
with a reduced vocabulary).

I read (IIRC, Sicentific American, late 1970's) that the average size of 
vocabulary that a (then) working-class London person in a "lesser" 
neighbourhood used during a week, was only three hundred words! (This 
factoid was so shocking to me that I will not forget it till the day I'm 
on my death-bed. I've got more than 40000 words in each of English, 
Swedish, and Finnish. [4])

As an opposite, take this paragraph from an imaginary math book:

   "Now, substituting a^e*(2pi*sin(alpha[inverse of the second 
derivative of beta at the index])) for any first term in every 
polynomial in the quaternion, it becomes obvious that the derivation 
needs a temporary extra term, which we will call Z(fab).

Now, after the substitution (which we will use thorugh page 34), we now 
will study the short-term changes in every dimension we're investigating 
here."

Wouldn't you say, this is "configurable syntax". And the poor student 
doesn't have a choice but to try to follow this crap. (No wonder the 
working-class guy has no more a chance of ever following this, than the 
productive, but oh, so challenged member of this newsgroup.)


All my musings here, make me write two things:

1: A language has to *provide* an obvious (and followable) path from the 
ridiculously simple, to the ultimately esoteric, with no (or as few as 
possible) discontinuities in mind set. (But see [2].)

2: Any _categorical_ statement that contains an implicit assessment of 
the {audience's|programmer's|critic's} abilities, and their relevance to 
the level that a particular construct in a language demands, is 
inherently obsolete. An example is "configurable syntax is an idea that 
people just don't like".

 That being said, I have no idea whether or not Nemerle will be 
 successful. I just speculate it has an uphill battle to win.


We better make sure D doesn't climb the same hill.

And damn sure that the potholes in the D uphill aren't larger than the 
disciples' stride.


---------

[1] Configurable syntax belongs to the same group as recursion. You can 
program for years without ever needing it (or understanding that you did 
need it, actually). And then, you see it in a textbook, and all they 
used it for was Fibonacci. Gee, great, you think, and then you write 
your own Fibonacci, and then just forget about the whole thing. They 
simply don't (or didn't, at the time I read textbooks on programming) 
ever show its relevance in real life everyday programming. (Yes, maybe 
at that time, hard disks with directory hierarchies were not common. (I 
used CP/M, couldn't afford UNIX. Neither did they.) Otherwise they'd all 
have had an example of summing the sizes of files in a directory tree. 
Which would at once have made the reader feel recursion actually has 
some relevance to their life.)

Configurable syntax isn't exactly what Walter makes his bread and butter 
on. Neither do I. So neither of us has any reason (today) to use it, or 
even imagine the benefits of it.


Having said that, I remember the time (years ago) when I suggested in 
this newsgroup that we should have a macro language above the regular 
programming syntax. I suggested it would be somewhat like Lisp, and it 
would then let us do some most amazing things, totally inconceivable to 
us at the time. I almost became the laughing stock of the crowd. (And 
those things were (mostly) much less amazing than what D templates do 
now. Except for a little configurable syntax stuff. :-) )

Similarily, I see configurable syntax as a way (somewhat orthogonal to 
templates, but not fully) of making it possible to *easily* write some 
kinds of programs that we really can't imagine right now.


As an example of how hard it is to get this stuff across, I'll admit to 
the following: in the old days, I used to imagine that Lisp is the 
all-powrful super language for _anything_ (except for bit twiddling and 
systems work), and that if you couldn't do something in Lisp, it was 
only because of your own limitations as a person.

Then, one day, I read that they're implementing macros! I dropped from 
my chair! If there ever was a language I didn't expect to need macros, 
Lisp definitely was it. Then, during the next years I read articles that 
made me believe (I wouldnt be preposterous enough to state I 
/understood/) that they actually were needed, and that they advanced the 
applicability of the language significantly.


So, configurable syntax for D, I assume *will* be a reality. But I hope 
it won't be before 2.0 is official. :-( !!!!

And while I'm at it, I think that in D4 (not D3) we will have a total 
overhaul of the current template syntax. (!!!) Yes, it beats the 
G-string off C++, no question. But that is not enough. And, when you 
really look at it, the "ease" of D templates is an illusion. The "D like 
syntax", the "invisibility" of the template system, is only to appease 
newcomers, to piss off C++ folks, and to delude ourselves.

Time will show that it will need to be more overtly Lisp like, and that 
actually a (sort of) difference in syntax to regular D is well motivated.


[2] This is in contrast to the "uphill potholes" I was talking before. 
Why it's okay (IMHO) to have a slightly different syntax, is, the mental 
leap from regular programming to templates is huge anyway. And it can't 
be made to go away either[3]. (Rumtime versus compile time is already 
hard enough for many. Then we have "is my code producing binary code, or 
is it producing some other source code? Then what happens? Can that in 
turn produce yet more source code?? Am I forced to only use this 
Recursion Stuff all over the place?", etc.)

So, then it would only be natural to have a slightly different syntax. 
That would also give us possiblilities beyond the current ones, to 
(first partly, and then more completely) implement a system of 
configurable syntax to D.


In the same vein that D still implements an ASM language, there should 
be a (ehh...) "Higher Level" language at the other end. Precisely like D 
has never deluded itself of being efficient enough at the Very Low Level 
to really make ASM obsolete, it should not delude itself with notions of 
not needing a fundamental VHL (Very High Level) language at the other end.

The current Template Language is excellent, beats anybody in sight, but 
that's not the final answer. And before long C++ #$ #$  will have 
implemented it, too. Or at least the more marketable details of it. But 
we have to maintain our lead. And that's done by advancing the bleeding 
edge so it stays just beyond their reach.


[3] One can try to hide a difference by making something "look the 
same". But that only serves to disorient people. Do you remember that 
there were *two* mazes in DD. Way past the "xyzzy" graffiti, you ended 
up in a maze. I spent a whole week around there, before a girlfriend 
pointed out that "the corridors are alike" but yesterday "the corridors 
are all different". That's when I understood there were two mazes. No 
wonder I'd had a feeling of being totally clueless there.

Microsoft has made a career of making stuff look alike when they're not, 
and non-alike when they are. It's poison to rational, intelligent users. 
But the idiots who just learn by rote memory what to do when, couldn't 
care less. Or understand the point of our grief.


[4] How would you measure how many words you have in a language? The 
easiest way (back when there were books), was to have somebody else look 
up a random word in a random page of a dictionary, and ask you to 
explain it. Do that like 80 times, and then calculate the percentage you 
got right. Compare that to how many words the dictionary brags of 
having, usually right on the cover. (You do need a proper dictionary, 
with more than 50000 words, of course.)

May 21 2009

Jason House <jason.house gmail.com> writes:

Georg Wrede Wrote:

 
 --- Disclaimer: this is a bit long. Read it later. ---


Wow, you're right. Sadly, I stopped reading about 80% through (discussion on D4)

At a high level, I agree with your assessment about an easy growth path for
newbors to gurus. I should also add that a language must make the code of gurus
remain understandable for all but the newest of newbies. (Ever try to read
through STL or a boost library?)

I also had an idea for a configurable syntax language that I almost started
developing. The concept was dead simple:
1. Provide the ability to call generated code at compile time. D comes close to
this, but D has some restrictions on which code can be called.
2. Expose all compiler primitives for potential use in user code: parse trees,
types, IL, raw assembly, etc...
3. Provide hooks to replace specific compilation phases (or wedge tasks between
phases)

With that, the language was sufficiently capable to morph into any existing
language. Everything else, including most language design was "merely" standard
library work.

My inspiration was seeing various boost libraries such as spirit and lambda.
They seemed like the coolest things ever, but all they did was add new syntax
for a common coding need.  I hadn't heard of LINQ but knew such a thing was
feasible in my language...




 Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Macros in Nemerle need to be compiled since they are regular Nemerle 
 code and they need to be loaded by the compiler (added to the command 
 line) in order to compile the code the calls the macros.

 essentially these are just plugins for the compiler.

 compared to the elegance of this solution, templates are just a crude 
 copy-paste mechanism implemented inside the compiler.


 Nemerle's interesting, but it has its own issues. The largest one is 
 that it will have to beat history: languages with configurable syntax 
 have failed in droves in the 1970s.


 This actually raises a larger issue.
 
 IMHO, it's not about configurable syntax, OOP, or any single paradigm.
 
 What really matters for a language is, the continuum that the 
 newbie--to--guru programmer faces during his ascent through the language.
 
 A *perfect* language should be reasonably usable by the newbie. While he 
 advances, he will encounter both needs and solutions for his 
 increasingly advanced/complex programming projects. Now, *any* serious 
 discontinuity, or forced change of paradigm, will constitute a hurdle. 
 And each such hurdle only serves as a point where this programmer (maybe 
 momentarily, but still), considers other alternatives. If such a point 
 is conspicuous or steep enough, he'll most probably venture to another 
 language.
 
 A programming language that has this in mind, will work like Windows: 
 there's always an obvious (who said good?? it's Windows, for crying out 
 loud) way to go, and for you to feel you're advancing on your career.
 
 Before I got into D, I was working on Enki. Enki was my own programming 
 language and of course made D look like a piece of crap. In Enki, you 
 had only very few primitives related to macro expansion, and you could 
 construct all language elements - if, while, for, structures, classes, 
 exceptions, you name it, from those primitive elements.


 Lisp, Forth, anyone???
 
 There were two elements that convinced me to quit Enki. One was that I'd 
 got word of a language called IMP72. IMP72 embedded the very same ideas 
 Enki had, with two exceptions: (1) it was created in 1972, and (2) 
 nobody gave a damn ever since. IMP72 (and there were others too around 
 that time) started with essentially one primitive and then generated 
 itself with a bootstrap routine, notion that completely wowed me and I 
 erroneously thought would have the world wowed too.


 Yeah, the academic honey pot. Always looks seductive in TeX formatted 
 papers!
 
 The second reason was that I've had many coffees and some beers with 
 Walter and he convinced me that configurable syntax is an idea that 
 people just don't like.


 You must forgive him, he's almost as old as I am!!! :O  [1]
 
 Thinking a bit more, I realized that humans don't operate well with
 configurable syntax.


 Actually, it's not only about that. Configurable syntax is of course a 
 major issue. But there's an other one. And that's redundancy.
 
 In any Real-Life language, there's some amount of redundancy. For 
 example, in many languages, both the predicate and the object are (is 
 this the word) inflected (?), in unison. This gives the ability for the 
 listener to skip (or not hear because of background noise) the ending of 
 either word, and then understand the sentence as a whole.
 
 In a similar vein, verbs have a different ending with plural and single, 
 even though the "number" is still available from the rest of the 
 sentence, or simply even the context.
 
 Redundancy lets people receive oral communication without undue fixation 
 on single-phoneme differences in the utterance. One might consider that 
 as a form of error checking, like 9-bit parity memory chips.
 
 
 (Something you might want to remember when people ask for compulsory 
 empty parenthesis at the end of functions and methods.) ((See my next 
 paragraph.))
 
 To use the hackneyed comparison, no natural language or similar
 concoction has configurable syntax. Not even musical notation or
 whatnot. There's one syntax for every human language. I speculated
 that humans can learn one syntax for a language and then wire their
 brains to just pattern match semantics using it. Configurable syntax
 just messes with that approach, and besides makes any program hugely
 context-dependent and consequently any large program a pile of crap.


 We may have a continuum here. At the one end is the configurable syntax, 
 at the other end the cast-in-stone regular syntax (which often comes 
 with a reduced vocabulary).
 
 I read (IIRC, Sicentific American, late 1970's) that the average size of 
 vocabulary that a (then) working-class London person in a "lesser" 
 neighbourhood used during a week, was only three hundred words! (This 
 factoid was so shocking to me that I will not forget it till the day I'm 
 on my death-bed. I've got more than 40000 words in each of English, 
 Swedish, and Finnish. [4])
 
 As an opposite, take this paragraph from an imaginary math book:
 
    "Now, substituting a^e*(2pi*sin(alpha[inverse of the second 
 derivative of beta at the index])) for any first term in every 
 polynomial in the quaternion, it becomes obvious that the derivation 
 needs a temporary extra term, which we will call Z(fab).
 
 Now, after the substitution (which we will use thorugh page 34), we now 
 will study the short-term changes in every dimension we're investigating 
 here."
 
 Wouldn't you say, this is "configurable syntax". And the poor student 
 doesn't have a choice but to try to follow this crap. (No wonder the 
 working-class guy has no more a chance of ever following this, than the 
 productive, but oh, so challenged member of this newsgroup.)
 
 
 All my musings here, make me write two things:
 
 1: A language has to *provide* an obvious (and followable) path from the 
 ridiculously simple, to the ultimately esoteric, with no (or as few as 
 possible) discontinuities in mind set. (But see [2].)
 
 2: Any _categorical_ statement that contains an implicit assessment of 
 the {audience's|programmer's|critic's} abilities, and their relevance to 
 the level that a particular construct in a language demands, is 
 inherently obsolete. An example is "configurable syntax is an idea that 
 people just don't like".
 
 That being said, I have no idea whether or not Nemerle will be 
 successful. I just speculate it has an uphill battle to win.


 We better make sure D doesn't climb the same hill.
 
 And damn sure that the potholes in the D uphill aren't larger than the 
 disciples' stride.
 
 
 ---------
 
 [1] Configurable syntax belongs to the same group as recursion. You can 
 program for years without ever needing it (or understanding that you did 
 need it, actually). And then, you see it in a textbook, and all they 
 used it for was Fibonacci. Gee, great, you think, and then you write 
 your own Fibonacci, and then just forget about the whole thing. They 
 simply don't (or didn't, at the time I read textbooks on programming) 
 ever show its relevance in real life everyday programming. (Yes, maybe 
 at that time, hard disks with directory hierarchies were not common. (I 
 used CP/M, couldn't afford UNIX. Neither did they.) Otherwise they'd all 
 have had an example of summing the sizes of files in a directory tree. 
 Which would at once have made the reader feel recursion actually has 
 some relevance to their life.)
 
 Configurable syntax isn't exactly what Walter makes his bread and butter 
 on. Neither do I. So neither of us has any reason (today) to use it, or 
 even imagine the benefits of it.
 
 
 Having said that, I remember the time (years ago) when I suggested in 
 this newsgroup that we should have a macro language above the regular 
 programming syntax. I suggested it would be somewhat like Lisp, and it 
 would then let us do some most amazing things, totally inconceivable to 
 us at the time. I almost became the laughing stock of the crowd. (And 
 those things were (mostly) much less amazing than what D templates do 
 now. Except for a little configurable syntax stuff. :-) )
 
 Similarily, I see configurable syntax as a way (somewhat orthogonal to 
 templates, but not fully) of making it possible to *easily* write some 
 kinds of programs that we really can't imagine right now.
 
 
 As an example of how hard it is to get this stuff across, I'll admit to 
 the following: in the old days, I used to imagine that Lisp is the 
 all-powrful super language for _anything_ (except for bit twiddling and 
 systems work), and that if you couldn't do something in Lisp, it was 
 only because of your own limitations as a person.
 
 Then, one day, I read that they're implementing macros! I dropped from 
 my chair! If there ever was a language I didn't expect to need macros, 
 Lisp definitely was it. Then, during the next years I read articles that 
 made me believe (I wouldnt be preposterous enough to state I 
 /understood/) that they actually were needed, and that they advanced the 
 applicability of the language significantly.
 
 
 So, configurable syntax for D, I assume *will* be a reality. But I hope 
 it won't be before 2.0 is official. :-( !!!!
 
 And while I'm at it, I think that in D4 (not D3) we will have a total 
 overhaul of the current template syntax. (!!!) Yes, it beats the 
 G-string off C++, no question. But that is not enough. And, when you 
 really look at it, the "ease" of D templates is an illusion. The "D like 
 syntax", the "invisibility" of the template system, is only to appease 
 newcomers, to piss off C++ folks, and to delude ourselves.
 
 Time will show that it will need to be more overtly Lisp like, and that 
 actually a (sort of) difference in syntax to regular D is well motivated.
 
 
 [2] This is in contrast to the "uphill potholes" I was talking before. 
 Why it's okay (IMHO) to have a slightly different syntax, is, the mental 
 leap from regular programming to templates is huge anyway. And it can't 
 be made to go away either[3]. (Rumtime versus compile time is already 
 hard enough for many. Then we have "is my code producing binary code, or 
 is it producing some other source code? Then what happens? Can that in 
 turn produce yet more source code?? Am I forced to only use this 
 Recursion Stuff all over the place?", etc.)
 
 So, then it would only be natural to have a slightly different syntax. 
 That would also give us possiblilities beyond the current ones, to 
 (first partly, and then more completely) implement a system of 
 configurable syntax to D.
 
 
 In the same vein that D still implements an ASM language, there should 
 be a (ehh...) "Higher Level" language at the other end. Precisely like D 
 has never deluded itself of being efficient enough at the Very Low Level 
 to really make ASM obsolete, it should not delude itself with notions of 
 not needing a fundamental VHL (Very High Level) language at the other end.
 
 The current Template Language is excellent, beats anybody in sight, but 
 that's not the final answer. And before long C++ #$ #$  will have 
 implemented it, too. Or at least the more marketable details of it. But 
 we have to maintain our lead. And that's done by advancing the bleeding 
 edge so it stays just beyond their reach.
 
 
 [3] One can try to hide a difference by making something "look the 
 same". But that only serves to disorient people. Do you remember that 
 there were *two* mazes in DD. Way past the "xyzzy" graffiti, you ended 
 up in a maze. I spent a whole week around there, before a girlfriend 
 pointed out that "the corridors are alike" but yesterday "the corridors 
 are all different". That's when I understood there were two mazes. No 
 wonder I'd had a feeling of being totally clueless there.
 
 Microsoft has made a career of making stuff look alike when they're not, 
 and non-alike when they are. It's poison to rational, intelligent users. 
 But the idiots who just learn by rote memory what to do when, couldn't 
 care less. Or understand the point of our grief.
 
 
 [4] How would you measure how many words you have in a language? The 
 easiest way (back when there were books), was to have somebody else look 
 up a random word in a random page of a dictionary, and ask you to 
 explain it. Do that like 80 times, and then calculate the percentage you 
 got right. Compare that to how many words the dictionary brags of 
 having, usually right on the cover. (You do need a proper dictionary, 
 with more than 50000 words, of course.)

May 22 2009

Georg Wrede <georg.wrede iki.fi> writes:

Jason House wrote:
 Georg Wrede Wrote:
 
 --- Disclaimer: this is a bit long. Read it later. ---




 Wow, you're right. Sadly, I stopped reading about 80% through
 (discussion on D4)


Yeah, one should not write opinion pieces when inspired...

 At a high level, I agree with your assessment about an easy growth
 path for newbors to gurus. I should also add that a language must
 make the code of gurus remain understandable for all but the newest
 of newbies. (Ever try to read through STL or a boost library?)


(Yeah, reading that kind of code makes one feel inferior to the gurus. 
And so very sad that the language makes even mid-level stuff entirely 
uncomprehensible. Not to speak of the amounts of time it has to take 
coding it.)

Strictly speaking, there's no way for a language to make guru code 
understandable to "anti-gurus". However (and what I guess you were 
thinkng of), when somebody uses the most advanced features in a 
language, then his stuff should not become incomprehensible to 
"anti-gurus" just because of the language itself.

What I mean is, if somebody does tensor algebra, it's pretty sure a high 
schooler won't get it, no matter what the language is. *But*, if someone 
calculates the area of a rectangle or a triangle, using the most 
advanced language features, then the *language* should not make it 
incomprehensible to non-gurus, or even "anti-gurus".

(I have to admit, no language can guarantee this, but it definitely has 
to be the aim when designing advanced language features.)

 I also had an idea for a configurable syntax language that I almost
 started developing.


 My inspiration was seeing various boost libraries such as spirit and
 lambda. They seemed like the coolest things ever, but all they did
 was add new syntax for a common coding need.  I hadn't heard of LINQ
 but knew such a thing was feasible in my language...


Spirit and lambda have inspired lots of people. Me too. And LINQ is a 
cool thing too. When I originally wrote about configurable syntax, LINQ 
would have made an excellent example of its usefulness. Sadly, I didn't 
know about it at the time.

May 22 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Georg Wrede wrote:
 Jason House wrote:
 Georg Wrede Wrote:

 --- Disclaimer: this is a bit long. Read it later. ---




 Wow, you're right. Sadly, I stopped reading about 80% through
 (discussion on D4)


 Yeah, one should not write opinion pieces when inspired...
 
 At a high level, I agree with your assessment about an easy growth
 path for newbors to gurus. I should also add that a language must
 make the code of gurus remain understandable for all but the newest
 of newbies. (Ever try to read through STL or a boost library?)


 (Yeah, reading that kind of code makes one feel inferior to the gurus. 
 And so very sad that the language makes even mid-level stuff entirely 
 uncomprehensible. Not to speak of the amounts of time it has to take 
 coding it.)
 
 Strictly speaking, there's no way for a language to make guru code 
 understandable to "anti-gurus". However (and what I guess you were 
 thinkng of), when somebody uses the most advanced features in a 
 language, then his stuff should not become incomprehensible to 
 "anti-gurus" just because of the language itself.


Two possible language features should make complicated template code 
significantly simpler:

1. Allow inner name promotion even if the template defines other 
members, as long as they are all private:

now:

template WidgetImpl(A, B) {
     ...
     alias ... Result;
}

template Widget(A, B) {
     alias WidgetImpl!(A, B) Widget;
}

proposed:

template Widget(A, B) {
private:
     ...
     alias ... Result;
public:
     alias Widget Result;
}

It's needed very frequently, puts sand in the eye, and almost sure to 
throw off the casual reader.

2. Handle qualifiers and ref properly. Right now I use an abomination:

enum bool byRef = is(typeof(&(R.init.front())));
///    UGLY   
/**
Forwards to $(D _input.back).
  */
     mixin(
         (byRef ? "ref " : "")~
         q{ElementType!(R) front()
             {
                 return _input.back;
             }
         });


Andrei

May 22 2009

bearophile <bearophileHUGS lycos.com> writes:

A configurable syntax has some advantages:
- It makes the language more flexible. I like the idea of this a lot.
- allows to do things that are otherwise hard to do.
- It can be used to write shorter programs.
- It can be used to define a sub-language fitter for a specific job. (Ruby
shows some of this, and CLisp shows lot of this).

A configurable syntax has some disadvantages too (you need some experience to
understand the following points):
- Every program can look different. So you may need lot of time to understand
code written by other people. This is bad if you have 50+ programmers working
on a project.
- The language gets more complex.
- Meta-programming is generally not easy to understand. So newbie programmers
will need more time to learn the language, the entry barrier to the language is
higher.
- It fragments the language community, creating more differences among
programs. This probably leads to a language that has much less already written
modules (example: In Python you can find a module for almost everything. This
sharing of code comes from the syntax that is standard, people using the same
single CPython interpreter, and so on. In Python even the coding style is
codified, there is only one normal way in writing code. This allows people to
share code in a simpler way. And having a rich community of re-usable modules
is probably the most important quality a modern language can have).
- Creating macros is sometimes like extending the language. But the discussions
on the D newsgroups and Python newsgroups have shown me that adding new good
syntax/semantics to a language is a very hard job. So most people that write
macros are going to add bad designs to the language. This is bad.

A silly solution is to have macros only in the standard library and in few
autorized libraries :o] But this is impossible to enforce.

So in the end it may be better to keep finding special and localized situations
where the D language may enjoy becoming a bit more flexible (generic infix
operators? Merging the syntax of compile-time functiong with some templates?
Etc etc) but it may be better to not add a generic configurable syntax (macros)
to D...

Bye,
bearophile

May 22 2009

Yigal Chripun <yigal100 gmail.com> writes:

Andrei Alexandrescu wrote:
 Yigal Chripun wrote:
 Nick Sabalausky wrote:
 I suppose that might make reverse-engineering easier which MS might 
 not like, but I'm not suggesting this as something that MS should 
 like or should even do, but rather suggesting it as (business issues 
 completely aside) something that would possibly gain the benefits of 
 both styles.


 that's the exact opposite of a good solution.
 I already mentioned several times before the language Nemerle which 
 provide the correct solution.
 important fact - Nemerle is a .NET language and it does _NOT_ need to 
 modify the underlining system.

 The way it works in Nemerle is pretty simple:
 the language has a syntax to compose/decompose AST.
 a Macro in nemerle is just a plain old function that uses the same 
 syntax you'd use at run-time and this "function" can use APIs to 
 access the compiler's internal data structures (the AST) and 
 manipulate it.
 you "connect" it to your regular code by either just calling it like a 
 regular function or by using attributes.

 let's compare to see the benefits:
 in D:
 tango.io.Stdout("Hello World").newline; // prints at run-time
 pragma(msg, "Hello World"); // prints at compile-time

 in Nemerle:
 macro m () {
   Nemerle.IO.printf ("compile-time\n");
   <[ Nemerle.IO.printf ("run-time\n") ]>;
 }
 // and you call it like this:
 m();
 Nemerle.IO.printf ("run-time\n");

 notice how both use the same code, the same printf function?
 the only change is that the second line inside the macro is enclosed 
 inside <[ ]> which means output (return) the AST for this code instead 
 of actually running the code and returning the result of the call.

 Macros in Nemerle need to be compiled since they are regular Nemerle 
 code and they need to be loaded by the compiler (added to the command 
 line) in order to compile the code the calls the macros.

 essentially these are just plugins for the compiler.

 compared to the elegance of this solution, templates are just a crude 
 copy-paste mechanism implemented inside the compiler.


 Nemerle's interesting, but it has its own issues. The largest one is 
 that it will have to beat history: languages with configurable syntax 
 have failed in droves in the 1970s.
 
 Before I got into D, I was working on Enki. Enki was my own programming 
 language and of course made D look like a piece of crap. In Enki, you 
 had only very few primitives related to macro expansion, and you could 
 construct all language elements - if, while, for, structures, classes, 
 exceptions, you name it, from those primitive elements.
 
 There were two elements that convinced me to quit Enki. One was that I'd 
 got word of a language called IMP72. IMP72 embedded the very same ideas 
 Enki had, with two exceptions: (1) it was created in 1972, and (2) 
 nobody gave a damn ever since. IMP72 (and there were others too around 
 that time) started with essentially one primitive and then generated 
 itself with a bootstrap routine, notion that completely wowed me and I 
 erroneously thought would have the world wowed too.
 
 The second reason was that I've had many coffees and some beers with 
 Walter and he convinced me that configurable syntax is an idea that 
 people just don't like. Thinking a bit more, I realized that humans 
 don't operate well with configurable syntax. To use the hackneyed 
 comparison, no natural language or similar concoction has configurable 
 syntax. Not even musical notation or whatnot. There's one syntax for 
 every human language. I speculated that humans can learn one syntax for 
 a language and then wire their brains to just pattern match semantics 
 using it. Configurable syntax just messes with that approach, and 
 besides makes any program hugely context-dependent and consequently any 
 large program a pile of crap.
 
 That being said, I have no idea whether or not Nemerle will be 
 successful. I just speculate it has an uphill battle to win.
 
 
 Andrei


I didn't talk about configurable syntax at all above.
Yes, Nemerle has this feature as part of their Macro system but that's 
just one rather small aspect about the system that can be removed. I 
also don't see the bigger problem with it as you describe since this is 
limited in Nemerle to specific things.

I'm also unsure as to what you define as syntax and what you define as 
semantics. for example, Smalltalk has only 5 keywords and it's 
implemented entirely as a collection of libraries. "if" "else" "switch" 
"while" are all implemented as methods of objects and therefore are 
configurable. Is that also wrong in your opinion?

I agree with dsimcha -
the language needs to provide simple intuitive defaults, that's why I 
think LISP didn't succeed. it is very powerful but the need to write 
your own macro just so you can say "4 + 5" instead of (+ 4 5) shows this 
point.

I think Nemerle provies this - the constructs in Nemerle for the Macro 
system are very simple and intuitive. you only have one extra syntax 
feature, the <[ ]>. think of D's CTFE only much more extended in scope - 
you write a CTFE function and compile it. (that's the Nemerle Macro 
equivalent) than you just call it in a different file and the compiler 
will execute this function at compile time.
Nemerle does not need an interpreter for this since these functions are 
compiled just like the rest of the code. Nemerle also provides compiler 
APIs so these functions could work on AST to add/alter/remove types and 
other constructs.

Last thing, basing your arguments on history is flawed. the Micro-Kernel 
idea got the same treatment after the failures in the 80's (Mach and 
co.) but nowadays this idea was revived and there are already several 
million cellphones that run an OS built on the L4 micro-kernel so it's 
even a commercial success.

May 21 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Yigal Chripun wrote:
 Last thing, basing your arguments on history is flawed. the Micro-Kernel 
 idea got the same treatment after the failures in the 80's (Mach and 
 co.) but nowadays this idea was revived and there are already several 
 million cellphones that run an OS built on the L4 micro-kernel so it's 
 even a commercial success.


Our industry goes in cycles, and I've been around to see a few 
(multitasking, microkernels, memory paging, virtual machine monitors, 
client-server...) That is because various tradeoffs in hardware have 
subtly changed with time. The human factor, however, has stayed the same.


Andrei

May 21 2009

"Nick Sabalausky" <a a.a> writes:

"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:gv5dpn$2oe9$1 digitalmars.com...
 I think Nemerle provies this - the constructs in Nemerle for the Macro 
 system are very simple and intuitive. you only have one extra syntax 
 feature, the <[ ]>. think of D's CTFE only much more extended in scope - 
 you write a CTFE function and compile it. (that's the Nemerle Macro 
 equivalent) than you just call it in a different file and the compiler 
 will execute this function at compile time.
 Nemerle does not need an interpreter for this since these functions are 
 compiled just like the rest of the code. Nemerle also provides compiler 
 APIs so these functions could work on AST to add/alter/remove types and 
 other constructs.


As I recall, we got onto this subject from discussing ways to combine the 
power of D/C++-style templates with the cross-[assembly/object] benefits of 
C#-style generics. I understand what you're saying here about why nemerle's 
macro system is like a better form of D's CTFE. But I'm unclear on how 
nemerle's macro system relates to the problem of achieving the best of both 
worlds between D/C++-style templates and C#-style generics?

May 21 2009

Georg Wrede <georg.wrede iki.fi> writes:

Nick Sabalausky wrote:
 Suppose (purely hypothetically) that the .NET assembly system 
 were changed to allow the source for a D/C++ style of source-level template 
 to be embedded into the assembly. Then they'd be able to do D/C++ style 
 source-level template/code-generation. Right?


I assume, actually presume, that would take the better part of a decade.

 Now obviously the big problem with that is it would only be usable in
 the same language it was originally written in.


That actually depends. Done the M$ way, it would. Done properly, it 
would work in any language. But then, that would mean a rewrite of the 
entire CLR, wouldn't it?

 I suppose that might make reverse-engineering easier  [...]


I don't think that's got anything to do with it. Not at least, if they'd 
really do it below the language/CLR boundary.

May 21 2009

"Nick Sabalausky" <a a.a> writes:

"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:gv4t8t$1r49$1 digitalmars.com...
 Nick Sabalausky wrote:
 Suppose (purely hypothetically) that the .NET assembly system were 
 changed to allow the source for a D/C++ style of source-level template to 
 be embedded into the assembly. Then they'd be able to do D/C++ style 
 source-level template/code-generation. Right?


 I assume, actually presume, that would take the better part of a decade.

 Now obviously the big problem with that is it would only be usable in
 the same language it was originally written in.


 That actually depends. Done the M$ way, it would. Done properly, it would 
 work in any language. But then, that would mean a rewrite of the entire 
 CLR, wouldn't it?


Actually, I only intended that part of it as a lead-in to my idea about 
templates/generics working on an AST-level instead of source-level (D/C++ 
templates) or bytecode-level (C# generics).

May 21 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Yigal Chripun (yigal100 gmail.com)'s article
 Andrei Alexandrescu wrote:
 Lutger wrote:
 Andrei Alexandrescu wrote:

 ...
 What the heck do you need generics for when you have real
 templates?  To me,
 generics seem like just a lame excuse for templates.


 understandably already busy implementing the using statement.

 Andrei


 While I don't fully understand how generics work under the hood in
 .NET, there are some benefits to how it is done. For example, you can
 use runtime reflection on generic types. And the jit compiler
 instantiates them at runtime. They may serve a different purpose than
 templates:

 "Anders Hejlsberg: To me the best way to understand the distinction
 between C# generics and C++ templates is this: C# generics are really
 just like classes, except they have a type parameter. C++ templates
 are really just like macros, except they look like classes."
 It seems that lack of structural typing is seen as a feature:

 "When you think about it, constraints are a pattern matching
 mechanism. You want to be able to say, "This type parameter must have
 a constructor that takes two arguments, implement operator+, have this
 static method, has these two instance methods, etc." The question is,
 how complicated do you want this pattern matching mechanism to be?
 There's a whole continuum from nothing to grand pattern matching. We
 think it's too little to say nothing, and the grand pattern matching
 becomes very complicated, so we're in- between."
 From: http://www.artima.com/intv/genericsP.html


 Oh, so Wal^H^H^Ha friend of mine I was talking to was right: there's
 some missing of the point point going on. The code generation aspect of
 templates is a blind spot of the size of Canada.

 Andrei


 Generics and code generation are two separate and orthogonal features
 that where conflated together by C++.
 while you can do powerful stuff with templates it smells of trying to
 write Haskel code with the C pre-proceesor.
 if you want to see a clean solution to this issue look at Nemerle.
 essentially, their AST Macro system provides multi-level compilation.
 c++ templates are a horrible hack designed to ween off C programmers
 from using the pre-processor and the D templates provide mostly cosmetic
   changes to this. they do not solve the bigger design issue.


Not sure I agree.  C++ templates were probably intended to be something like
generics initially and became Turing-complete almost by accident.  To get Turing
completeness in C++ templates requires severe abuse of features and spaghetti
code
writing.  D extends templates so that they're actually *designed* for
metaprogramming, not just an implementation of generics, thus solving C++'s
design
problem.  Mixins (to really allow code generation), CTFE (to make it easier to
generate code), static if (to avoid kludges like using specialization just to
get
branching) and tuples (to handle variadics) make D templates useful for
metaprogramming without massive kludges.

May 20 2009

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

dsimcha wrote:
 Not sure I agree.  C++ templates were probably intended to be something like
 generics initially and became Turing-complete almost by accident.


That is factually correct. It was quite a hubbub on the C++ 
standardization committee when Erwin Unruh wrote a C++ program that 
wrote prime numbers in error messages. See http://tinyurl.com/oqk6nl

Andrei

May 20 2009

BCS <ao pathlink.com> writes:

Reply to Yigal,

 D templates provide mostly cosmetic changes to this.
 


If you think D's templates are C++'s template with a few "cosmetic changes" 
than you aren't paying attention.

A few cosmetic changes aren't going to allow 1.4MB of c++ header files to 
be anywhere near duplicated in 2000 LOC (Boost sprit vs dparse)

May 20 2009

BCS <none anon.com> writes:

Hello dsimcha,

 What the heck do you need generics for when you have real templates?
 To me, generics seem like just a lame excuse for templates.
 


smaller object code? OTOH a good implementation will noice when I can fold 
together several template expansions

May 19 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from BCS (none anon.com)'s article
 Hello dsimcha,
 What the heck do you need generics for when you have real templates?
 To me, generics seem like just a lame excuse for templates.


 together several template expansions


I understand that object file bloat with templates is at least a theoretical
concern, but come on.  For most programs, at least most of the ones I write,
most
of the memory consumption is data, and code is only a tiny fraction.  Does
anyone
have a real world use case where object file bloat due to templates was a
significant problem *and* you weren't working w/ an embedded system where you
couldn't use C#/Java anyhow?

May 19 2009

BCS <none anon.com> writes:

Hello dsimcha,

 == Quote from BCS (none anon.com)'s article
 
 Hello dsimcha,
 
 What the heck do you need generics for when you have real templates?
 To me, generics seem like just a lame excuse for templates.
 


 fold together several template expansions
 


 theoretical concern, but come on.  For most programs, at least most of
 the ones I write, most of the memory consumption is data, and code is
 only a tiny fraction.  Does anyone have a real world use case where
 object file bloat due to templates was a significant problem *and* you
 weren't working w/ an embedded system where you couldn't use C#/Java
 anyhow?
 


It's not just file size, it can also cause memory and cache pressure.

But to answer your question, I don't remember exactly how big the object 
files were but I've had DMD use up 700+ MB of ram. I /think/ it was kicking 
out 10+MB object files.

That was running dparse with a 200 rule grammar. OTOH generics won't help 
with that.

May 19 2009

Kagamin <spam here.lot> writes:

BCS Wrote:

 smaller object code? OTOH a good implementation will noice when I can fold 
 together several template expansions


That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.

May 20 2009

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Kagamin wrote:
 BCS Wrote:
 
 smaller object code? OTOH a good implementation will noice when I can fold 
 together several template expansions


 That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.


They're not always binary-incompatible. For instance, if a template only works 
with pointers or references (this includes object references) to parameter
types 
it might well contain the exact same machine code for some of the
instantiations.
A compiler backend or linker could recognize these cases and use a single 
instantiation's machine code for them.
(Essentially, these are pretty much the same cases where generics would have 
been sufficient)

May 20 2009

Kagamin <spam here.lot> writes:

Frits van Bommel Wrote:

 That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.


 They're not always binary-incompatible. For instance, if a template only works 
 with pointers or references (this includes object references) to parameter
types 
 it might well contain the exact same machine code for some of the
instantiations.


If you require that the class inherits some interface and call that interface's
methods, they'll be incompatible. I'll dare to say this is the most useful
variant of generic code.

May 20 2009

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Kagamin wrote:
 Frits van Bommel Wrote:
 
 That's the difference. You can't fold templates because they're binary
incompatible as opposite to generics.


 with pointers or references (this includes object references) to parameter
types 
 it might well contain the exact same machine code for some of the
instantiations.


 If you require that the class inherits some interface and call that
interface's methods, they'll be incompatible. I'll dare to say this is the most
useful variant of generic code.


Okay, so it doesn't (usually) work for interfaces, but it'll work if the 
requirement is for a common base class. Or perhaps even if they happen to have
a 
common base class that implements the interface in question.

May 20 2009

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Denis Koroskin wrote:
 On Wed, 20 May 2009 13:09:37 +0400, Kagamin <spam here.lot> wrote:
 
 BCS Wrote:

 smaller object code? OTOH a good implementation will noice when I can  
 fold
 together several template expansions


 incompatible as opposite to generics.


 You can fold /some/ templates. I believe LLVM already does merging of
identical functions (including templates, virtual functions etc) as a part of
optimization process. Not sure about LDC, though.


LLVM has a function merging pass, but LDC doesn't run it by default at any 
optimization level. (You can pass -mergefunc to run it explicitly, as with any 
LLVM pass)
It has some limitations though. Since it runs on IR, it matters what LLVM type 
values have. That means it might merge Templ!(int) and Templ!(uint) since int 
and uint are both an i32 to LLVM, but it normally wouldn't merge Templ!(int*) 
and Templ(short*) even if the template compiles down to "return cast(T) 
somefunc(cast(void*) arg);" because the types are still different (i32* vs
i16*).
To do the latter transformation, the pass would need to be reimplemented to run 
when the code is closer to machine code.

May 20 2009

bearophile <bearophileHUGS lycos.com> writes:

Frits van Bommel:
 To do the latter transformation, the pass would need to be reimplemented to
run 
 when the code is closer to machine code.


Can't this feature be asked to the LLVM developers?

Bye,
bearophile

May 20 2009

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

bearophile wrote:
 Frits van Bommel:
 To do the latter transformation, the pass would need to be reimplemented to
run 
 when the code is closer to machine code.


 Can't this feature be asked to the LLVM developers?


Sure, feel free to file a feature request: 
http://llvm.org/bugs/enter_bug.cgi?product=new-bugs

May 20 2009

"Denis Koroskin" <2korden gmail.com> writes:

On Wed, 20 May 2009 13:09:37 +0400, Kagamin <spam here.lot> wrote:

 BCS Wrote:

 smaller object code? OTOH a good implementation will noice when I can  
 fold
 together several template expansions


 That's the difference. You can't fold templates because they're binary  
 incompatible as opposite to generics.


You can fold /some/ templates. I believe LLVM already does merging of identical
functions (including templates, virtual functions etc) as a part of
optimization process. Not sure about LDC, though.

May 20 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

dsimcha escribi�:
 == Quote from Christopher Wright (dhasenan gmail.com)'s article
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 are people who are unaware of D and are coming to C# from Java. What's
 "cool" about C# is that it's like a less-shitty version of Java (and *had*
 good tools, although the newer versions of VS are almost as much of a
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me
 wonder - If Java has gotten so fast as many people claim, why is Eclipse
 still such a sluggish POS?).

 Compare C# to D though and most of the coolness fades, even though there are
 still a handful of things I think D could still learn from C# (but there's
 probably more than a handful that C# could learn from D).


 that's still quite useful. And autoboxing is convenient, though not
 appropriate for D.


 What the heck do you need generics for when you have real templates?  To me,
 generics seem like just a lame excuse for templates.


Yesterday doob reported a bug in Descent saying "when you compile your 
project and it references a user library that has errors, when you click 
on the console to jump to the error, it doesn't work". I said to him: I 
never thought a user library could have errors! How did this happen to 
you? He replied: "I found a bug in a template in Tango".

That's why generics doesn't suck: if there's something wrong in them, 
the compiler tells you in compile-time. In D, you get the errors only 
when instantiating that template.

Generics might not be as powerful as templates, but once you write one 
that compiles, you know you will always be able to instantiate it.

May 20 2009

bearophile <bearophileHUGS lycos.com> writes:

Ary Borenszweig:
 That's why generics doesn't suck: if there's something wrong in them, 
 the compiler tells you in compile-time. In D, you get the errors only 
 when instantiating that template.


It's just like in dynamic languages, you need to unittest them a lot :-)
So having a "static throws()" to assert that a template isn't working is very
useful.

Bye,
bearophile

May 20 2009

dsimcha <dsimcha yahoo.com> writes:

== Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 dsimcha escribi�:
 == Quote from Christopher Wright (dhasenan gmail.com)'s article
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 are people who are unaware of D and are coming to C# from Java. What's
 "cool" about C# is that it's like a less-shitty version of Java (and *had*
 good tools, although the newer versions of VS are almost as much of a
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me
 wonder - If Java has gotten so fast as many people claim, why is Eclipse
 still such a sluggish POS?).

 Compare C# to D though and most of the coolness fades, even though there are
 still a handful of things I think D could still learn from C# (but there's
 probably more than a handful that C# could learn from D).


 that's still quite useful. And autoboxing is convenient, though not
 appropriate for D.


 What the heck do you need generics for when you have real templates?  To me,
 generics seem like just a lame excuse for templates.


 project and it references a user library that has errors, when you click
 on the console to jump to the error, it doesn't work". I said to him: I
 never thought a user library could have errors! How did this happen to
 you? He replied: "I found a bug in a template in Tango".
 That's why generics doesn't suck: if there's something wrong in them,
 the compiler tells you in compile-time. In D, you get the errors only
 when instantiating that template.
 Generics might not be as powerful as templates, but once you write one
 that compiles, you know you will always be able to instantiate it.


Yes, but there are two flaws in this argument:

1.  If you are only using templates like generics, you simply use a unit test to
see if it compiles.  If you're not doing anything fancy and it compiles for one
or
two types, it will probably compile for everything that you would reasonably
expect it to.

2.  If you're doing something fancier, like metaprogramming, you have to just
face
the fact that this is non-trivial, and couldn't be done with generics anyhow.

3.  As Bearophile alluded to, templates are really a clever hack to give you the
flexibility of a dynamic language with the performance and compile time checking
of a static language.  This is done by moving the dynamism to instantiation
time.
 Therefore, whereas in a dynamic language you pay at runtime in terms of the
"here
be monsters, this code may not be being used as the author intended and tested
it", with templates you pay at instantiation time.  However, IMHO this is orders
of magnitude better than not having that flexibility at all.  I personally can't
figure out how people accomplish anything in static languages w/o templates. 
It's
just too inflexible.

May 20 2009

Jacob Carlborg <doob me.com> writes:

dsimcha wrote:
 == Quote from Ary Borenszweig (ary esperanto.org.ar)'s article
 dsimcha escribi�:
 == Quote from Christopher Wright (dhasenan gmail.com)'s article
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 are people who are unaware of D and are coming to C# from Java. What's
 "cool" about C# is that it's like a less-shitty version of Java (and *had*
 good tools, although the newer versions of VS are almost as much of a
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me
 wonder - If Java has gotten so fast as many people claim, why is Eclipse
 still such a sluggish POS?).

 Compare C# to D though and most of the coolness fades, even though there are
 still a handful of things I think D could still learn from C# (but there's
 probably more than a handful that C# could learn from D).


 that's still quite useful. And autoboxing is convenient, though not
 appropriate for D.


 generics seem like just a lame excuse for templates.


 project and it references a user library that has errors, when you click
 on the console to jump to the error, it doesn't work". I said to him: I
 never thought a user library could have errors! How did this happen to
 you? He replied: "I found a bug in a template in Tango".
 That's why generics doesn't suck: if there's something wrong in them,
 the compiler tells you in compile-time. In D, you get the errors only
 when instantiating that template.
 Generics might not be as powerful as templates, but once you write one
 that compiles, you know you will always be able to instantiate it.


 Yes, but there are two flaws in this argument:
 
 1.  If you are only using templates like generics, you simply use a unit test
to
 see if it compiles.  If you're not doing anything fancy and it compiles for
one or
 two types, it will probably compile for everything that you would reasonably
 expect it to.


I used tango.text.xml.Document with wchar and dchar as the template type 
and in tango.text.xml.PullParser there were some functions that took 
char[] instead of T[] as the argument. 
http://www.dsource.org/projects/tango/ticket/1663

 2.  If you're doing something fancier, like metaprogramming, you have to just
face
 the fact that this is non-trivial, and couldn't be done with generics anyhow.
 
 3.  As Bearophile alluded to, templates are really a clever hack to give you
the
 flexibility of a dynamic language with the performance and compile time
checking
 of a static language.  This is done by moving the dynamism to instantiation
time.
  Therefore, whereas in a dynamic language you pay at runtime in terms of the
"here
 be monsters, this code may not be being used as the author intended and tested
 it", with templates you pay at instantiation time.  However, IMHO this is
orders
 of magnitude better than not having that flexibility at all.  I personally
can't
 figure out how people accomplish anything in static languages w/o templates. 
It's
 just too inflexible.

May 20 2009

Christopher Wright <dhasenan gmail.com> writes:

dsimcha wrote:
 == Quote from Christopher Wright (dhasenan gmail.com)'s article
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:gus0lu$1smj$2 digitalmars.com...

 I've repeatedly failed to figure out the coolness of C#, and would
 appreciate a few pointers. Or references. Or delegates :o).


 are people who are unaware of D and are coming to C# from Java. What's
 "cool" about C# is that it's like a less-shitty version of Java (and *had*
 good tools, although the newer versions of VS are almost as much of a
 bloated unresponsive mess as Eclipse - Which come to think of it, makes me
 wonder - If Java has gotten so fast as many people claim, why is Eclipse
 still such a sluggish POS?).

 Compare C# to D though and most of the coolness fades, even though there are
 still a handful of things I think D could still learn from C# (but there's
 probably more than a handful that C# could learn from D).


 that's still quite useful. And autoboxing is convenient, though not
 appropriate for D.


 What the heck do you need generics for when you have real templates?  To me,
 generics seem like just a lame excuse for templates.


Put a template in an interface.

Use reflection to instantiate a template.

May 20 2009

"Nick Sabalausky" <a a.a> writes:

"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.ut4vynx5eav7ka steves.networkengines.com...
 The docs are reasonable once you figure out how  they are laid out.


I find the docs to be so slow as to be almost unusable. F*(*^*&%*& AJAX.

May 19 2009

Lutger <lutger.blijdestijn gmail.com> writes:

Andrei Alexandrescu wrote:

...
 I've repeatedly failed to figure out the coolness of C#, and would 
 appreciate a few pointers. Or references. Or delegates :o).



It's not in the language. 

C# only has to do 'better' than C++ and Java to be cool and in that it
succeeds: Besides many smaller improvements, it provides delegates / events,
lambda's and true generics compared to java. Compared to 
C++ it provides, well, lots of the same stuff that make people prefer Java over
C++. 
It does this while still being familiar. Take F# for example, probably a much
cooler language: I suspect this is too alien for most people.

The real attraction of C# is the framework and the IDE. A lot of programmers
don't program in a language, but in an ecosystem where the language is just a
part of it alongside the framework, toolchain and 
documentation.

May 19 2009

Bill Baxter <wbaxter gmail.com> writes:

On Wed, May 20, 2009 at 1:09 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 Yigal Chripun wrote:
 I think you miss the point here.
 Generics and code generation are two separate and orthogonal features that
 where conflated together by C++.


 It's kind of odd, then, that for example the Generative Programming book
 (http://www.generative-programming.org) chose to treat the two notions in
 conjunction.


Yeh, there's definitely a overlap.  Orthogonal isn't quite the right word there.

I'm reading a bit on C++/CLI right now, which is C++ extended to
inter-operate with CLR.
C++/CLI has *both* classic C++ templates and CLR generics:

  template<typename T> ...    // all code specializations generated at
compile-time (if at all)
  generic<typename T> ... // code generated at compiletime
unconditionally, specialized at run-time.

I'm not clear on exactly what happens at runtime in the generic<>
case.  I had been thinking it was simply that the compiler does some
type checking at compile time and the VM code then just manipulates
pointers to Object from there.  That may be what happens in Java
generics, but in CLR generics at least you can specialize on
non-Object value types and that apparently does not result in
everything getting boxed.  So it seems like there's a little something
extra going on.

I think the main reason for having Generics is that they're the best
anyone currently knows how to do at the IL bytecode level.  Generics
give you a way to define generic parameterized types that work across
all the languages that target a given VM's bytecode.  But that doesn't
preclude any language that targets that VM from *also* implementing
compile-time templates, or code generators, or AST macros at the
source code level.

But the problem with source-level code generation is that you then
need the source code in order to use the library.  I think they were
trying to avoid that with C#.   If you have a compiled C# assembly,
then you have everything you need to use it.   Period.   (I think.)
At any rate, a tech that requires inclusion of source code is not very
interesting to Microsoft, because Microsoft doesn't generally like to
let people see their source code in the first place, and they know
that many of their biggest customers don't like to either.  They're
nervous enough about just putting de-compileable bytecode out there.

--bb

May 20 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 18 May 2009 12:00:02 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 I've repeatedly failed to figure out the coolness of C#, and would  
 appreciate a few pointers. Or references. Or delegates :o).


The IDE is excellent.  The docs are reasonable once you figure out how  
they are laid out.

But basically, C# is a language invented to support .NET.  Try programming  
in any other .NET language and you find weird quirks and shoehorning (even  
in VB.Net).  C# is MS' language, so they build in all the things that make  
sense to support .NET.

two killer features for me: 1. .NET is usually installed or easily  
installed on any MS system.  2. the reflection/attributes are awesome.

That being said, I prefer the syntax of D to C#, there are definitely some  
warts.  Generics are next to useless, especially when compared to D  
templates.

-Steve

May 18 2009

Bill Baxter <wbaxter gmail.com> writes:

On Mon, May 18, 2009 at 12:09 PM, Robert Fraser
<fraserofthenight gmail.com> wrote:
 Steven Schveighoffer wrote:
 The IDE is excellent. =A0The docs are reasonable once you figure out how
 they are laid out.


 I really don't get what's so great about VS. After using JDT (Eclipse Jav=


 I find Vs kind of lacking. IMO, MS invests a lot of resources in areas to
 sell VS to companies rather than programmers. Automatic checking against =


 models... okay, that's a cool feature, but I'd rather it could highlight =


 semantic errors without my having to click "build" or have more than 5
 refactorings or have quick-fixes for errors, or...


It's a lot nicer with Visual Assist or (from what I hear) Resharper.
But it is sad that you have to pay even more money to make the thing
you paid so much money for in the first place more usable.
Considering things like Eclipse are free.

--bb

May 18 2009

BCS <ao pathlink.com> writes:

Reply to Bill,

 But it is sad that you have to pay even
 more money to make the thing you paid so much money for in the first
 place more usable.


VS/MS/etc is a for profit ecosystem. They assume that your system and software 
is paid for by your boss and he's spending 10-20 time that much on your
paycheck 
so who cares. At least that's the impression I get.

May 18 2009

grauzone <none example.net> writes:

 and the .net cil is a genious idea. The most succefull compilers are the 
 ones that recognize that there is multiple languages, multiple 
 archictectures and that there should be something in the middle. CIL 
 just leaves it in the middle code until the last minute. MS may not do 
 the best operating systems but the whole .net thing is very good in my 


And what exactly is good about byte code?

It's portable? My D code is portable too. Sure, it requires 
recompilation, but it doesn't need a clusterfuck-VM just for running it.

 opinion and I think sun is better for there solaris than there java.


.Net is just Microsoft's Java clone, and Sun didn't invent byte code either.

May 19 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

grauzone wrote:
 and the .net cil is a genious idea. The most succefull compilers are
 the ones that recognize that there is multiple languages, multiple
 archictectures and that there should be something in the middle. CIL
 just leaves it in the middle code until the last minute. MS may not do
 the best operating systems but the whole .net thing is very good in my 


 And what exactly is good about byte code?
 
 It's portable? My D code is portable too. Sure, it requires
 recompilation, but it doesn't need a clusterfuck-VM just for running it.


There's a few points here:

1. Users don't like compiling software.  Hell, *I* don't like having to
compile software since it invariably doesn't work first go, even when
the build instructions are correct (they often aren't.)

2. A very large number of Windows developers write closed-source
software.  The idea of having customers obtain and compile their
software scares the pants off of them.  If it didn't, they wouldn't
invest so much money in obfuscators.

I hate to be the one to tell you this, but... MS didn't design .NET to
make you happy.  *ducks*

  -- Daniel

May 19 2009

"Tim Matthews" <tim.matthews7 gmail.com> writes:

On Tue, 19 May 2009 08:56:59 +1200, BCS <ao pathlink.com> wrote:

 VS/MS/etc is a for profit ecosystem. They assume that your system and  
 software is paid for by your boss and he's spending 10-20 time that much  
 on your paycheck so who cares. At least that's the impression I get.


I think vs express editions that can be used to make great software, sell  
the software and not pay MS a single cent is very generous of them and the  
.net cil is a genious idea. The most succefull compilers are the ones that  
recognize that there is multiple languages, multiple archictectures and  
that there should be something in the middle. CIL just leaves it in the  
middle code until the last minute. MS may not do the best operating  
systems but the whole .net thing is very good in my opinion and I think  
sun is better for there solaris than there java.

May 19 2009

"Tim Matthews" <tim.matthews7 gmail.com> writes:

On Wed, 20 May 2009 15:08:43 +1200, Daniel Keep  
<daniel.keep.lists gmail.com> wrote:

 I hate to be the one to tell you this, but... MS didn't design .NET to
 make you happy.  *ducks*

   -- Daniel


Windos is a very user orientated os and to make the user happy they try to  
get all devs writing code that will work on windows easily. Also IIRC java  
bytecode is interpreted by default but .net is jit/aot which is how my cpu  
should be used. I think .net is only interpreted on the .net micro  
framework

May 19 2009

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Wed, May 20, 2009 at 12:26 AM, Tim Matthews <tim.matthews7 gmail.com> wr=
ote:
 On Wed, 20 May 2009 15:08:43 +1200, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:

 I hate to be the one to tell you this, but... MS didn't design .NET to
 make you happy. =A0*ducks*

 =A0-- Daniel


 Windos is a very user orientated os and to make the user happy they try t=


 get all devs writing code that will work on windows easily. Also IIRC jav=


 bytecode is interpreted by default but .net is jit/aot which is how my cp=


 should be used. I think .net is only interpreted on the .net micro framew=




Just, uh, wow.  Please dude, read up on this stuff first.

May 19 2009

"Tim Matthews" <tim.matthews7 gmail.com> writes:

On Wed, 20 May 2009 17:31:14 +1200, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 Just, uh, wow.  Please dude, read up on this stuff first.



This thread turned into a java vs .net argument. I'm sorry but I don't  
know the details of the JVM's just in time compiler. The virtual machine  
in the name plus the design goals led me to this misunderstanding "It  
should be interpreted, threaded, and dynamic"

http://en.wikipedia.org/wiki/Java_(programming_language)#Primary_goals

http://en.wikipedia.org/wiki/Comparison_of_the_Java_and_.NET_platforms

May 20 2009

Christopher Wright <dhasenan gmail.com> writes:

davidl wrote:
  From a commercial basis for Walter, it may be easier to glue a C# 
 frontend against the DMD backend to create a native C# compiler.


Mono has AOT compilation. On the other hand, I've experienced more ICE 
per minute with Mono than with dmd. This is partially due to dmd's near 
monoculture and .NET's huge majority market share -- people code around 
dmdfe bugs, but not around Mono bugs.

May 18 2009

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Wed, 20 May 2009 23:40:54 -0400, Nick Sabalausky <a a.a> wrote:

 "Christopher Wright" <dhasenan gmail.com> wrote in message
 news:gv29vn$7a0$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Christopher Wright" <dhasenan gmail.com> wrote in message
 news:gv0p4e$uvv$1 digitalmars.com...
 Nick Sabalausky wrote:
 I can see certain potential benefits to the general way C# does
 generics, but until the old (and I do mean old) issue of "There's an
 IComparable, so why the hell won't MS give us an IArithmetic so we  
 can
 actually use arithmetic operators on generic code?" gets fixed (and  
 at
 this point I'm convinced they've never had any intent of ever fixing
 that), I don't care how valid the reasoning behind C#'s general
 approach to generics is, the actual state of C#'s generics still  
 falls
 squarely into the categories of "crap" and "almost useless".


 methods, and interfaces cannot specify static methods.


 Then how does IComparable work?


 It uses a member function instead.


 And they can't do the same for arithmetic?


Keep in mind that the member method does not map to an operator.

So you still have to call it directly:

object.compareTo(object2);

-Steve

May 21 2009

D Programming

C/C++ Programming

Other

digitalmars.D - Re: OT: on IDEs and code writing on steroids