Anders Hejlsberg on C# 3.0

spongman writes "Channel9 has a video of Anders Hejlsberg demoing C# 3.0. The new language enhancements include implicitly typed locals, extension methods, strongly-typed lambda expressions, anonymous types, and LINQ - a builtin SQL-like syntax for data access. The spec, samples and a working compiler can be found on MSDN."

Comments

Looks more like Delphi every release

[dr3vil]

But then, Bill Gates himself said that the only thing wrong with Delphi was that it wasn't a Microsoft product.

Re:Looks more like Delphi every release

[ergo98]

But then, Bill Gates himself said that the only thing wrong with Delphi was that it wasn't a Microsoft product.

What are you talking about? I used Delphi for years, and then switched to .NET, and while Anders of course brought a lot of Delphi-ism to the .NET Framework and C#, these new C# 3.0 additions are nothing like Delphi, and C# 2.0 is already worlds beyond what Delphi ever achieved. LINQ, and DLINQ, are very exciting improvements in removing the disconnect between the database and the middle/front tier, and given the tremendous importance of that it will be remarkable.

The toughest thing about this sort of technology, though, is that it isn't complete and usable in real projects, so as developers we're uncertain how much time to waste playing with the demos and learning (how many developers must be pissed seeing the hype machine starting over C# 3.0, when they still don't even have the ability to use C# 2.0 in production - e.g. VS.NET 2005 is only at the RC stage). Unless you're a blogger or writer making money writing about how much it makes you wet your pants, there's just no practicality in it.

Re:Looks more like Delphi every release

[antoy]

Wow, Delphi had generics, extension methods and a query system?

I'm not trolling, but I had no idea. Can anyone verify this? I don't have any experience in Delphi and the Wikipedia entry is not much help.

In any case, I'm pretty excited about the new features, as they were the exact things that I often needed but did not have. And it's about time we got querying in-language (although anonymous methods can also do the job most of the time).

Re:Looks more like Delphi every release

[Haeleth]

Er, Delphi never supported type inference, closures, or metaprogramming of the sort that Microsoft are introducing to .NET in C# 3 and VB 9. These features are coming from the functional programming world, from languages like Lisp and ML.

For existing languages that offer similar features in a braces syntax, see Nemerle or Scala.

(Languages like Ruby offer related features, but their lack of static typing means they're more distant cousins.)

Re:Looks more like Delphi every release

[Decaff]

LINQ, and DLINQ, are very exciting improvements in removing the disconnect between the database and the middle/front tier, and given the tremendous importance of that it will be remarkable.

On the contrary, it is big step backwards. One area of intensive research in IT for years is setting up a portable high-performance disconnect between database and other tiers. For many applications the database is just a resource, and embedding query languages within code is a bad idea. If you look at transparent persistence systems like JDO and Hibernate, almost all of the data retrieval and processing can be done with no query language at all - optimised query languages tailored for specific databases can be generated in the background, and this querying can be very optimised indeed.

Embedded SQL in computer languages has been around for a very long time - take a look at SQL/J. There are more elegant ways to do things.

Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.

Re:Looks more like Delphi every release

[ergo98]

One area of intensive research in IT for years is setting up a portable high-performance disconnect between database and other tiers.

It is high-performance. Watch the demo - at one point Anders sets up a log, and you can see that the LINQ query was transformed into the appropriate, performant T-SQL which is passed to the RDBMS. It isn't doing the standard, shittacular "pull everything back in a terribly unscalable manner and then filter it in the middle tier", but rather appears to be analyzing the whole of the query and communicating it effectively to the source.

Embedded SQL in computer languages has been around for a very long time

It isn't embedded SQL. It's set operations that obviously share commonalities with SQL, but are largely different. Again, have you watched the video or read the spec? DLINQ, by the way, is the ORM system that makes the objectpersistence "transparent" (leaky abstraction, like all ORMs, but still).

Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.

I doubt it'll include support either, out of the box. Instead, like always, they've created a generalized data services layer that any provider can plug into - create a ADO.NET 3.0 data provider for MySQL, and your data service can be the target of LINQ operations.

Re:Looks more like Delphi every release

[Mr2001]

No, it didn't. These new additions to C# have nothing to do with Delphi, except that "var" is also a Delphi keyword.

Re:Looks more like Delphi every release

[bheer]

Er, it might help if you actually read the spec. This isn't 'embedded SQL' in the sense of Pro*C -- the 'queries' are really a bit of (helpful) syntactic sugar over an object-oriented, typesafe set of expressions (you'll see the lambda expressions, new to C#, used heavily here):

from c in customers
where c.City == "London"
select c.Name

turns into

customers.
Where(c => c.City == "London").
Select(c => c.Name)

Of course, if you don't like it you can always pass strings of SQL text to the data layer, or do everything with StoredProcs -- after all, DLINQ helpfully shields you from ADO.NET but nothing stops you from using ADO.NET either directly or through alternate layers like NHibernate.

This should also answer your point about optimised SQL generation ... the programmer does not type SQL into C#, SQL gen is still done in the background.

Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc.

They don't have to. Implementing DLINQ is really as simple as implmenting a pattern (which Helsberg called the 'query expression pattern') and adding your own DB-specific code.

Currently Oracle and DB/2 ship libs for ADO.NET, you can be quite sure they'll ship libs for DLINQ. If the MySQL and Postgres communites want DLINQ support badly enough, I'm sure someone will write it.

Re:Looks more like Delphi every release

[broody]

...LINQ, and DLINQ, are very exciting improvements in removing the disconnect between the database and the middle/front tier

All hail our new fat client overloads. Oh joy.

Re:Looks more like Delphi every release

[ergo98]

All hail our new fat client overloads. Oh joy.

Fat clients? You do know that the majority of .NET development occurs in the web services/web app space, right? Even then, middle-tier services in .NET are just as usable by a web facade as they are a fat client. In no way is this a fat client-only technology.

Re:Looks more like Delphi every release

[mabinogi]

>if you look at transparent persistence systems like JDO and Hibernate, almost all of the data retrieval and processing can be done with no query language at all.

Only for extremely simplistic cases, eventually you _will_ need to write queries. However, you don't use the database's native query language, you use one provided by the ORM tool. This appears to be the same sort of thing....

Re:Looks more like Delphi every release

[Decaff]

Er, it might help if you actually read the spec.

I did.

This isn't 'embedded SQL' in the sense of Pro*C -- the 'queries' are really a bit of (helpful) syntactic sugar over an object-oriented, typesafe set of expressions (you'll see the lambda expressions, new to C#, used heavily here):

It is still an embedded query language. This encourages a

"Also, I can't believe that MS C# is going to include support for MySQL, Postgresql etc, like Hibernate, NHibernate, JDO etc."

They don't have to. Implementing DLINQ is really as simple as implmenting a pattern (which Helsberg called the 'query expression pattern') and adding your own DB-specific code.

Adding the DB-specific code IS providing support. The point of having MySQL or PostgreSQL or Oracle etc. driver support provided by the ORM vendor (JDO or Hibernate) is that they can put the time in to generate very optimised specific SQL for those databases without you having to implement any pattern or add anything specific yourself.

Currently Oracle and DB/2 ship libs for ADO.NET, you can be quite sure they'll ship libs for DLINQ. If the MySQL and Postgres communites want DLINQ support badly enough, I'm sure someone will write it.

That is not the same as having very high quality optimised drivers for those databases that generate specific SQL.

Don't get me wrong - there are exciting things in this C# release - especially lambda expressions, but embedding query languages in business logic seems just bad practise to me - it is mixing things that should be kept separate.

Re:Looks more like Delphi every release

[Decaff]

" >if you look at transparent persistence systems like JDO and Hibernate, almost all of the data retrieval and processing can be done with no query language at all."

Only for extremely simplistic cases, eventually you _will_ need to write queries.

Only minimal ones, which is why I used the phrase 'almost all'.

However, you don't use the database's native query language, you use one provided by the ORM tool. This appears to be the same sort of thing....

Indeed, but possibly lacking major features of other mature systems, such as transparent persistence.

Re:Looks more like Delphi every release

[Decaff]

"Embedded SQL in computer languages has been around for a very long time"

It isn't embedded SQL. It's set operations that obviously share commonalities with SQL, but are largely different.

I should have said 'embedded query languages'. My point stands... this is new.

Again, have you watched the video or read the spec?

Yes.

DLINQ, by the way, is the ORM system that makes the objectpersistence "transparent" (leaky abstraction, like all ORMs, but still).

Nowhere in the information can I find terms such as 'persistence by reachability' which are appropriate for true transparent persistence. I may be wrong, but it looks like true transparency is not supported.

I doubt it'll include support either, out of the box. Instead, like always, they've created a generalized data services layer that any provider can plug into - create a ADO.NET 3.0 data provider for MySQL, and your data service can be the target of LINQ operations.

There are plenty of alternatives for other languages that do support these database 'out of the box'.

Re:Looks more like Delphi every release

[Anonymous Coward]

... or C++/Smalltalk/Java together with a OODB or relational OODB like ObjectStore, Versant or Obejctivity from the 1990s.

Re:Looks more like Delphi every release

[bheer]

I feel your pain about putting queries into business logic, but to look at DLINQ as an ORM tool is to miss the point. In the real world lots of people embed SQL in code (because they don't have time/skills/resources to devote to ORM, or simply don't know any better, or whatever) and the code they churn out today is a mess, to put it charitably. Now these very people can use a far more robust system at very little extra cost.

>> Implementing DLINQ is really as simple as implmenting a pattern ... and adding your own DB-specific code.
> Adding the DB-specific code IS providing support.

I think you misunderstood me. When I said adding 'your' own DB-specific code, the generic 'you' was a DB-vendor. So someone from Oracle would have to implement the pattern and add Oracle-specific code, etc. The programmer who uses DLINQ to connect to an Oracle DB wouldn't have to do anything special other than add an a /r:OracleDLINQ.dll at compile time.

That said, C# 3.0 is in very early stages now, and of course I don't expect serious support from Oracle/IBM until it moves closer to beta.

Re:Looks more like Delphi every release

[Decaff]

I feel your pain about putting queries into business logic, but to look at DLINQ as an ORM tool is to miss the point. In the real world lots of people embed SQL in code (because they don't have time/skills/resources to devote to ORM, or simply don't know any better, or whatever). Now these very people can use a far more robust system at very little extra cost.

This is something that has always bugged me about Microsoft since I started seriously using their products over 20 years ago. With their development tools they encourage ease-of-use at the expense of quality. It happened with VB, and now it is happening in many ways with .NET. The problem is that now many developers will be using embedded query languages in their code and thinking this is good practice. IT standards and code maintainability will suffer, in my view.

I think you misunderstood me. When I said adding 'your' own DB-specific code, the generic 'you' was a DB-vendor.

I assumed this - I was talking about vendors too (I was probably unclear).

So someone from Oracle would have to implement the pattern and add Oracle-specific code, etc. The programmer who uses DLINQ to connect to an Oracle DB wouldn't have to do anything special other than add an a /r:OracleDLINQ.dll at compile time.

I don't think this should be up to the vendor. The vendor already provides a standard connection mechanism with detailed information about the nature of their databases and the SQL support these database provide through ODBC and JDBC drivers.

With current high-performance Java systems, such as JDO (and soon, EJB 3.0), the implementor of the ORM puts the work in to provide high-performance translation from the ORM query language to the DB vendor's SQL. ORM vendors compete as to the quality of their code production. Why should DB vendors have to implement yet another spec when ODBC and JDBC are so widepread and detailed? Microsoft has all the information they need to output specific SQL for a range of vendors. However, I am pretty sure they won't.

Re:Looks more like Delphi every release

[kabz]

Man, software guys are hilarious sometimes. I suppose you have people slaving away over some O/R diagramming tool for days on end coming up with data models and 'metadata' code.

Please don't mod me down, I spent years emailing 'data modelers' with suggested models for various business requirements. They would then plug them in to a tool and generate some goop that would be absorbed by a layer over an Oracle database, producing a new set of 'objects' that would be manipulated by my application, and hopefully serialized correctly by the Oracle layer.

To me this always seemed like a lousy approach, because code always had to suck in all the objects, show them in some interface, etc. This is much more suited to a proper object database, rather than a pseudo object layer in a relational database.

Against Oracle it was usually as slow as shit.

In my current job, we have dispensed with 'tools'. A datamodel is something you spec out into a requirements document, then just build straight into SQL tables. It might take a morning to build and test a table, with FK references, and initial cut at indexes.

Programmers can build a simple batch process in a few days, and if the SQL is good, then the process will be good. Much of our software runs against millions of records as a matter of course. If there are problems, then the approach is to have a DB guru look at the tables, indexes, SQL plans etc. I'm not sure how you could really optimize performance on a bunch of 'objects' that can't be optimized much beyond batching up the queries and using bind variables.

I think the simple approach is no muss, no fuss. Add comments if you agree or disagree.

Re:Looks more like Delphi every release

[bheer]

In my current job, we have dispensed with 'tools'. A datamodel is something you spec out into a requirements document, then just build straight into SQL tables. It might take a morning to build and test a table, with FK references, and initial cut at indexes.

Intensive batch jobs are ideal candidates for an in-DB solution like SQL or SProcs (or a thin layer of Pro*C). The problems come with complex systems.

Requirements change. Over time, new classes of users enter the system, with brand new demands. The same data store is used by hundreds of apps. Most of these apps aren't batch jobs. In this scenario if the apps are all talking to the database directly you have a recipe for disaster. In OOP terms, your DB is now public. The only way to bring sanity to development is to develop what is essentially an API for working with your data. That is what ORM can do, cleanly.

Re:Looks more like Delphi every release

[shmlco]

Good news! We're merging with another company and embracing open source! Most of our stuff won't change, but we do need to point our business logic and web systems at their tables, in Postgre, and I also think most of the table relationships are similar but the table and field names are different. About half the data will be coming from a web service too.

[pause]

What do you mean we've hard coded all of the SQL table and field names and relationships directly into our business logic and web pages? What idiot assumed we'd never, ever change anything?

Or... We've grown to the point were all the connections are affecting our performance. We need to put some application servers into the mix.

Or... We need to provide web services to our customer database. We can just reference the existing objects, right? We don't need to recreate all that business logic, do we?

Bottom line. Your "no fuss, no muss" is simple and efficient... right up until it isn't.

BTW, that first example isn't made up. Of course, in our case, we just changed the data layer around a bit to feed the same objects the rest of the system depended upon.

Re:Looks more like Delphi every release

[shmlco]

Yet another reason why it's a bad idea is that someone has to learn a specialized query language that's supported only by C#. If you do, your developers and code will be locked in. At least SQL knowledge and queries are portable across languages (PHP, CF, etc.).

Re:Looks more like Delphi every release

[Bloater]

Check out nemerle for a more generic feature, macros.

You can define a 'from' macro that does all this in just a few minutes. This is not new stuff, and I can't believe this Anders guy is billing it as a great new thing when it's been done before - for a .Net language no less - in a far more generic and powerful way.

Re:Looks more like Delphi every release

[dr3vil]

What are you talking about?

That was a quote. His Billness said that to Anders when he was calling him at Borland trying to get him to jump ship. This tactic was obviously rather successful. That and the 5 million dollar sign-on bonus, of course.

Re:Looks more like Delphi every release

[Billly Gates]

Wasn't Hejsberg the lead designer of Borland's Delphi and Pascal products?

It would make sense for him to bring more features of the languages he prefered best.

Re:Looks more like Delphi every release

[kabz]

Well, we generally run on app servers connected to a database cluster. We might have 3 or 4 app servers that run the main C++ modules that contain business logic and SQL queries. This setup interacts with the thick client through the database and has been proven to scale pretty well, even with most users creating and updating data, not just browsing.

You have a pretty good point about providing web services, but Citrix is a decent way to push an application to outside users. This has its own advantages, but, yeah, it's sure not web services.

New app servers can be added to a running system pretty easily, and in development locally, this is as easy as hitting CTRL-F5 in MSDEV.

I saw various examples like yours when I worked in an oil services company, and while it looks good to expose the same 'objects' from different databases, in practice, the semantic differences and hard to express rules made it very hard to get any kind of substantial example to work well. If you threw enough programmers at the problem, you could get it to work but then you have a slow, fragile mess of middleware over disparate databases.

I think object layers can be a good deal if you have a purpose built back end, but for industrial strength software that runs flight reservation systems, insurance claim adjustment and other huge systems, you need to be a bit nearer the metal, and maintain control over how the business logic implicit in your SQL is deployed against the data.

Re:Looks more like Delphi every release

[Z00L00K]

Well... languages does a lot of cross-inheritance, especially when they are new and fresh. And C# (C-hash as I like to say to the annoyance of everyone) is a relatively fresh language on the market.

The most annoying thing with that language is that it is very similar to Java, but is using different classes. Understandable since it is M$ behind it and they got slapped by Sun for incompatible Java.

Anyway, what I still don't understand is why M$ still are marketing VB as a programming language. It is just remotely related to Basic, and still suffers from the bad things with Basic which leads to hard-to-read code and lack of structure. OK, there are a lot of programmers out there that have learnt VB in and out, but I still would like to see better languages as the major language for a lot of operations. Why not promote programming macros and scripts in a more structured language with stronger typing instead?

And still, don't forget Ada.

Re:Looks more like Delphi every release

[ClosedSource]

"The most annoying thing with that language is that it is very similar to Java, but is using different classes. Understandable since it is M$ behind it and they got slapped by Sun for incompatible Java."

You mean a different language uses different classes? Who would have thought it?

"And still, don't forget Ada."
I wish I could. Ada's a great language to use if your OS is written in Ada. Otherwise, don't bother.

In particular, I like Ada's unchecked conversion which should be called "brain-dead" conversion. If you convert a 16 bit value to a 32 bit one, the upper word is just garbage. I guess punishing the programmer for politically incorrect usage was more important than doing a conversion that made sense.

Re:Looks more like Delphi every release

[barrkel]

You can use VS2005 Beta 2 in a release environment: it's got a Go Live license.

I'm currently writing a large project in C# 2.0, for real-world deployment. Can't wait for C# 3.0.

Re:Looks more like Delphi every release

[ergo98]

You can use VS2005 Beta 2 in a release environment: it's got a Go Live license.

Very good point, and that clarification is necessary as I was ambiguous in my first post. Instead I meant that until the final release, few organizations want to, or will allow, the use of Whidbey, for development. It is a rare, edge shop that is actually taking advantage of the Go Live license.

Re:Looks more like Delphi every release

[Kosgrove]

Yeah, but you have that problem with all of the ORM libraries I've looked at. Hibernate/NHibernate has the same problem - it uses its proprietary HQL. At least it provides you a layer of abstraction so you're not completely locked into a database vendor, although I can't think of an example where different vendors implement basic statements like INSERT, UPDATE, and SELECT differently...

Re:Next version : line nunbers

[Anonymous Coward]

whoever modded this as troll never used GWBASIC :D

Who is Anders Hejlsberg?

[bogaboga]

For those just like myself who might not know who Anders Hejlsberg is, I post a link http://en.wikipedia.org/wiki/Anders_Hejlsberg that might help you understand who this man is.

I did not know he was very instrumental in developing Pascal, a language I was an expert at one in the mid nineties.

Re:Who is Anders Hejlsberg?

[Anonymous Coward]

>> a language I was an expert at one in the mid nineties

>You were an expert in a language without knowing its background and history?

Give him a break: he was only one year old.

Re:Who is Anders Hejlsberg?

[Detritus]

Niklaus Wirth designed Pascal. Anders Hejlsberg wrote a number of popular Pascal compilers, such as Turbo Pascal.

Re:Who is Anders Hejlsberg?

[Anonymous Coward]

In his defence, he said Anders developed it, which he did by adding extensions. He did not say he created it.

Seems to get more like Ruby, Python and Delphi ...

[MSch]

... every release. Now is that good or bad?

Re:So what?

[QunaLop]

got angst? it is an update to a open specification for a computer language... for which there is hundreds of thousands of programmers and millions of dollars invested... ...clearly this is not newsworthy you might ask yourself why mandrake gets an "ad" when dell offers it as an option on 1 laptop model...

Re:So what?

[/ASCII]

So what is C# is Windows only? 90% of all Slashdot readers are Windows users.

Why implicitly typed locals?

[Mr2001]

In an implicitly typed local variable declaration, the type of the local variable being declared is inferred from the expression used to initialize the variable. When a local variable declaration specifies var as the type and no type named var is in scope, the declaration is an implicitly typed local variable declaration. For example:
var i = 5;
var s = "Hello";

Can someone explain the point of this? C# is not JavaScript; these aren't true dynamically typed variables, the compiler just assigns a type for you instead of making you do it yourself. I can easily take half a second out of my day to figure out what type a variable should be, and end up with more readable code.

Re:Why implicitly typed locals?

[darweidu]

You can, but what advantage is there? code in implicity typed languages (which includes the dynamically typed languages) is just as easy (if not easier to read). Eg: foo = 5.0f; bar = 18; baz = "what"; Would the "float", "int" and "String" types really added much to the understanding of the program?

Re:Why implicitly typed locals?

[iGN97]

You type less, obviously.

It also allows you to write pieces of code that are more generic. The LINQ samples have a lot of examples of this.

For example:

foreach (string s in collection) {
      Console.WriteLine(s);
}

means you have to change the type everytime you change the type in the collection.

foreach (var item in collection) {
      Console.WriteLine(item);
}

means that you can use it with any time that implements ToString, which is pretty much any type.

There are numerous other benefits from the type inference, and they become more apparent with lambda expressions, where you can write expressions like "x => x % 2 == 0" instead of writing the equivalent bool-returning delegate with a typed parameter.

Most of the new features of C# 3.0 are quite impressive and more importantly very useful.

Re:Why implicitly typed locals?

[ObsessiveMathsFreak]

I can easily take half a second out of my day to figure out what type a variable should be, and end up with more readable code.

Ahh, but just think of all those poor migrating Visual Basic programmers whose only expierience of a c type syntax has been a spattering of javascript. They'll feel right at home.

With any luck, we'll make programmers of them yet.

Re:Why implicitly typed locals?

[Anonymous Coward]

However, these VB devs may be surprised to hear var's aren't like VB's Variant type.

Re:Why implicitly typed locals?

[hattig]

Indeed, this is really BASIC like, with 'var' instead of 'let' as the keyword. Of course, most BASICs allowed you to skip the 'let' keyword. Indeed, many BASICs also allows you to specify the type of the variable via use of $, %, etc. a$ = "foo" : b% = 2 and so on. Like I have some issues with autoboxing in Java 5 (it does make the code look nicer, but the programmer is being less concise with what they mean), I think this kind of stuff will eventually lead to more bugs and dodgy code - it isn't hard to actually THINK about the types, or use generics, and thus have proper code and design in your application.

C# is nice, but the version numbers are spiralling up before the previous version is even being used. I think they just want to catch up with "Java 5".

Re:Why implicitly typed locals?

[Anonymous Coward]

I believe you don't gain anything at declaration with one or another, but instead during variable passing.

something(int foo, float bar) is easier to understand than something(foo, bar).

Re:Why implicitly typed locals?

[Mr2001]

I guess all the implicit typing additions make sense in the context of LINQ, where SQLish queries are translated into C# code involving lambda expressions. In all my years of coding in Delphi and now C#, I've never needed to use BDE, ADO, or any other OOP database interface, so I can't gauge how useful these additions will be.

However, this example of yours seems like a bad one:

foreach (var item in collection) {
    Console.WriteLine(item);
}

If you're changing the type of the collection, a few foreach loops are the least of your concerns - what about all the code that actually manipulates the items' methods and properties? And if you're using a snippet like that so much that you're tempted to paste it over and over to work with collections of different types, you should really change it to a generic method:

static void PrintItems<T>(ICollection<T> collection)
{
    foreach (T item in collection)
        Console.WriteLine(item);
}

In summary, I can see how these implicit typing additions would be useful for the compiler, or rather for the language designers to explain how the compiler will implement features like lambda expressions and LINQ, but I can't see myself ever using 'var' instead of an actual type name.

Re:Why implicitly typed locals?

[Anonymous Coward]

Yet anothe clueless Slashdot reader. C# 3.0 supports anonymous types.

Re:Why implicitly typed locals?

[Sanity]

Can someone explain the point of this?

One point of it is to allow you to use anonymous classes without having to declare them. Lets say you use LINQ to do a join between two tables - you can assign the result of the join to an implicitly typed variable and reference the fields, without having to give this new object type an actual name.

So (forgive screwy SQL-like syntax):

var result = select a.name as name, b.age as age from...;
log("username is "+result.name+" of age "+result.age);

The variable result is a class which has fields "name" and "age", and we can refer to it without ever having to give this class an actual name. Now bear in mind that all of this is strongly typed and can be verified by the compiler.

As a Java programmer, it is exciting to see these developments in C#, it makes me wonder whether Java is destined to fall behind C# - it sure looks like that is happening....

Re:Why implicitly typed locals?

[naasking]

Can someone explain the point of this? C# is not JavaScript; these aren't true dynamically typed variables, the compiler just assigns a type for you instead of making you do it yourself. I can easily take half a second out of my day to figure out what type a variable should be, and end up with more readable code.

It's about saving time and typing effort. This C# 3.0 is honestly just a trivial hack though. Why bother with C# 3.0, when there's a .NET language that can be considered advanced enough to be C# 4.0; it's called Nemerle.

"Nemerle is a high-level statically-typed programming language for the .NET platform. It offers functional, object-oriented and imperative features. It has a simple C#-like syntax and a powerful meta-programming system."

With full type inference, not just "local" like in C# 3.0, Nemerle permits you to avoid specifying types practically anywhere. They also provide a C# to Nemerle code converter. Pretty cool. I'm definitely considering converting a major software product to Nemerle for the enhancements it provides.

Re:Why implicitly typed locals?

[phidiot]

It looks like it would be useful when combined with LINQ type queries as in:

var q =
from c in customers
where c.City == "Seattle"
select new { c.Name, c.Age };

q would result in an implicitly typed collection of objects that contain Name and Age properties only.

Here is a good description of using both

Re:Why implicitly typed locals?

[RAMMS EIN]

In the past, I've made the argument that forcing people to declare types lowers productivity and decreases legibility.

The one good rebuttal I got was that it really helps to declare types on function parameters; it serves as a kind of documentation of the intended use and operation of a function. Plus, of course, it allows the compiler to catch errors where the function you write doesn't have the type you say it does.

I guess that's also the reason Haskell programmers like to declare the types of their functions, even though it's optional in Haskell.

Re:Why implicitly typed locals?

[vadim_t]

Um, C# classes automatically inherit from 'object', which provides ToString.

So just:
foreach (object o in collection) {
        Console.WriteLine(o.ToString());
}

Or I'm missing something here?

Re:Why implicitly typed locals?

[iGN97]

Hi!

I know what you're saying, but "the code that actually manipulates the items' methods and properties" will of course fail at compiletime if it is not valid. Noone is advocating this as a fantastic new approach to systems development; in the context of just writing code outside lambda expressions it's nothing but a convenience. But to me, after having watched a number of webcasts, it seems very convenient indeed. It is the comfort of writing python with the strength of C#, and I cannot wait to start using it myself.

Well, I have actually downloaded the stuff, so I am already using it. ;)

Re:Why implicitly typed locals?

[Mr2001]

Having a declared type lets you know how you can use that variable. Can you pass it as a ref parameter to method XYZ that wants a "ref int"? Can you use it to store the result of method ABC, which returns a float?

In a dynamically typed language, the answer is always yes because variables have no fixed type. But in C#, the variables still have fixed types; they're just hidden. You have to look at the declaration "var x = 5" and think "Hmm, I guess that's an int", just like the compiler does. And for declarations like "var y = SomeFunction()", you have to go look up SomeFunction to find out what type it returns before you can know y's type.

It might save you a split second of typing to write "var" instead of a real type name, but 6 months from now when you have to find a bug in that code, it'll cost you just as much time to figure out what type those variables are.

Re:Why implicitly typed locals?

[Mr2001]

If it's a collection of value types (e.g. List), you'll take a performance hit when you convert each item to object. Since Console.WriteLine() has overloads for the intrinsic value types, you can avoid boxing by pulling the item out as an int and passing it to Console.WriteLine(int).

Re:Why implicitly typed locals?

[JChung2006]

Why implicitly typed variables? Anonymous types.

Today, you have C# code that looks like this:

MyClass o = new MyClass();

Which you could replace with var:

var o = new MyClass();

However, with anonymous types, you can have code that looks like this:

var o = new { Product='Beverage', Price='0.60' };

Without var, what type would you declare this variable? You could declare it as object, but to access the object's Product and Price properties, you would still need to cast the variable to some type, and what type would that be?

Anonymous types and implicitly typed local variables are C# language infrastructure to support LINQ, new language constructs to support type-safe access to relational and XML data stores in C# itself, rather than requiring code using separate class libraries like System.Data and System.Xml to access that data.

Check out http://msdn.microsoft.com/netframework/future/linq /default.aspx for more details on the LINQ project.

Re:Why implicitly typed locals?

[dotcher]

C# 3.0 also gains anonymous value types. You can do something like:

var c = new {Name = "Fred Bloggs", Age = 12};

Now, what type is c? It's an anonymous struct type, with two members - Name and Age. As it's anonymous, it's obviously not possible to declare it using the standard syntax.

The language is still strongly, statically typed, though - the following would throw a compile-time error:

c.Dept = "CS";

Now, as to why this construct was added to the language in the first place: these anonymous types are useful when using LINQ to query a data source:

var expr = people.Select(p => new {
p.Name, BadCoder = p.Age == 11
});

foreach (var item in expr)
Console.WriteLine("{0} is a {1} coder",
item.Name,
item.BadCoder ? "bad" : "good");

expr and item are both given the appropiate type for the data they contain, with no need to explicity define the types. Most of the benefits of strong static typing are retained with this approach, and there's no need to define a type to store data for every weird query you run against the database.

One benefit that is lost is the ability to share these types across assembly boundaries, which might be an issue in real, three-tier applications. On the other hand, if there's a need to pass data directly from the database to the client application, what's the point of having the middle tier in the first place? So, this might turn out to be a non-issue.

(My examples were taken or adapted from this white paper, which is an overview of the LINQ project, including the new syntax added to C# 3.0.)

Re:Why implicitly typed locals?

[Spinlock_1977]

I think you guys are missing the obvious. Try writing some asp.net code - you end up with variables declarations that look like this:

System.Configuration.AppSettingsReader appSettingsReader = new AppSettingsReader();

That can be shortened to just:

AppSettingsReader appSettingsReader = new AppSettingsReader();

if you include a 'using System.Configuration' at the top of your module. But still, I'd much prefer to write:

appSettingsReader = new AppSettingsReader();

and let the compiler do the obvious.

It's darn hard sometimes to pick out variable names in those longer declarations because there's text on both sides of the variable name. Implicity typing means variable names can be leftmost on the line, which improves the readability of the code noticably.

Re:Why implicitly typed locals?

[iGN97]

Yes, the code throws away type information, while my example does not. Type inference is convenience. You type less with the same functionality.

Re:Why implicitly typed locals?

[Mr2001]

Now that makes sense. Thanks.

Re:Why implicitly typed locals?

[samael]

Possibly because people keep whining that when typing:

myClass exampleInstance = new myClass("Test");

that they have to type the word "myClass" twice.

This way you can presumably type

var exampleInstance = new myClass("Test");

Not sure it's a major saving though...

Re:Why implicitly typed locals?

[Greyfox]

And which of those rebuttals lowers productivity and decreases legibility? For a toy program where you can easily keep track of all your functions in your head, having to declare types isn't that useful. On a production system with thousands of functions, it'd be impossible to maintain the application without typing. Even the level of flexibility Java gives you leads to run time errors more often than not.

I like dinking around in Lisp, PostScript or Forth from time to time but you quickly realize that without type checking any major program in those languages would be pretty much unmaintainable.

Re:Why implicitly typed locals?

[smug_lisp_weenie]

This is incredibly useful when you have generic types in a more complex scenario. Something like this is a better example:

Iterator<AdvancedHashMap<HashingClass56,NestedKey, ArrayList<int>>> i=
      new Iterator<AdvancedHashMap<HashingClass56,NestedKey, ArrayList<int>>>();

when definining a complex generic type, not having to declare the full type for "i" makes sense, no?

Re:Why implicitly typed locals?

[Xepo]

This would be a boon to boost::spirit in C++. In fact, they're thinking of reusing the auto keyword to add this functionality to C++0x.

Check out this page to see why it'd be so useful.

Re:Why implicitly typed locals?

[noamt]

foreach (var item in collection) {
            Console.WriteLine(item);
}


This example makes no sense.
Is "collection" a collection of objects or something more concrete? If it's an object collection, s/var/object/ in your example.
The compiler inferes the variable type at compile-time, not run-time. So "var" will become "object" anyway.

var i=5; // same as int i=5;
i="str"; // won't work, because i is an int.

Of course, maybe I got it wrong..

Re:Why implicitly typed locals?

[uberchicken]

I'm hoping it means I can do:

var x = new System.IO.StreamWriter();

instead of

System.IO.StreamWriter x = new System.IO.StreamWriter();

Re:Why implicitly typed locals?

[iGN97]

I almost forgot. Another good reason to have the ability to have the var type-inference is the C# 3.0-feature anonymous types.

It allows you to write:

var v = new { Answer = 42, NotTheAnswer = 32 };
Console.WriteLine("The Answer is: {0}", v.Answer);

The usefulness of this isn't immediately apparent, before you look at query projections:

public void Linq9() {
    string[] words = { "aPPLE", "BlUeBeRrY", "cHeRry" };
 
    var upperLowerWords =
        from w in words
        select new {Upper = w.ToUpper(), Lower = w.ToLower()};
 
    foreach (var ul in upperLowerWords) {
        Console.WriteLine("Uppercase: {0}, Lowercase: {1}", ul.Upper, ul.Lower);
    }
}

The example is stolen from the LINQ examples at http://msdn.microsoft.com/vcsharp/future/linqsampl es/.

These just isn't a sensible way (that I can think of) to reference the anonymous type with the same degree of type safety.

Re:Why implicitly typed locals?

[Anonymous Brave Guy]

You state, repeatedly, that large programs "without typing" or "without type checking" cannot be maintained. I think you're missing the point.

Most of the languages we're talking about here are strongly typed, and their code is naturally highly generic. Type inferencing doesn't leave a gap for run-time errors in this context, because you can't have type mismatches in the first place. This framework also avoids implicit conversions yielding accidental type coercion, a significant class of programmer error in some other languages.

The drawback to type inferencing is that it does leave scope for logic errors, where you wind up calling a function that doesn't do quite what you think it does with the type of data you've supplied, yet compiles quite happily because the syntax makes sense for all the types involved. As another poster noted, even with type inferencing, it can be useful to declare the interface to some key functions explicitly as a sanity check.

BTW, several large-scale applications have been written and maintained in such languages; many of them have web sites that list examples.

Re:Why implicitly typed locals?

[Sigma 7]

C++ implements typedefs which effectivly eliminate the problem of fully typing out type names.

The alternative is Java, where everything extends from Object (requiring minimal typing stuff.)

Re:Why implicitly typed locals?

[Tayssir John Gabbour]

For a toy program where you can easily keep track of all your functions in your head, having to declare types isn't that useful. On a production system with thousands of functions, it'd be impossible to maintain the application without typing. Even the level of flexibility Java gives you leads to run time errors more often than not.

Are people aware that this is the archetypal static-typing troll? ;)

Re:Why implicitly typed locals?

[Anonymous Brave Guy]

If you're changing the type of the collection, a few foreach loops are the least of your concerns - what about all the code that actually manipulates the items' methods and properties?

It will fail to compile if it really doesn't make sense. See my other post for comments on the danger of logic errors that remain here.

And if you're using a snippet like that so much that you're tempted to paste it over and over to work with collections of different types, you should really change it to a generic method:

Why? As far as I can see, your code provides no advantage over his, and in general your approach will be more cumbersome. The difference is just that in one case, types must be specified explicitly by default but can be treated collectively via templates/generics, while in the other case, code is generic by default, but types can be specified explicitly where it's useful for sanity checking purposes.

Re:Why implicitly typed locals?

[shutdown -p now]

Can you pass it as a ref parameter to method XYZ that wants a "ref int"?

If your code uses "out" or "ref", it's pretty much broken by design. There's good reason why most modern languages (Java among them) don't have these anachronisms. If you need to return several values, return a struct (many languages have tuples for that, but unfortunately C# doesn't).

