C# vs D

[natter]

@chuck:
why didnt you chose D instead of C#?
wouldnt cobra->D be the better choice?
how much work will a cobra->D implementation be?
what are the steps to do?

i think cobra->D would be a good thing for both languages.


and what i dont understand:
member-vars in classes are like '_var'
member-methods are like '.method()'
why arent member-vars like '.var' ?
they could be declared as 'var' and accessed by '.var'
just as methods are declared as 'method' and accessed by '.method'

and is there a reason not to write 'class foo is partial' instead of using 2 lines?

[Charles]

These are good questions!

D was one of the languages I investigated in 2005 prior to my third and final attempt to create Cobra. You probably noticed it on the Acknowledgements page. Back then, I was actually looking for a language to use so that I didn't have to build a new one.

When I started on a new version of Cobra in Jan 2006, D had many admirable qualities. These included contracts, unit tests and good run-time performance. However, .NET was more mature with less bugs, a large user community, and plenty of third party libraries and tools.

Also, .NET has always had the explicit invitation for other languages to run on their platform. The fact that Microsoft itself put out C#, VB and more, meant that many tools and libraries did not assume a particular language.

However, while I believe that .NET was the right place to start, I think supporting other platforms will be necessary for Cobra to achieve popularity. Besides the obvious the benefit of expanding the potential user base, there is the added lure of giving developers a language they can "take with them" if they switch platforms.

So lately, I've been refactoring the compiler to pave the way for other backends. My next target is Java/JVM, but I'm not opposed to other backends. I think D and Objective-C, for example, would be viable targets. Potentially C and C++ as well, but those would involve a lot more work.

On the surface, the primary thing you would have to do is copy SharpGenerator.cobra to a DGenerator.cobra and get it working. But then there are questions about library differences between different platforms: .NET vs. JVM vs. D vs. Obj-C. Some of these we can subsume by generalizing aspects of the language, such as how to provide a custom hash code for your objects, etc. and how to represent a stream of objects (T*). These are high on my list of priorities and I'll be posting separately on the hash code thing later.

Regarding syntax, the goals are to embrace object-oriented programming--which includes encapsulation--and to provide a fairly uniform syntax between projects (more so than, say, C# or Java). The underscores are used to indicate visibility where "_foo" is protected and "__foo" is private. Conventionally, object variables are protected so that outside objects cannot tamper with an object's data. You can declare "var foo as type" if you like in which case you must access the variable as ".foo".

Note that parameters and local variables are barred from starting with an underscore. Also, it would not make sense to access a local via a period. So the result is that when you're reading code, you can instantly tell which identifiers are args/locals and which are not. Member access always starts with an underscore or period.

I also expect the underscore/period syntax to be quite beneficial when using an IDE with autocomplete as the list of choices can be pruned down to members only.

Regarding "class Foo is modifier", I agree the restriction of putting the "is" (as well as the "inherits") on a separate line should be relaxed. I just haven't gotten to it yet.

-Chuck