www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D vs. C#

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
I want to write an article about D. Therefore I want to show more
Nov 23 2006
next sibling parent reply "Andrey Khropov" <andkhropov_nosp m_mtu-net.ru> writes:
Frank Benoit (keinfarbton) wrote:


 I want to write an article about D. Therefore I want to show more


 




(only type-parametrized classes and functions via generics) whereas you have
templates in D.

Plus DbC and built-in unit testing.


supported) and strong typedefs.

Anyway there's a comparison page http://www.digitalmars.com/d/comparison.html

-- 
AKhropov
Nov 23 2006
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Andrey Khropov schrieb:


 (only type-parametrized classes and functions via generics) whereas you have
 templates in D.
 
 Plus DbC and built-in unit testing.
 

 supported) and strong typedefs.
 
 Anyway there's a comparison page http://www.digitalmars.com/d/comparison.html
 


Thanks for your reply.
I am aware of the comparison table on digitalmars.com.

But I am very interested in more detailed points of view, because a
simple YES/NO is not really sufficient for an article.


experience and opinions. With these I can go to mr. google and do a more
specific and deeper investigation.

Your listed points are a good start for me, thanks again.
Nov 23 2006
prev sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Andrey Khropov wrote:

 Frank Benoit (keinfarbton) wrote:
 

 I want to write an article about D. Therefore I want to show more






 

 (only type-parametrized classes and functions via generics) whereas you have
 templates in D.
 
 Plus DbC and built-in unit testing.
 

 supported) and strong typedefs.
 
 Anyway there's a comparison page http://www.digitalmars.com/d/comparison.html
 




// Alias a namespace
using Utilities = System.Collections;

// Alias a class.
using List = System.Collections.ArrayList;

// Alias an instance of a generic class.
using IntegerList = System.Collections.Generic.List<int>;
Nov 23 2006
prev sibling next sibling parent reply antonio <antonio abrevia.net> writes:
Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more


 





framework
documentation
debugger
Microsoft Integrated Developement Environment (IDE :-) )

Very good "guides" for framework extensibility (ex: connection with a 
different SGBD are very standardized...you can find really good 
implementations of ado.net for PostgreSQL, Firebird.  D Database access 
is ridiculous... because D has not a proposal for standard database 
connectivity )


D:
*has not an standard framework (has not the "rules" for a standard 
framework extensibility)
*documentation:  if you are not talking about D compiler, you have not 
really "massive" framework/libraries/extensions to document... and the 
ones you have are poorly documented (forums are the main "documentation" 
repository)
*not native debugger.
*Poor IDEs(syntax highlight and so on... nothing really ).


D weakness... is just the things you need to be productive:  No one 
want's to work in a unique framework... in a unique "path"... in a 
required D-Fundation: D people is more worried about Linux vs Windows 
than D productivity.
Nov 23 2006
next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Antonio,
the points you listed are very good. Well "good" because I know nothing

First time I hear about those "rules".

What do you think if you put the focus on the languages itself? Ignoring
existing libs, IDEs ...
Nov 23 2006
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Frank Benoit (keinfarbton) escribió:

 Antonio,
 the points you listed are very good. Well "good" because I know nothing

 First time I hear about those "rules".
 
 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...


I think this days a language isn't just "the language", i.e.: the 
syntaxis and semantic.

Questions I want to ask to a language:
1. Does it have a great power of expresiveness?
2. Will I have to program all the *so common* classes like collections, 
io, network, etc., or instead of focusing on my problem I'll have to 
invent the wheel again?
3. Will I get my job done quickly?
4. Will my programs require some other annoying frameworks, virtual 
machines and on on the target machine?
5. Will my programs be fast?

My answers would be:

nowadays, and D dosen't have this (I don't know if this is possible for 
a compiled-to-native language).
2. Well, you'll surely find some good libraries out there. But 
integration with other systems that use some other libraries will be 
very painful. And choosing a library is also some time you'll loose. If 
interfaces (like the ones in java.util) are defined in D, together with 
a good core library, everything should be easier to do. But I think 
interfaces are not that efficient in D... am I wrong? And yes, you'll 
feel that poor performance in your 2Ghz double core processor.

powerful IDEs, and point 2 is also a thing to consider.
4. No, and it's one of the things I like most of D: a great power of 
expressiveness compiled to native binaries.
5. Yes, very fast, and that's another point for D.