Can you use it to store the result of method ABC, which returns a float?

The whole point is that instead of wasting time on this, you let the compiler do its job and just make it work by writing:

var x = Abc();

Again, code which reassigns a local variable is almost always badly written. In most functional languages, you simply can't reassign a variable once you bind a value to it. A few exceptions to these are some iterative algorithms, such as traversing a linked list, written imperatively. In this case you still have an option of declaring the type explicitly. But it should be a rare thing, because you'd normally just use foreach anyway. And now with real lambdas, who wouldn't use functional approach anyway? ;)

To sum it up, in 95% of all cases, var x will do exactly what needs to be done, while saving your time. I would say that it is a definite improvement.

Re:Why implicitly typed locals?

[statusbar]

Yes.

People who complain about run-time type checking errors are obviously not running unit tests! They think that if their statically typed code compiles, it must be correct!

--jeff++

Re:Why implicitly typed locals?

[dubl-u]

As a Java programmer, it is exciting to see these developments in C#, it makes me wonder whether Java is destined to fall behind C# - it sure looks like that is happening....

Yep. Java 1.5 certainly was a big step forward, but it seemed to mainly be catching up, rather than getting ahead. And they seem to have backed off in 1.6; I don't see anything as radical as the templating stuff. I was really hoping for closures, for example. And it certainly doesn't seem as ambitious as C# 3.0.

Re:Why implicitly typed locals?

[dubl-u]

it really helps to declare types on function parameters; it serves as a kind of documentation of the intended use and operation of a function.

It's true. Especially if you don't have named parameters, the typing makes things much clearer.

Another thing I like about static typing is the IDE magic that it makes possible. There are a number of automated refactoring tricks that I'm very fond of that I don't think could be done without static typing.

Of course, as another person pointed out, if you have good unit and acceptance tests, a lot of the save-me-from-myself features of static typing become harder to justify.

Re:Why implicitly typed locals?

[Anonymous Coward]

It might save you a split second of typing to write "var" instead of a real type name, but 6 months from now when you have to find a bug in that code, it'll cost you just as much time to figure out what type those variables are.

However, this still isn't VB's "Variant" type. If you use a var actually being a string later on as an int, that'll lead to the usual type casting error.

It could make the code a bit harder to read though, but not cause those bad VB problems with Variants.

Re:Why implicitly typed locals?

[seguso]

For example, with type inference, the code

void foo(list<shared_ptr<int> > l)
{
list<shared_ptr<int> > :: const_iterator i;
i = l.begin();
//...

}

becomes just

void foo(l)
{
var i;
i = l.begin();
// ...
}

The advantage is obvious. That was C++ code, but it should be easy to find similar examples for C#.

Re:Why implicitly typed locals?

[Anonymous Brave Guy]

Why bother with C# 3.0, when there's a .NET language that can be considered advanced enough to be C# 4.0; it's called Nemerle.

Because Microsoft's weight is heavily behind C#, but not Nemerle. Ask any Visual J++ developer how much you can count on Microsoft's long-term support for proprietary languages that aren't their current pet. Caveat programmor. :-)

Re:Why implicitly typed locals?

[Tayssir John Gabbour]

I like dinking around in Lisp, PostScript or Forth from time to time but you quickly realize that without type checking any major program in those languages would be pretty much unmaintainable.

Incidentally, within Common Lisp, someone wrote a sublanguage that "has the most powerful type system of any existing functional language, including ML and Haskell." Qi. Now, that's "power" in a formal sense, as he explains here to curious critics.

Re:Why implicitly typed locals?

[Anonymous Coward]

I've watched a presentation on this before and your example is slightly off and obscures the true purpose of implicit typing. In the case of foreach loops, implicit typing is... implicit.

So all you would say is
foreach( item in collection ) { ... }

Since the collection was likely a generic of some kind with a static type for its contents, i.e. List, item would be an int and you would be allowed to do all the normal int stuff with it.

The main advantage is not flexibility per se, but conciseness. It removes the need to spell out the type name, particularly when iterating over a generic holding a long classname. Removes the need to say
foreach( ExcessivelyLongClassNameRequiredByMyCompanysStyleG uidelines item in collection ) { ... }
every time you need to iterate over the collection again.

Re:Why implicitly typed locals?

[MBraynard]

Of course, because you still CAN declare the data type your entire comment is moot. You're more making a case aginst using implicits rather than an argument against C#.

Re:Why implicitly typed locals?

[jzeejunk]

well.. one reason I can see is C#3.0 supports anonymous types (as shown in the demo). now the type has no name but you still want to be able to access members so you declare the reference as var. its different from object in that you get compile time type checking ..

Re:Why implicitly typed locals?

[Anonymous Coward]

now this will be fun. all those comments will be modded -1 redundant because they read >4 comments only.

Re:Why implicitly typed locals?

[metasyntactic]

I've written a series of posts on the new Linq technologies we've just previewed. My focus has been on the C# aspect of it (as i'm a C# language developer), but i'll also be discussing DLinq and XLinq (XML oriented query and transform). I try to go beyond just discussing the what the new features are, to more of a "why this is a good thing?" approach and "what existing problems do the new features solve?" You can find the blog posts here:

