Sign in to follow this  
aidan_walsh

[.net] .NET 3.0 is a lot closer than we thought

Recommended Posts

Looks like Microsoft has been hiring from Sun. They seem to have gotten the people responsible for the whole Java\Java2 thing...
Quote:
Somasegar's WebLog tells us: The .NET Framework has always been at the core of WinFX, but the WinFX brand didn't convey this. The WinFX brand helped us introduce the incredible innovations in terms of Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Windows Workflow Foundation (WF) and the newly christened Windows CardSpace (WCS) formerly known under the codename "InfoCard." The brand also created an unnatural discontinuity between previous versions of our framework and the current version. With this in mind we have decided to rename WinFX to the .NET Framework 3.0. .NET Framework 3.0 aptly identifies the technology for exactly what it is - the next version of our developer framework. The change is in name only and will not affect the technologies being delivered as part of the product. The .NET Framework 3.0 is still comprised of the existing .NET Framework 2.0 components, including ASP.NET, WinForms, ADO.NET, additional base class libraries and the CLR, as well as new developer-focused innovative technologies in WPF, WCF, WF and WCS
So .NET 3.0 is really .NET 2.0 with some other stuff that they were working on tacked onto the side. The upcoming C# 3.0 will probably target .NET 4.0, which will be CLR 3.0, and WinFX 2.0. Everyone still following? Of course none of that matters. It will still be refered to by everyone as 3.0 - which of course is the point of it all. One way to look at it is that it simplifies having to explain to people what WinFX is. Of course, you shouldn't have to explain that to them any more than you should what WinForms is. The biggest (and probably only real) boon is that it makes distributing apps that build on these a lot easier. The fun part is initially trying to get your head around it. EDIT: Added link.

Share this post


Link to post
Share on other sites
I love the little diagram they have at the link. "We are changing the name of one of our technologies. This is what the change will look like from a strategy/pretty diagram point of view. Note the change in lettering."

Share this post


Link to post
Share on other sites
Quote:
Original post by jflanglois
I love the little diagram they have at the link. "We are changing the name of one of our technologies. This is what the change will look like from a strategy/pretty diagram point of view. Note the change in lettering."
The diagram is more complex than that. The color changed too!

Share this post


Link to post
Share on other sites
I couldn't find where in the article that they said they had been hiring Sun engineers. Could you post a link to that??

Cheers
Chris

Share this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
Last I checked, C#3.0 wouldn't require any changes to .NET or the CLR, so it'd still target .NET 2.0

Well I admit not keeping as much up to speed as I probably should, so it was just something of an assumption that there would be CLI changes in the next version as well.

Quote:
Original post by chollida1
I couldn't find where in the article that they said they had been hiring Sun engineers. Could you post a link to that??


Yeah, that was me being facetious...

Share this post


Link to post
Share on other sites
Quote:
Original post by Alpha_ProgDes
Did they hire the Sun people to confuse us with all the numbers?


i think that was the joke. besides, they already have the xbox division for that. ba-zing!

Share this post


Link to post
Share on other sites
Quote:
Original post by SticksandStones
Ok, so C# 3.0 will use .NET 4.0 which will come after .NET 3.0 that was really WinFX but not?


Wow, I should get into government if I this good with misinformation [grin]

Actually, I seem to have been wrong there. That was a bad assumption on my part, as Spoonbender pointed out C# 3.0 will apparently (so far anyway) target the current .NET 2.0 CLR, which will of course at that time be in .NET 3.0.

WinFX is .NET 3.0. Most of the underlying stuff is already out as .NET 2.0, but when WinFX is released come Vista, it will be integrated with what we now know as .NET 2.0 and released as .NET 3.0.

Share this post


Link to post
Share on other sites
Quote:
Original post by SticksandStones
Ok, so will .NET 3.0 that is WinFX support the other stuff that .NET 3.0 was supposed to have a few months ago?


I can only suppose.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
What did you expect?
Everytime they add something to the .net libraries they have a new C# compiler?
Everytime they add something to the .net libraries the new stuff will have the same version as the .net framework?

Share this post


Link to post
Share on other sites
So here are some questions I have about the .NET platform.

1. Why not include a linker so distributing .NET applications becomes viable?
2. When are we gonna get an officially supported .NET language that doesn't completely ignore all programming language research outside of the Java world? (closures, metaprogramming system, duck typing and/or type inference system, etc.)
3. Can we get some assurance that choosing .NET as a platform will not result in vendor lock-in? Another words, how about contributing code to Mono?

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
So here are some questions I have about the .NET platform.

