.NET Version Poll

[Charles]

If you're on Microsoft .NET, Cobra requires version 2.0 and up. But how high of a minimum version number are you comfortable with? Please respond to the poll.

[gauthier]

I voted 3.5,

I'm using it since end of 2007 and haven't got any issue upgrading from 2.

that move/option would also pave the road to 2.5 (silverlight/moonlight + DLR integration)

any 2.0 voters to speak here?

[pchapin]

any 2.0 voters to speak her?

The higher you set the minimum, the more potential users you rule out. Increasing the minimum version is reasonable if everyone is using a higher version anyway or if there are compelling technical reasons for requiring a higher version. Of course I would hope that Cobra would work fine with the latest version of .NET as well, but all things being equal (if they are!) the lower the minimum required version, the better.

[gauthier]

I'm not for discarding effort to support 2.0, most frameworks still support (minus microsoft one it seems...), the language was presented almost 1 year ago when c# 3 was all fresh as combining features from c# as well.

multi-targeting runtime is a must-have and should be feasible since the lower runtime is 2.0 (nunit still has support for 1.0 bin) and the use of clr deps versioning.

the Silverlight core is also lighter than full fledged 2.0 runtime, it means it could be possible to use cobra to script the browser in web applications which will surely bring new people to the language

[Charles]

Btw the existing ticket for this is ticket:73

[jonathandavid]

I voted 3.5 because it adds some features that Cobra could possibly benefit from. From the Wikipedia article:

* Adds support for expression trees and lambda methods
* Extension methods
* Expression trees to represent high-level source code at runtime.[20]
* Anonymous types with static type inference
* Language Integrated Query (LINQ) along with its various providers


I don't know if these are fundamental changes on the framework, or simply syntactic enhancements to the C# language. But anyway they are relevant to Cobra as long as Cobra generates C# code instead of CIL.

One potential drawback of integrating these "advanced" 3.5 features into Cobra is that they might be difficult to implement in the Java/D backends, but I'm sure Chuck already has thought about a way to deal with this.

An extra reason for requiring 3.5 is that Cobra is still at an early stage. By the time it goes mainstream, 3.5 will be available to almost everybody, and 2.0 will sound plain ancient. Chuck: by this I don't mean to imply that it will take Cobra very long to become popular. Rather, what I mean is that things go very fast in the .NET world, with new versions coming out almost every year.

One drawback of requiring 3.5 is that some of the features might not be 100% supported under Mono, but I don't know about that (at least in their website they claim to support LINQ).

[Csaba]

Hi,
I voted .NET 2 since I have some large applications using VB 2005 and WinForms 2 in .NET 2. I do measurement and control programming with "simple" and straightforward interface showing measurement values and curves from instruments. I'm not interested in the "rich user experience" and similar BS for Web programming. I bought at book about .NET3.5, read it and I did NOT find a single reason to use .NET 3.5 instead of WinForms 2 in .NET 2! Yes, I read a lot about all new fancy stuff, but I'm not bright enough to understand how it simplifies the kind of programming I do!

Note, it is difference between class libraries, the language and CLR. It is possible to use C# 3 with lambda functions together with WinForms 2 in .NET 2!

Most of all I would like to have a programming language with true duck typing that would simplify my programming. Further, it should have first class functions and a .NET version (WinForms) that uses first class functions and not “events”. I hope DLR and future .NET will be major clean up and true improvement for all users!

For me it really doesn't matter if Cobra supports WinForms 2 or not since it is not likely I ever will rewrite the VB programs with WinForms 2 I'm supporting now.

Regards
Csaba

[Charles]

My decision is that Cobra will maintain support for .NET 2.0 and up. If there is a need to do so, we will produce .NET 3.5 and .NET 4.0 specific Cobra compilers in addition to the one that only requires .NET 2.0.

Some additional observations and musings if you are interested:

I know that a .NET 2.0 compiler can read libraries for .NET 3.0 which was just additional libraries. And it's clear to me that .NET 3.5 not only adds libraries, but also new compilers. What I don't know yet is if the virtual machine for .NET 3.5 is any different (other than optimizations). I used the C# 3 compiler from VS 2008 to compile "Hello, world" and when inspecting the resulting virtual machine, found that it depended on mscorlib 2.0.0.0 which was interesting.

Regarding getting LINQ and friends to run on the JVM platform, I think that is doable simply by following Microsoft's design and implementing it. With the exception that I haven't wrapped my head around the creation of delegate instances on the JVM. (Should you wish to discuss that, please break out a separate forum topic.)

[jonathandavid]

Regarding getting LINQ and friends to run on the JVM platform, I think that is doable simply by following Microsoft's design and implementing it.

There seems to be a "port" of LINQ of Java:

http://quaere.codehaus.org/

Of course it is a modified version of LINQ adapted to the syntax of Java. For example:

Iterable<Integer> lowNumbers=
        from("n").in(numbers).
        where(lt("n",5).
        select("n");

Maybe Cobra's JVM backed could take "pure" LINQ and translate it to Quaere's Java code. Under this approach, the code above would be generated by the Cobra compiler when the user writes "from n in numbers where n > 5 select n".

My main concern is having to implement N versions of LINQ if there are N backends (other than .NET) to be supported. To avoid this problem, a thin backend-specific abstraction layer could be defined, and a pure Cobra LINQ implementation, built on top of that layer, would be shared among all backends. Sounds like a lot of coding fun!

As for simulating delegates in Java, there seems to be some work already done:

http://www.onjava.com/pub/a/onjava/2003 ... gates.html

The proposed solution is not statically typed, but that shouldn't be a problem since all the Java code will be generated by the Cobra compiler, which will make sure that the types match.

[Charles]

Cool. Thanks for the links. I've made a note of them and they will come in handy in the future.