http://blogs.msdn.com/cyrusn/archive/2005/09/13/46 5390.aspx and
http://blogs.msdn.com/cyrusn/archive/2005/09/16/46 9953.aspx

                -- Cyrus (http://blogs.msdn.com/cyrusn)

Re:Why implicitly typed locals?

[spongman]

two reasons:

1. you type less.
2. when the the right-hand-side expression is an anonymous type (or an array, collection of anonymously-typed objects) then there is non name you can write on the left.

Re:Why implicitly typed locals?

[Richard W.M. Jones]

It might save you a split second of typing to write "var" instead of a real type name, but 6 months from now when you have to find a bug in that code, it'll cost you just as much time to figure out what type those variables are.

Actually that's complete nonsense. Type inference is the norm in functional languages, and I hardly ever feel the need to annotate types (which is possible, but rarely done).

The real advantage is when you start to generate rich structures - possible in OCaml, for example, but still not possible in C#/Java. Perhaps they'll get round to adding that feature next.

Rich.

Re:Why implicitly typed locals?

[Anonymous Coward]

You type less, obviously. ...

foreach (string s in collection) {
            Console.WriteLine(s);
}

If you want to type less, I suggest the following:

(mapcar 'print collection)

Re:Why implicitly typed locals?

[metasyntactic]

To specifically answer your question:

There is no nececssity to use implicitly typed local variables in the example you provided. You can still declare such code as:

int i = 5;
string s = "Hello"

The necessity for "var" comes from situations where you're using "Anonymous Types" which (as their title implies) have no nominal type that can be used in their declaration. A good example of that is:

var q = customers.Where(c => c.City == "Seattle").Select(c => new { c.Name, c.Address });

What's the type of 'q'? Well, in this case it's an System.Collections.Generic.IEnumerable. What's that ...? Well, it's an anonymous type containing two properties (Name, and Address) typed to whatever the statically known types of Customer.Name and Customer.Address are. Since there is no declaration that can express that, you can then use "var" to allow the compiler to take care of all of it.

Several of the new Linq C# featuers include:

• Extension methods - a convenient syntax invoking methods on a different type than what they were explicitly declared on.
• Lambda expressions - those: c => c.Name, snippets above
• Object Initializers - an expression based apprach to instantiating and initializing an object (that goes far beyond the existing "new" call of today).
• Anonymous types - Shown above. the new { ... } expression.
• Expression Trees - My new fav features. Captures a C# expression into a strongly typed object that can then be passed to any consumer. This is how we can pass a C# expression (like the one shown above) to your DB of choice and allow it to generate SQL (or whatever it wants) optimized for their platform that can then run server side!

Read more about it from the links in the OP and also feel free to check out some of my blogs on the topic:

http://blogs.msdn.com/cyrusn/archive/2005/09/13/46 5390.aspx and
http://blogs.msdn.com/cyrusn/archive/2005/09/16/46 9953.aspx

                                -- Cyrus (http://blogs.msdn.com/cyrusn)

Re:Why implicitly typed locals?

[Anonymous Coward]

The ints get boxed when they are put into the collection. The performance hit was already taken.

Re:Why implicitly typed locals?

[justsomebody]

Actually it does. Over 500% of speed.

While the previous was object typed, your parents example used generics. If you don't know what gerics are think like this:

While original was always typecasting object to string during runtime.
C# 2.0 defined generics which provide the same conversion at compile time and optimized addressing of the variable.

But then again, problem of .Net is not language specs or being without some features. Problem lies in sloppy memory handling. And this is the problem that hasn't been addressed with this spec either. I mostly code software that has to run 365/24/7. All of my tests to apply .Net (and I tried it because language it self is beatiful) were doomod from the start. After heavy used app with a lot of data was running for a day or two every single bit of memory was consumed and all system started crawling. There was no option but to restart. Well, that's something I can't afford so I ditched .Net and went to older more proven ways. But somehow I still hope that there would exist just as beatiful language as C# without sloppy memory handling.

Re:Why implicitly typed locals?

[uberchicken]

I may be missing your point, but that's a bad example; you'd surely do:

foreach (object item in collection) {
        Console.WriteLine(item);
}

Re:Why implicitly typed locals?

[metasyntactic]

Grrr... Posted before checking. Looks like my generic declaration was stripped for looking too much like XML. Specifically:

What's the type of 'q'? Well, in this case it's an System.Collections.Generic.IEnumerable<...>. What's that ...? Well, it's an anonymous type containing two properties (Name, and Address) typed to whatever the statically known types of Customer.Name and Customer.Address are. Since there is no declaration that can express that, you can then use "var" to allow the compiler to take care of all of it.

Re:Why implicitly typed locals?

[Anonymous Coward]

Simple answer:

Lots of users were wondering why they had to repeat themselves:


LongWindedNamedThing x = new LongWindedNamedThing(); // why do I have to declare that x is a LongWindedNamedThing, and then assign a new LongWindedNamedThing() to it?

var x = new LongWindedNamedThing(); // ahh - ive saved myself some typing now

Re:Why implicitly typed locals?

[iGN97]

The problem is that your code throws away the type information. If you want to do anything with the item, you have to downcast it. This is incurs runtime overhead and has the possibility of failing at runtime. Errors in handling the "var"-reference will be handled at compile-time.

The point is that var is a convenience. Writing:

var s = "Hi!";

is equivalent with writing:

string s = "Hi!";

The exact same code will be generated. The benefit of using var is that it's usually less to write (especially when working with collection types like Dictionary<int, string>, for example).

What I was trying to illustrate with the foreach is that code written works for more cases without sacrificing any kind of strong typing. Using "var" never results in a hidden "object" unless you write

var o = new object();

The scaremongers that indicate that this will somehow sacrifice either runtime-security or make it harder to track down bugs are just prematurely worried. I actually think that the opposite will be the case, thanks to code that's easier to read. So I guess you could say I'm prematurely sighing with relief. ;)

What I was trying to say with the foreach-example is simply:

foreach (var item in collection) { // ... }

will work regardless of the T in IEnumerable. It is less code to maintain, and it works exactly like continuously substituting the "var" for the T. This makes the written code more generic. It works with more types of data without sacrificing type safety. You can do operations on "item" without doing a downcast and errors will be found at compiletime, unlike working with object.

Re:Why implicitly typed locals?

[jrumney]

Can someone explain the point of this?

Remember, Microsoft's audience is VB programmers. I look forward to version 6.0, which will see the much awaited return of line numbers.

Re:Why implicitly typed locals?

[Chris_Jefferson]

This is supposed to be coming to C++ via the keyword "auto". I'm not sure how things are in C#, but I can't wait until I can write:

auto it = v.begin();
instead of (say)
vector >::const_iterator it = v.begin();

Re:Why implicitly typed locals?

[Coryoth]

In the past, I've made the argument that forcing people to declare types lowers productivity and decreases legibility.

The one good rebuttal I got was that it really helps to declare types on function parameters; it serves as a kind of documentation of the intended use and operation of a function. Plus, of course, it allows the compiler to catch errors where the function you write doesn't have the type you say it does.

I really wish using contracts (preconditions and postconditions) for this purpose would catch on. It provides better more exacting documentation of the function (not just the type on inputs and outputs, but specifics of what they must be, and what sorts of results you can expect in return), with an OO language that supports it (like Eiffel or D) it fits very naturally with inheritance (you cna weaken inherited preconditions, but not strengthen and vice versa for post-conditions), and it automatically provides an extremely powerful test harness for all your code by simply setting a switch to check all contracts at runtime.

If this sounds interesting and you program in Java, please take a look at JML and related tools. It lets you specify contracts via a JavaDoc style notation that

(1) Gets added to your javadoc documentation.
(2) Can be used to automatically generate a unit testing framework.
(3) Allows you to use extra static checking tools (like ESC/Java2) that can catch far more errors than static types alone - all prior to runtime.

If you're bothering to document your functions why not formalise the documentation a little further to allow generation of unit tests and extra static checks? It just makes sense.

Jedidiah.

Re:Why implicitly typed locals?

[Anonymous Brave Guy]

One of us is misunderstanding here, but I'm afraid it's not me.

There is nothing about inferred typing that requires things to be of some base "object" type. Indeed, in many languages that use it, there is no base type, nor even necessarily the concept of inheritance.

In the case of the code we were discussing:

foreach (var item in collection) {
Console.WriteLine(item);
}

it would be normal to deduce the type of item from the type of collection and the behaviour of the foreach ... in ... construct. That type would then be checked against the requirements for WriteLine, and an error generated at compile time if the types were incompatible. Whether C# specifically will be doing this, I don't know, not having read the specs for the new features in detail. There's no reason the use of type inferencing techniques generally can't, though.

You seem to be looking at this from the point of view of C# and its current generics features only, and in that restricted context, perhaps there is indeed some silly performance hit. I'm looking at the pros and cons of inferred types generally, and in that more general context, there is no need for the clutter of generic syntax, and many languages work quite happily without it.

BTW, even if your platform does implement this naively by using a universal base type, a performance hit of 500% for doing so is appalling, and suggests you have far deeper problems on that platform than how generics are handled!

Re:Why implicitly typed locals?

[Anonymous Coward]

Wow, that is sweet. I have always wanted to be able to return anonymous structs from functions. That way you don't have to declare a new type just to return two values from your function (and you don't have to use out parameters either). However, Intellisense will practically be required when working with anonymous types.

Re:Why implicitly typed locals?

[Spy Hunter]

C# 3.0 will have anonymous structs, meaning that you can return two (or N) values from a function without explicitly declaring a type and without using "out" or "ref" parameters. They're better than tuples because each member of the anonymous struct can be given a sensible name. "out" and "ref" are mostly useful in interop with C or C++ functions that have pointer parameters, and in that role they work very well. Any pure C# code that uses "out" and "ref" should be rethought. Luckily they don't seem to get abused much in my experience.

Re:Why implicitly typed locals?

[Anonymous Coward]

That's why IDEs are becoming more important. The IDE can do the code analysis for you and notify you immediately when you've got it wrong. If you don't know what type a var is, the IDE can tell you. If you don't know what members your var has, Intellisense will tell you as you type. If you pass your var to a function that doesn't accept it, the IDE can underline it in red immediately and tell you what you've done wrong. This means that writing code in a plain text editor will become harder, but that doesn't make the language bad. We need to move beyond coding in plain text editors.

This is simply a natural progression toward more sophisticated IDEs to go along with our more powerful languages. The computer doesn't just compile code, it can help you understand your code and write better code. Some people will resist; they don't trust the computer to help them write code; they want to do it all in their heads; they think IDEs make you weak. We need to move beyond that attitude to progress in computer science.

BTW, the main use of var is not to save you two keystrokes when typing string. If that was its only use I would agree with you. In fact, I think prohibiting this use of it would be good. However, var is essential to the other new language features because it allows anonymous types which don't actually have names, and so can't be declared as the type of a variable.

Re:Why implicitly typed locals?

[Mr2001]

Why [use generics instead of pasting an implicitly typed snippet]? As far as I can see, your code provides no advantage over his, and in general your approach will be more cumbersome.

Because if you're pasting a snippet everywhere, it's probably more complicated than just a foreach loop with one line of code inside - it isn't hard to just write a one-line foreach loop for the appropriate type each time you need it.

If you're pasting, say, a dozen lines of code at different places all around your program, what happens when you realize one of those lines was wrong? You have to go find every place where you pasted it and make a small change. Better to move the code into a method, where you only need to change it once.

Re:Why implicitly typed locals?

[Mr2001]

Yes, exactly. I love C#, I just didn't see the point of implicit typing.

Now I do, but the examples in the spec are pretty lame. I'll never need to write anything like "var x = 5" because I know 5 is an int. It seems to me implicit types are only useful when you can't specify a type name because you're using anonymous types.

Re:Why implicitly typed locals?

[Mr2001]

The ints get boxed when they are put into the collection. The performance hit was already taken.

No, not since C# 2.0 (which, amusingly, is still in beta) introduced generic collections. List<int> is a collection that can only hold ints; you can add and extract items without any boxing or unboxing. That's arguably the main purpose of generics in C#, and the main advantage of C#'s generics over Java's.

Re:Why implicitly typed locals?

[Anonymous Brave Guy]

If you're pasting, say, a dozen lines of code at different places all around your program, what happens when you realize one of those lines was wrong? You have to go find every place where you pasted it and make a small change. Better to move the code into a method, where you only need to change it once.

No argument there, but how does this affect the question of whether inferred type information is useful or not?

Re:Why implicitly typed locals?

[Compuser]

This sounds like an IDE issue. When you look at
code in a decent IDE, you should be able to mouse
over a variable name and it should tell what type
of variable the compiler thinks it is.

Re:Why implicitly typed locals?

[shutdown -p now]

C# 3.0 will have anonymous structs, meaning that you can return two (or N) values from a function without explicitly declaring a type

How so? You still have to declare the type of the return value for non-local methods, so what would the the type of the function returning an anonymous struct?

Re:Why implicitly typed locals?

[StarsAreAlsoFire]

Because: All languages eventually either die out, or evolve into LISP. :~)

And maybe you can't (decide which is the best type). Even with 'int', maybe you could have made it a short? Or, (oops!) a long?

But in this case, the reason you need an implicit type is because the compiler is going to create a class for you, via reflection; litterally, the data type you need DOES NOT EXIST until after you end that line of code using the semicolon. That is, when you call these (absolutely KICK ASS) LINQ functions, it will create a datatype on the fly.

Re:Why implicitly typed locals?

[MBraynard]

In the old school of programing conventions, you are expected to indicate the type in the NAME of the variable.

Re:Why implicitly typed locals?

[Javagator]

It seems to me implicit types are only useful when you can't specify a type name because you're using anonymous types.

That seems to be the biggest argument for implicit typing. But why didn't they just introduce a keyword that just applied to anonymous types instead of making the entire language more error prone and less readable. You would be able to type

var c = new {Name = "Fred);

But not

var x = 5; var y = 5.0;

When you really meant:

double x = 5; float y = 5.0F;

For over a decade computer science gurus have preached that implicit typing is a bad idea, and most of the non-scripting languages (C++, Pascal, Java, Modula 2, etc.) have followed that lead. Now, Microsoft is taking a big step back toward VB, something I find inexplicable.

Re:Why implicitly typed locals?

[gfody]

jesus, the code the parent posted offends me in so many ways. just what the fuck is wrong with named, typed, out parameters anyways?

Re:Why implicitly typed locals?

[Trejkaz]

Your example seems to throw away the type information to the same degree as his did. In both cases, the actual type of the object is unmodified and merely the type of the reference has changed.

Re:Why implicitly typed locals?

[Trejkaz]

Wouldn't it be better to use packages to distinguish classes from each other instead of building increasingly-long classnames to avoid collisions? Then you would no longer need to worry about really long classnames like that.

Re:Why implicitly typed locals?

[iGN97]

If you think my example seems to throws away type information, you don't understand how type inference works.

Here are two simple examples, both iterating collections of strings to output the length of the string, one using object, the other using var (type inference):

var collection = new [] {"This", "is", "a", "demonstration"};
 
foreach (object o in collection) {
  if (o is string) { // Check to see if o is string
    Console.WriteLine("Lenght of string: {0}", ((string)o).Length));
  }
}

with inference:

var collection = new [] {"This", "is", "a", "demonstration"};
 
foreach (var s in collection) {
  Console.WriteLine("Length of string: {0}", s.Length); // It is known that s is of type string
}

So while it might seem to throw away the information about the underlying type, it doesn't.

The first line in both examples uses the new feature called implicitly typed arrays (26.6 in the specification). From that point on, it's known that collection is an array of strings.

The "foreach (var s in collection)" then infers that the type of s is indeed string. This gives you an obvious benefit of "foreach (object o in collection)" as the example shows: you'll have to check that o is the expected type and add the extra typing for the cast. Both runtime overhead and inconvenience.

Re:Why implicitly typed locals?

[Trejkaz]

If you know it's a string, though, you won't be iterating through objects, you'll be iterating through strings. So the sum benefit is 3 characters, the difference between typing "var" and "string".

Re:Why implicitly typed locals?

[iGN97]

No, the benefit is also that the code you wrote is generic, and you won't have to change it when you change the collection type.

Re:Why implicitly typed locals?

[Trejkaz]

Well, you're calling various methods on that object which assume that it's a string. I'd imagine you'd be changing all of those when you change the collection type.

Re:Why implicitly typed locals?

[iGN97]

Obviously.

Re:Why implicitly typed locals?

[AscendantOat]

...you can add and extract items without any boxing or unboxing. That's arguably...the main advantage of C#'s generics over Java's

Having used Java's generics since JSE 1.5b1, I can attest that the minor performance and consistency loss that comes from Java's inability to parameterize primitive types is trivial next to the problems of type erasure.

Java's erasure mechanism limits its generics to compile-time checks and cast avoidance. Working around erasure requires client code to pass in a type token, which your code then has to keep track of. C# just handles everything for you.

Not trying to be rude, but ...

[hritcu]

Do we really have to have a Slashdot post followed by a flamewar every time a guy at Microsoft opens his mouth?

Re:Not trying to be rude, but ...

[Anonymous Coward]

Yes. Otherwise, this might be a nice place to come. No one would want that.

Re:Not trying to be rude, but ...

[advocate_one]

Do we really have to have a Slashdot post followed by a flamewar every time a guy at Microsoft opens his mouth?

you must be new here... ;)

Re:Not trying to be rude, but ...

[Richard_at_work]

Equally not meaning to be rude, but some people are interested in more than Linux and OpenOffice. This is supposed to be News for Nerds, and news about version 3 of a language fits right in.

Re:Not trying to be rude, but ...

[hritcu]

My remark was not speciffically about this post, which is pretty OK. I just have the impression that Microsoft-related articles tend to arouse much more animosity then almost any other kind of Slashdot article. And there were a lot of these type of articles lately. I'm starting to become tiered of flaming microsofties, so maybe I will just skip them.

Re:Not trying to be rude, but ...

[Da Fokka]

I'm starting to become tiered of flaming microsofties, so maybe I will just skip them.

...or you could consider not flaming them?!

Re:Not trying to be rude, but ...

[Anonymous Coward]

... sure... why not?

Re:Not trying to be rude, but ...

[Anonymous Coward]

No controversial news means no ad views as people constantly reload to see if their latest barb has caught any fish. Slashdot users can only post so many suck-up "Linus is so smart" posts per article, but they can have a flamewar over RMS all day long.

Re:Such a pity

[iGN97]

Migration away from Windows might be a problem, but you can't escape the fact that on Windows, currently and in the future, C# and other .NET languages are The Big Gun. It's too expensive not to use it, because if your competition does, they will be running around you in circles, blowing holes in you. There simply is no product that delivers the same kind of raw productivity.

And the way I see it, the same is about to become true for Mono on Linux, even though they might only currently share a subset which is compatible. C# on Linux with managed bindings (Gtk#, for example) is extremely potent (see Beagle, Diva, F-Spot, etc.).

As the compatible subset becomes larger, there will obviously be an added benefit. The work being done in both camps (MS for innovation and Mono for re-implementation) is, IMHO, very impressive.

Re:So what?

[FoboldFKY]

You've obviously never heard of Mono...

Re:Next version : line nunbers

[kronocide]

"Overbloated" is a redundant (overbloated) expression.

LINQ

[jurt1235]

The built in SQL like language would be usefull in many languages. It is now just waiting for LINQ version X (for short LINQX) before the confusion starts.

Re:LINQ

[RAMMS EIN]

``The built in SQL like language would be usefull in many languages.''

Yep. If done right, it can completely eliminate the possibility of SQL injections. This is something that too few people realize, but with SQL injections being a very common kind of vulnerability, it's definitely worth putting some thought and effort in.

Way to go!

[RAMMS EIN]

It seems that Microsoft is finally doing something with all the great research they funded. C# is becoming more and more like Lisp and ML, and might well become the first language in recent times that carries the approval of both academics and the industry. .NET as a whole gets many things right; multiple languages that can target the CLR and interoperate, special modifications made to create a friendlier environment for functional languages, registration of the core technologies with an independent standards body, publication of an implementation for multiple platforms, with source code, etc. etc.

Of course, .NET doesn't get everything right, but it's amazing how many good things are in there, especially considering that it comes from Microsoft.

Re:Way to go!

[shutdown -p now]

What really makes me curious is the mention of 'expression trees' for lambdas. It sounds suspiciously like AST, and if so, Lisp-style macros are sure to follow.

Re:Way to go!

[Anonymous Coward]

The 3.0 language is a readability / code comprehension nightmare! I just hope Sun doesn't try to copy any of this into Java.

Re:Way to go!

[iGN97]

From what I understand, it's the same thing. Some examples on the LINQ samples query the expression tree. It basically means that for SQL Server which supports C#/.NET in the server, you can transport the expression tree from the client to the server to minimize the transported resultset. It can obviously also be used to build the SQL on the client side for databases that doesn't support .NET on the server side by querying the expression tree and making SQL that reflects the contents of the expression.

It would be excellent to have real macros too, but I haven't heard any mention of it yet. :(

PDC Keynote, day 1

[iGN97]

For anyone interested in development on Windows, or the possible future direction of Mono, I recommend checking out the PDC Keynote for day 1. The duration is about 3:20, and you'll see demonstrations of the 5219-build of Vista, a lot of Avalon apps, four great architects at Microsoft doing live coding (showcasing LINQ, Indigo (WCF), Avalon (WPF) and Atlas, among other things) and a lot of interesting information about where things are heading.

A lot of it is market-speak and sales, but it is a developer conference. The link can be found here: http://www.microsoft.com/events/executives/billgat es.mspx (Click on the "On-Demand Webcast"-link. High up on the page.)

Can someone explain the advantages of C# over VB?

[FlorianMueller]

This is a real question, not a rhetorical one, no matter how provocative it may seem.

What really are the benefits that a developer gets by using C# instead of VB.NET? Either way, it's a vendor and platform lock-in, so there isn't really a portability gain. In terms of performance, the tests that I've read about haven't really shown a major advantage in favor of C#. As for functionality, C# was ahead of VB.NET in .NET 1.x, but in .NET 2.0, VB.NET has closed the gap by also allowing unsigned integers, custom operators etc.

I personally tried both, and I'm much more productive with VB.NET because I get clear keywords such as LOOP and END IF instead of braces. Theoretically, I could add comments to a brace that indicate what type of structure ends at the respective point, but that's a waste of time, and if I modify an algorithm, then the function of those closing braces may change. Also, the VB.NET editor's auto-completion feature is more advanced.

I'd really be interested in knowing other advantages that C# has, which is why I'm asking. So far it seems to me that some may be more familiar with a Java/C-style syntax (in which case I'm wondering why they don't go right for C++ or Java). Another reason may be that some people have this view that "real men don't program in BASIC".

The Microsoft Trap

[MrSteveSD]

C# is a nice language, but the problem is I just don't trust Microsoft anymore. From a business perspective sticking with Microsoft has proven to be a mistake.

I work for a software house in London and we have a large VB6 application that has been built up over many years. VB6 has effectively been dumped by Microsoft, so our application is slowly rotting away. There is absolutely no way we can rewrite it in C# or VB.Net, we just don't have the resources. I suggested that we at least write all new components in C# and use interop, but that turned out to be a real pain, especially when trying to debug.

So what do we do? Spend a fortune rewriting our product in C# while our competitors (who may be using Java) continue to improve their products. And once we have eventually finished the rewrite, will Microsoft just dump .NET and move on to something else?

I have to wonder. If there had been a number of VB6 vendors, rather than just Microsoft, they could never have dumped VB6. In that situation we would have all just moved over to another vendor.

Is anyone else here in a similar situation?

Re:The Microsoft Trap

[vadim_t]

Yup, me.

Maintaining a big database driven app. But I'm in a somewhat less nasty situation. We have this curious setting here, people keep coming up with new ideas for the program, and I keep implementing them. This is allowing me to simply decide that a change is radical enough so that I might as well rewrite that part in C#, and that's what I'm doing. For now it's going pretty well. Since it's an internal app, making people run two programs instead of one is quite possible.

It looks like Mono is progressing quite nicely, so I'm hoping that by the time .NET dies, and I doubt that'll happen soon, I'll be able to continue with Mono.

Of course, the ideal solution would be to stay away from Microsoft, but that's not possible for now. While C# is a nice language indeed, especially compared with VB, all this crap only makes me hate Microsoft more than I already do.

Re:The Microsoft Trap

[callipygian-showsyst]

Is anyone else here in a similar situation?

Yes! We has all these Apple Hypercard applications, then Apple dumped us like a hot potato! However, I'm prohibited from the /. "terms of service" from saying anything bad about Apple, or comparing Apple to Microsoft.

Re:The Microsoft Trap

[Anonymous Coward]

The real problem is that while your competitors were rewriting their products in Java, you were sticking with VB. And now you want to blame Microsoft for that. Sorry, that's not gonna fly. And yes, I am a software developer. Rewriting into another language can get you a lot of benefits that you can quickly roll out into your application. It's not 'just' rewriting. And .NET does not necessarily mean platform/vendor lock, either.

Not that that actually matters, because most people are all still using Windows anyway, and will be for a long time.

Re:The Microsoft Trap

[Eric604]

Code conversion? Sounds like a nice job for some internships.

Re:The Microsoft Trap

[the eric conspiracy]

Is anyone else here in a similar situation?

Yes, we had a similar problem, made even worse by the fact we needed something that could scale a lot better than VB does.

The solution for us was to move to Java. Fortunately our company is growing at a resonably rapid rate so that we were able to adsorb the VB programmers who for one reason or another didn't want to move to Java into some other role.

We still have a few older customers running the old VB6 application but by end of next year they will all be moved over to Java.

I see all this .Net hype, and rapid changes/feature addtions to the language and laugh. MS is leading you down the garden path, and in 5 years MS will be coming out with .New and you will be screwed again.

Don't EVER forget that MS is a pure software company, and that means they MUST continue to sell new versions / churn their customer base to stay in business.

Re:The Microsoft Trap

[MrSteveSD]

Your right of course Mr Conspiracy. Microsoft needs us to keep moving away from what we have, otherwise they won't make money.

I have certainly thought about Java, but we have a lot of Microsoft "inertia" so it would be a big scary move. Then again having to rewrite a huge application again later is more scary.

Of course Java is a proprietary language as well, but I get the impression that Sun are less likely to screw all the developers, at least while they are less powerfull than Microsoft.

