Julio César Carrascal Urquijo wrote:
> C# things that don't have an equivalent in D.
> * 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 port-based concurrency library for C# 2.0 developed by George 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



> D things that don't have an equivalent in C#.
> * Tupples.


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

marcio

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.
>  > The other proposal is more like Java/Python/C#'s way, where the
>  > 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.

From what was discussed, I don't think something like C#'s IEnumerable interface would be needed. Generic UDT templates could be built with something like C#'s GetEnumerator, 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.

On Fri, 24 Nov 2006 07:42:30 -0800, Marcio <mqmnews123@sglebs.com> wrote:

> Julio César Carrascal Urquijo wrote:
>> C# things that don't have an equivalent in D.
>> * 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 port-based concurrency library for C# 2.0 developed by George 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
>
>
>
>> D things that don't have an equivalent in C#.
>> * 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

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.

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.

Frank Benoit (keinfarbton) wrote:
> Thanks for spending the time to write these things down.
> It really helps me.

Your welcome.

Marcio wrote:
> Julio César Carrascal Urquijo wrote:
>> C# things that don't have an equivalent in D.
>> * yield operator
> 
> 
>     I'd like to point out that the Concurrency and Coordination Runtime (CCR) makes heavy use of yield.

Didn't know that. Thanks for the info. The yield operator in C# it's 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.

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

Frank Benoit (keinfarbton) wrote:
> Antonio,
> the points you listed are very good. Well "good" because I know nothing
> about C#, and this is also true for the things around C# and Dot NET.
> 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:

It's an error to take C# in an isolated way:  if you do this, D is more featured language compiler.  C# must be analyzed as part of .Net platform (Virtual Machine, Framework, Compiler), because c# was thought as the "way" programmers access to and extends framework.

C# is "interface" oriented because framework standarization: from this 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 best multipurpose "full-possibilities" compiler) and C# is only the .Net platform productive language:  You can't compare them, because they are not the same  (you can compare D, C and C++, you can compare C# and Java... but you CAN'T compare D with C# or Java... ).

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

Antonio,

Even at Microsoft, I would hazard the guess that different people implemented the .NET Framework classes than actually developed the CLR, or even VB.NET, C#, J#, etc.  Each probably even had its own project manager, but that's really a guess.

Microsoft has the resources to put into this, but D doesn't have it all yet.  If you are comparing infrastructures, D will not win against C#. 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.

Also, I disagree with your comments on C#; I don't believe it was designed as the way to access the framework.  In fact, I think .NET smells much stronger of Visual Basic .NET than of C#.  But that's really an opinion.

Further, C#'s syntax and features are actually represented in a standard 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 best multipurpose "full-possibilities" compiler) and C# is only the .Net platform productive language:  You can't compare them, because they are not the same  (you can compare D, C and C++, you can compare C# and Java... but you CAN'T compare D with C# or Java... ).
> 
> 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