Fog Creek Software
Discussion Board




Longterm impact of .NET

And now for something completely different (sorry, trolls):
As I understood, with .NET it doesn't really matter which programming language you use, since in the end you'll get MSIL anyway. Furthermore you can derive from .NET components no matter if they're programmed in C#, VB.NET, C++ with Managed Extensions...
Do you think this will change the way we use different programming languages. Is it just a question of personal "taste"?
What about using different programming languages within the same project?

Stephan
Thursday, March 21, 2002

it is a matter of personal taste to some extent already.  .NET makes it a difference of degree rather than kind, it might exacerbate a trend that exists already-but it won't create a sea change (let me qualify it as "in my opinion"). 

i've read a crap-load of .NET articles in the past month or so.  my impression that it will be an evolutionary advance-rather than a revolutionary breakthrough (makes things we do today far easier, rather than a whole new paradigm).  so i think it will be a factor in the evolution of specialized programming languages (for instance, Perl is traditionally a language geared toward regexp and command line tools-but now they have visual Perls-Java added regexp in 1.4, and so forth) developing into general purpose languages that reflects a convergence in function though a maintenance of stylistic differences. 

personally, i can't live without {} and ;, so i know where i stand.

Razib Khan
Thursday, March 21, 2002

The 'Language Independant' aspect of .Net isn't new.  In ASP you can use either VBScript or Javascript.  You can even add PHP or Perlscript.

The strange thing is that everybody uses VBScript.

This has always puzzled me.  At my place we have to use VBScript on our ASP code, company standard.  Yet we also have to use Javascript on the client code.

Surely it makes more sense to use Javascript at both ends - then you have to deal with only one language.  As it stands I'm switching between the two, which isn't ideal. 

So I think that everybody will just use C#, because thats the recommended language, except for those that have migrated using VB.NET.

Ged Byrne
Thursday, March 21, 2002

Your choice of language may also depend on what everybody else is using. For instance if there are thousands of tutorials on every aspect of programming in C#, but developing in JScript on the .NET platform isn't well documented, you may find developing in C# easier.

Ben
Thursday, March 21, 2002

If there's anything new in the .NET approach to multiple languages, it's that you can use the languages very closely together. It's more than just being able to call a function written in C# from a VB .NET client; you can actually subclass a C# class with VB .NET code. If there's another system that offers this, it's news to me (though I wouldn't be surprised). This is much deeper language integration than just hosting multiple script engines in classic ASP.

On the other hand, the "language independence" has been blown a bit out of proportion by Microsoft's PR machine. The design of the CLR (Common Language Runtime) imposes some limits on what a language can do and still be a first-class .NET language.

Plus, how often do you NEED to derive a class from someone else's source code in another language?

As to the long-term impact...too soon to tell, of course. I switch back and forth between C# and VB .NET depending on the project. But then, I've done that in other language for years, before .NET appeared on the scene.

Mike Gunderloy
Thursday, March 21, 2002

on using javascript on server-side and client-side for ASP-the reason against this for some people is that it can be confusing for some people to switch between two modes of using javascript, and using vbscript gets rid of the confusion.  i always thought it was a lame excuse, but ppl use it nonetheless (i think it applies to newbies-i always habitually add ; at the end of a line of vbscript when i first use it after a long break)

Razib Khan
Thursday, March 21, 2002

Just because they all compile to IL doesn't mean they compile the same.  Here's a recent example:

http://www.stronglytyped.com/Articles/fog0000000032.html

Peter Drayton posted the teaser...very interesting.
http://www.razorsoft.net/weblog/

Richard Caetano
Thursday, March 21, 2002

I switch depending on what I'm doing now (VB.NET to C#), but I could stay in one and still get things done - it's mostly switching just because I can.

On the "how often do you NEED to" subclass or inherit from someone else's code, it's not that I have needed to, but I am guessing that component vendors will eventually use this to great advantage: ship the widget assembly and let the customer (developer) inherit and extend: or allow your widget to graph out a collection of wonkets, or any other object a developer wants to put in, as long as they implement IWonket or inherit from wonket (perhaps nifty functions there).

It's a simpler step from the current "implement this COM interface" that some windows things do, and it has no horrible language interactions.

I do agree that it's going to be a more evolutionary process, because people (like me) will take steps down the wrong roads because we can - but eventually, .NET will be a pretty langauge independant system.  Hopefuly, employers will know that a C# guru will do pretty good with VB.NET, too.

Philip Rieck
Thursday, March 21, 2002

A thought that crossed my mind: if C# is case sensitive then you can declare two classes with same name only different case. But then, when calling from VB (that's not case sensitive) which one will be called?
I have'nt tried this yet.

Szasz Attila
Friday, March 22, 2002

Szasz,

The CLR mandates that any externally callable (ie, non-private) members' names must differ by more than just case. So, even though C# supports case-insensitivity, exposing multiple members or classes that differ only by case will break CLR-compatibility.

Ian Lowe
Friday, March 22, 2002

VB will call whichever version is declared first in the C# namespace. It won't see them both.

Mike Gunderloy
Friday, March 22, 2002

Some not-so-obvious things about .NET and language interoperability:

1) CLR has some features than are not accessible from C# or vrom VB.NET. If you write in IL assembly, you can access all the CLR features. Example: C# has 4 acess types (public, private, protected, internal) while CLR has 5  (4 + "protected internal").

2) From the other hand, to enable cross-language interoperbility, the code should follow CLS (Common Language Specification) standard, which is usually a subset of a CLR-based language. Example: Int32 is CLS type, UInt32 is not (but it's available in C#)

Igor Krivokon
Friday, March 22, 2002

I think MS loved to trumpet that whole language interop stuff just to make .NET sound cool, and to poke Sun in the eye for their "Java everywhere" stance.

.NET just seems like COM version 2. Write components, use them in any language. Sure, in .NET you can inherit classes across languages etc. but do you really think thats a *good* idea?

Kenshi
Saturday, March 23, 2002

*  Recent Topics

*  Fog Creek Home