It would be nice to use a totally non-proprietary language. C++ would be an attractive option if it wasn't so dangerous. Some sort of C++ with Garbage Collection added and some newever features would be good. There are lots of non-proprietary scripting languages like Python and Ruby of course, but they do not seem suitable for a big business application.

Re:The Microsoft Trap

[putaro]

Hey, I had a ton of stuff written in Dylan! And a big OpenDoc application too! And I've still got to port my accounting system off of Applesoft Basic (hey, wait, didn't Microsoft have their fingers in that one too?)

Re:The Microsoft Trap

[SavvyPlayer]

There is not so much a question of whether MS will dump .Net as whether it will eventually dump .Net 1.1. It has several good reasons to do so, for example, the .Net threading model was rushed out the door a half-baked hack. To continue to support apps written against that model throughout the life of the platform will prove a money-losing proposition even 5 years from now.

Sun dropped support for Java 1.1 years ago. Granted the changes needed to migrate apps to 1.2 were often minor and inexpensive, generally speaking one must go into distributed or desktop software development with the expectation that all such projects have by nature a far shorter lifespan than, say, that of a typical mainframe app.

Because your app was built over the course of "many years", the app must have begun life as a VB4 or VB5 app, no? Despite the fact these iterations of VB each required some changes to your codebase, it would be very interesting to get the scoop on how your IT organization managed to justify building a large mission critical app on VB4 (or 5) in the first place, when even the OS itself could hardly be relied upon to run continuously for 24 hours.

Re:The Microsoft Trap

[dubl-u]

I can't believe this got rated insightful.

The real problem is that while your competitors were rewriting their products in Java, you were sticking with VB. And now you want to blame Microsoft for that.

Having used VB on exactly one project, I must admit that writing a large app in it suggests masochistic tendencies. But I think it's fair to blame Microsoft for following Microsoft's advice.

The fact that many vendors are basically untrustworthy does not mean that you shouldn't yell at vendors every time the shiv you. The vendors can learn from the pain, and your colleagues learn to fear the vendor when they hear you yelling.

And .NET does not necessarily mean platform/vendor lock, either.

You mean in the weak sense that some vendor could theoretically reimplement it someday? That was true for VB, too. Doesn't seem to be working out so well, does it?

Re:The Microsoft Trap

[the eric conspiracy]

Of course Java is a proprietary language as well, but I get the impression that Sun are less likely to screw all the developers, at least while they are less powerfull than Microsoft.

Java is proprietary - but not sole source, That is a big difference.

You are right that something really standardized like C++ would be even better. But we don't have that.

Re:The Microsoft Trap

[16K Ram Pack]

(About 80 miles west of London)

Not so much in terms of implementation, as skill. If I've got to reskill, it had better be so I can gain a performance advantage in terms of products delivered, not to just stand still, which is how I feel.

One real bummer was also that the sessions in ASP and ASP.NET were incompatible. If you had something with session based security, you couldn't just add an ASP.NET page. You had to rewrite it. We ended up rewriting a whole application into .net.

I'm looking seriously at open source, because it seems to me that things are much more about what people need, as opposed to what suits the supplier. That's not to say that things won't get dumped, but of course, you have the option to support it yourself, or find someone else to do it.

As someone else said, Microsoft only make software. In the days of mainframe computing, software was an add-on, and the costs were more about an annual license, which meant gradual and steady change. Most 4GLs which existed for them saw little change, because they weren't constantly trying to get people to shell out for an upgrade.

For all the benefits of change, people should remember the cost of change. It took me a serious amount of time to go from knowing nothing about ASP.NET/C# to really knowing it. Any productivity improvements long-term have to be offset against that. Too often, I see the MS environment being that by the time you've soaked up the costs and become really mature in the technology, it's time to start again.

So, what's the best alternative? Ruby? PHP? Python? Any thoughts gratefully received.

Re:The Microsoft Trap

[TheNarrator]

I agree with you here. I grew less attracted to the Microsoft platform back in the day when I tried to do VC++ development and keep some frameworks I had created maintained over several Microsoft product lifecycles. The feeling I got was that Microsoft is going to change their database API, their inter-object communication API, their web api every year or so without warning. When they do you'll have to read a whole book on the new API, which does mostly the same thing except all the naming conventions are different and it only works on the next version of windows and your development platform. This means that you have to upgrade your development platform, the client, the server, the database server, the app server, the web server, etc. Everytime you do this there is an additional cost. Your framework also broke because there's some naming convention or new gotcha in how the new api works. Microsoft then tells you that you're better off using their implementation instead which lacks cool features of yours but is the standard and is maintained along the upgrade treadmill for you. This library of course costs money. To sum it up, Microsoft's attitude is any system that isn't rewritten from the ground up every year is a legacy system.

Meanwhile over in Java land I've got framework code lying around from 2000 that still works exactly the way I wrote it and upgrades have been painless. Instead of always looking over my shoulder planning for the annual round of api upgrades and breakage and having to read lots of boring technical documentation infused with Microsoft marketing hype each time they re-invent db persistance I can just think about my code and the business I am working on.

Re:The Microsoft Trap

[oldCoder]

Microsoft will only provide good Windows-programming tools if you agree to use lock-in programming tools. So if you want to do good work in Windows programming you will end up using lock-in Microsoft products.

Just look at the design quality of MFC vs the ATL package. Any really good application framework in C++ is going to be, almost by definition, a framework that can be ported to another OS, such as Linux or Apple. So MS came up with MFC that stamps it's Windows identity on every other line without remorse.

When ATL slipped out it was quickly dubbed "A mistake" and the next release was merged back into MFC so no portable programming could take place.

By using a proprietary programming system like .NET and C# or VB.NET, Microsoft is free to innovate and provide truly excellent tools without worrying abouut somebody trying to copycat and port their tools to another platform. Enabling platform portability for Windows programs would be just too expensive. This way, there's no threat.

For the same reasons, Borlands OWL and then Delphi had to be killed, and Java extinguished. Java, though, has not been killed, but MS can attack it through fundamental quality (.NET ...) since they're not portable. Java is the last, best hope for software platform portability on the client and when it's gone, it's gone. Ruby and Python are just niche products, and any Ruby.NET or Python.NET is necessarily going to be just different enough so that the apps written in them aren't platform-portable.

Java and .NET share a weakness, however. If you want to distribute a demo for web download you have to redistribute a massive runtime to download and install with it. And .NET just isn't done yet: WinForms is an interim product and "Vista" will disrupt everything.

Web apps are the next threat to MS after Java. Should we look for MS to start breaking AJAX sometime soon? You'll notice that, as somebody pointed out, MS stopped all development on IE and DHTML when the web platform became too threatening.

COM and DCOM were the MS attempt to side-step all important client and Web systems and thrust a new unportable infrastructure on the user community. But the sword had a double edge and it's complexity and unreliability cut back at Microsoft as well.

If you want to write client code for Windows, live with the lock-in. Avoid COM programming as much as possible.

Re:The Microsoft Trap

[Detritus]

Congratulations, you've discovered why some people insist on using standardized languages with multiple implementations, even though X has all those pretty bells and whistles.

Re:The Microsoft Trap

[Anonymous Coward]

I've just entered a company which is in precisely the same situation. We're located in the city (London) are a well-known publishing and e-commerce company. I'm the technical architect of the e-commerce side of things.

Important:

* Embrace change early and often. Incremental changes are easier to budget for and provide resources for.

* You knew VB was going to die for years. Why didn't you do anything about it.

* It's harder going from a shit C# app written by poorly trained monkeys to a well thought out and designed C# app (my job at the moment) than going from a VB6 to a C# app.

* C# is here to stay. I'd expect something better to turn up in about 10 years.

* C# is easier and cheaper than *everything* else with tools like VS.net, NUnit, NAnt, CruiseControl.Net. The .Net tools aremuch nicer than their java counterparts.

Just jump to it and stop moaning or something better will have come out by the time you've finished talking about it.

Re:The Microsoft Trap

[MrSteveSD]

Maybe that's what the Open Source community should really be concentrating on. A totally open source standardised modern language fit for serious business development. Something that can be enhanced over the years.

There are some pretty smart people out there coming up with languages like Ruby and Python, so its not an impossibility.

It would seem to be a better idea than trying to copy Microsoft with Mono.

What features do we need?
Classes, Inheritance etc
Garbage Collection
Reflection
Aspect Oriented Facilities?
Generics...

Re:The Microsoft Trap

[man_of_mr_e]

Actually, Java is effectively sole source. You are confusing multi-platform with sole source.

Sun makes the only Java platform on many OS's, and they control it's destiny and licenses. So, even if you have your own implementation, you're limited by what Sun says you can do.

If sun decides to drop Java, you can't just take their source and continue working on it, unless they release it open source.

Re:The Microsoft Trap

[man_of_mr_e]

Jezus. Microsoft has been telling the world that VB was going away since 1999. You had plenty of warning. VB.NET has been out since 2002. Conversion from VB to VB.NET is *NOT* that big of a task, no matter how large your project is. 80+% will convert without problems, 10-15% will convert with minor problems. 5% may need to be rewritten, but that's the price of progress. You will gain MUCH more than you lose by converting.

Bite the bullet. hire a temporary contractor to help with the job for a few weeks. The cost of NOT converting will be FAR more than the cost of converting, unless your app truly is dead and won't be maintained.

However, it may be better to convert to C# if you're worried about this ever happening again. It's an ISO standard langauge, and there are multiple implementors. If Microsoft decides to abandon it, there will certainly be people to step up to the plate and fill their shoes.

Plus, there are some very nice VB to C# converter programs to make the conversion job easier, though they won't help you with learning a new language (that you'll have to do on your own).

Frankly, it's suicide to stay with VB6. Even if you move to Java, it will be better than staying with VB6.

Re:The Microsoft Trap

[the eric conspiracy]

Sun makes the only Java platform on many OS's

That doesn't seem right given that there are open source JVMs _and_ gcj.


So, even if you have your own implementation, you're limited by what Sun says you can do.

How is that? You can make any thing you want so long as you don't use the Java trademark.

If sun decides to drop Java, you can't just take their source and continue working on it, unless they release it open source.

I think you greatly misunderstand the history and licensing of Java.

Re:The Microsoft Trap

[Anonymous Coward]

Yes,

Don't use microsoft's "api" languages like vb, c#, mfc etc if you don't want to re write in the future.

Do what microsoft does. Microsoft writes code in C.

Nothing serious is written in any other language just for this same reason. The languages they produce are simply to make it easier for customers and follow the same "upgrade" mentality as the operating system and office do.

Ofcourse you could also use the non ms languages and they tend to not get killed.. ie.. the 3 p's..

R

Re:The Microsoft Trap

[man_of_mr_e]

You can make any thing you want so long as you don't use the Java trademark.

Tell that to Microsoft, who lost the ability to use THEIR OWN IMPLEMENTATION of Java, trademarked or not.

While, I could implement my own version of Java from scratch, if you've used *ANY* sun IP in your code, you're under Sun's iron fist, and as far as I know, even gjc uses Sun IP. For example, the class libraries all have the name "java.*" in them, which means it would be a trademark violation just to include any of the java libraries, even if they were entirely open source.

You could rename them, of course, but then you break all the existing code, making it effectively a new language.

This is one advantage to the CLR, while there are some Microsoft.* and Vb.* class libraries, the standardized CLR uses class libraries free of trademarks (aka System.*)

I think you greatly misunderstand the history and licensing of Java.

I think you greatly underestimate the extent to which Sun has burrowed their IP into the entire platform.

Re:The Microsoft Trap

[MrSteveSD]

Yes we tried the conversion wizard. The time estimated to convert the project kept getting bigger and bigger. Besides which I wouldn't trust the mess spewed out by it.

VB6 had deterministic finalization due to its reference counting. .Net is garbage collected, so you can't reliably convert your code, even in principle. e.g. You have a VB6 class that closes a file when it destructs, in VB.Net the file may be left open for ages.

We don't intend to stick with VB6, but a total rewrite is not really going to happen at the moment. When you rewrite an application it should be because of business reasons, not because your tool vendor has dumped you.

Re:The Microsoft Trap

[man_of_mr_e]

Actually, VB6 was not anywhere near as deterministic as you think it was.

VB6 was based on the COM model (which is one reason it was so easy to interface with COM). While COM does usually release objects when the reference count reaches 0, it's not required to, and can do so when it makes sense.

VB is basically just as garbage collected as VB.NET is. The only difference is that VB.NET is a little more lackadaisical about finalizing, which is why features like the using keyword in C# are so nice (I wish VB had it).

I realize that a conversion is still a lot of work, but it's nowhere near the work that a rewrite is, though of course the real cost is retesting everything.

There *ARE* lots of business reasons to rewrite as well. There are a ton of productivity enhancements coming down the pipe, and a ton of new windows foundation features you can take advantage of (for example, the Windows Workflow Foundation, which an amazing number of VB/database sytle apps could make very good use of).

No doubt, it's hard to stay on top of technology. That's the inherant cost of it. Even Java deprecates features and makes changes.

The problem here is that VB -> VB.NET was a major jump. But, in my mind, it was a necessary one, and the right choice. I think MS could have made extra effort to improve the conversion process, but that's a different argument.

You might also consider the cost of a commerical migration tool, such as ArtinSoft's http://www.artinsoft.com/

You might also want to read this article:

http://www.ftponline.com/vsm/2003_06/online/meader /

In the end, you can't sit still. Plus ca Change.

Re:The Microsoft Trap

[Anonymous Coward]

There is absolutely no way we can rewrite it in C# or VB.Net

Perhaps instead of rewriting you could translate?

I worked on a project that translated VB6 code into Java back in 2001. This was done in about 12-14 months with 6-9 developers. The project had server component with about 1500 classes, and GUI interface with about 120 forms.

It worked because the changes were taking place at the language level and with the help of automated tools. The objective of the translating team is to preserve the language semantics ant not to understand and rework the application. The company we worked for kept developing new features in their application and at the end of the day, they ran our translator to convert it all to Java. The code may not have been the prettiest and most maintainable on earth, but it was semantically correct with similar performance characteristics then the original. The project also involved porting MS SQL to Oracle with the entire reporting infrastructure. There was another team working in that area and they started about 6 months into our project.

Today, the system is still in production, as far as I know. Former VB experts moved to a new language and our client managed to stay in business.

The problem with VB and some other MS technologies in general is that they attract developers who are not capable of seeing its limitations. Today the same group of people is not capable of seeing language design problems in C#.

The best part in .NET is what came from MS cooperation with other industry players, mainly in the web services area. The rest of it is just somebody's wet dream.

Re:The Microsoft Trap

[the eric conspiracy]

Tell that to Microsoft, who lost the ability to use THEIR OWN IMPLEMENTATION of Java, trademarked or not.

In fact Microsoft is still distributing their incompatable 1.1.4 JVM as part of Windows XP SP1. As part of a broad technology agreement Microsoft agreed not to further develop this product. However this technology agreement gave Microsoft broad access to Sun's IP.


I think you greatly underestimate the extent to which Sun has burrowed their IP into the entire platform.

Then howcum we see implementations of JVMs from a broad variety of other sources? BEA, IBM, HP, various Open Source, Charis, and of course the Non-Java Kaffe NewMonics etc. etc.? Explain that, please.

Re:The Microsoft Trap

[man_of_mr_e]

In fact Microsoft is still distributing their incompatable 1.1.4 JVM as part of Windows XP SP1

Umm.. no. They're not. XP SP1 is no longer being distributed by MS (and hasn't for a few years), instead they ship XP SP1a, which doesn't include their JVM.

Further, as part of their settlement with Sun, they had to remove all MS JVM support from a ton of other products as well. See:

http://www.eweek.com/article2/0,1895,1405300,00.as p

And, btw, all of those third party products have agreements with Sun, and are using their IP.

Re:The Microsoft Trap

[Styros]

Last time I checked, Java is directly tied to Sun. Who's to say that Sun won't dump Java in the future?

Re:The Microsoft Trap

[Billly Gates]

Keep VB6 and the app.

Where I work teh application we use is not mdi very friendly even though it spawns seperate windows. Why?

Because its a Windows 2.0 application converted to a Win32 one with tons and tons of baggage along the way.

For example to switch windows you need to select the Window menu option since it does not appear on the taskbar.

But it works right? Why do you think SCO is still around? Many apps are still maintained and just compiled with 15 year old compilers running XENIX or dos in an emulator.

Hell rumor has it that Chase Bank uses an emulator which runs another emulator which runs a 1960's program written cobal that runs all of their transactions. The source code was lost 25 years ago. If its not broke dont fix it.

Re:The Microsoft Trap

[yuiop]

Microsoft writes code in C.

Very little at Microsoft is written in C. Almost all client code is C++ or C#.

Re:The Microsoft Trap

[aarku]

I've been writing C# for about 6 months now and have not touched Microsoft software. What you say? That's right, I've been using Mono.

Re:The Microsoft Trap

[Anonymous Coward]

Most of the JVMs that aren't from Sun are simply ports of Sun's code to other hardware, e.g IBM porting to AIX, etc. They're done under license from Sun.

There are a handful of projects like Kaffe providing from-scratch implementations, but none of them provide all of the APIs of the Sun one.

Re:The Microsoft Trap

[StarsAreAlsoFire]

I don't know. I have NEVER heard a professional friend suggest that something commercial be written in VB. Ever.

Sure, there are some benifits to VB... but not very many.

MS is dumping VB for exactly the same reason that nobody I know would recommend it as a serious commercial option: VB is not a serious computer language. It has so much CRAP in its history that it has to support that there is no way to expand the language without completely changing it.

I also stopped using VB in the era where you would have to go download the VB dll packs for it to work though... so a while back.

Honestly, I would say that any company that cannot re-create an in-house VB application in less than 6 months in 'some other language' using a professional level IDE should have done better research before starting production of said application in the first place.

Core functionality should have been written in C/C++ and placed in DLLS, then called from VB. Etc. I always beleived that was was the POINT of visual basic -- to design visual applications. 'Real code' goes elsewhere; all the events get handeled in the VB code.

While it does sound like I am defending MS, I have to say that I have also avoided .NET for the same basic reason: it is MS. Looks like that might have to change though, because I've been dreaming of something like LINQ for the past three or so years.

Re:The Microsoft Trap

[pamar]

You probably already know about this, but in case you didn't, realbasic (www.realbasic.com) is considered the most viable migration path for people with visualbasic code and skills.

Have a look (I cannot vouch for them personally, because I have exactly 0 experience with VB myself, but everything someone ask for a VB "replacement", Real Basic always crops up).

HTH.

Re:The Microsoft Trap

[gisborne]

You might look into using REALbasic for the conversion. For work that's probably a little less than using the MS conversion wizard, your application would run on Windows, Mac (OS X and 9) and Linux.

Re:The Microsoft Trap

[MrSteveSD]

I'd sort of heard of it, but I hadn't investigated fully. It looks pretty good. Conversion might not be too bad, and it is cross platform and even has inheritance.

The main drawback is that its proprietary again and its a small company. I've been playing with Java and Eclipse today and I'm quite impressed. Aside from being cross platform it looks like you can even compile to native code with tools like Excelsior.

Re:The Microsoft Trap

[pamar]

I recommended Real Basic over any other language (like Java) because from your original post I reckoned that your company cannot affor a complete rewrite... RB claims to be similar enough to make porting a breeze, and even offer a conversion tool that could theoretically make things easier (even if you will have to do some work to complete the port).

I like Java myself, but any language apart from RB will force you to a complete rewrite and there is no specific support for converting from VB to Java... or at least noone I know.

Re:The Microsoft Trap

[the eric conspiracy]

Umm.. no. They're not. XP SP1 is no longer being distributed by MS (and hasn't for a few years), instead they ship XP SP1a, which doesn't include their JVM.

Actually yes they are still distributing MSJVM through Windows Update if you have it installed using Windows SP1.

And, btw, all of those third party products have agreements with Sun, and are using their IP.

Nope. Actually there are at least 3 clean room JVM implementations out there - Japhur, Kaffe and NewMonics. The Apache Foundation has a fourth in progress named Harmony, and GNU classpath is a fifth. I also suspect that the Eclipse incremental compiler is a clean room implementation.

Not one of these would be impacted should Sun decide to terminate all Java licenses.

Re:The Microsoft Trap

[neutralstone]

Well, it's not as though usable substitutes don't exist. Several are listed here, for instance.

Re:Can someone explain the advantages of C# over V

[SuperJason]

I have a whole list of reasons, which have been hashed out millions of times in millions of other forums.

I'll just give you the top reason that I use c#.

In VB.NET, Build and Rebuild are the same thing! If you change one class and do a build, on a large project it can take MINUTES.

The same project and change in c# can take SECONDS to build.

The time savings alone could buy a lot of stuff.

Is Java falling behind?

[Sanity]

It is exciting to see developments like this in C#, particularly stuff like LINQ (the inelegance of using SQL from within other languages has bugged me for quite some time).

Java's language features, by comparison to C#, seems to be moving along at a glacial pace, only recently getting features like foreach loops, and generics.

I personally prefer Java because of Eclipse, but Sun are really going to have to get a move on if Java is to remain competitive with C#.

Re:Is Java falling behind?

[Qui-Gon]

I'm not sure I'd call it a "glacial pace". There are plenty of enhancements being made to Java (the platform and language) beyond convenience enhancments. See JCP.

Re:Is Java falling behind?

[hattig]

Note that Generic Java has been around since 1999 or before, and you could use it if you wanted to have generics in your java code before 1.5 came out.

Sun took their time with Generics for a reason, they're very powerful but easy to get wrong. Maybe they dragged their heels a bit as well - I'm sure that a few people within the Java community didn't like the idea of 'messy code' because of all those angle brackets.

I'm hoping that the C# competition will be a mutually advantageous one, with the existence of the other driving innovation. The biggest threat to Java would be ignoring C#.

I don't like the LINQ syntax, and at some level would it be neater to merely have a neat data access abstraction system than to alter the language?

SQL:
SELECT name, age FROM customers WHERE city='London';