But, as far as I know, speed is not (that much) a concern, and everybody 
has a virtual machine, so...
Nov 23 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Ary Manzana wrote:

 Frank Benoit (keinfarbton) escribió:

 Antonio,
 the points you listed are very good. Well "good" because I know nothing

 First time I hear about those "rules".

 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...


 
 I think this days a language isn't just "the language", i.e.: the 
 syntaxis and semantic.
 
 Questions I want to ask to a language:
 1. Does it have a great power of expresiveness?
 2. Will I have to program all the *so common* classes like collections, 
 io, network, etc., or instead of focusing on my problem I'll have to 
 invent the wheel again?
 3. Will I get my job done quickly?
 4. Will my programs require some other annoying frameworks, virtual 
 machines and on on the target machine?
 5. Will my programs be fast?


6. Will my programs be portable?


 
 My answers would be:

 nowadays, and D dosen't have this (I don't know if this is possible for 
 a compiled-to-native language).
 2. Well, you'll surely find some good libraries out there. But 
 integration with other systems that use some other libraries will be 
 very painful. And choosing a library is also some time you'll loose. If 
 interfaces (like the ones in java.util) are defined in D, together with 
 a good core library, everything should be easier to do. But I think 
 interfaces are not that efficient in D... am I wrong? And yes, you'll 
 feel that poor performance in your 2Ghz double core processor.

 powerful IDEs, and point 2 is also a thing to consider.
 4. No, and it's one of the things I like most of D: a great power of 
 expressiveness compiled to native binaries.



basically have to install the whole dang library collection on any 
machine that you intend to run your program on.  "Hey I've got this 
great little 10 line script"... kind of loses its cool factor when you 
have to install 50MB or more of other stuff just to use the script.


 5. Yes, very fast, and that's another point for D.
 
 But, as far as I know, speed is not (that much) a concern, and everybody 
 has a virtual machine, so...


6.  D code is fairly portable between Windows/Linux/Mac, so with care, 
and judicious selection of external libraries, a recompile for the 
target machine is all that is needed.   Java has an embedded version.  D 
lacks any sort of embedded strategy right now, AFAIK.  Though it should 
be great for embedded stuff.


--bb
Nov 23 2006
parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Bill Baxter wrote:
...

 
 
 6.  D code is fairly portable between Windows/Linux/Mac, so with care, 
 and judicious selection of external libraries, a recompile for the 
 target machine is all that is needed.   Java has an embedded version.  D 
 lacks any sort of embedded strategy right now, AFAIK.  Though it should 
 be great for embedded stuff.
 
 
 --bb


Yeah, the embedded support is kinda weak.  I made that linux -> 
arm-wince-pe cross compiler, which has quirks and is getting old :(

This would be much better if we could just have one person working on 
each of the platforms out there that need to be targetted.  I'm thinking 
arm-linux, arm-symbian (if possible), and arm-palmos (if we care). 
These should all be reachable through gdc.  Not sure what other embedded 
OSes are out there that are not too proprietary or hard to hit.  Anyhow, 
  I think good embedded support is doable, we just need a couple folks 
actually willing to do it.
Nov 23 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
Ary Manzana wrote:

 Frank Benoit (keinfarbton) escribió:

 Antonio,
 the points you listed are very good. Well "good" because I know nothing

 First time I hear about those "rules".

 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...


 
 I think this days a language isn't just "the language", i.e.: the 
 syntaxis and semantic.
 
 Questions I want to ask to a language:
 1. Does it have a great power of expresiveness?
 2. Will I have to program all the *so common* classes like collections, 
 io, network, etc., or instead of focusing on my problem I'll have to 
 invent the wheel again?
 3. Will I get my job done quickly?
 4. Will my programs require some other annoying frameworks, virtual 
 machines and on on the target machine?
 5. Will my programs be fast?
 
 My answers would be:

 nowadays, and D dosen't have this (I don't know if this is possible for 
 a compiled-to-native language).
 2. Well, you'll surely find some good libraries out there. But 
 integration with other systems that use some other libraries will be 
 very painful. And choosing a library is also some time you'll loose. If 
 interfaces (like the ones in java.util) are defined in D, together with 
 a good core library, everything should be easier to do. But I think 
 interfaces are not that efficient in D... am I wrong? And yes, you'll 
 feel that poor performance in your 2Ghz double core processor.


