|
Actually Chris, you should start a new poll with the title: "What makes you so sick about the new Microsoft technologies?"
And the possible answers could be like this:
(1) I feel like a pirate being forced to use *stolen* technologies from others (.NET from Sun's .COM and C# from Java, at least conceptually).
(2) A new language that dummies the power of C++ and generates software having the same performance as that made by VB / ASP / COBOL.
(3) Keep me spending my time and money on new technologies every few months.
(4) All of the above
|
|
|
|
|
Scott McNealy, you do really need to calm down.
|
|
|
|
|
>> *stolen* technologies from others (.NET from
>> Sun's .COM and C# from Java, at least conceptually)
Name one feature of Java that hasn't been done before.
Inheritance tree rooted in Object: SmallTalk, '70s
Reflection: SmallTalk, Objective-C '70s, '80s
Byte code / virtual machine: P-Pascal '81
Gargabe collection: Lisp, '70s ??
RMI: RPC, DCOM
Portable Class Libraries: C runtime
Portable GUI Class Libraries: Saw a demo of this from a company in Boulder,CO in 1992, can't remember the name.
>> A new language that dummies the power of C++
Don't use C#. You will still be able to compile C++ into native code.
>> Keep me spending my time and money on new
>> technologies every few months.
You don't have to spend your time or your money. Just keep coding in C++. Some of us don't mind giving up a little flexibility/performance to realize productivity gains. After all, even you realize the productivity benefits of using C++ over assembly language. 
|
|
|
|
|
One of the things that confused me (and I admit, made me sceptical) was the whole concept of the need for an intermediate language. If it all gets compiled to native code in the end, why not simply compile it to native at the start and be done with it.
The reasons are as follows: JIT compiling allows the CLR to produce code that will take advantage of the current processor. Current compilers will default to supporting the 486 chipset, whereas many of us are running PIII's. Compiling just-in-time allows the CLR to use the maximum capabilities of the current processor (or processors) by producing code that takes advantage of, say MMX instructions or PIII specific instructions should they be available.
Another reason is the compile-once, run anywhere advantage. No more shipping separate x86 and Alpha versions. An IL exe will be able to run on x86, Alpha, Itanium 64bit, mobile chips (SH3, MIPS etc).
Finally, JIT compiling means the CLR can produce different code for different circumstances. Suppose system memory is running low - the compiler can compile and run in a way that minimises impact on system resources.
|
|
|
|
|
Just what Sun did with their Java Virtual Machine (JVM) five years ago
|
|
|
|
|
Actually MS provided the first JIT compiler for Java, not Sun. It was what made the MS JVM faster than all the others
|
|
|
|
|
My memory is that Borland had the first JIT. Then Symantec. Any idea where this can be checked
|
|
|
|
|
I've got an early copy (pre 1996) of Borland C++ 4.5 at home - I beleive it has the JIT and some rudimentary IDE hooks for building .java in the IDE. When was microsoft's first JIT release?
I sure do miss ObjectWindows :
|
|
|
|
|
On all of this (and the previous message), are you not thinking of JIT debuggers? They were a crucial thing for C/C++ compilers before Java came along. Both Microsoft and Borland had JIT debuggers for their products. JIT Compilers are not required for C/C++ since most executables are native but they are very useful for Java
|
|
|
|
|
... except for the reduction in performance for native C++ code. The idea that C++ is being de-tuned so Visual Basic wont suck as much is a real shame.
|
|
|
|
|
Native C++ code won't have any reduction in performance. C++ code marked for .NET output (forget the term MS uses) will be compiled to the IL while the rest is compiled to native code. If you want power but also want to export to .NET you simply code in native C++ and wrap with a .NET wrapper, AFAIK
|
|
|
|
|
It's strange to see so many developers unimpressed with Microsoft strategy and the new technologies that were announced.
Among the PDC attendees there was certainly some cynicism, especially when the unavoidable Java comparisons were made, but in general there was a very warm reaction to this stuff. While some parts may be a little disappointing (especially to MFC/ATL programmers), there were many parts to the whole thing that were really great.
I'm just wondering if the negative reaction some people have to this is due to Microsoft and/or the media not reporting enough detail to really give you a feel, or whether it simply isn't something that takes your fancy
|
|
|
|
|
First off, I am glad to see that you have gathered so much info on .NET, Chris. I was really glad to see some first-hand comments from the PDC.
I see several reasons why MS is pursuing .NET, although not all are for us developers. (Surprise!) One major reason, as mentioned below in another message, is that if C# is pulled off correctly, the ugliness of COM/ATL/etc will be a thing of the past. (Except for high performance apps of course.) I mean, let's face it, COM is really ugly and hard, and it doesn't really need to be. C# is removing all of the unnecessary detail of IDL, GUIDs and all the rest. It's probably what COM should have been at the beginning.
As for the CLR, this ain't the grand unifying scheme that Sun was envisioning for Java. One of my coworkers thinks that this is the method that MS is using to skate around the problem of them being broken up by the DOJ. Since MS suspected their OS and dev people would be separated, what better way for their developers to deal with the situation than to compile to a common VM? A VM is not something that us developers need at all, but with the DOJ trial, MS was forced to figure out a way to continue to develop software in the lean, mean way they've been accustomed to. Food for thought.
And finally, no, I'm not excited about tying the whole Internet together with .NET. This is just complete marketing gloss. There are still going to be millions of Web sites, all with their own ideas for design and layout, .NET or no. I don't believe that the ability to tie Web sites together constitutes a compelling _need_ to do so. After all, that's what links are for.
Brando
|
|
|
|
|
I recently left Microsoft to join an Internet startup in Austin, where hopefully, my stock option will be worth something. However, I can tell you that this project has been in the works at MS for years and has nothing to do with the DOJ. I agree with Chris that you really have to see some demo's to appreciate what this tool can do. Based on the internal demo's I have seen, and without violating my NDA, I have the following observations:
Attributed programming will make it as easy to write COM objects in C++ as it currently is in VB. The previous author is right. COM is much more complicated than it needs to be. ATL was a step in the right direction, and now MS is taking us even further.
The XML editor that comes with VS 7.0 is killer. It beats the socks off anything else out there currently.
In my current position as a software engineer for a .com startup, I would love to have a tool like this. I am going to do all I can to promote this tool with my company
|
|
|
|
|
I'm all for new technologies, but MS dumps a new one on us every six months!
also, COM has been such a mess for so long (not the COM specification itself, but everything you need to do to get a COM interface up) that, hearing MS go on, yet again, about some new wrapper for COM is going to change the world is just more of the same.
and, if i don't like it, i'll just stick with VC6.
-
|
|
|
|
|
Personally I can see how important .net is going to be. However, I reserved my judgement until I read all the docs and fully understood where they were going with it.
MS have clearly been developing this for a long, long time and purposely kept it secret so that, once released and standardized, they retain their edge based on the lead they have in development tools.
I think a lot of the negative reaction is down to the fact that this wait. The media has apparently been successful in convincing developers that MS have gone stale, and that their technology doesn't matter anymore. And, sure, if MS stuck with the "unmanaged code" and "complex components" approach then they probably wouldn't matter any more in 5 years time.
So it seems that it's going to take a little more than just a conference to teach the world to face MS again. I think it will happen, but that it's going to take a little longer than they expected.
Once people start seeing that the majority of .net is standards-based (albeit new standards) and that MS just provide the best tools to use this new standard, becoming an MS zealot will be the best choice. People will soon realize what this "standard technology" can do compared to Sun's "proprietary technology", Java.
Writing has never been sufficient to convince people -- they just want to see it in action. Those who weren't at the PDC will just have to wait till September when it becomes downloadable.
--jm
|
|
|
|
|
I am also surprised. I was completely jazzed by what I saw and have played with since returning via the NGWSSDK and VS.NET.
When COM came along it solved some problems (allowing application and component services to be used across languages and process boundaries). However, it made the developer's job harder.
I look at the .NET Frameworks, the CLR and C# and I can see my job getting much easier with respect to writing reusable code. I will be able to focus more time on my value added and less time on boiler plate code, referencing counting, managing memory and deciphering the Win32 API.
I think this is a lot of the appeal of Java - simpler programming paradigm - and less so the portability story. However, I don't think everyone is going to buy into developing in just one language.
And hey, if squeezing every last bit of performance is your bag you can write native C++ applications that compile down to x86 instructions. MS has taken anything away from any developer. We just have some more options now for Windows development.
|
|
|
|
|
every few years MS gets grand ideas about how the computing world should work. OLE, COM, VBX, ActiveX, DCOM, COM+, ASP, ASP+, etc.. some of these catch on, some don't. but even those that do catch on never change the scene the same way MS wanted them to.
so, IMO, this is just more of the same
|
|
|
|
|
I would disagree. From the sounds of what is being offered, I think this is a step in the right direction, and one that will be equivalent of Win16 to Win32. In this respect I mean that there they cleaned up a lot of the plaque that had been building up (such as different memory models) and I think the .NET initiative (although its crappy name [in my opinion!]) will do the same cleanup treatment for the mess that has become of COM
|
|
|
|
|
Sorry for intrusion but what mess are you talking about? COM basically consists of one "simple" idea of vtable and "magic" run-time to instantiate those vtables. Everything else are additions - you are not required to use them
|
|
|
|
|
Well the things that have been mentioned so far are what you classify as "Additions" (but they are still important if you want to have a working product that integrates into other systems!!)
But also what about apartments ?? (or contexts (as they were otiginally called I think??), and as they have come back to haunt the MTA people who were sharing interfaces between thread in w2000)
What about security ?? (not that I have had the chance to play COM+'s security)
they can hardly be called "additions" and can hardly be called simple! And if you think they are (good for you), but go and explain all the rules to someone who is trying to learn COM.
Paul
|
|
|
|
|
What mess are you talking about. COM is great, it's elegant and powerful and solve a lots of problems. The only thing that they mess is using to many name for the same technology
|
|
|
|
|
Windows programming for a VC-developer is a mess. Take fx a string. In MFC you have a CString, COM uses BSTRs, CComBSTRs, the C language has char*, the WinAPI has a whole bunch of string types (TCHAR, LPSTR, LPCSTR, LPWSTR etc.) which is just typedefs of other types.
What's the reason for that ? Why can't we just have a string like those VB-people.
I think thats really a mess. The common type system in .NET solves that among a huge amount of other things
|
|
|
|
|
It is a mess, IDispatch is a mess. Type Libraries and Variant compatible interfaces are a mess. Arrays are a big mess. GUIDs in VB is a big mess. Versioning interfaces in VB is a big mess. The strategy behind interpreted P-Code running in a sandbox is non-existent (script only is not sensible)
.NET solves this and more. This is big, and the people that don't think so don't understand it fully yet. The fact that a lot of this is being sent to ECMA should be making big players like IBM take notice.
|
|
|
|
|
Well, THESE things are an old root, called C. it was originally decided that C has no native string class; and The common acceptance of STL simply came too late (partially based on the fact that it requires a deep understanding of C++ and is very confusing for beginners).
Remember, C was originally designed to program both mainframes, and embedded systems that have neither display nor keyboard; or too few RAM to make dynamic memory managment useful. And C++ (luckily) inherited much of this attitude.
On the other hand, I agree - MS would have hit the spades if they had provided CString as MFC-independent class from the very beginning (one of the most tedious problems of ATL or raw Win32 programming is finding an appropriate string class - typical solution is to rip CString off MFC)
The other thing, C has always taken the option of the most effective code - and ANSI applications run faster under Win98, but under WinNT/2K, UNICODE applications are clearly favoured. That's why you have tons of macros for the Ansi/Unicode stuff in C. VB opted for BSTR's - but this was an easy choice, when UNICODE was somehthing that had to be supported and simplicity is favoured over effectivity. Remember, the C design thought of any weird "char" size (like 7 or 9 or whatever bits) - but not of a character type that is larger than the smalles adressible unit.
After all, it's the old song of the intentions of C - to clearly point this out: you can't blame MS being responsible for "too much backward compatibility", this time it was Bjarne himself.
------
Some general note:
If MS makes compromises to care for existing code they are blamed of being overly backward compatible (which I do, too, often enough), If they cut the rope, peoply cry "they betrayed us" (again, I often join this chorus).
I do MFC/ATL programming for a living, though I should be most "affected" by the change - strangely enough, I'm looking forward to these things. I simply hope for a relief of the COM pain.
Regards,
Pete
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