Java (I haven't used JDO or whatever it is called, but a quick implementation of an abstraction would probably come out with something like):
DataSource ds; ... // Returns an ArrayList of results, each result is a HashMap. // Alternatively we could create some form of Table datatype!
ArrayList results = Query(ds, "customers", new Fields("Name", "Age"), new HashMap().put("City", "London"));

I think that enough forms of data access abstraction exist already, and that they are a nicer way of extending a language than actually altering the language itself.

I was just reading http://nemerle.org/Features and I think that these new C# features are merely there to fix things that aren't very nice in the C# language at the moment. I truly hope that SQL on that page isn't how you have to do SQL in C# currently!

Re:Is Java falling behind?

[MSBob]

Java innovates but in a different area. There is a lot of emphasis on extending Java with Aspect Oriented Programming (AOP). There is an incredible extension to Java called AspectJ. You owe yourself to download AspectJ and its Eclipse plugin. You'll see the future of java programming when you try it.

Re:Is Java falling behind?

[Sanity]

I don't like the LINQ syntax

Well, you have two options, one of which is intended to look similar to SQL, the other is closer to the existing C# syntax, either way - I think the syntax is fine, its subjective.

and at some level would it be neater to merely have a neat data access abstraction system than to alter the language?

I really don't think you can do the type inference that LINQ does without explicit support.

Re:Is Java falling behind?

[fupeg]

The answer to your question is no. Java has clearly borrowed some things from C#, though C# itself heavily borrows from Java. The EJB 3.0 spec for example will make use of dependency injection. Take a look at Groovy which will be integrated into Java (javax.script in 6.0.)

Now it is true that as a more widely used (on the Enterprsie level) language, Java is going to move more slowly than C#. C# is newer and trying to take mindshare from Java, so it must move faster. Just having a great IDE is not enough.

Re:Is Java falling behind?

[Anonymous Coward]

Not really. Java is already benefiting from the outgoing attitude towards developers. Particularly, with stuff like LINQ.

In Java, the problems LINQ is trying to address are addressed by O/R tools and frameworks. In fact a lot of the features of LINQ (based on the examples) can be found in frameworks like Hibernate. Perhaps Anders Hejlsberg is merely a follower in this area, or perhaps LINQ is a genuine invention of his, except it looks more like just re-invention of the wheel.

As to Java, the fact the language does not undergo many changes is a good thing. One might say it is a testimony to a good design.

Re:Is Java falling behind?

[horza]

Java's language features, by comparison to C#, seems to be moving along at a glacial pace, only recently getting features like foreach loops, and generics.

Even worse, C's language features don't seem to have moved since the late '70s. Thank god no-one is still using that any more.

Phillip.

Re:Is Java falling behind?

[nikster]

I agree that Java has not improved in ages. I write Java client apps and have been for a while. The JVM has come along very well and since 1.4 it allows us to write really great end user apps - it's fast as hell. Once they get the memory usage under control it will be perfect.
But the language and the libraries are suffering from the weight of (bad) past decisions. There are usually about 3 million ways to do anything in Java. The language was great when it came out, but it has not been improved at all. The improvements in 5.0 are really a joke - too little, too late, and an unbearably ugly syntax.

Here's what Sun would have to do to improve Java:

• Sit down and decide on what to keep and what to deprecate with an eye on deprecating as much as possible and leave a clean orthagonal set of libraries
• rewrite all the tutorials so they make sense, then provide a patterns library for good solutions for common problems (non-existent)
• quit wasting resources on second-best IDEs and embrace Eclipse and the rich client platform. Get over it.
• educate people about threading (other than the "use it when your program is slow, hurrh" kind of crap in the current tutorials).
• Then make the language nicer.

Ruby is publicly available and everyone at Sun should be made to read the Ruby book [1]. Java would improve dramatically as Sun would suddenly become aware of how far behind Java really is.

Newsflash to Sun: Being miles ahead of c doesn't cut it anymore!

[1] free old version or the second edition

Re:Is Java falling behind?

[Trejkaz]

A great IDE would still be a good start, though. I'm still waiting to see an IntelliJ IDEA for C#... the JetBrains guys do seem to be working on a few C# apps lately, so who knows, maybe it will happen.

All personal experience with Visual Spewdio.NET has been less than satisfactory due to all the missing features, mainly thanks to my experience with actually-"great" IDEs.

Re:Is Java falling behind?

[gafter]

Java's developed at a glacial pace in comparison to C#? Um. Have you noticed that C# doesn't have generics yet ("planned for Whidbey") and yet Java has had them for about a year?

Re:Seems to get more like Ruby, Python and Delphi

[RAMMS EIN]

Good, obviously. The one reason Ruby and Python (I don't know about Delphi) are so popular is that they're easy to program in. There is no good reason other languages are not so easy to program in*, so when they become more like the easier languages, that's good.

* People often cite performance, but there's no reason a Ruby program couldn't perform comparably to a C program. Yes, Ruby is interpreted, dynamically typed, and all that, but with enough effort, a compiler could be built that optimized away unused dynamism and yielded fast programs.

Re:Can someone explain the advantages of C# over V

[FlorianMueller]

This rebuild thing is indeed a good point. My project is pretty big, and that's why I know all too well but you're talking about. I make extensive use of DLL's to minimize the amount that gets recompiled, but obviously it would be nice to be able to reuse object code at the build level.

Re:Such a pity

[hattig]

There simply is no product that delivers the same kind of raw productivity.

Which is why all large institutions pay big bucks to J2EE developers to develop in-house applications using ... J2EE!

It is nice that C# exists, and it has a lot of nice features, but I fail to understand you 'raw productivity' statement. How is C# more productive to code in than, say, Java 5?

I'm not dissing your opinion, I just want to see some solid reasons. I think that the existence of C# is good for everyone as it will drive innovation in Java, and vice versa, but I don't see where it has massive advantages overall.

Bzzzzt

[Anonymous Coward]

Mono is good for writing toys but nobody is going to bet the baby on Microsoft not enforcing their IP rights.

Not really

[Sanity]

C# is strongly typed, Ruby and Python (not sure about Delphi) are dynamically typed. The difference is that with C# (and Java), the compiler can prevent all sorts of bugs that in Ruby and Python you will only encounter at run time.

You might think C# is moving away from being strongly typed with the new "var" construct, but you would be wrong. All types are still inferred and verified by the compiler.

As IDEs and compilers grow more powerful, I think people will start to realise that strongly typed languages can be just as easy to program in as dynamically typed, and you get the added benefit of more help from the compiler at spotting bugs.

Re:Not really

[GnuVince]

You got it wrong. C# is strongly and statically typed, while Ruby and Python are strongly and dynamically typed. Get your definitions right, dynamic vs static refers to when type checking is performed, at compile-time or a run-time. Strongly typed vs weakly typed means whether you can freely mix types. C, PHP, TCL are weakly typed, Lisp, C# and Ruby are strongly typed.

Re:Not really

[Ambassador Kosh]

I think you mean that C# is STATICALLY typed which means the typing is done at compile time. C#, Ruby and Python are all strongly typed but Ruby and Python do the typing at runtime. So C# is Static Strong Typing and Ruby/Python are Runtime Strong Typing.

My experience so far even with stuff that has tens of thousands of very well refactored code is that static typing has caused me more problems then it has solved.

Mostly because type systems are not very good and most bugs I run into have nothing to do with object type.

Re:Not really

[Courageous]

A bit of history. The static languages people don't regard static and strong typing to be different. Hence, they'll say insane things, like assert that "C" is "strongly" typed, which it isn't. It's statically, but weakly typed, where "weakly" should be taken to mean that it really is possible to treat a value type as some other value type.

So while I'm with ya on the whole "python is strongly, dynamically typed," and "c is weakly, statically typed" thing, if you were to go out to textbook CS, you might have some 'splainin to do. Only the dynamic language folks tend to understand this distinction so well.

C//

Re:Not really

[Waffle Iron]

The difference is that with C# (and Java), the compiler can prevent all sorts of bugs that in Ruby and Python you will only encounter at run time.

Yeah, and 9 times out of 10 I will have run my program, got the runtime exception, seen the stack trace, spotted the error and fixed it by the time your compiler has finished spitting out its litany of obscure type errors for you to work through.

Re:Not really

[Anonymous Coward]

If I don't wear a seatbelt in my car I find that I can get in and out quicker 9,999 times out of 10,000. The thought of this saved time gives me a warm fuzzy feeling on the other occasion when I end up flying head first through the windscreen.

Re:Not really

[GileadGreene]

Eh? I've seen all sorts of "static language people" complain about C's weak typing. Of course, these folks tend to be Haskell or SML users rather than C users, so they actually have some idea of what constitutes "strong" typing (as well as static typing).

Now, you will see some theoretical CS types argue that dynamic typing doesn't constitute typing at all, i.e. that tagged values are not the same as types in a type-theoretical sense. However, I've never heard any of them claim that C is strongly typed either.

Re:Not really

[Waffle Iron]

If I don't wear a seatbelt in my car I find that I can get in and out quicker 9,999 times out of 10,000. The thought of this saved time gives me a warm fuzzy feeling on the other occasion when I end up flying head first through the windscreen.

You'd have a point if static typing were as useful as seatbelts. Unfortunately, it's actually more like filling your car with Silly String. It won't actually save you from many hazards, and it gets in your way so you can't see what you're trying to do.

Re:Not really

[spongman]

that's fine if your program is so simple that every posible code path can be executed in a short amount of time, but for anything but the most trivial rograms this is impossible (see Turing for a reason why). This means that for dynamically typed languages, the onus is on testing to find a whole slew of errors that statically-typed languages can find at compile time.

not a good solution for multi-K-line programs written by large teams of programmers.

Re:Not really

[Waffle Iron]

So because the function says it takes an integer, and I fed it some integer, everything is going to be fine by definition? I think not. You are still going to need to exercise every line of code in runtime tests.

Static typing finds maybe 10% of the possible potential errors in your program at the expense of doubling the effort to write and understand it. In some cases static typing may be a necessary evil to attain the required execution speed, but as a "safety" feature any benefits it provides are outweighed by the complexity it adds to your code.

Re:Not really

[Coryoth]

C# is strongly typed, Ruby and Python (not sure about Delphi) are dynamically typed.

First off it's static typing that C# has and Python and Ruby don't. Python and Ruby have strong typing, while Perl and C have weak typing. Delphi has strong static typing.

As a side note, it looks as if Python is going to get optional static typing with type inference in future versions, which could make for an interesting and flexible language.

Jedidiah.

Re:Not really

[Coryoth]

So because the function says it takes an integer, and I fed it some integer, everything is going to be fine by definition? I think not. You are still going to need to exercise every line of code in runtime tests.

Static types are just a very weak form of formal specification. A stronger form would be something like contracts (preconditions, postconditions and invariants) as used in things like Eiffel and D and SPARK, which allow you to specify not just the type of the inputs and outputs, but specific properties that are required of them. Another step up the formality chain again requires you to be very explicit in your specification allowing the contracts to be statically checked prior to compilation - that covers all the code paths and doesn't require runtime checking - and properties of the software to be formally proved.

Static typing finds maybe 10% of the possible potential errors in your program at the expense of doubling the effort to write and understand it. In some cases static typing may be a necessary evil to attain the required execution speed, but as a "safety" feature any benefits it provides are outweighed by the complexity it adds to your code.

Whether the benefits you gain from any level of formal specification, be it static typing or full formal methods, are worth it depends on how badly you need to be sure the system works and how costly any errors are. For some systems it really isn't that important - having a prototype or working code is more important that catching every last glitch. For other systems (security, avionics, banking and finance software etc.) any sort of glitch, bug or exploit is sufficiently costly that the extra effort to catch as many errors statically as possible is going to be worth it. There is also a spectrum of different needs in between.

As another note, static types needn't complicate your code as much as you might imagine. Try looking at a language with good static types (SML or Haskell come to mind) and you'll see that static types can be quite easy and require very little extra work (in comaprison to static types in other languages).

In my experience static vs. dynamic typing is really a matter of how well I've managed to nail down exactly what sorts of data structures I'm going to use. If I'm still doing exploratory/prototype/research code then dynamic types win out every time because they provide incredible flexibility. If I have nailed down what data structures I want to use then static types aren't any extra work and provide and extra buffer of safety.

Jedidiah.

Re:Not really

[GileadGreene]

n my experience static vs. dynamic typing is really a matter of how well I've managed to nail down exactly what sorts of data structures I'm going to use. If I'm still doing exploratory/prototype/research code then dynamic types win out every time because they provide incredible flexibility. If I have nailed down what data structures I want to use then static types aren't any extra work and provide and extra buffer of safety.

Actually, I'd argue that static type checks are just as valuable during prototyping. They force the compiler to check the sanity of the data structures and functions you've put together. If you've written a new function that's trying to do something incompatible with the data structure you've already defined the compiler will flag that immediately. Then you can evaluate whether you need to modify the data structure definition or the function in question. Without a static type check you may end up with something that passes your unit tests, but doesn't truly represent your intentions once it hits corner cases (not that you can't end up in that boat even using static checks, but it's less likely).

I should probably point out here that I'm thinking in terms of development using a type-inferred language (Haskell, ML, etc) in which static typying is not so cumbersome.

Re:Not really

[harlows_monkeys]

Yeah, and 9 times out of 10 I will have run my program, got the runtime exception, seen the stack trace, spotted the error and fixed it by the time your compiler has finished spitting out its litany of obscure type errors for you to work through

In other words, your bugs show up after deployment, his bugs are found before deployment. Guess which one of you I'd hire to write my critical systems?

Re:Not really

[Waffle Iron]

Huh? Where did I say that the program got "deployed" before debugging was finished?

If you think that "It compiled without errors" == "It's ready to deploy", then you shouldn't be involved with writing critical systems.

Re:Not really

[spongman]

sure, but that case is the same for both camps (although statically-typed languages could potentially subclass 'integer' to a more restrictive set). the argument that static typing is more difficult is purely subjective, but I'd argue strongly against it. what happens, for example, if one of my teammates changes some key structure in a library. how do i know that my code that uses it is going to work? with dynamic typing there's no complete code analysis, but with static typing I have a tool that'll tell me exactly where the changes need to occur: it's called a compiler. as i said before, if you're writing trivial programs then dynamic typing is great, hell bash is great, but if you're working on a large project in a large team over many years then it just doesn't cut it.

Re:Not really

[Courageous]

Well, you have me there. Let's just say that, "in certain crowds, there are those who seem to believe that strong and static typing are the same thing." My explanation for which crowds those were, exactly, may have been a bit faulty... :)

C//

Re:Such a pity

[Da Fokka]

It is nice that C# exists, and it has a lot of nice features, but I fail to understand you 'raw productivity' statement. How is C# more productive to code in than, say, Java 5? I'm not dissing your opinion, I just want to see some solid reasons. I think that the existence of C# is good for everyone as it will drive innovation in Java, and vice versa, but I don't see where it has massive advantages overall.

I do like C# slightly better than Java 5 but that's not the big difference. It's the tools. VS.NET just works really well. I've worked quite a lot with Eclipse and although it's a nice IDE, VS.NET (especially 2005) is lightyears ahead.

Re:Such a pity

[Anonymous Coward]

so youre saying you would recommend a less appropriate technology for the job simply to satisfy your bias against microsoft?

Re:Such a pity

[iGN97]

I'm going to go out on a limb here and state my personal opinion: Java, as a mainstream platform for developing desktop applications has failed.

The enterprise isn't everything, and while Java 5 is excellent at creating enterprise applications, it just cannot compete with C# on .NET or Mono for desktop applications.

Feel free to point at any number of successful Java desktop applications (Eclipse, X-Develop, etc), but they all demonstrate the same thing: Java was never created to play ball with the other kids (I will not speculate whether this is accidental or intentional). This is especially true for Windows, which is the largest target platform for desktop applications. Take a look at how you install Eclipse on Windows, for example. Does it even slightly resemble the rest of the desktop experience?

As a desktop user, I constantly "notice" Java applications, whether during installation or when it's running, because of odd looking UIs, missing runtime environments (which are often painful to get a hold of. Even WinFX-applications have a fairly nice download frontend.). I don't want to "notice" the applications, I just want to run them.

Regarding the enterprise, I think Java is an excellent alternative, just keep it away from the users. I think that currently .NET might have an advantage in developer productivity, but Java wins hands down because of the richness of runtime environments supported. And Java is great, as long as you maintain a nice bufferzone between it and your customers (be it a web-presentation layer or a web-service, etc).

It will be fun to see what happens with the enterprise, but I feel that someone needs to take a big step back if they are to stop C#/.NET/Mono from taking the desktop. Saying "I'm just sticking with C, and so should you" is only going to work until the gap becomes large enough. While I personally find the managed environments superior today, noone can argue the speed at which things are progressing. The managed environments, .NET and Mono are going at light speed while C is at a virtual stand-still.

Writing unmanaged C++ for Windows applications for Vista and beyond is not going to be a good idea; it's going to take a long time compared to the alternatives (C++/CLI, C#, VB.NET), and the result is not going to be better (look at the Avalon-applications from the PDC keynote, which are mainly XAML, and Sparkle which is completely managed; they are the coolest UI-experiences I've ever seen).

Re:Can someone explain the advantages of C# over V

[Mr2001]

If you like VB.NET syntax, there's probably no reason to switch.

Personally, I hate just about every aspect of VB.NET's syntax. Too wordy and inconsistent. 'List (Of Integer)' instead of 'List<int>', 'CType(x, String)' instead of '(string)x', etc.

A more objective advantage is C#'s support for unsafe code. If you need to do high-performance bitmap operations, or pass pointers back and forth to native code, you can't do it in VB.

Also, the yield keyword is simply awesome if you need to implement IEnumerable. In VB, it's a pain to write even one implementation, but with C# 2.0, you can easily make a bunch of enumerable methods on the same class. For example, you could make a collection class that can be used like so:

MyIntCollection col = new MyIntCollection(...);

// process every item
foreach (int i in col) ...

// process every second item
foreach (int i in col.SkipItems(2)) ...

// process every item between 1 and 100
foreach (int i in col.ItemsBetween(1, 100)) ...

// process all items backwards
foreach (int i in col.Reverse()) ...

CCL

[alucinor]

Hmm ... the syntax reminds me of CCL ....

I guess you'd have to be in healthcare IT to know what I mean, though.

Re:Next version : line nunbers

[Ray Alloc]

Just like C-hash

Written in both--

[Tominva1045]

As someone who has served as a consultant and written applications in both languages this is what I can add:

My VB apps were much quicker to prototype- to provide something to a customer in helping them determine requirements when they aren't really sure what they need. Also, the VB apps are often easier to maintain (less cryptic code can be easier to maintain).

My C# apps were usually written in that language because the client had a preference for it- not that any logical reason was given (unless you count putting C# in marketing information to justify higher costs). Also, because the lanugage can be more difficult to follow (meaning less likely the client's in-house developers can code or update it) than VB, consultans can often charge a higher hourly rate to code in it.

Both languages build to the same IL output.

Comments such as this one from above a great language for people who don't want to know to much about what thier program is actually doing - but VB .NET is, and will always remain a hack.

show a real bias whilst not providing any detail whatsoever. So take them with a grain of salt. Unless your reading machine language, you don't really know what your appp is doing.

It is possible to write great code in each. It is also possible to write really bad code in each. It comes down to the developers ability and preferences.

If you have a nice fat contract and want to perch in your ivory tower looking down upon the commoners, go with C#.

If you have demanding clients and need to give yourself some breathing room, go with VB.

Re:Can someone explain the advantages of C# over V

[FlorianMueller]

Thanks, this is useful information. I will need some unmanaged stuff in my project but it will be OK for me to just have that in a separate DLL, which may then be written in C++ or C#. As for type conversions, there are various keywords like CStr (convert to string) or CInt (convert to integer) that are a shorter alternative to CType(Variable, Type) for at least the most commonly used types.

Language Bloat?

[Xepo]

They keep adding more and more stuff to the language...is there anyone that can really read all of the code that is possible to be written in C#? It sounds like a readability nightmare to me.

Heck, it took me years to learn all of the components in C++, and I'd bet that the specification for the complete language is now much smaller than C#'s. And there's still stuff waiting to be discovered on the level of template meta-programming.

Is all of the stuff they keep adding actually useful? Or is it just being added so that they can give the impression of progress, and maybe convert more people to using it? Granted, I'm excited about C++0x, but unlike what I would be thinking if I used C#, I'm not worried because I trust the standards body to not put completely unnecessary stuff into the language. What do you C# programmers think?

Re:Language Bloat?

[linumax]

I'm not worried because I trust the standards body to not put completely unnecessary stuff into the language. What do you C# programmers think?

Don't you consider ECMA a standard body?!!!
Standard ECMA-334 C# Language Specification

Re:Language Bloat?

[Xepo]

Well, sure, it's a standards body. But I could grab a couple friends, goto mellow mushroom, and design a language over some booze, and call ourselves the standards body for that language. That doesn't mean anyone would trust us. The C++ standards body is taking time (perhaps a little too much, but still) to consider every aspect of the language, how the changes will impact existing programs, whether the changes are necessary, or even useful, and getting community feedback. If the ECMA is indeed the one advancing the language, and not just controlled by some group at MS, then I think I'd be hesitant to trust them to not screw up my projects in the future.

Re:Language Bloat?

[man_of_mr_e]

Well, just like the more esoteric features of C++, you don't have to use them if you don't want to. If you want to stick to a subset, you're more than welcome to.

BUT, for those people that DO want to use them, they provide powerful features that would require either a lot more work, or couldn't be done at all. Or, the features make the language safer, and less error prone for certain tasks.

Lots of people still write C++ code as "more strongly type C" or "C with classes". They don't use templates, or overloaded operators, or placement operators, or anything else. And that's fine. That doesn't mean those features are useless.

And, C# *IS* an ISO standard. Version 1 was ratified by the ECMA and was then "fast tracked" and accepted by ISO. Version 2 has (as of July) been accepted by the ECMA and is now on the fast track to ISO. Version 3, which won't even have an impelmentation by Microsoft or anyone else for at least a year or more to come will likely be standardized as well.

Standardization doesn't mean the lanugage becomes static and never changes. It means that 3rd party vendors have a specification to follow for interoperability, and that you can rely on 3 vendors implementing the same standard to be relatively interoperable.

Re:Language Bloat?

[Xepo]

Sure, if you're working on a personal project, you can choose to use them or not. But if you're even on a two-person team, you have to know at least the set of features that the other person knows, in order to be able to read their code. If you're working on anything decently large, say, a 10-15 programmer team, then you basically have to know the whole language, or have guidelines that say which features will and won't be used. Hence, language bloat is a problem.

Sure, it is standardized. Just as how I arrange the socks in my drawer is standardized. I never said that C# wasn't standardized. However, that standardization means close to nothing. I said that I trust the C++ standards body to not mess things up, not that I trust *any* standards body. I never said that it never has to change (in fact, if you had paid attention to my post, I said I was excited about the change), I said I was glad that the C++ standards body was taking their time, and picking out the essential features from the cruft, instead of just throwing in everything, and having to yank the kitchen sink from Mozilla's hands to be able to throw it in as well.

Re:Language Bloat?

[Baki]

But you'll at least have to READ and understand it, since you'll see all kinds of constructs in code from others.

No, I would rather see different programming languages for different programming styles (e.g. functional or OO), not trying to mix every possible feature into one single language.

It may keep the appearance, liked by managers, that there is one "standard" language that "everyone" knows. But in reality, you'll have a mess of features and mixing them, and only few programmers being able to read and understand all code they have to work with. Very dangerous IMHO.

Re:Language Bloat?

[man_of_mr_e]

And what happens when you start a project in the "baby" language, and then discover you need "the advanced language" to implement a given feature. Now you have to rewrite you code to the new language, just because your current language isn't powerful enough.

That's silly.

Re:Language Bloat?

[spongman]

Version 3, which won't even have an impelmentation by Microsoft or anyone else for at least a year or more to come...

BTW: my OP linked to a download for the C# 3.0 compiler. It works just fine and the IL it generates runs on the 2.0 CLR.

Re:Language Bloat?

[Anonymous Brave Guy]

And, C# *IS* an ISO standard. Version 1 was ratified by the ECMA and was then "fast tracked" and accepted by ISO. Version 2 has (as of July) been accepted by the ECMA and is now on the fast track to ISO.

Which is interesting, because normally ISO won't allow updates to a standard without a certain length of time between them to ensure stability. I can't remember the exact spacing required for different categories, but I'd be surprised if the C# "standard" could really be supplied to and approved by ISO three times in such a short space of time. I'm deeply suspicious of ECMA, and of this whole "fast tracking" process.

Re:Language Bloat?

[man_of_mr_e]

BTW: my OP linked to a download for the C# 3.0 compiler. It works just fine and the IL it generates runs on the 2.0 CLR.

That's true, but I was referring more towards a commercial implementation, not a research one. Sorry for the confusion.

Re:Language Bloat?

[man_of_mr_e]

The purpose of "fast tracking" is that there is very little to be gained by two seperate standards bodies doing a full standards process (and in fact, it can be detrimental). If it's been done by one body, then ISO need only review the work and decide on whether it should be accepted or not.

Fast tracking requires a 2/3 majority vote of all ISO members to aprove. So this isn't a "under the radar" kind of thing.

As for the length of time, I don't think that applies to fast tracked standards. It typically applies to ISO developed standards as far as I know.

Microsoft May Have a Future

[alucinor]

Thanks to some of the brilliant developers at MS, we can get some awesome stuff out of this company, like C#.

Now, too bad management will keep on trying to tie .NET down to their sinking ship, Windows.

If only the .NET framework could be freed from Windows, and given the official blessing to target all platforms, including Linux, then Microsoft could set itself up as the supreme tools vendor for the platform. It'd be a bright future for MS, and overnight .NET would probably become the de facto standard for development on Linux!

But no ... the stodgy petrified boys up top will always put Windows first ... to MS's undoing, no doubt.

Re:Microsoft May Have a Future

[Anonymous Coward]

Wont work. Ratio of developer licenses to end-user licenses is way to small. They would have to charge $10,000 per seat for developer license to make even close to the same revenue. Their only hope is to make Windows so good and cool it compels people to keep upgrading. Fact is XP is pretty good client, and 2000/2003 server is pretty solid for most server tasks. This is good for everyone, because it will force MS to make really good products finally. Windows client wont die for a while, until Google implements 90% of what you need a client OS for.

Re:So what?

[xanatos367]

Why is parent a troll? Ironically enough it's true.

- Windows using, C# coding slashdot reader.

I just realized...

[Xepo]

in about six months, they'll be able to rename C# "perl without the @, or the $"! "P-@$"? They can advertise it as "As powerful as a scripting language, like perl!", and all of the half-intelligent programmers will read that as "Gives you nightmares from trying to read code, just like perl!"

Where's the Kitchen Sink?

[ChaoticCoyote]

Why, oh why must language inventors continue to add every possible concept to their pet project? Must every language try to be everything to everyone?

No programming language is suited to all applications; anyone who claims omnipotence for their particular language is exhibiting either ignorance or arrogance. A wise programmer knows how to use many tools in appropriate contexts; it's this sort of rational maturity that separates amateurs from professionals. It makes no more sense to develop a web-hosted applet in C++ than it does to write a high-performance batch-processing engine in Java. Using multiple programming languages isn't a simple matter of syntax -- it's a matter of divergent perspectives that force me to think about what I'm developing.

A disturbing trend has emerged in the last decade, with developers trying to make every programming language applicable to every task; we add object-oriented features to COBOL and Fortran, add generic types to Java, and expand the C++ library with a plethora of complex templates. Now C# is "borrowing" all sorts of ideas from all over the map, without any thought for how all these pieces fit together into a cohesive and logical whole.

In the end, we get bloated tools that include features ill-suited to their core design. Instead of focusing on a clear set of goals, languages compete in an edless feature competition that often ignores sound engineering practices.

I have done professional C# programming, and the language does not impress me. Certainly it has some very good ideas -- but it lacks any sense of cohesion in design or intent, and it's ties to Microsoft make me leary of using it for long-term coding projects.

Re:Where's the Kitchen Sink?

[ivoras]

The entire parent post can be summarized as "Real Programmers Use Assembler".

I myself welcome each and every language feature that will make programming easier. It's true that not every language is optimal for every purpose but it's up to the programmer (or system designer) to choose which language to apply where.

(And yes, I know assembler. So what?)

Re:Where's the Kitchen Sink?

[superid]

I don't think this is a kitchen sink addition. I think this will be a welcome addition to a very large fraction of C# developers. First, my gut feeling is that the majority of non-trivial C# applications connect to databases of some kind, this will help that. Second, even if you don't use a DBMS this will be useful for complex operations on pretty much any data structure that you create.

This will make me a lot more productive and I'm going to install it ASAP!

Re:Where's the Kitchen Sink?

[ChaoticCoyote]

The point of my original post is: Real programmers use concise tools that are appropriate to the task at hand.

The more you complicate the plumbing, the easier it is to plug up. Creeping featurism is the major source of bugs in software today -- the more features, the harder a program is to implement, test, and debug.

As for assembler: I don't do much of it any more, except on certain performance-critical inner loops, and only then if the app is guaranteed to be platform specific. Otherwise, I stick to C, C++, Java, Fortran 95, and Python for most work, sometime slipping itno Visual Basic or C# as required.

Re:Where's the Kitchen Sink?

[ChaoticCoyote]

In C#'s domain, improved database connectivity is very important. Heck, I've been known to write a bit of VB or C# when the situation calls for it -- if I want a quick Windows app, I reach for C#, not C or C++. However, I don't do very much platform-specific work anymore, and Mono notwithstanding, .Net-tools aren't really appropriate to the code I develop.

Re:Where's the Kitchen Sink?

[Anonymous Coward]

Try Python. It is very close to a do-anything language. The only problem is that programming in it is so easy that we don't have a standard:

web framework
gui

And our libraries formatting conventions differ across modules. For example the logging module uses Java naming conventions. thisIsMyMethod(). However, other modules use this_method().

Not too big of a deal, but definitely causes you to RTFM a time or two.

Re:Where's the Kitchen Sink?

[XNormal]

Why, oh why must language inventors continue to add every possible concept to their pet project? Must every language try to be everything to everyone?

This isn't just a random heap of features. They all combine to create the query syntax which can run in-memory as C# code or be translated to external query languages such as SQL or XQuery and sent to a remote server for execution.

No programming language is suited to all applications;

But C# with embedded query syntax is an elegant solution to bridging high level languages and databases. This answers a very real and very pressing need in the industry.

Certainly it has some very good ideas -- but it lacks any sense of cohesion in design or intent, and it's ties to Microsoft make me leary of using it for long-term coding projects.

It only looks that way if you don't RTFA...

Re:Where's the Kitchen Sink?

[shutdown -p now]

A disturbing trend has emerged in the last decade, with developers trying to make every programming language applicable to every task; we add object-oriented features to COBOL and Fortran, add generic types to Java, and expand the C++ library with a plethora of complex templates. Now C# is "borrowing" all sorts of ideas from all over the map, without any thought for how all these pieces fit together into a cohesive and logical whole.

True, true... *shaking head* all those nice people, if only they knew how much time they could save simply by discovering Common Lisp for themselves instead of reinventing it based on yet another language - Now With Curly Braces (tm)!

Re:Where's the Kitchen Sink?

[Bastian]

C++ was also built up over time with a continuous chain of "welcome additions." And then the language collapsed under its own weight.

Isn't the whole point of the .NET environment that it suddenly becomes trivial to get modules written in two different languages to work together? If so, then why isn't it being leveraged by, say, using Microsoft's Scheme.NET (or whatever they call it) for areas where functional makes sense, using C# in areas where imperative makes sense, etc. etc.

Makes me wonder why they bothered developing the CLR and much of the rest of the .NET technology at all if all they ever really planned on doing was bloating up C# and forgetting about all those (what we might now recognize as) cute product demo toys they rolled out in the beginning.

Re:Where's the Kitchen Sink?

[JChung2006]

In addition to accessing data stored in relational databases, these changes in C# 3.0 and the LINQ project are also useful for extracting and manipulating data stored in XML.

Re:Where's the Kitchen Sink?

[man_of_mr_e]

I think the part you misunderstand is that C# is effectively the "Reference language" for the CLR. Therefore, anything the CLR does, C# must do as well, because it's the "reference implementation".

That means, adding features to the CLR for a Scheme.NET or Eiffel.NET necessarily means adding those features to the reference language as well. It's all part of the standardization process.

It would be silly to have the CLR do things that C# didn't support. You wouldn't have a reference implementation for the standards body to accept and approve.

Re:Where's the Kitchen Sink?

[ChaoticCoyote]

I did read the article, and (as I said elsewhere in this thread) there's good reasons to add the query "stuff."

But the query stuff isn't the only thing they are adding to C# with version 3.

In some ways, I think it's a dick-measuring contest: "Hey, the X language has frotz! We'd better get frotz too!"

Re:Where's the Kitchen Sink?

[tydbits]

This isn't quite so. In particular C#:

• does not support named indexers (both VB.Net and C++/CLI have that),
• does not have support for managed pointers in return values (C++/CLI can return managed pointers, e.g. T% f()),
• does not have notion for typed references to boxed values (C++/CLI have that: int^),
• does not support covariant or contravariant generic parameters (Eiffel uses genercs variance),
• etc.

Re:Such a pity

[heinousjay]

Lightyears ahead in what way, exactly? I've used them both, as well, and I found that VS.NET was great as long as I wanted to do something Microsoft wanted me to do, and fell right apart as soon as I tried to do things another way - maybe you know the mystical wonders I missed. Care to list a few?

Re:I recomend Java

[Da Fokka]

It's much better, runs everywhere and is already used by many big vendors. I strongly recomend Java.

That's nice to hear. Fortune 500 companies are always interested in recommendations by Anonymous Cowards.

Re:Such a pity

[hattig]

I'd argue that Java isn't a major success on the desktop because:

1) AWT sucked totally
2) Swing integrated poorly because of its design. Instead of being a neat interface like WxWindows on top of native user interfaces and layouts, etc (with a Java implementation for unsupported desktops), it did it all itself.