I don't think D interfaces would have any less performance potential than any
other language using 
interfaces (or even C++ MI)? The one big advantage for D is that the methods
would already be 
compiled, so when you 'traverse' an object hierarchy the JIT wouldn't need to
be (re)run for each 
method.



 powerful IDEs, and point 2 is also a thing to consider.
 4. No, and it's one of the things I like most of D: a great power of 
 expressiveness compiled to native binaries.
 5. Yes, very fast, and that's another point for D.
 
 But, as far as I know, speed is not (that much) a concern, and everybody 
 has a virtual machine, so...


I agree except for this last point - C and C++ are still so popular in large
part because of 

succeed.
Nov 23 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Dave wrote:

 I don't think D interfaces would have any less performance potential 
 than any other language using interfaces (or even C++ MI)?


Since D interfaces are implemented just like C++ MI, there is no 
performance difference between the two.
Nov 24 2006
parent reply Ary Manzana <ary esperanto.org.ar> writes:
Walter Bright escribió:

 Dave wrote:

 I don't think D interfaces would have any less performance potential 
 than any other language using interfaces (or even C++ MI)?


 
 Since D interfaces are implemented just like C++ MI, there is no 
 performance difference between the two.


I wrote that because of the recent discusion about iterators. I copy and 
paste:

Bill Baxter said:

 That's like C++'s way.  Iterator is basically a generalized pointer.

 iterator  is like a pointer that knows it's own limits.


Walter Bright said:

 I think the C++ like way will be a lot more efficient, and I think it
 will work.


So now I wonder what "a lot more efficient" means.

Some people (like me) think it's very hard to understand C++ iterator 
semantic, and it's also harder to implement your own iterator.  And if 
doing it that way dosen't improve your performance, then you are loosing 
easy development against a little better performance (which you can 
always have by not using iterators at all).
Nov 24 2006
parent Dave <Dave_member pathlink.com> writes:
Ary Manzana wrote:

 Walter Bright escribió:

 Dave wrote:

 I don't think D interfaces would have any less performance potential 
 than any other language using interfaces (or even C++ MI)?


 Since D interfaces are implemented just like C++ MI, there is no 
 performance difference between the two.


 
 I wrote that because of the recent discusion about iterators. I copy and 
 paste:
 
 Bill Baxter said:
  > That's like C++'s way.  Iterator is basically a generalized pointer.

  > iterator  is like a pointer that knows it's own limits.
 
 Walter Bright said:
  > I think the C++ like way will be a lot more efficient, and I think it
  > will work.
 
 So now I wonder what "a lot more efficient" means.
 
 Some people (like me) think it's very hard to understand C++ iterator 
 semantic, and it's also harder to implement your own iterator.  And if 
 doing it that way dosen't improve your performance, then you are loosing 
 easy development against a little better performance (which you can 
 always have by not using iterators at all).


Ah, I think I see your concerns with interfaces and iterators.


interface would be needed. 

MoveNext, Reset and 
Current w/o using IEnumerable (these would be 'built-in'). Then they could be
used via the standard 
foreach syntax with implicit type inference, and avoid the overhead of the
interface.

I think what Walter has in mind would be the best of both worlds really.
Nov 24 2006
prev sibling parent Serg Kovrov <kovrov no.spam> writes:
Hi Ary Manzana, you wrote:

 I think this days a language isn't just "the language", i.e.: the 
 syntaxis and semantic.
 
 Questions I want to ask to a language:
 1. Does it have a great power of expresiveness?
 2. Will I have to program all the *so common* classes like collections, 
 io, network, etc., or instead of focusing on my problem I'll have to 
 invent the wheel again?
 3. Will I get my job done quickly?
 4. Will my programs require some other annoying frameworks, virtual 
 machines and on on the target machine?
 5. Will my programs be fast?


Excellent points, Ary. I would also add:

6. Will my program use memory efficiently?

-- 
serg.
Nov 24 2006
prev sibling parent reply antonio <antonio abrevia.net> writes:
Frank Benoit (keinfarbton) wrote:

 Antonio,
 the points you listed are very good. Well "good" because I know nothing

 First time I hear about those "rules".
 
 What do you think if you put the focus on the languages itself? Ignoring
 existing libs, IDEs ...
 
 
 


In the posts exposed in last 3 days, you can see a lot of comparisons 
and opinions.

Here you are my basic opinion:




as the "way" programmers access to and extends framework.


point of view, there is a lot of functionalities proposed in D that are 
not really utile:  Microsoft was to try how to... and Java gived him the 
way.

