Fog Creek Software
Discussion Board

Choice of language


Wait for new version of windows and you will be able to write your 16K windows application.

Wait for Mono guys finish their .NET clone and you would be able to write command line utility in .NET language of your choice at least in Linux. And hey, use ROTOR for Free BSD.

Wait for the new version of SQL Server, you will be able to write Stored procedure in .NET language of your choice

Wait for new version of Office and you would be able to write Word and Excel macros in .NET languages.

.NET is a significant technology change and its ripple effect over other technologies will take a couple of years. Give it some time then you only need to know C# or Visual Basic .NET and you will be all set with Windows, Web, Office, Linux, FreeBSD and SQL Server development.

So what's the point?
Start learning .NET now, by the time you will be expert in it, you will have all the opportunities to do above tasks.

And basically don't be skeptic.

Steve Johnson
Sunday, May 05, 2002

Hmm sounds like what they said about Java.

Joel Spolsky
Sunday, May 05, 2002

Steve, do you have one of those big-arse foam hands with ".NET" on it?  'cause basically what you're offering sounds like boosterism - we should be skeptics, because technology companies consistently fail to deliver (I believe Microsoft are planning to offer the filesystem they promised to ship with Cairo - Windows NT 4.0 - with Longhorn, coming RSN; Java still hasn't reduced Windows to a collection of poorly debugged device drivers).

One point you've missed in your analysis, Joel, is that you don't get a free hand with languages under .NET ATM - if they operate in ways not supported under the CLR the ports have had to drop those features.

Rodger Donaldson
Sunday, May 05, 2002

Waiting for D7 for .NET support and small executables too when required

Sunday, May 05, 2002

There are two simple questions which should clear things up a lot, for those of us who haven't studied .net closely. 

1)  Can unmanaged code interop "reasonably" with the CLR?
2)  Is there a large performance/usability penalty when doing this?

If this can be done with few problems, C programmers can write deterministic code and Schemers can use continuations.  I can understand if data needs to be wrapped for interop.

Then again, I remember Mike Gunderloy saying that calling legacy COM from .net took forever.

mad mark
Monday, May 06, 2002

"It seems like .NET gives us a "choice" of languages precisely where we couldn't care less about it -- in the syntax."

I think the point is that Microsoft and business couldnt really care less about the the things that we couldnt care less about, if you know what I mean.

Developer preference wont drive the changes that are made. Thats small micro stuff and the big picture is much much bigger, most developers will die in the middle of a syntax preference debate while the world shifts beneath them.

Monday, May 06, 2002