I can only name two mainstream Java desktop applications off the top of my head - Azureus and LimeWire, both of which have slightly dodgy reasons for existing. IIRC they either use SWT or custom interface code anyway. SWT is really the only viable option for writing desktop applications in Java these days. There are probably some other Java applications that use, e.g., KDE or Gnome or Win32 bindings too.

Thing is, the world is moving to web based interfaces. Whether it will be Google's vision, or Mozilla's vision (XUL), or Microsoft's vision (XAML) remains to be seen, but Microsoft have the existing market benefit currently.

I certainly wouldn't start a new Windows application using C or C++ these days, but that is a completely different discussion.

Bashing MS is the whole point of this website...

[bigweenie]

Are you a newbie? That is the whole point of this website.

If you don't want to bash MS, then go to some MScentric site and wax wonderful about their propietary crapola. Some that are on the MS payroll continue to espouse the virtues of MS here (perhaps you?!), but we all enjoy how much time, money and effort MS spends trying to alter the overall message of slashdot.org.

Lesson for MS to learn: FUD doesn't effect a community of a single mind and purpose.

C# will not replace Java. It is a wonderful Java knock-off with a great IDE (Visual Studio), but it is not a Java killer.

End of rant.

/bigweenie

Only if you like being chained to M$

[Anonymous Coward]

Just ask executives and managers if they want their business chained to whatever Microsoft decides 5-10 years from now.

Once you ask that question, I doubt any executive would select the Microsoft solution.

Re:Only if you like being chained to M$

[EvanED]

As opposed to being chained to Sun?

Microsoft and innovation

[XNormal]

As an open-source I really hate to say this but...

This is a terrific example of honest-to-god innovation from Microsoft.

Yes, I know, the building blocks have been available in some form or another in many other platforms. But so far nobody has managed to bring all of this together so elegantly.

The features are not just a random heap of syntactic sugar. They combine to create the query syntax (using lambdas) which can be either executed directly in C# (with the help of external methods) or be available as a runtime data structure (shades of lisp) that can be translated dynamically to an SQL or XQuery and sent to a remote server for execution. The type inference ensures that the query syntax is not littered by type declarations yet remains typesafe.

Nice work, Anders. I guess the Comega team deserves much of the credit, but I have the feeling it was Anders who brought it all together into a clean and not too "academically smelling" framework.

Re:Microsoft and innovation

[tkinnun0]

My experience with lambdas leaves a lot to be desired, but these examples look suspiciously similar:

var numsInPlace = numbers.Select((num, index) => new {Num = num, InPlace = (num == index)});

var lowNums =
from n in numbers
where n select digits[n];

How many other ways are there to do the same thing? Clean, I think not.

Re:Microsoft and innovation

[XNormal]

How many other ways are there to do the same thing? Clean, I think not.

Anders Hejlsberg is no Guido Van Rossum and Microsoft doesn't have the luxury of carefully evolving language design over a period of 15 years.

Syntactic sugar naturally means TMTOWDI but it's not always evil. In this case I think it's justified. 1000% more justified than the monstrosity that C++ has become.

Damn it. I find myself defending Microsoft too much lately... It doesn't mean I suddenly started to like their business strategy, but there's less and less to complain about from a quality point of view.

Re:Microsoft and innovation

[Dan Berlin]

Except that SQLObjects for python has a very close syntax and *does* do what LINQ does. Sorry, it's not innovation, nor have just "building blocks" been available on other platforms. It's been here, in production use, for years now.

Re:Microsoft and innovation

[Anonymous Coward]

This is a terrific example of honest-to-god innovation from Microsoft.

Oh for fuck's sake. Most of the stuff here is standard equipment in Haskell and Lisp.

And as for the LINQ crap, well, for *decades*, people like like Chris Date have been *begging* for relation operators in mainstream programming languages, along with built-in relation types (as opposed to just arrays or regular sets).

Even though the core of the relational algebra has been defined since the 70's, nobody has bothered to do this. We have arithmetic embedded in most languages (+, -, *, etc) why not fundamental data operations?

And now that Microsoft has created LINQ, instead of doing the right thing and embedding a COMPLETE relational algebra, they come up with some craptacular SQL ripoff.

If you've studied the RM (which you should before anybody lets you near a computer), you know that a certain minimal set of operators are needed to express *any possible* data query. Take a good look at LINQ and let me know what's missing.. that's right.. JOIN. The most fundamental relational operator is apparently MIA. WTF? Are they waiting for 2.0?

And on top of that, they don't use algebraic notation, they use SQL-like semi-procedural notation. This is like doing arithmetic like this: "ADD A TO B" instead of the more algebraic "A+B".

It's just the usual ad-hoc junk, designed to move copies of product, rather than solve problems completely and correctly once and for all (a COMPLETE query language would never need a 2.0 version, you know what I mean?).

Re:Can someone explain the advantages of C# over V

[ilyanep]

As far as I see, .NET is a 'program with whatever you want' system. All the languages are being brought up to the same level so that people who are more experienced that C or Java can use C++ or C#, while VB programmers can use VB.NET (if they're not too lazy to re-learn the language)

The reason one might not go to C++ or Java is:
C++ has a little bit more tricky syntax than C# (as one book I have says: "C# is a language of few words") -- there are many fewer keywords in C# than C++

Java may not deliver the same functionality that a programmer needs, or maybe they're forced in some circumstance to use Visual Studio...

BTW, the only language I've ever seen (course not that I've seen them all) with END IF is Visual Basic...

Working?

[liquid_rince]

"working compiler can be found on MSDN"

This means the other compilers AREN'T working.

Re:Working?

[Anonymous Coward]

nitpick.

Re:Working?

[liquid_rince]

I'm no nitpicker, just someone who's not very humorous.

This is a nitpicker: http://www.ukubusters.com/

Excuse me, there is a nice toasty spot in hell for me be prepped as I type.

Re:So what?

[Anonymous Coward]

I browse slashdot using windows from work 5 days a week yet I'm not the windows user, my company is. How many windows sufferers like me are there in your 90%?

Solid evidence, please?

[Anonymous Brave Guy]

Do you actually have any solid information to support your claims here, or are you just expressing your personal opinion as fact?

Almost all of the posters objecting to type inferencing here quote examples like your

var y = SomeFunction()

as an illustration of how code is less readable without a type. Guess what? Code isn't very readable if you call your functions SomeFunction anyway, and writing

int y = SomeFunction()

or

SystemLibrary.MathModule.FloatingPoint.LongDouble y = SomeFunction()

really doesn't help.

On the other hand, if your functions and variables have meaningful names, you probably don't care whether the value returned is a float or a double most of the time. Type inference makes your code more generic, without losing any particularly useful information (if it is useful, you can still specify it), and the type safety of the system prevents the sort of

double -> float -> loss of precision

errors typical in languages like C.

In other words, I see a lot of scare-mongering in this thread, but very little evidence that it's justified, other then people saying, "It's unfamiliar and I don't like it". Do you have anything more for us?

Re:Solid evidence, please?

[Mr2001]

Guess what? Code isn't very readable if you call your functions SomeFunction anyway

Obviously that was a placeholder. Read "SomeFunction()" as "the result of calling some function".

I don't know what libraries you're using, but in my experience, most function names don't include their return type. Quick, what's the return type of ArrayList.ReadOnly()? The same as TextBox.ReadOnly? How about Color.ToArgb().. does that return an "Argb", analogous to ToString(), or does it return 3 integers, like you just passed to Color.FromArgb()?

Re:Solid evidence, please?

[dcam]

Two words: Function overloading.

Re:Solid evidence, please?

[Anonymous Brave Guy]

Well, obviously you should read the interface for any function you're using to see what data it wants and what it gives back. Nothing about inferred typing precludes that; in simple cases, it simply saves typing a few characters and cluttering your code with type names you don't really need.

Regarding the final questions in your post, I'll simply note that if you get the types wrong, a strongly typed language will point that out immediately anyway, so you're in no more danger with inferred typing than you would be any other time you made bad assumptions about an interface you were using.

Re:Solid evidence, please?

[Anonymous Brave Guy]

Can you name a language that resolves overloading based on return type?

Re:Solid evidence, please?

[dcam]

Hmmm, good point. I had always assumed that C# offered overloading based on return type. Now I test it I find it doesn't. Sorry about that.

Re:Solid evidence, please?

[Mitch Monmouth]

The criticism of the example name of SomeFunction notwithstanding, you raise a valid point

If there is a benefit to this, it is because when you decide to change your database id from an int to a long, you don't need to change every reference to an id. In fact, Java does have implied types just like this. It just doesn't work in nearly as many cases.

For example, if SomeFunction returns an int and SomeOtherFunction takes an int as a parameter.

In Java, you can do this:

SomeOtherFunction(SomeFunction());

The type is "implied". But god forbid you want to use the return value of SomeFunction() before passing into SomeOtherFunction(). Now you have to declare the type:

int i = SomeFunction();
i++
SomeOtherFunction(i);

Now lets say you want to change your whole system to use longs. In Java (assuming this stuff is scattered all over your code) ugh.... In C#, it's trivial.

Implied types are not for convenience of not typing the actual type on declaration. It is to allow for better flexibility and mutibility.

Re:Solid evidence, please?

[FromFrom]

There is no implied type in SomeOtherFunction(SomeFunction()). The return type of SomeFunction is defined and the type of the parameter of SomeOtherFunction is defined.

Re:Solid evidence, please?

[tpv]

You do not appear to understand implied typing.

class Foo {
long SomeFunction();
void SomeOtherFunction(String arg);
void SomeOtherFunction(long arg);
}

SomeOtherFunction( SomeFunction() ) ;

How does the the compiler know whether you wanted "SomeOtherFunction(String)" or "SomeOtherFunction(long)" ?
It's implicit in your code, due to the return type of "SomeFunction".

That's all implied types do.
long l = SomeFunction()
The "long" is redundant. The compiler doesn't need it - it already know what type SomeFunction returns, as shown from the previous example.
If you want to add it because you think it makes your code more readable, then that's allowed, but the compiler doesn't need it.

Re:Solid evidence, please?

[Mitch Monmouth]

This is old, but I just read it and you are not correct.

long SomeFunction():
long x = SomeFunction();

The "long" is redundant. You can replace it with the generic "var".

void SomeFunction(long x);
long y = 1234;
SomeFunction((long)y);

The long cast is redundant. You can get rid of it, thus implying the type, and as you said, "If you want to add it because you think it makes your code more readable, then that's allowed, but the compiler doesn't need it." It's EXACTLY the same.

Re:Can someone explain the advantages of C# over V

[Anonymous Coward]

The main advantage is that C# lets microsoft charge royalties at some point in the future when the language specification has been widely adopted.

Good idea getting better.

[tuomoks]

The (very) good part is that the syntax gets formalized. But the idea itself is old - anybody remember those basic simulation jobs where a ship goes from one harbour to another. The cargo changes, the crew changes, lines in/out, etc. but the base (the ship) was same. No need to code that, just change the properties and no need to know beforehand what for ex. the cargo is. Now - think a message in computer system, starts plain but the payload gets compressed, encrypted, enhanced, some pictures added, and so on - fail the delivery, no need to any clean up or rebuild, just take the base and in retry send it to the same route. Huge savings in coding, no need to hardcode properties, properties can change dynamically at any time, even the destination can change with no coding, etc.. And yes - old idea and coded many times over but this is the first time this type of higher abstraction in language itself. I have seen it done in assembler, Simula, LISP, Prolog, Delphi, C, PL/I, etc.. but always differently.

Kitchen Sink Language

[sproketboy]

Yet more evidence that C# is designed by monkeys. Add as much garbage to the language as possible to attempt to appease every programmer's wank fantasy. Ultimately you'll please no-one.
BTW Still waiting for GOTO Line Numbers to be added.

Re:Kitchen Sink Language

[sproketboy]

When is the truth flame bait? You inbred turdburgler.

Re:Can someone explain the advantages of C# over V

[shutdown -p now]

By .NET 2.0, C# and VB.Net are really just two different syntaxes for the same semantics. So feel free to use whichever is more convenient to you.

ECMA or Microsoft Standard?

[Anonymous Coward]