Of course, some people disagree some interfaces proposals, but it's the 
cost of productivity.


My conclusion:

D is not "productivity" oriented (Walter and D people wants to have the 

platform productive language:  You can't compare them, because they are 



My error:

I lived in a mistake the last 3 years:  I spected D people to 
work/produce a complete platform (because the fashioned way:  .Net, 
Mono, wxWindows, PHP,...).

My error was a simple confusion:  D is a language, not a platform.

D community never will implement this "platform/framework" because they 
are interested in a practical exploration of possibilities not really in 
a serious productive alternative... this is work for other people... D 
is only the tool.

See you
Antonio
Nov 25 2006
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Antonio,

Even at Microsoft, I would hazard the guess that different people 
implemented the .NET Framework classes than actually developed the CLR, 

manager, but that's really a guess.

Microsoft has the resources to put into this, but D doesn't have it all 

It is true that it is not ready for that fight yet.

That said, comparing it to C/C++ is a much easier win for much the same 
reasons.

Some programmers do not need the full class library written for them, 
though.  If I need to parse xml, I'll either use a C library or write my 
own (which I have done.)  You're very correct that D is not a RAD 
language, and I don't think it's intended to be one.

Over time, different class or library frameworks will emerge for D, and 
one will become popular.  Since this has not yet happened, most people 
are not interested in the obvious comparison you've made - rather, in 
the comparison for the future.

To say that my pile of $1,000,000 in cash is better than your $600,000 
in investment - right now - is easy.  But it's much more interesting to 
know if the investment will be worth more in ten years or not.  I think 
that is the question being asked.

Just my opinion.


designed as the way to access the framework.  In fact, I think .NET 

an opinion.


which would theoretically be framework agnostic, much like JavaScript. 
AFAIK.

-[Unknown]



 My conclusion:
 
 D is not "productivity" oriented (Walter and D people wants to have the 

 platform productive language:  You can't compare them, because they are 


 
 My error:
 
 I lived in a mistake the last 3 years:  I spected D people to 
 work/produce a complete platform (because the fashioned way:  .Net, 
 Mono, wxWindows, PHP,...).
 
 My error was a simple confusion:  D is a language, not a platform.
 
 D community never will implement this "platform/framework" because they 
 are interested in a practical exploration of possibilities not really in 
 a serious productive alternative... this is work for other people... D 
 is only the tool.
 
 See you
 Antonio
Nov 25 2006
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Unknown W. Brackets wrote:



 designed as the way to access the framework.  In fact, I think .NET 

 an opinion.


And the smell of "NotJava .NET" is pretty strong too.

--bb
Nov 25 2006
parent reply Dave <Dave_member pathlink.com> writes:
Bill Baxter wrote:

 Unknown W. Brackets wrote:
 


 designed as the way to access the framework.  In fact, I think .NET 

 really an opinion.


 
 And the smell of "NotJava .NET" is pretty strong too.
 
 --bb


Funny thing is, I think that most of the runtime and big chunks of the .NET
library can trace their 
roots back to MS Visual J++ <g>

Was .NET announced before or after Sun won the judgement? (I can't remember).
It may turn out that 
MS lost the battle but won the war on that one, if losing Java was the impetus
for .NET anyhow.
Nov 25 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Dave wrote:

 Bill Baxter wrote:

 Unknown W. Brackets wrote:



 designed as the way to access the framework.  In fact, I think .NET 

 really an opinion.


 And the smell of "NotJava .NET" is pretty strong too.

 --bb


 
 Funny thing is, I think that most of the runtime and big chunks of the 
 .NET library can trace their roots back to MS Visual J++ <g>
 
 Was .NET announced before or after Sun won the judgement? (I can't 
 remember). It may turn out that MS lost the battle but won the war on 
 that one, if losing Java was the impetus for .NET anyhow.


It was definitely round about the same time Sun was suing them over 
their non-standard extensions to Java.  I think folks at Microsoft liked 
Java the language, but if Sun wasn't going to let them add COM 
extensions and win32 APIs and such, then it was never going to be a 
viable replacement for VB.  So they did what they had to do in my view. 

the Microsoft Kool-aid.

--bb
Nov 26 2006
parent "JohnC" <johnch_atms hotmail.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:ekd9kg$1e89$1 digitaldaemon.com...

 Dave wrote:

 Bill Baxter wrote:

 Unknown W. Brackets wrote:



 designed as the way to access the framework.  In fact, I think .NET 

 really an opinion.


 And the smell of "NotJava .NET" is pretty strong too.

 --bb


 Funny thing is, I think that most of the runtime and big chunks of the 
 .NET library can trace their roots back to MS Visual J++ <g>

 Was .NET announced before or after Sun won the judgement? (I can't 
 remember). It may turn out that MS lost the battle but won the war on 
 that one, if losing Java was the impetus for .NET anyhow.


 It was definitely round about the same time Sun was suing them over their 
 non-standard extensions to Java.  I think folks at Microsoft liked Java 
 the language, but if Sun wasn't going to let them add COM extensions and 
 win32 APIs and such, then it was never going to be a viable replacement 

 pretty sweet thing for anyone willing to swallow the Microsoft Kool-aid.

 --bb


Almost right. It was really the virtual machine that Microsoft was 
interested in. The JVM team felt increasingly stifled by Sun, and wanted to 
take the VM places it couldn't go (whether for legal or other reasons). 
Ambitions for multiple-language support, plus deeper interoperation with COM 
and native code, motivated them to join forces with the existing COM team.

COM 2.0 was born ... but it was a brief marriage. Apparently they fell out 
over how they should implement memory management. One half wanted to 
continue with explicit management (reference counting via AddRef/Release) 
while the other was interested in garbage collection. So they parted 
company. Soon, the GC guys gave birth to the CLR (acquiring a company who'd 
developed a research VM along the way).

Meanwhile, the C++ team was investigating meta data. With the new CLR team, 
they developed Microsoft Intermediate Language, and soon had a prototype GC 

nineties as the weird offspring of C++ and IDL. It was codenamed "Cool" 
(C-based Object Oriented Language).


the first public release followed in 2002.

Now, where'd I put that bottle of Kool Aid?
Nov 26 2006
prev sibling parent Antonio <antonio abrevia.net> writes:
Unknown W. Brackets escribió:

 Antonio,
 
 Even at Microsoft, I would hazard the guess that different people 
 implemented the .NET Framework classes than actually developed the CLR, 

 manager, but that's really a guess.
 
 Microsoft has the resources to put into this, but D doesn't have it all 

 It is true that it is not ready for that fight yet.


No, obiouslly I'm not comparing them.
Otherwise, people is producing heterogeneous small solutions:  Some
"guided" work (a "unique" guided work) must be interesting in a common
library production.


 
 That said, comparing it to C/C++ is a much easier win for much the same 
 reasons.
 
 Some programmers do not need the full class library written for them, 
 though.  If I need to parse xml, I'll either use a C library or write my 
 own (which I have done.)  You're very correct that D is not a RAD 
 language, and I don't think it's intended to be one.
 


I agree... but I don't need a RAD, I need "hight abstraction" (unified 
vision of the system resources): D is promissing a lot... really 
promissing good levels of abstraction without performance losting. I 




 Over time, different class or library frameworks will emerge for D, and 
 one will become popular.  Since this has not yet happened, most people 
 are not interested in the obvious comparison you've made - rather, in 
 the comparison for the future.
 


Actually I use Mango and PostgreSQL acces for a "small" solutions
(server side)... Mango support for servlets is really a pleasure... this 
is my example about standards... why not to grow to other "server side" 
common resources (i.e. Data Base access,...)



 
 Just my opinion.
 

 designed as the way to access the framework.  In fact, I think .NET 

 an opinion.
 

 which would theoretically be framework agnostic, much like JavaScript. 
 AFAIK.


I'ts true, but I allways use de same example: .Net/Java Virtual Machine 
is to Machine the same than Framework is to de Operative System.
¿Who wants to program without S.O. support?




 
 -[Unknown]
Nov 27 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
antonio wrote:


 D community never will implement this "platform/framework" because they
 are interested in a practical exploration of possibilities not really in
 a serious productive alternative... this is work for other people... D
 is only the tool.


That is certainly a wrong conclusion. There is just so much infrastructure
needed to build this framework, that it hasn't really been a viable
possibility until maybe about now. Heady progress could possibly have been
made, if the structure of the JDK or .Net had been more or less copied, but
I think most people understand that this would put D ahead in anyway, even
if the language itself was superior. D needs a framework that takes D and
it's strengths into account.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Nov 26 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
antonio wrote:

 Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more




 examples?


 

 
 framework
 documentation
 debugger
 Microsoft Integrated Developement Environment (IDE :-) )
 
 Very good "guides" for framework extensibility (ex: connection with a 
 different SGBD are very standardized...you can find really good 
 implementations of ado.net for PostgreSQL, Firebird.  D Database access 
 is ridiculous... because D has not a proposal for standard database 
 connectivity )
 



can't (well, it could, 
but with poor performance (interop), which would defeat the purpose).


 
 D:
 *has not an standard framework (has not the "rules" for a standard 
 framework extensibility)
 *documentation:  if you are not talking about D compiler, you have not 
 really "massive" framework/libraries/extensions to document... and the 
 ones you have are poorly documented (forums are the main "documentation" 
 repository)
 *not native debugger.
 *Poor IDEs(syntax highlight and so on... nothing really ).
 
 
 D weakness... is just the things you need to be productive:  No one 
 want's to work in a unique framework... in a unique "path"... in a 
 required D-Fundation: D people is more worried about Linux vs Windows 
 than D productivity.
 