I think the whole point of .NET language model is not that you can CHOOSE any language you want - it is that you can USE the code written in virtually any language.
It was COM/DCOM which promiced such a thing, but really - it was too heavy, too complicated for easy usage (ActiveX, ATL developers - correct me, if I'm wrong).
In .NET you can use an object written in C++ in your VB app. You can call your old PERL code from C# application.
Moreover, you can finally buy a library of components and inherit your classes from its classes. This is why Delphi had zillions of small components (often free). .NET promices more than Delphi - because of its language variety. When somebody will write ObjectPascal compiler for VS .NET and VCL adapters - you will instantly find hundreds of components available for your VB app.

Roman Eremin
Monday, May 06, 2002


Roman has it right; the point of multiple languages in .NET is language interoperability. Your COBOL componenet is usable, callable, inheritable and debuggable from my VB.NET code. Of course, there is also the benefit of minimized training as your favourite language ports to .NET.

A fair portion of the similarity you're seeing between C# and VB.NET can be explained by each language being in its first .NET version. Microsoft has said that we can expect more divergence in future versions (C# focussing on "power", VB.NET focussing on "RAD development"). Sorry, no cite.

Ian Lowe
Monday, May 06, 2002

Language interoperability is the key.  In fact, Miguel de Icaza says that one of the motivating factors for Mono was their experience with providing, and keeping up with, all the language bindings for GNOME.

As a library vendor with .NET, you code it in whatever language you want and your customers use whatever language they want.  This is the compelling feature of language interoperability in .NET.

Just look at how many XML stacks are out there: Perl, Python, C, C++, Java, ... all slightly different.  With .NET, it doesn't matter what language I choose - I can learn and use the .NET framework's XML stack and get on with my real work.  Language vendors get a compelling base class library 'for free' just by implementing a CLR compiler.

Monday, May 06, 2002

Any first class .NET language must have the same execution model as C#.  The execution model includes inheritance, object lifetime and so on.

If a language does embrace the C# execution model, then the language is reduced to a syntax difference from C#.

You only need to look at VB to see why this is true. Although VB.NET has the same syntax as VB, VB.NET does not share the same execution model with VB. Object lifetime is one example of the differences between these languages.

Language interoperability in .NET is just marketing hype.  The only thing you really get is syntax interoperability.

Bravada Zadada
Monday, May 06, 2002

Peter Coffee of EWeek made this same point.  .NET reduces all languages to its choice of lowest common denominator.

For example, C++ loses multiple inheritance and templates, at least for now.

See for an interesting discussion with many examples.  And no, they don't say Java is any better, really.


Tom Haviland
Monday, May 06, 2002

Until .NET, every serious Windows-based language had to support interoperability with the Win32 run time. You could reasonably claim that the Win32 run time (with GetProcAddress and LoadDLL) restricted every language to a common-language-runtime that was based on a subset of the C language.

All .NET does is raise the bar from everything-looks-like-C to everything-looks-like-C#.

Similarly, .NET raises the bar from every-compiler-emits-486-code to every compiler-emits-IL.

I don't think .NET constrains language design any more than the prexisting Win32 (or C standard library) did. You can still use wacky paradigms within your own language, and only have to use standard paradigms when interoperating with the rest of the system.

Now, a seperate question is why support more than one language as your main language. The main reason for this is backwards compatability with existing programs, and just as importantly, with existing programmers. Supporting multiple languages allows .NET to be used on more kinds of projects than just supporting one language. (For example, MS can sell .NET to VB, Java, C++, perl, Javascript, and Cobol programmers. That's around 99% of the commercial application market place, I think.)

Jack Palevich
Monday, May 06, 2002

A previous poster writes "I don't think .NET constrains language design any more than the prexisting Win32 (or C standard library) did."

That's correct. But if a language does not constrain itself to the C# model then it will either have a yucky interoperability layer or it will be a second class citizen in terms of performance or features.

Object lifetime is a good example of this. The CLR does not provide direct support for the deterministic object lifetime in VB classic.  If VB.NET retained deterministic object lifetime, then it would either need to wrap all objects with a reference counting holder or use some new set of objects with AddRef/Release semantics. Either way, VB.NET would be a second class citizen.

If the CLR truely supported any language design, then VB.NETs deterministic lifetime feature would have been retained.

Bravada Zadada
Monday, May 06, 2002

"The idea is, choose any language you want, there are zillions, and they all work the same way."

Could you please refer us to a Microsoft document that says this? I don't remember coming across this from Microsoft.

My understanding is that the idea (to borrow your terminology) can be divided into two: (1) ANY language can be compiled into the same IL and be able to run on any machine that has .NET, PROVIDED the libraries you depend upon are there; (2) You can achieve interop between any two languages, provided they can both support the same subset of the .NET "type space".

Nothing forces the languages to work the same way. The fact that both VB.NET and C# are so close in "spirit" is misleading -- there are many other languages that can be compiled into IL which work totally differently.

For example, if you want to write a C++ program utilizing templates and multiple inheritence and whatever, and have it compile to IL, you can. It will work the same on Windows or Unix or whatever, as long as that platform has a .NET runtime and the libraries that you depend upon.

The same goes for many other languages as well.

What you can't do is export (for example) your C++ templates to a C# application -- you'd have to write wrappers -- but this level of interop is still years ahead of what you get with DLLs (C functions with no type info), vtbl COM (C++ virtual methods with little type info), COM Automation (some type info with no type safety), or Java (all type info needed, but here your choice of languages is limited to Java).

"VB.NET and C#.NET are virtually identical except for tiny syntactic differences. And other languages that want to be part of the .NET world need to support at least a core set of features and types or they won't be able to Play Well With Others."

Completely true.

"But how do I develop a UNIX command line utility in .NET?"

Very easily -- you start up VS.NET, and create a program in your favorite language, being careful to use only the parts of .NET which are included in Rotor. (Or, you pay attention to that "other project" to port .NET to Linux.)

"How do I develop a tiny Windows EXE in less than 16K in .NET?"

Very easily -- you start up VS.NET... you get the idea. I'm surprised that you asked that question. From my experiments (not too many, I fully admit), the size of the executables I get is FAR smaller than similar C++ code. In general, even though .NET executables include meta-data on their exported types, IL is usually smaller than x86 code (not to mention RISC native code).

Please don't count that 20MB as part of your code. The "ship vehicle" for .NET is Windows itself, so most users will not have to download it themselves. Yes it is a problem.

"It seems like .NET gives us a "choice" of languages precisely where we couldn't care less about it -- in the syntax."

I think this is not so. The syntax is one advantage, but there are many others.

(Disclaimer: My opinions in no way reflect on those of Microsoft.)

Ziv Caspi
Monday, May 06, 2002

Everyone's talking about how cool .net will be.

That's all well and good but my time machine is broken so I'm working in the here and now. What has .net done for me lately?

Could you realistically write a .net app now to distribute over the net without annoying a large percentage of your target audience who will have to grab the 20mb runtime at 33.6kbps?

(disclaimer: I'm not a .net basher, Visual Studio .net is installed on all the machines I use at work and at home, and I'm a beta tester for .net server, so i've made an investment in it)

Robert Moir
Tuesday, May 07, 2002

I think that with the current state of .NET itself and its penetration, it's only really viable for internal applications and web services.

Seriously, who is writing shrink-wrapped .NET applications? I know of a few, but it seems like everyone talks about internal or B2B applications in an environment where installing the framework isn't a problem.

Glarkonman 2000
Saturday, May 11, 2002

*  Recent Topics

*  Fog Creek Home