What gives Microsoft the right to unilaterally update the ECMA C# standard? Unless the whole ECMA standard thing was just a farce all along.

Re:ECMA or Microsoft Standard?

[Anonymous Coward]

I'm acting the way America acts best: unilaterally!
— Homer Simpson

Re:ECMA or Microsoft Standard?

[man_of_mr_e]

I'm not sure you understand the process. Standards don't update themselves, someone has to do the work, then recommend it.

In this case, the 2.0 changes to C# have already been accepted by the ECMA (as of July) and ratified as an ECMA standard. It has then been forwarded on to ISO for fast tracking (just like the first version was).

C# 3 will also be recommended to the ECMA, who will analyze it, possibly recommend changes (though they will have likely worked with the ECMA to develop the spec in the first place, so that may not happen much). And again, be ratified by the ECMA and sent on to ISO for fast tracking.

Microsoft isn't doing anything wrong here. Lots of standards work this way.

Re:ECMA or Microsoft Standard?

[spagetti_code]

The fact that this is such a fast moving standard is very interesting. Most standards take years of negotiation to move forward - with MS at the helm this one is fair trucking along. In effect, this makes the standard a moot point - it is unlikely that anyone will have the resources or willpower to create a competitive implementation to C# given the goal posts move so rapidly. MS have brilliantly created a standard, and probably what will be the only real-world usable implementation of that language. They get the best of both worlds - standards and proprietary. Cool.

Re:ECMA or Microsoft Standard?

[man_of_mr_e]

Actually, that's not really true. Mono has kept up pretty well with the standard, and as far as I know already has a full C# 2.0 implementation, and is working on C# 3 already.

The deal is, Microsoft has to publish their spects YEARS in advance. C# 2 was first published in 2003 with public working committee drafts. This standard process has allowed Mono to follow the progress and implement the features as well.

C# 3 is likely to be the same thing, by the time Microsoft ships a commercial compiler, Mono will likely be right there with them.

Languages falling behind

[Anonymous Brave Guy]

As a Java programmer, it is exciting to see these developments in C#, it makes me wonder whether Java is destined to fall behind C# - it sure looks like that is happening....

Perhaps. But then again, Java evolved very fast in its first few years, and a lot of what it evolved was crap, particularly the numerous poorly-considered additions to the library that now have to be supported pretty much forever. Policies on language features were made on evangelical grounds -- "We don't need templates!" springs to mind -- and a decade or so later, people are eating their words (as more conservative/deep-thinking programming communities have been telling them they would all along).

There is a lot of merit to stability in programming languages that are used by real people for real jobs. Some languages go too slowly, IMHO: I think C++ is drifting off into specialist worlds with a single really active supporter at the expense of useful mainstream stuff with no champion, but that's more a result of the way the standards committees are set up than anything else. Likewise, Perl 6 is becoming almost a completely different language, which is no longer recognisable as an evolution of Perl 5. But at least there's time for people to keep up, and in the meantime, everyone's able to use a solid baseline in C++03/Perl5 for real work.

These developments in a mainstream language like C# have potential to bring useful programming techniques into the mainstream, for the first time in some cases. Still, when most of the C# world is still exploring version 2, I can't help feeling that they'll either lose support or develop a community full of keen but under-informed developers producing naff code because they didn't have time to learn everything at once. Sometimes exciting isn't the best thing.

Re:Languages falling behind

[gidds]

"We don't need templates!"... a decade or so later, people are eating their words

Worth pointing out that since C has a singly-rooted object tree -- everything is a subclass of java.lang.Object -- the need for generics was much less pressing than in C++.

Also that Java's generics are rather different from C++'s templates: they're simple, don't duplicate any code, and are extensible without recompiling. Whereas I see templates more as a sort of metacompiler that just happens to let you do generic stuff as well...

Re:Job security

[Bastian]

If your C# code ever becomes reasonably readable or maintainable, you can easily be replaced.

Re:Can someone explain the advantages of C# over V

[dubl-u]

Theoretically, I could add comments to a brace that indicate what type of structure ends at the respective point, but that's a waste of time, and if I modify an algorithm, then the function of those closing braces may change.

Why would you need such a thing?

Reading your comments, my first reaction is that if you don't know which blocks end where, your blocks are too big. Whenever I start wondering which closing brace is which, it's time to do an Extract Method refactoring.

Microsoft and innovation:Software Factories

[Anonymous Coward]

The ultimate goal of Microsoft.

http://lab.msdn.microsoft.com/teamsystem/workshop/ sf/default.aspx

The latest Visual Studio and chapter 16 of "Software Factories: Assembling applications with patterns, models, frameworks, and tools" reenforce this.

Re:Such a pity

[Mostly a lurker]

I do not argue against currently using Microsoft products, or even potentially using them indefinitely. I do though think being locked into Microsoft is strategically dangerous.

As a company, they have become used to rapid revenue growth. They have sustained this, in the past, by increasing their customer base. In the future, it is very likely that they will try to maintain revenue growth in two ways. The first is by expanding into application packages at the expense of the VARs. The other is by milking those clients that have no alternative to continued use of their products.

To avoid the risk (IMHO the likelihood) of huge future costs, it is essential to retain a credible threat of moving away from Microsoft.

Re:Can someone explain the advantages of C# over V

[Anonymous Coward]

I think VB.NET is very underrated. It's superbly designed, with considerations for normal human beings :)

It's much easier to learn than C#. But of course if you already know java or C++, C# will be easy to learn too.

That said, if you want to do any cross-platform development, VB.NET is a good bit behind C#. See the mono project and mbas.

Also a limitation of both is that you can't change anything you don't like. Microsoft decides everything for you. I'm leaning to open source programming languages for .NET and Mono, such as boo. See also nemerle, which is more similar to C#.

Implicitly typed local are good

[vyvepe]

* type names can get long, especialy when templates are used

* why do you want to do the compiler's work

* editor with intelisense will tell you the type for the expression in most cases so no need to repeat it

* you do not need to modify so much places if type changes during development

* and if you really want you can get the exact type, but mostly it is just waste of time

AFAIK, they are going to add this to C++ too

Re:Implicitly typed local are good

[stevejs]

Yes this is under consideration for the C++ stadard.
Matt Pietrek mentions the addition for C++, from Herb Sutter's talk:

http://blogs.msdn.com/matt_pietrek/archive/2005/09 /16/469213.aspx