Right, but libraries aside, I think one could be as productive with D as almost
any other language 
on Linux where it's pretty common (and often as productive) to just use a good
editor as your 'IDE'.

D will probably take hold on Linux faster than in the Windows world for a
myriad or reasons anyhow.
Nov 23 2006
parent Antonio <antonio abrevia.net> writes:
Dave escribió:

 antonio wrote:

 Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more




 examples?




 framework
 documentation
 debugger
 Microsoft Integrated Developement Environment (IDE :-) )

 Very good "guides" for framework extensibility (ex: connection with a 
 different SGBD are very standardized...you can find really good 
 implementations of ado.net for PostgreSQL, Firebird.  D Database 
 access is ridiculous... because D has not a proposal for standard 
 database connectivity )


 

 really can't (well, it could, but with poor performance (interop), which 
 would defeat the purpose).


Object Orientation give us the posibility of a great API:  "backwards" 
compatibility must not forece us to "think" on C APIS... (imagine using 
8086 non protected model... i386 allows you to do it, but you can't 
imagine a good operative system without CPU memory protection support 
becaus he has to mantain "backward" compatibility with 8086 memory model).

The main thing here is "unified way to"... there is a lot of C libraries 
for data acces... The "lovely" way is to select only one standarization 
choice (Object Orientation, please):  escape of simple C libraries 
API... free your mind.