1. Why not include a linker so distributing .NET applications becomes viable?

ClickOnce Application Manifest.
Quote:

2. When are we gonna get an officially supported .NET language that doesn't completely ignore all programming language research outside of the Java world? (closures, metaprogramming system, duck typing and/or type inference system, etc.)

F#.
Quote:

3. Can we get some assurance that choosing .NET as a platform will not result in vendor lock-in? Another words, how about contributing code to Mono?

Rotor.

Anything else?

Share this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
ClickOnce Application Manifest.

That's an alternative to Sun's WebStart. It doesn't address the problem I mentioned (having the .NET runtime *in the first place*). This makes it completely impractical to deploy .NET applications and a royal pain in the ass to write server applications (one thing is dropping python.exe in the bin directory, another thing is waiting for an hour to install an "update" to the OS). Why can't they just let us link to .NET libraries statically? Furthermore, ClickOnce only runs on IE.
Quote:
Original post by capn_midnight
F#.

Dude, I know about F#. It's a research project. It's no more officially supported than IronPython.
Quote:
Original post by capn_midnight
Rotor.

Come on, man. If I build my business around .NET and tomorrow Microsoft chooses to obsolete existing Windows version and double the price for the new version, I'm stuck. I may choose to run Windows today because I feel it's a great server OS for the buck, but if they double the price I might wanna move. Whoops, I can't.

I want a commercial version of .NET supported on multiple platforms (no, Win32 and Win64 is not it). I also want assurances that they won't drop support tomorrow. Contributions to other projects would be nice. Their current license doesn't allow that.

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
Quote:
Original post by capn_midnight
ClickOnce Application Manifest.

That's an alternative to Sun's WebStart. It doesn't address the problem I mentioned (having the .NET runtime *in the first place*). This makes it completely impractical to deploy .NET applications and a royal pain in the ass to write server applications (one thing is dropping python.exe in the bin directory, another thing is waiting for an hour to install an "update" to the OS). Why can't they just let us link to .NET libraries statically? Furthermore, ClickOnce only runs on IE.

Because linking to the libraries statically completely defeats the purpose of having a COMMON Language Runtime, a COMMON Language Interface, etc, as well as defeats the purpose of having parallel versioning. And since you're talking about server applications, the market is mainly held by Java, which has the same (if not worse) issues. You're so worried about platform independence, statically linking the libraries is going AGAINST that goal!

Right now I can write apps that run on .NET, mono, and DotGNU, specifically because the API is standardized and the application is free of those libraries.

ClickOnce will, however, help you manage application dependencies. What do we have for that with native languages? Apt-get? How do I run that on Windows? I don't want to get locked into Linux. Google Pack Updater? Who knows if they'll ever finish it.
Quote:

Quote:
Original post by capn_midnight
F#.

Dude, I know about F#. It's a research project. It's no more officially supported than IronPython.

It's not a research project, it's currently in Beta. .NET is only a few years old, It's progressed extremely far in that time, especially compared to it's nearest competitor, Java. There are a lot of companies that are working on different .NET languages. Maybe you could throw your hat in the ring. Do you expect MS to do all the work? I thought you didn't want to depend on MS too much. JScript.NET has a lot of what you're talking about and it IS a fully released language.
Quote:

Quote:
Original post by capn_midnight
Rotor.

Come on, man. If I build my business around .NET and tomorrow Microsoft chooses to obsolete existing Windows version and double the price for the new version, I'm stuck. I may choose to run Windows today because I feel it's a great server OS for the buck, but if they double the price I might wanna move. Whoops, I can't.

I want a commercial version of .NET supported on multiple platforms (no, Win32 and Win64 is not it). I also want assurances that they won't drop support tomorrow. Contributions to other projects would be nice. Their current license doesn't allow that.

If MS were to do that, they would be completely shooting themselves in the foot, especially since .NET is only MS's implementation of the CLR/CLI ECMA Standard. Why standardize it if they were going to jack everyone over?

*Current* applications (with a few minor exceptions) run on .NET and Mono (DotGNU is kind of lagging behind). So if you adopt .NET now, and MS jacks you over, there is nothing preventing you from switching to FreeBSD or OSX and running Mono or Rotor.