C++ syntax (from Matt's blog):
before:
foo::iterator i = myList.begin();
after:
auto i = myList.begin(); // Type of 'i' is inferred from the assignment

Re:Can someone explain the advantages of C# over V

[Loconut1389]

PASCAL:

program demo3;
var x:byte;
begin
x:=5;
if x=5 then
      writeln('It is 5') (*no ; here*)
    else
      writeln(It isn''t');
writeln('So there.');
end.

Because of LINQ

[neile]

The examples above (var i = 5, etc.) are pretty simple and I agree, not particularly useful.

The place where var is useful is when you're writing LINQ code. When you're writing LINQ statements you are effectively building objects on the fly. You don't know what the object will look like when you write the LINQ statement, but you also want to make sure that once it's assigned it's fixed to that type and you get the benefits of it being "strong" through the rest of your code.

There are tons of examples of this over at http://msdn.microsoft.com/vcsharp/future/linqsampl es/projection/default.aspx#anonymous1. Here's one:

public void Linq10() {
        int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
        string[] strings = { "zero", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine" };

        var digitOddEvens =
                from n in numbers
                select new {Digit = strings[n], Even = (n % 2 == 0)};

        foreach (var d in digitOddEvens) {
                Console.WriteLine("The digit {0} is {1}.", d.Digit, d.Even ? "even" : "odd");
        }
}

Neil

Re:Can someone explain the advantages of C# over V

[ilyanep]

Okay I concede that point then...

I have just one problem with it

[alexo]

The problem is that MS strongly ties the language with the IDE.

That is, whenever C# (or Visual [anything] for that matter) gets new features, we have to buy a new version of Visual Studio to take advantage of it.

For every developer that may work on a project that will use these new features (and our developers tend to move around).

I have run into several annoying bugs and limitations in the .NET framework 1.1 and MS's response has invariably been "it is fixed in 2.0". However, to use it, we will have to buy VS 2005. Want a bug fix? Buy the new version! Neat.
Now C# 3.0 comes along. Will we have to upgrade to VS 200x yet again?

With these forced upgrades, MS has effectively implemented a subscription model for their software.

Re:I have just one problem with it

[caseih]

What are you talking about? The .NET environment and C# environment has always been available as a separate, free download from MSDN. While developing in Visual Studio is nice, you absolutely don't have to. The compiler is a standalone commandline compiler and the runtime environment certainly doesn't have anything to do with Visual Studio. The Mono developers regularly download the latest versions of .NET to compile their test suites and compare the results to Mono's results.

What forced upgrades are you referring to? I must be missing something here.

Re:I have just one problem with it

[btobin]

The problem is that MS strongly ties the language with the IDE. That is, whenever C# (or Visual [anything] for that matter) gets new features, we have to buy a new version of Visual Studio to take advantage of it. No you don't. I've been doing C# and VB.NET development for several months now, and I've never shelled out any money to MS for tools. All the compilers and runtimes are freely downloadable from MS, and there are several good free IDEs (one of them from Microsoft). Check out SharpDevelop for a really nice open source .NET IDE written in C#. I'm not a big MS fan (I only grabbed the stuff because a job I was looking at wanted me to learn it), but these new C# features are extremely compelling.

Re:I have just one problem with it

[Anonymous Coward]

How dare you interrupt MS-bashing with facts? Clearly you are with the terrorists

Re:I have just one problem with it

[spongman]

I must be missing something here.

What you're missing here is that this is Slashdot and so half the posters must necessarily have a blatant disregard for the facts.

Re:So what?

[Anonymous Coward]

Shut up, You know Penguins fly, dont you?

When will it End?

[sycodon]

Basic, Pascal, C, C+, C++, Objective C, Java, Small Talk, (endless variations of "talk"), etc,etc,etc.

When will someone finally say enough? When can I stop learning the latest re-arrangment of the same damn languages? Has anyone really come up with something New?

Re:When will it End?

[Anonymous Coward]

C+? I'm fairly sure that would never compile.

Re:When will it End?

[Anonymous Coward]

1958: LISP. The implementation of all other features, including those as-yet undreamed of, is an excercise left to the reader.

MOD PARENT TROLL

[BarryNorton]

Lesson for MS to learn: FUD doesn't effect [sic] a community of a single mind and purpose [!!!].

C# will not replace Java. It is a wonderful Java knock-off with a great IDE (Visual Studio), but it is not a Java killer.

End of [flame]

Your comments about the 'point' of this website are a self-fulfilling prophecy. Realists (yes, there are people who are neither brainwashed by Microsoft, nor the supposed crypto-Anarchist 'resistance' you seem to think you represent) just cannot be bothered anymore.

Slashdot is over, you're welcome to it...

Re:MOD PARENT TROLL

[bigweenie]

Open source means that I can get to the code and make it even better. That is not anarchism and it is not the end of capitalism, free enterprise. When MS open sources their software, then MS will find the love they so desperately want from slashdot.org. Until then, they will send paid flamers like you to say how naughty truth tellers like me are. The purpose of slashdot.org is to show the world that making all the source code available for any software you write is the best possible way to make all the code work better, faster, smarter and [oh my gosh] even less expensive. Hmmm. For those of you who bother to read these threads that espouse the virtues of MS, remember that true free enterprise does resemble anarchy in some respects. Monopolists fear true free enterprise. Let free enterprise reign and let the anarchy begin!!!

Do you get paid by the slashdot.org post?!

Slashdot.org does not have to pay homage to MS to survive. It has proven that over and over again. Slashdot.org will prove its resilience again as Vista is released and the MS FUD spews waste in amounts and levels of hatred never seen before. MS knows that this is the battle of Armegeddon for its OS. If you think that your FUD will go unresponded to, you are sorely mistaken. Slashdot.org loyalists are ready for your dirt and we will respond with class and truth.

Reject your weathly master and join us. You still can. You are always welcome. /bigweenie

Re:MOD PARENT TROLL

[BarryNorton]

Until then, they will send paid flamers like you to say how naughty truth tellers like me are.

You're just proving my point - only here would you read this deluded nonsense. I am an academic researcher, funded by the European Union (and you know their healthy scepticism regarding Microsoft).

I should declare an interest, though - the last conference but one where I presented was sponsored by Microsoft Research (as well as Cisco). Do I have a mark on my forehead? Am I damned? Can you show me the way?...

Hire 100 Indian Programmers...

[Anonymous Coward]

to rewrite it in PHP or Java. They're really cheap, I hear. So cheap that no one in the U.S. writes code anymore - we're all systems analysts (Hey, Mom! Looka here, I'm a systems analyst!-)

But seriously, nothing is too complex to rewrite. First find the best language (e.g, maybe you need Prolog or Lisp because the app has rules) then rewrite it.

This was __news__ on tuesday

[Anonymous Coward]

I sumbitted news reguarding C# 3.0 announcements on tuesday when it first happened, but my story was immediately rejected. Slashdot desperately needs a meta moderation system for story submission to enable wiki-like corrections in the story summaries for a short period before the story goes live and to look out for moderation abuses such as suppressing stories that lack an anti-Microsoft spin.

Here is the original submission:

With Visual Studio .NET 2005 and the .NET 2.0 run-time not even out of beta, Microsoft has released the C# Version 3.0 Specification (doc format) at their Professional Developers Conference 2005. New features include SQL-like and XQuery-like query expressions, implicit (on initialization) typing, lambda expressions and more. The primary focus of the language extensions are encompassed by The LINQ Project which aims to bridge the gap between the object-oriented and relational worlds in a simple and type-safe way.

Extra Crap?

[Anonymous Coward]

My feeling is that is is a bunch of extra crap that will never be tought or if they are taught will be tought incorrectly. A very large number of prorammers don't even know WTF a lambda is. They have never needed it.

I swear, I have been told that to have a program with more than one .cs file requires 'multi-file assemblies'. (Some sort of weird psudeo-library system.)

Greenspun's Tenth Rule of Programming

[ari_j]

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.

These changes to C# bring it closer to Common Lisp, and therefore make it easier to include those ad hoc implementations of it.

Re:Greenspun's Tenth Rule of Programming

[togofspookware]

By that logic, Common Lisp itself is the most ad hoc implementation of Common Lisp there is.

Re:Greenspun's Tenth Rule of Programming

[ari_j]

How so? Common Lisp is very well-specified.

Re:Greenspun's Tenth Rule of Programming

[Anonymous Brave Guy]

/me glances at current sig, smiles, and walks on.

Insert \\ Magic Bullet ?

[oldCoder]

Are there any examples of insertion? What to do with null fields? I haven't had time to study all the stuff yet...

So, in wrap up, how far does this take us to the Brooks' "Magic Bullet" for programming? Does further tying data structure into code still provide the clean separation between code and data required by good design? Can I prevent my data definitions from proliferating all through my source base so when the DBA re-does the database I'm not stuck with obsolete and broken applications?

And can I do stored procedures and give up SQL entirely or will DBA's need to learn both SQL and a new .NET language in addition to all their existing admin tools?

Can I use Reflection to inquire of the structure of the data and generate code to manage the database? Or are the older solutions still the best for this?

In what other ways will SQL-server and .NET become more tightly integrated? And when will the both become part of the Operating System like IE, with all the attending benefits?

I see the polymorphism angle (XML/Databases/Arrays) but is there a way to inherit data definitions? To subclass them?

And when will the WMI, the Windows hierarchy in a GUI application, the programs own class hierarchy through Reflection, and the HTML-DOM be accessible through these new interfaces, or have I just run aground on the shoals of logic and imagination? A bridge too far? How about the files in a directory, or is that just WMI again?

What tools and hacks will be need to deal with volatile (externally modified) dynamic data? SQL-server has some of it's own but coders still need to specify read-with-lock from read-without-lock. All the other data except for arrays and some XML is volatile (subject to modification by other threads or CPU's). Different data sources have different volatility models (db's, WMI, processes running on the OS, nodes on the net).

Re:Can someone explain the advantages of C# over V

[theguru]

Here's a simple one: Developer moral. I've been writing ASP.Net with C# since Beta 1. Most of the developers I've had on my teams are happy to be writing in C# instead of VB.Net. It feels more like a "real" language, so they feel more like "real" devleopers.

Re:Seems to get more like Ruby, Python and Delphi

[shmlco]

Of course, Macromedia built ColdFusion to output Java bytecode. Add the proper libs, and it runs on any high-performance Java system, including J2EE systems... where all the performance optimization work is already being done. They just piggyback on top of it.

General vs. specialist languages

[Anonymous Brave Guy]

I think there's a lot of truth in what you wrote there. That said, while specialist languages have their place, I'm increasingly wondering why no-one has yet produced the next great general purpose language.

Why can't we have a simple, elegant syntax like much of Haskell or Python, with punctuation frenzies reserved for things like regular expressions and printf formats where history shows they work well? Why can't we have a grammar that's amenable to parsing by automated tools, to make it easy for IDEs to provide refactoring aids, consistent formatting, etc? Why can't I have an imperative language that still supports higher-order functions and the like? Why can't I have proper disjunctive types and pattern matching in a language that supports OO with RTTI/reflection capabilities anyway?

I don't do professional compiler design, but I'm fairly familiar with the theory, and none of this seems to be prohibitively difficult. Indeed, most of it has been done in some form or other, somewhere. I just don't see why none of the places that invests so much in programming languages has managed to produce something like this yet. If they did, I don't see any reason we couldn't have a language suitable for a wide variety of applications, offering a clean, powerful syntax, yet still generating code that performs at a comparable speed to that from a low level language.

The technology seems to exist, it's just the language that (bizarrely) doesn't yet. We seem to be stuck in a rut where the only languages that are willing to risk major departures from common syntactic conventions and tool sets are new scripting languages and academic research, and so far each of them has had some significant drawbacks when it comes to industrial-strength, large-scale projects.

Aspects are not a Java language innovation

[tshak]

Java innovates but in a different area. There is a lot of emphasis on extending Java with Aspect Oriented Programming (AOP).

AspectJ is not part of the Java language. There are many AOP solutions for .NET as well.

Anders Should Cash In His Stock Options...

[Anonymous Coward]

The guy's a toolmaker pawn in Microsoft's "embrace, extend, extinguish" strategy. In this instance Microsoft wants to put an end to independent database vendors and tie users permanently into Microsoft's SQL Server database.

And why do they always save the hardest-to-implement (and most necessary) features for "later versions"? I'm speaking here of transaction processing and the true ACID properties of databases. No one in their right mind would use an enterprise database without these features, and they aren't in LINQ.

With Vista requiring a PC with 2 GByte of DDR3 SDRAM and a graphics card with at least 256 MByte memory, I expect Microsoft's stock to plummet in a manner akin to IBM's after release of the PS/2. Microsoft was the last to enter the dot-com market and will be the last dot-com to fall; until that happens the dot-com correction isn't over.

Re:Anders Should Cash In His Stock Options...

[man_of_mr_e]

Umm.. No. First, LINQ is database independant. It uses a provider model that 3rd party vendors can plug into to generate the code in question. Microsoft provides providers for MS SQL, Jet, and a few others, but there's nothing stopping MySQL or Postgre, or Oracle or anyone else crom providing their own.

Second, Vista won't REQUIRE the hardware you mention, that will simply be the "Optimum". Vista will degrade various features that require more hardware than you have (such as 3D Compositing).

If you've got a 1Ghz PC with 256MB RAM and integrated video, it will still work fine, you just won't see as many advanced featuers.

Re:Can someone explain the advantages of C# over V

[man_of_mr_e]

Well, both languages are more or less functionally equivelent. The C# is basically modeled after the CLR (or is it vice versa? I don't know), and most closely reflects the core CLR architecture. This makes it *slightly* more efficient than VB in some cases.

My experience is that VB is a little easier to learn, and provides some nice syntactical sugar (such as the Left/Mid/Right stuff) that C# doesn't (the functionality is still there, it's just not a nice keyword). C# has some nice things like the using keyword to help with resource management.

I find that people that come from VB are most comfortable with VB.NET, and those coming from C++ and Java are most comfortable with C#. The years gone stigma of VB is still there for these people, and many of them can't bring themselves to give VB.NET much respect (even though it's a fully first class language now).

Another thing to keep in mind is availability of talent. There are more VB programmers out there than C++ and Java programmers combined. If your code needs to be maintainable by any monkey they hire down the road, VB may be a better choice.

C# is more "efficient" to program in. It uses fewer words, is more compact, and doesn't waste the programmers time. VB.NET is easier to read, helpful, hand holding (not really, but to some degree), and warm and fuzzy.

It's all about style, attitude, experience, and familiarity.

Re:Insert \\ Magic Bullet ?

[iGN97]

Don't know the answers to all your questions, but I can fill in some of the blanks. Null-fields are supported through nullable types. It basically allows you to make versions of value-types that can also be null:

int? i = null; // int which can also be "null"

What I've seen so far has been on the query-side of things, but there is often mention of "setting" data. From what I heard in one of the videos, this will actually replace ADO.NET in future versions, so you will obviously need the ability to insert data into the database. Chances are that it will be outside of "LINQ", tho, as the Q is for Query.

SQL-server 2005 can use C# for stored procedures. I know Vista will ship with WinFX, which is basically a bunch of .NET accesible-stuff.

Anything that can be enumerated can be queried, so regarding WMI, my guess is that it is fairly simple to apply. The PDC-keynote uses an enmeration of processes on the system as a starting point. If the data is non-linear, it is a fairly simple thing to implement the interface LINQ uses to query the data, so you can make sure the semantics are correct.

That makes files in a directory incredibly simple to work with using LINQ, actually a lot simpler than manually foreach'ing. If you look at the PDC keynote video, you'll get info that is immediately applicable to the file system too.

Regarding volatile data, I'm not sure. We've all seen a foreach-loop throw when the collection being iterated is modified, but what the future holds I do not know. My guess is that it will not be up to LINQ whether or not it works; querying and iterating a database datasource doesn't care if data is modified, some local datacollections do. I guess the simplest and best would be just to let it be up to the underlying source and callee to handle it.

Mod parent down

[ad0gg]

.Net runtime which comes with the compilers has been a free download since it came out.

.net Framework

Intelligent design?

[pammon]

Rather than allowing C# to evolve naturally, Microsoft is hoping that they can get people to buy into its intelligent design

Seriously, I've never seen anyone try to evolve a production language this quickly. They're throwing in features left and right. It's exciting! But it's also terrifying: I feel like C# is being driven at breakneck speed towards, err... I don't think Microsoft actually HAS any ultimate goal in mind for C#, as long as they can cover a lot of ground getting there.

And if you drive this fast, eventually you're going to crash, and when C# does, it will fragment into dozens of small shiny sublanguages. People will carve out their C# comfort zones containing the features they feel comfortable with and exclude the rest. Two C# programmers will no longer always speak the same "dialect," making it difficult understand each others' code.

The fact that there's a great deal of overlap among C#'s features only makes this worse. Programmer A's heavy use of generics and lambda expressions will be unfamiliar to programmer B, who never bothered to learn those features since he can accomplish the same things using implicit typing and LINQ.

And, needless to say, differing levels of compiler support will also exacerbate this problem.

I'm surprised Microsoft isn't more careful, given the cautionary example of C++. C++ is in the later stages of this disease. Large projects have to specify the C++ sublanguage dialect that they're using. And we aren't talking simple style guidelines, but the excision of large chunks of features, like RTTI and exceptions. If C# continues the way it's going, it will wind up like this.

ding! That was the sound of me reaching my metaphor limit of three per post. I guess I better end this. So to sum up:

Microsoft, you are the largest software developer and in control of the OS and development tools. You are in the unique position of being able to dictate every aspect of a new programming language. It will be used for years to come by millions of developers in all different situations. This is a blessing and a tremendous opportunity.

Don't fuck it up.

(please?)

Re:Intelligent design?

[Bill Dog]

Interestingly, and informatively, I think, everything you're saying about MS and C# could be said about Sun and Java. I was doing Java in the 1.0 and 1.1 days. For 1.1 they changed the event model, so you had to unlearn the former and learn the latter. Then they came out with Swing, just as you were getting a handle on all the AWT classes. By only the 2nd version (1.1) a disconcertingly large number of API's were already deprecated.

But a) Java was new, and b) the company behind it had big plans for it -- capturing market share. That's the ultimate goal any corporation has for their proprietary language. And I'm not down on corporations or their proprietary languages -- I used VB for a little while, and recognized that it was very good for what it was. But in general, better to have a non-proprietary committee-driven language, like C++, where additions are considered at great length (an understatement!) by those who are (mostly) only interested in what's best for the language and its developer community.

On your comment on C++, it is in no such stage of any such disease. It's inventor, in recent thoughts on the next version (featured here on Slashdot a few months ago), is very cognizant of the drawback of dumping every good idea into a language such that there are 6 or 7 ways of doing the same thing. He understands that not every library should be standard (included with the language/standard).

Note that the page you linked to for your impression that C++ leads to the specification of sublanguage dialects is from 7 years ago, with the last update being 4 years ago, to add "don't use reserved words as identifiers" (duh). Things like "don't use exceptions" and "don't use C++ standard library features" (!!!) date back to, as mentioned there, Visual C++ 1.5! Most of that document is either obsolete or profoundly bad advice, today.

That said, as a final thought, I will agree that sublanguage dialects of computer languages do exist, but generally a single shared one, not incompatible ones. Maybe when a language is new, different subsections of the developer community will go off in different directions and try different new features to the bepuzzlement of others, but over time best practices are realized and books are written that convey them to new users, and an equilibrium occurs, so that everyone is generally on the same page. It helps if people try to code to that, too.

Re:Intelligent design?

[pammon]

Your criticism of Java for making early, hasty changes is dead on, but I would like to think that the damage was lessened because the changes were mostly confined to libraries - deprecating APIs and the like. Had the changes been to language features, things would have gotten much nastier (as if AWT->Swing wasn't nasty enough!)

But all of these proposed changes are to the C# language proper, not libraries. I think that's an essential difference.

Stroustrup (did you call him "its inventor" because you couldn't spell it either? I had to look it up!) wrote in that link "Library extensions will be preferred to language extensions." Hooray! IMO, it's too little, too late for C++, but I'm happy that he's made that distinction. I hope that the C# folks get that message soon, because they haven't yet.

Compare their approach to LINQ (from, where, select, in, etc. all become keywords) to, say, Apple's new Predicates stuff, which accomplishes the same thing (or at least appears to) without relying on new keywords.

Regarding C++ sublanguages - ok, my Mozilla link wasn't very good. But I stand by my point, that any given project will cherry-pick C++ features to construct their own internal C++ subset. Boost makes heavy use of exceptions and templates; wxWidgets doesn't. The STL barely uses inheritance. If you're programming for Boost, you should try to avoid using catch to catch exceptions. If you're programming for SGI, you shouldn't use C++ strings. Etc.

Java doesn't have issues like these. Java programs by and large all make heavy use of exceptions and inheritance, and recommending that you avoid catch() or strings is unthinkable! Keeping the language features trim and widely relevant is a big help.

You're right that, in principle, new users can learn best practices and start writing in the corresponding shared subset of the language, and really good C++ programmers do. If it weren't so damned hard to become a really good C++ programmer, this might actually happen in practice. Until then, best-practice libraries like Boost will remain out of reach for the majority of C++ programmers

(Though Stroustrup acknowledges that C++ makes things "unnecessarily difficult" for newbies. Maybe there is yet hope.)

What will be Sun's reaction

[aCapitalist]

I wonder if Sun will play the copying game as they did with Java 5 after C# came out.

I've argued that Sun might want to quietly start researching what's next after Java. I know about Fortress, but to me the description came off as more of a new distributed Fortran than a general purpose language - maybe I'm wrong there.

So Dolphin (7.0) VM is supposed to address some issues regarding dynamic languages. If I can play armchair quarterback, I would go ahead and come up with an "agile" language of their own (along with Java) and release that with dolphin (2008 or so?). Sun probably won't adopt groovy or any other open source project because of NIVH syndrome, and it doesn't have to be dynamically typed or anything, but look at languages like Python and Ruby and understand why people like those languages.

The reason I bring this up is because continually playing the catchup game with Microsoft seems to be a losing proposition. Microsoft never had the same philosophy of a dumbed-down C++ like Java did. And corporate has always liked the idea of a dumbed-down language where the programmer is an interchangeable cog.

I guess what I'm really saying is that I just see Java going into COBOL-legacy mode fast because it seems to really be a niche, server language already. Maybe it's time to start talking about what comes after Java

Re:What will be Sun's reaction

[Lord of the Fries]

Dolphin? Link? Are you referring to Object-Arts Dolphin Smalltalk? If so, I'm curious what changes/improvements you are referring to. I'm a regular Squeaker/VisualWorkser myself.

Microsoft and Lisp - Innovation?

[ari_j]

Can you explain to me what C# now has that Common Lisp doesn't? This is not a troll or flame, I am curious.

Re:Microsoft and Lisp - Innovation?

[Spy Hunter]

Visual Studio. MSDN documentation. Support from Microsoft and adoption by thousands if not millions of developers around the world. Tight integration with Windows, SQL Server, IIS, Office. Excellent form designer. Drop-dead simple integration with legacy code written in C/C++. Decent syntax. Similarity to existing established languages.

Re:Microsoft and Lisp - Innovation?

[Spy Hunter]

Hmm, after reading the great-grandparent post again I see that wasn't the focus of your question. Let me put it this way: Choosing the correct features, implementing them in a simple and elegant way, integrating them into a decent practical syntax which is similar to widely-used langages in a way such that teams of non-experts can understand and use it in an everyday environment; *that* is the innovation. It is very difficult; this is not merely copying Lisp even if you could theoretically implement these types of features in Lisp. It is true innovation.

Re:Microsoft and Lisp - Innovation?

[ari_j]

I asked which of the new features do not already exist in Common Lisp. Your list is not a new thing or an innovation - choosing the correct features is common sense and very subjective to determine, implementing them in a simple and elegant way is common sense and something CL has done for a long time, "decent practical syntax" is what people afraid of parentheses say about Lisp before using it extensively (e.g., me 5 years ago). None of those are new in C#, anyhow.

Re-read the G^nPP and let me know which of those things are not available in Common Lisp. As to your original list, it proves to me that you haven't used CL enough to criticize it fairly. Good IDEs, such as the one included with Allegro Common Lisp, are available.

Not liking the language is fine, being afraid of it is even acceptable and normal. But don't knock it 'til you try it.

Re:Microsoft and Lisp - Innovation?

[StarsAreAlsoFire]

LISP syntax is 'different' in such a way as to shove the difference 'in your face'. Not on purpose, just because it is really hard to hide raw power, esp. when there is no desire to do so.

C# is trying to hide that from the coder, in many ways, and to use the unmitigated power of LISP (functional programming)... while not making the coder cry.

Coding in pure LISP (well) requires a completely different mindset than writing code in any other language -- I suppose I should differentiate. I *probably* mean 'functional' when I say LISP, but LISP is the only functional language I have learned (poorly).

I got as far as the dropped jaw effect that probably hits pretty much everyone when they suddenly understand just how MUCH more powerful LISP is than, say, everyday C. I then went ' I must ponder how I can use this...' and never got back to it ;~)

As to 'available?' Simple. Libraries. And a KICK ASS SQL tool. Damn I want to try that stuff out now.... But no point until the release the 'finished product' for me.

Re:Microsoft and Lisp - Innovation?

[Pants75]

Users?

Re:Microsoft and Lisp - Innovation?

[Anonymous Coward]

Lots of enclosing brackets.

Re:Microsoft and Lisp - Innovation?

[ari_j]

So, nothing at all, other than that the features are hidden with syntactic sugar.

Re:Microsoft and Lisp - Innovation?

[StarsAreAlsoFire]

You are a troll.

Grow up.

Re:Microsoft and Lisp - Innovation?

[ari_j]

Apparently "troll" is now defined so as to include people who are informative of similarities and curious of differences between two languages. I'll update my lexicon. Thanks.

Re:Such a pity

[man_of_mr_e]

You apparently haven't used VS 2005 yet. It really does address nearly all of those issues. Things like tool palettes now work in both code and design modes. The design mode no longer rewrites your code. For ASP projects, you no longer have "project" files, and it no longer compiles to a big dll.

The productivity improvements in 2005 are monstrous, and it's damn good IDE even if you tend to spend all your time in code view now.

Re:Such a pity

[Anonymous Coward]

How so? In what way? Can you answer the question or are you too busy staying on message?

So keep writing in VB6

[samael]

Is the language or tool going to stop working tomorrow?

Are the programs you write suddenly not going to work on Windows?

Then keep writing in VB6!

Re:Such a pity

[heinousjay]

Well, I get it now. I checked out the pictures, and now I see why VS.NET 2005 is the greatest of all.

Re:Such a pity

[man_of_mr_e]

You're going to have be more specific. I gave examples of how the IDE no longer interferes with you doing things the way you want to.

The original message was very vague about what specifically he had problems with, and I commented on a few things off the top of my head.

If you mean "How is it more productive", then just watch any of the demos over at Channel 9 for examples. Things like context sensitive intellisense in the HTML editor (ie, it will only show you valid items within a given block), the amazingly cool visualization capable debugger with datatips (yeah, I know that sounds like marketing bullshit, but they really are cool). See http://www.code-magazine.com/Article.aspx?quickid= 0503061 for an example

Honestly, if you just *USE* it for a few hours, you'll be amazed. And you can download it for free too.

Re:So what?

[m50d]

That doesn't matter. I've been saying java is slow and getting modded down as troll for years.

Java work all in Libraries

[SuperKendall]

Java is actually moving ahead at a goodly clip - it's just that most of the work is in libraries and extensions instead of the core language.

For examples, check out Groovy, or Hibernate (complete with its own HQL for querying objecs) or Tapestry.

I would still say the Java velocity is substantially higher than .Net, which is still working to port all of the really good Java tools as quickly as they can.

Looks more like Boo to me

[LifesizeKenDoll]

I'd actually say that it looks like it's taking a lot of Boo's features. The inferrence, the lambdas, there's only 2 features that Boo doesn't have, and they'll be taken care of within a month.

http://boo.codehaus.org/

upgrade it to vb.net

[Anonymous Coward]

i ported a medium sized vb6 app to vb.net in a week... it really wasnt a big deal at all.

Re:Can someone explain the advantages of C# over V

[dedazo]

In the 1.0 CLR the C# compiler produced slightly (and I emphazise slightly) better-performant IL under certain conditions. We created a whole bunch of test harnesses (loop unrolling, exception handling sequences, type casting, etc) to profile the generation of IL. Much of this gap (that again, wasn't significant to begin with) was narrowed in 1.1. I expect it should be gone by now.

VB.NET/C# are choices. Choices for developers, for IT departments, for commercial software companies. In the WinDNA days, you could have really expert, expensive C++ folks cranking out the critical parts of your product and a bunch of less-qualified VB devs writing features to spec and it all came together using COM as a binary-level glue. Microsoft gives you the same option today, albeit VB is less crippled now. There will always be differentiating features (VB is less verbose, C# has more 'power' syntax) to keep them apart.

It's all just choice.

How About Some Press for 'D'

[OmgTEHMATRICKS]

I get sooo sick of hearing about Microsoft's new C++/Java ripoff that it just occurred to me that no one has talked about a clean, vendor free inheritor to the C++ crown.

Imagine if you took everything you knew about C, C++ and Java and fixed it. What would you have? You would have 'D'. A completely underrated language that follows on in the tradition of C/C++ non-vendor specific languages.

If you want to work like a sharecropper, keep expressing your algorithms and developing your projects in Microsoft proprietary language. If you want portability and something better than C++, check out D here.

Re:How About Some Press for 'D'

[Anonymous Brave Guy]

Imagine if you took everything you knew about C, C++ and Java and fixed it. What would you have? You would have 'D'.

No, I really wouldn't.

The reason so few people mention D -- and, I promise you, plenty of us have looked into it -- is that it has no compelling advantage. Java wasn't much of a step up from C++, and indeed was a step in the wrong direction in many areas, which is why so many people still use C++. It does at least have some clear advantages for some applications/environments, though. Ditto for C#. Where is D's niche? What can it do so much better than these other tools to justify buying into a small language from a small company with a small community?

New language

[Xtravar]

There's just so much new crazy stuff in C# 3.0 compared to 1.0. A lot of the features seem like cool ideas, at first glance, but I think I'd get annoyed after awhile with the versatility.

For me, C# 1.0 was a more perfect version of C++. Now it's just getting weird. I'd say Microsoft is trying to push a new programming paradigm into the mainstream by introducing these functional language features.

Having too many easy methods of doing something in a language makes a programmer less effective.

For example, 40 different ways to create an array/collection is just going to slow a programmer down, trying to find the best way of doing something. Maybe some programmers don't care and pick one regardless of its merits, but when I'm faced with several ways to go about something that all seem equally appealing, I get writer's block.

That's why I like C and PHP3. The languages are somewhat inherently limited, so they don't make you go nuts trying to find the best solution. In PHP you only have one real way to store arrays - a hash. In C, you don't have to worry about defining class interfaces and making them comprehensive and perfect because there are no classes.

You have several ways of using pre-written methods in C# 3.0, which is completely amazing.. until you have to write your own method and decide whether you want it to be an Extension Method or inside an Interface/abstract class/class, and then static or instance, virtual or abstract, property or get/set, etc etc. Other languages implicitly restrict you to only a couple options.

I like having a language that dictates its own coding conventions so that I don't have to figure out which way of doing something is 'more correct'. Maybe I'm nuts. Don't get me wrong, I love C#, but adding more flexibility will drive me up the wall.

Re:New language

[Anonymous Coward]

Dude, how do you say nail on the head.

these new features are awesome but I too find myself trying to figure out which is the best/optimized way to do something .... is it this or that (google, google, msdn, msdn, ...) ....

Would be nice if they come up with some compiler directives or something for say the PREFERRED way.

my 2 cent

Could someone help me out?

[CokeDog]

How do you call a lambda expression? I'm familiar with anonymous methods in delegates, but I don't understand how c => c.City == "London" for a parameter, which returns a bool, is easier than just saying (c.City == "London"), which also returns a bool. In the first case, "c" would only be used once, so what's the point? Thanks in advance, Alek

Re:Could someone help me out?

[pietvo]

c => c.City == "London" is a function returning a bool, while (c.City == "London") is just a bool. So they are different. Moreover the latter will give an error as c is an undefined variable. The reason you have to give a function is that this function has to be called for every tuple. If you would give just an expression, it is true or false depending on the value c has at the moment of the call, which has no relationship with the tuples to be inspected.

And a lambda expression is just called like other functions: f(x) where f is the name of the parameter in the definition of the called method.

Re:Could someone help me out?

[barrkel]

A lambda expression is compiled as either an anonymous delegate (just like C# 2.0), or an Expression> tree, depending on the declaration of the method you're passing the lambda expression to.

So, c => c.City == "London" translates to:
delegate(City c) { return c.City == "London"; }. That is, 'c' is an argument passed in when the method you're calling calls the delegate (a.k.a. lambda expression) you've passed in.

However, (c.City == "London") is simply an expression using 'c' which is in scope already, in the scope of the outer caller.

The neat think about the lambda expressions is that if the callee desires, it can take in an expression tree instead of a delegate reference. This means it can package up the expression tree and export it across the network to process it elsewhere, for example: this is the case for DLINQ, where the packaged format is a dynamically generated SQL expression.

Re:Could someone help me out?

[CokeDog]

Ok, I think I get it. Instead of passing the result of c => c.City == "London", you're passing the function itself, which can then be used by the Where() function. That is neat. Thanks a lot for the replies.

For generics.

[autopr0n]

std::map>::iterator i = mymap[j].begin();

or

var i = mymap[j].begin;

Re:Can someone explain the advantages of C# over V

[Loconut1389]

well, technically its not an 'end if', just an end =)

has no real advantages over '}'

Re:Such a pity

[Anonymous Brave Guy]

It will be fun to see what happens with the enterprise, but I feel that someone needs to take a big step back if they are to stop C#/.NET/Mono from taking the desktop. Saying "I'm just sticking with C, and so should you" is only going to work until the gap becomes large enough.

Perhaps. The alternative outcome is that whatever industry you work in finds that the UI stuff is only a small part of the application, for the bulk of it current practices using $OTHER_LANGUAGE work just fine, and this emperor has no clothes. Saying "C# and .Net will bring massive productivity benefits" is only going to work until the gaps have failed to materialise for long enough, too.

In reality, of course, there are few absolutes and most projects will appear somewhere on the sliding scale. For smart dev teams, the choice of whether to invest in C# and .Net will depend on where on the scale they fall.

Re:Such a pity

[Anonymous Brave Guy]

Thing is, the world is moving to web based interfaces.

Well, maybe it is this week. My experience has been that applications trying to do this bring little benefit and a lot of drawbacks over old-fashioned desktop apps. Why does my word processor/development environment/mathematical modelling framework/computer game need to use a web-based interface?

The claimed advantages are mostly marketing hype from companies who are investing (perhaps unwisely) in this technology. The rest of the world will carry on making programs that work for as long as they make money (commercial) or make the programmers feel good (various free software/OSS/shareware things).

C++ with Garbage Collection added

[evangineer]

Sounds like you want D http://www.digitalmars.com/d/

I am curious as to why you might think that Python and Ruby aren't suitable for a big business application though. They may be uncommon in enterprise environments, but that doesn't necessarily mean that they aren't suitable for the job.

More Wrappers Please Sir!

[irritating environme]

DLINQ wraps LINQ which wraps ADO which wraps ODBC which wraps core MSSQL api. Then write DCOM wrapper around whole program. Then make ActiveX control. Then reference from Excel VBA. Wheeeee!

Lemme know when D piggybacks an API

[irritating environme]

Languages don't really matter anymore. Java as a language isn't important, as much as Java and its innumerable APIs are. Which is why Ruby, Python, and PHP all write wrappers to the Java core API so that their languages all can do something useful. So all these features in C# aren't anything special. People don't really care about java's new language features, they just care about new APIs.

LINQ useless w/o transactions

[irritating environme]

I didn't see that, but I assumed MS wouldn't be so stupid to do that. No transactions? Have fun folks.

So was "overkill"

[irritating environme]

Still has a meaning...

Does anyone remember PL/I?

[Anonymous Coward]

Decades ago, this was THE language that was going to be all things to all people. Where is it today? Any language that has too many features in its core design will ultimately fail the test of time.

Why?

[Trejkaz]

Funnily enough, most database binding libraries in Ruby seem to work exactly like that.

The way I see it, a language which pretends to be statically typed (as Java and C# do) should stick to being statically typed. If developers wanted to use a dynamically-typed language they would use one, rather than perverting another language which doesn't quite fit the programming paradigm.

It also seems to me that this battle between Java and C# is mainly to distract people away from languages like Ruby which really are a step forward instead of just an evolution on top of something else.

Re:Can someone explain the advantages of C# over V

[Anonymous Coward]

Actually, C# source doesn't resemble IL at all. The CLR is effectively a RPL engine -- if you've spent any time programming SysRPL on an HP48 or the like, you'll find it relatively easy to read.

So the purpose of the compiler is to find the most effective (and safe) way of expressing foo language into RPL, and then spooling it out with metadata. You can do this yourself, using either CodeDOM or (in 2.0) Lightweight Code Generation -- the same technique IronPython uses to achieve a compiled, strongly-typed, dynamically-typed language.

LINQ isn't new

[idlake]

LINQ is basically list comprehensions over arbitrary objects with a sequence interface. That's actually not new either--both CommonLisp and Python have had similar constructs.

it's been freed

[idlake]

The Mono project gives you all the good stuff from .NET (the language, the core libraries), plus all the good stuff from Linux and open source (Gnome, Gtk+, other standard libraries), while avoiding all the bad Microsoft stuff (XP, Windows APIs, Windows libraries, etc.).

So, .NET may well become the de-facto standard for development on Linux.

Re:Bashing MS is the whole point of this website..

[idlake]

C# will not replace Java. It is a wonderful Java knock-off with a great IDE (Visual Studio), but it is not a Java killer.

Java is doomed whether or not C# will replace it: except for a few specialized niches, Java has failed to become a factor in mainstream software development.

Microsoft spoofs the world

[Anonymous Coward]

So we have now this wonderful new feature "LINQ". The very first example I stumbled over on

http://msdn.microsoft.com/vcsharp/future/linqsampl es/>

was this:


GroupBy - Simple 1

This sample partitions an array of numbers into groups according to the number's remainder when divided by 5. the sample uses group by to create the groups of numbers and select to create an anonymous type consisting of the remainder value and the group of numbers with this remainder.

public void Linq40() {
        int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

        var numberGroups =
                from n in numbers
                group n by n % 5 into g
                select new {Remainder = g.Key, Numbers = g.Group};

        foreach (var g in numberGroups) {
                Console.WriteLine("Numbers with a remainder of {0} when divided by 5:", g.Remainder);
                foreach (var n in g.Numbers) {
                        Console.WriteLine(n);
                }
        }
}


Well, in C this would be something like this:

#include

int main(int argc, char* argv[])
{
    int i, j, numbers[] = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

    for (i = 0; i

No comment.