C Database libraries are the basis.  D OOFramework is the 
infraestructure "high" level programmers need.
Nov 24 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more


 



I honestly think you cannot write an objective comparison if you don't 


I just wanna comment on what Andrey wrote as well:

Andrey Khropov wrote:

 Frank Benoit (keinfarbton) wrote:
 I think the biggest thing is that you have no metaprogramming support 




 (only type-parametrized classes and functions via generics) whereas 


you have

 templates in D.

 Plus DbC and built-in unit testing.


 supported) and strong typedefs.


Well, so what? Just because it doesn't have meta programming doesn't 

I mean, you can't put that kind of thing in an article and hope that it 
will attract programmers to D.
One might even argue that having a unittest framework is better than a 
built-in unittest construct.
Same applies for aliases and string typedefs.
Nov 23 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more


 



I'm just going to compare languages because a comparison between .NET's 
Base Class Library and Phobos isn't fair anyway. This isn't an 
exhaustive list, is just what I remembered at the moment.




parameter you can only call methods defined on Object unless you tell 
the compiler that it will be of a predefined (base) class witch pretty 
much defeats the purpose of a generic class in most cases.

This limitation makes generics useful mostly for container types and 
impedes advanced meta-programming like what's available on D.


for methods with certain signatures to implement properties. Some people 
prefer one style over the other but the result is pretty much the same.


can be handy, for example, for a code generator to safely modify a file 
while the user modifies another for the same class. D doesn't has any 
way of doing this.


module that implements Signals & Slots witch is a similar concept but 



as real closures so you can return them from a function. I use these a 
lot, they cut down work every where. In D returning a delegate or using 
it after the function ended is undefined and probably will get you an 
Access Violation.

D has lazy parameter evaluation where one or more parameters of a 
function aren't evaluated until they are needed. Very useful feature and 



* Syntax for nullable types.
* Operator ?? for null testing.
* yield operator


* Tupples.
* Unions.
* Mixins.
* DBC.
* Inline Assembler.




1.0 version for January 1 of 2007.


So, if you want the String class to have a method that converts to camel 
convention you can add it and call it like s1.ToCamelCase(). D supports 
something like extension methods but only for arrays of any type, just 
declare a function with a parameter of the type you want to extend.