The standard is open, which is more than can be said for Java OR C++. If anything, .NET has a better chance of becoming the panacea of cross-platform compatability than either Java (in bytecode) or C++ (in source code).

All I hear from you is "I want to be free from the tangles of MS" and "I want MS to do more."

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
"All I hear from you is "I want to be free from the tangles of MS" and "I want MS to do more.""

those two statements are certainly *not* mutually exclusive.

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
Quote:
Original post by capn_midnight
F#.

Dude, I know about F#. It's a research project. It's no more officially supported than IronPython.
The whole god damn point of the CLI is that anyone can do a language and it doesn't need "official" support to be perfectly usable for everybody. You can go write an app in F# today, ship it, and your users will have no idea that anything is different. Admittedly the VS extension is primitive and such, but to insist that MS build a whole new language team and award it C# importance is just unreasonable.
Quote:
I want a commercial version of .NET supported on multiple platforms (no, Win32 and Win64 is not it). I also want assurances that they won't drop support tomorrow. Contributions to other projects would be nice. Their current license doesn't allow that.
Novell supports Mono. More than that, I do not know.

Share this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
Because linking to the libraries statically completely defeats the purpose of having a COMMON Language Runtime, a COMMON Language Interface, etc

The purpose of CLR and CLI is to allow interoperation of multiple languages. Statically linking to the runtime (which shouldn't be more than a few hundred kb) and the appropriate class libraries doesn't defeat this purpose.

Quote:
Original post by capn_midnight
as well as defeats the purpose of having parallel versioning.

The purpose of concurrent versioning is to ensure that replacing a shared library with a newever version won't break applications that depend on the old version. If you link statically, this problem disappears all together.

Quote:
Original post by capn_midnight
And since you're talking about server applications, the market is mainly held by Java, which has the same (if not worse) issues.

I never said Java is any good.

Quote:
Original post by capn_midnight
You're so worried about platform independence, statically linking the libraries is going AGAINST that goal!

No it doesn't. It prevents people from running the same executable on many different architectures without recompiling. If you want that, you'd have to do dynamic linking. Most people don't mind recompiling though, but they do mind having the user download 100 meg runtime and spend an hour installing it just to run a 3 meg app.

Quote:
Original post by capn_midnight
Right now I can write apps that run on .NET, mono, and DotGNU, specifically because the API is standardized and the application is free of those libraries.

As I said, few people care about that. All you'd have to do to port is recompile. You're trading off ability to deploy your app without recompiling with ability to deploy your app at all. Why not just give people the option?

Quote:
Original post by capn_midnight
ClickOnce will, however, help you manage application dependencies.

If you link statically you won't have any dependencies.

Quote:
Original post by capn_midnight
It's not a research project, it's currently in Beta.

It's not supported in Visual Studio, Microsoft didn't put its weight behind it, it's not being properly funded. Instead they chose to fund the abomination that is C#.

Quote:
Original post by capn_midnight
.NET is only a few years old, It's progressed extremely far in that time, especially compared to it's nearest competitor, Java.

Dude, stop comparing .NET to Java. Saying something is better than Java is like not saying anything at all. Why don't you compare it to other competitors like Ruby, Python, or Lisp?

Quote:
Original post by capn_midnight
Do you expect MS to do all the work? I thought you didn't want to depend on MS too much.

I expected them not to ignore every single aspect of programming language research in the first place. As it stands, C#/.NET is just a very well polished Java. I don't want a very well polished Java.

Quote:
Original post by capn_midnight
*Current* applications (with a few minor exceptions) run on .NET and Mono (DotGNU is kind of lagging behind). So if you adopt .NET now, and MS jacks you over, there is nothing preventing you from switching to FreeBSD or OSX and running Mono or Rotor.

There was a time when I was contributing bug reports to Mono when I was trying to port a .NET application to it. It certainly wasn't easily portable. That was a few years ago though, the situation might have changed dramatically. Rotor doesn't support the latest version of .NET on platforms other than windows.

Quote:
Original post by capn_midnight
All I hear from you is "I want to be free from the tangles of MS" and "I want MS to do more."

Well, yeah. There is an abudance of very powerful languages that are free as speech and beer. If they want my business they have to work harder.

Share this post


Link to post
Share on other sites
Quote:
I expected them not to ignore every single aspect of programming language research in the first place. As it stands, C#/.NET is just a very well polished Java. I don't want a very well polished Java.


Then take a look at the C# 3.0 specification.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this