.Net Framework and Visual Studio Now Available
DJ-Dodger writes "The Microsoft Blogs are all buzzing with news that the .NET Framework 2.0, Visual Studio.NET 2005 and Sql Server 2005 have released to manufacture. Michael Swanson's blog has a nice run down of what's available now and what's coming. The short version: MSDN Subscribers can download everything now, everybody else can pick up their copy after the November 7th launch." The .Net framework is downloadable from FileForum.
This article made me think about it. I mean Microsoft is shipping an operating system without a compiler included. Isn't that strange, that everyone takes this as normal? Isn't a compiler an integral part of an operating system.
I mean sure, a nice IDE is something different, and with those Express Editions things have changed now, but still... if you buy a computer out of the box you can't program it. Not even a simple compiler, Basic or whatever.
In the good ol' days that would have been unthinkable...
Eclipse is an absolutely awesome development platform. It is packed with so many useful things, that it's hard to imagine what developing without would be like. Being able to rename a class and every call to it, or turn a bunch of methods into an interface or seeing all compiler errors in real time etc., is so mind bogglingly useful that I don't think I could ever go back to a plain text editor unless it was forced on me. I'd say without a shadow of doubt that using something like Eclipse halves the amount of time it takes to develop code over a text editor.
DevStudio 2003 is not so great in this regard (although editing forms is easier) but I expect that the 2005 edition is a hell of a lot better. I'll have to grab the "express" version and get a taste of how far it's advanced.
Does anyone know what changed between .NET 2 and 1.1? I can't find anything on Microsoft's site describing what changed.
Ignore the fact that Java stole from C++ and Smalltalk just as much as C# stole from java.
Ignore the nifty new features that C# introducted... Annotations, foreach, data binding etc.
Ignore the fact that Java has now lifted these features from C# and has them in the new version of Java!
Ignore all of the neat new features coming with 2.0 and 3.0. Generics and Closures? Who needs thoose!
It's 2005 because it was developed during 2005?
s p0 12_3-5129900.html
Developed in 2005?
http://www.eweek.com/article2/0,1895,1656883,00.a
http://news.com.com/The+long+road+to+Yukon/2100-1
SQL Server 2005, previously codenamed Yukon, is about two years behind schedule.
Just one sidenote: These morons that run Slashdot really blow me away. I hardly think I'm the only one, but I put in a submission just after the RTM yesterday with more information, that was worded better, that was more accurate, and that had several interesting historical links. It was REJECTED before the submission they accepted was even submitted (how do I know that? Because the submission referenced some lame blog post that happened about 11 hours after the release, after anyone who actually cares for this sort of info had heard it from someone who heard it from someone [repeat that about 7 times]).
Am I bitter? Absolutely - These morons seem to just randomly pick and choose their tripe stories. When one carefully crafts a submission to do the job that these clowns are too incapable of doing, to know that they're rolling dice between swigs of Jägermeister. And then, for the people dumb enough to actually rely on Slashdot for any sort of info (there might be a few left), they get to hear it a day or more later. Timely!
Because most programmers, regardless of platform, are idiots by default. Typically the reason for the problem is that the person writing the application makes the stupid assumption that the user can write a file to the same directory that contains the program. The other common mistake is attempting to write to HKEY_LOCAL_MACHINE.
Unfortunately this is largely because DOS and Win9x could not prevent this from happening. People got lazy and carried over their non-skills to WinNT. But some of those programmers also carried their non-skills to UNIX. I've worked with two UNIX-based systems where security was atrocious.
One was an autodialer platform built on RedHat Linux 7.2. All daemons run as root. All users log in as root. They even train you to transfer files to the host by logging into FTP as root and putting the files into the same directory as the main database files and where the core binaries are kept. One mistaken overwrite and BOOM.
I tried to lock down what I could, creating separate logins for users and a public user for FTP that only had access to a single directory. It drove their support nuts who would always blame me anytime something broke. Fortunately, I don't work with this system anymore.
Ignore the fact that Microsoft could have just supported Java in the first place instead of trying to illegally maintain their monopoly by undermining it.
Does a Christian soccer team even need a goalkeeper?
you are sacrificing quite a bit of processor time and system memory in the process. Garbage collectors and every other tool meant to make programming easy costs heavily in time and hardware. Most probably you are going to say that now days computers are fast enough to pay the toll...
No, actually, I'm going to ask why Digital Mars D, a language with garbage collection, wins as many CPU time contests as it loses to g++ in the Great Computer Language Shootout, and uses less memory.
Maybe it's time to re-examine your preconceptions?
You seem to be have a lot of complaints about what is essentially good API design:
.NET - not as "open" as open source perhaps, but it makes versioning far less painful, and hence, backwards compatibility is much easier to achieve.
* Sealing classes is good practice when that class is not designed for inheritance.
* Preventing unchecked construction is good practice when an object is designed to be the result/a handle to/or a control mechanism for some other (possibly transient) object state. Enumerators are a prime example here.
* Classes that only exist to provide some internal implementation are best left internal - a smaller public API means less things to support in perpetuity, and less chance that a programmer will rely on implementation details.
* Static classes have many uses - you can use them to represent a singleton object, or you can encapsulate, non-object specific operations. Like everying in System.Math for example. Not everything is best represented as an object - Microsoft is pragmatic enough to recognize that, even if some object-oriented bigots don't or won't.
Perhaps you're used to open source, source code reuse where you can basically hack anything you want to achieve your ends so long as you are prepared to deal with serious merge conflicts when you version your code. Microsoft restricts software to API reuse in
Actually, it was Sun who undermined it. They were more interested in the WORE fantasy then in the adoption of the language. If they hadn't sued MS, Java would probably have been second only to VB as the language of choice on Windows, C# would not exist, and the number of desktop Java apps would probably be an order of magnitude higher.
I believe that Sun wanted Java to be somewhat slow on all systems equally so they could sell Java processors that accelerated Java applications to native speeds. Having a Java implementation that optomized performance on Windows threatened that plan. Thus the suit.