is a little better.


syntax tree of any code block you declare as a query expression and pass 
it around to methods, serialize it or compile and execute it. If you've 
programmed in Lisp, you'll recognize this. In D... Not yet but we are 
getting there with Tupples. Je je.

Language integrated query (LINQ) witch more or less is SQL integrated in 

to the features described before. Cool stuff. Nothing like this in D has 
been discussed.


beats C#s a** on this.

Hope this helps.

--
Julio César Carrascal Urquijo
Nov 23 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Julio César Carrascal Urquijo wrote:

 


<snip>

 

 can be handy, for example, for a code generator to safely modify a file 
 while the user modifies another for the same class. D doesn't has any 
 way of doing this.
 


Actually, I think you can achieve the same effect in D using mixins.

--------------
template CodeGenerator_Class_Part()
{
     //declarations ...
}
--------------
template Class_Coder_Part()
{
     //declarations
}
--------------
class Class
{
     mixin CodeFenerator_Class_Part!();
     mixin Class_Coder_Part!();
}
--------------

I think each of these can be in a separate file.
Nov 23 2006
parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Hasan Aljudy wrote:

 Actually, I think you can achieve the same effect in D using mixins.
 
 --------------
 template CodeGenerator_Class_Part()
 {
     //declarations ...
 }
 --------------
 template Class_Coder_Part()
 {
     //declarations
 }
 --------------
 class Class
 {
     mixin CodeFenerator_Class_Part!();
     mixin Class_Coder_Part!();
 }
 --------------
 
 I think each of these can be in a separate file.


Not quite. Methods aren't imported from the mixin and don't participate 
in function overloading unless they are explicitly aliased, if I 
remember correctly.
Nov 24 2006
prev sibling next sibling parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Thanks for spending the time to write these things down.
It really helps me.
Nov 24 2006
parent =?UTF-8?B?SnVsaW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpv?= writes:
Frank Benoit (keinfarbton) wrote:

 Thanks for spending the time to write these things down.
 It really helps me.


Your welcome.
Nov 24 2006
prev sibling parent reply Marcio <mqmnews123 sglebs.com> writes:
Julio C=E9sar Carrascal Urquijo wrote:


 * yield operator



	I'd like to point out that the Concurrency and Coordination Runtime=20
(CCR) makes heavy use of yield.


"The Concurrency and Coordination Runtime (CCR) is a lightweight=20

Chrysanthakopoulos in the Advanced Strategies group at Microsoft. Here=20
http://channel9.msdn.com/ShowPost.aspx?PostID=3D143582 , we have a deep=20
discussion about CCR with George, a Software Architect, and Satnam=20
Singh, Architect. You can get more info about CCR on the CCR Wiki=20
http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime . =

This is super cool stuff and represents a really innovative approach to=20
making managed threaded programming more readily understandable and=20
predictable.

Please check out the OOPSLA/SCOOL paper on the CCR=20
http://research.microsoft.com/~tharris/scool/papers/sing.pdf .

Click here http://channel9.msdn.com/Showpost.aspx?postid=3D206574 to see =

how the CCR is being used by the Microsoft Robotics Group."

CCR Programming http://channel9.msdn.com/ShowPost.aspx?PostID=3D219308

     * article:=20
http://msdn.microsoft.com/msdnmag/issues/06/09/ConcurrentAffairs/default.=
aspx





 * Tupples.



	It would be nice if the article compared to Eiffel as well. Eiffel has=20
DbC, generics, Tuples, agents, etc.

marcio
Nov 24 2006
next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Fri, 24 Nov 2006 07:42:30 -0800, Marcio <mqmnews123 sglebs.com> wrote:


 Julio César Carrascal Urquijo wrote:


 * yield operator



 	I'd like to point out that the Concurrency and Coordination Runtime  
 (CCR) makes heavy use of yield.


 "The Concurrency and Coordination Runtime (CCR) is a lightweight  

 Chrysanthakopoulos in the Advanced Strategies group at Microsoft. Here  
 http://channel9.msdn.com/ShowPost.aspx?PostID=143582 , we have a deep  
 discussion about CCR with George, a Software Architect, and Satnam  
 Singh, Architect. You can get more info about CCR on the CCR Wiki  
 http://channel9.msdn.com/wiki/default.aspx/Channel9.ConcurrencyRuntime .  
 This is super cool stuff and represents a really innovative approach to  
 making managed threaded programming more readily understandable and  
 predictable.

 Please check out the OOPSLA/SCOOL paper on the CCR  
 http://research.microsoft.com/~tharris/scool/papers/sing.pdf .

 Click here http://channel9.msdn.com/Showpost.aspx?postid=206574 to see  
 how the CCR is being used by the Microsoft Robotics Group."

 CCR Programming http://channel9.msdn.com/ShowPost.aspx?PostID=219308

      * article:  
 http://msdn.microsoft.com/msdnmag/issues/06/09/ConcurrentAffairs/default.aspx





 * Tupples.



 	It would be nice if the article compared to Eiffel as well. Eiffel has  
 DbC, generics, Tuples, agents, etc.

 marcio



Is this just me, or does this just look like CSP with a face-lift?  Even  
the name "CCR" seems designed to look like "CSP"

I wish MS would credit the orinigation of their work, rather than  
advertising the work as their own.  Furthermore, I think this has been  
discussed here several times before.

-JJR
Nov 24 2006
parent Marcio <mqmnews321 sglebs.com> writes:
John Reimer wrote:

 Is this just me, or does this just look like CSP with a face-lift?



    CSP as a library using yield to achieve continuation-passing style 
the easy way, plus extra features.


 I wish MS would credit the orinigation of their work, rather than 
 advertising the work as their own.  Furthermore, I think this has been 
 discussed here several times before.


	Well, Hoare now works for them anyway.

"He is now an Emeritus Professor there, and is also a senior researcher 
at Microsoft Research in Cambridge, England."

http://en.wikipedia.org/wiki/C._A._R._Hoare

http://research.microsoft.com/users/thoare/

marcio
Nov 25 2006
prev sibling parent reply =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
Marcio wrote:

 Julio César Carrascal Urquijo wrote:


 * yield operator


 
 
     I'd like to point out that the Concurrency and Coordination Runtime 
 (CCR) makes heavy use of yield.



another time-saver and I probably should have written more about it.

One of the coolest thing I wrote with yield was an encapsulation of 
several loops that iterated over the fields of an object using 
reflection. All of them needed some start, finish and filtering 
conditions but the code was very similar.

I started writing a class that implemented IEnumerator and splitting the 
loop to implement the interface was starting to get very hard. Then I 
remembered yield and the IEnumerable interface and everything got 
converted to a single method and a couple of properties. Something like:

class FieldInfoEnumerable
	: System.Collections.Generic.IEnumerable<FieldInfo>
{
	public IEnumerator<FieldInfo> GetEnumerator()
	{
		Type type = m_initialType;
		do
		{
			foreach (FieldInfo fi in type.GetFields(m_bindingFlags))
				yield return fi;
			type = type.BaseType;
		}
		while (type != m_finalType);
	}
}


The compiler made the hard work and converted the loop into a 
IEnumerator for me. I wish D had a yield operator. Maybe for D 2.0.

I'm reading the OOPSLA pdf and downloading the videos right now.

Thanks again.
Nov 24 2006
parent Daniel Keep <daniel.keep+lists gmail.com> writes:
Julio César Carrascal Urquijo wrote:

 ...  I wish D had a yield operator. Maybe for D 2.0.


Afraid I don't have the links on me, but Google for and look at 
StackThreads; specifically the coroutine module.  That lets you write 
coroutines that use a yield *function*.  D doesn't need yield to be an 
operator: we get by just fine writing it as a library.



	-- Daniel
Nov 26 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Frank Benoit (keinfarbton) wrote:

 I want to write an article about D. Therefore I want to show more


 



Take a look at this:

http://en.wikipedia.org/wiki/C_Sharp#C.23_3.0_new_language_features


(LINQ). Those would 
be good to point out.
Nov 23 2006
prev sibling parent Samuel MV <samuel jxdesigner.com> writes:
I've programmed a little bit in both, and from my very personal point of 
view ;-) ...


- Nice debugger
- Lots of libraries with tons of functionalities
- Lots of books, code and tutorials for learning


Better in D:
- Speed + Expresiveness
- No need to install 100 MB framework in every computer
- KISS: as I've said before I'm tired of spending my time searching in 
the standard library to find out how to use correctly a 
'AbstractWriterAbstractFactoryGeneratorAddAnotherLongNameHere' ;-)


About IDEs: I'll be happy with a version of the olde VMS ISPF editor 
with some Rexx macros :)
Nov 24 2006