Slashdot Mirror
Microsoft Developers Respond To .NET Criticism
bonch writes "Richard Grimes of Dr. Dobbs Journal wrote an article entitled Mr. Grimes' Farewell, in which he discusses what he feels are inherent flaws in .NET, and how he is abandoning his .NET column. Grimes argues that .NET is merely thin wrappers to Win32 calls (Avalon uses message functions that date back to 16-bit Windows), that Microsoft has abandoned confidence in both .NET and sales of Longhorn, and that the framework itself is too large and poorly implemented, most of it ported from past APIs like WFC and VB. Dan Fernandez, Microsoft's Visual C# Project Manager, has responded in his blog. Richard Grimes appears in the comments to defend his criticism, referencing first-hand disassembly of .NET APIs using ildasm. Scott Swigart has also responded to the criticism of Visual Basic .NET. Apparently, Mr. Grimes struck some nerves."
Of course it is. That's called functional programming!
I suggest you take some time to read up on functional programming.
(Disclaimer: I know what you're meaning to say, I'm merely pointing out that the term you used isn't what you think it is.)
"So should Firefox. They are simply papering over the enourmous cracks and legacy rubbish that is Netscape 4.0."
The Mozilla project did do a massive rewrite of the original Netscape code.
But surely the library is a wrapper. You're not calling Win32 directly, but through the framework shim. You can implement the namespaces on more than one platform, mono is proof of that.
This is an old tactic of Microsoft. Thow out backwards compatibility and force an upgrade. I think most M$ users are used to this by now. If you want to keep up with the latest and greatest you have to rewrite to take advantage of the cool new features. This has been going on since the beginning.
It will continue as long as developers are still willing to take the dirty sanchez that Microsoft has to offer. Microsoft is in it for the MONEY only. Advancement of computer science is not a concern.
This is an old tactic of Microsoft. Thow out backwards compatibility and force an upgrade.
Uh, no. The framework works on Win98+ (see the download page).
Half the complaints here are picking up on the "layer on top of Win32" comment which is exactly the backward compatibility point.
How is 23.7 many times 15?
Isn't the guy also complaining that alot of it is just wrappers? If they weren't, wouldn't it be much bigger?
Can't have it both ways.
The C99 specification has been out for over 5 years. There is really no excuse for using older versions these days.
I am TheRaven on Soylent News
Are you sure? Why most DOS apps still runs in Windows XP? You can use your Word 6.0 in your Windows XP with no problems. I think it makes sense to rewrite parts of your application to take advantage of new features. How can you develop software using an API that doesn't exists? Try to develop a Linux app
Umm .. the .Net library has a namespace called System.Windows which contains all the windows-specific functionality (COM, System.Windows.Forms, etc).
.Net is undeniably built with Windows in mind, but it's hardly 'win32-based'.
Nobody is forced to use this namespace, nor can we blame MS for offering Windows-only functionality.
The runtime runs just fine on any platform (Rotor and Mono show this) and the library is clearly devided between Windows libs and 'common' libs like XML, SOAP, HTTP, etc.
There are also plenty third party libraries available to enable platform independence. (GTK#, WX#, etc.)
The path I walk alone is endlessly long.
30 minutes by bike, 15 by bus.
Just so you all know, THIS GUY WAS MAKING A JOKE. .Mac is completely unrelated in scope to .NET. It's an Apple-centric hosting service with lots of OS integration for contact and bookmark syncing, plus webmail and hosting. It's not a runtime. I wish I had mod points right now.
That's exactly it.
MS heard a lot of feedback - from me included - that developers weren't going to spend time and effort learning about Avalon and WinFS if only Longhorn users would have it. WinXP is very well saturated right now, today.
There is no way I am going to develop any app that only works for Longhorn users. At the last PDC conference there were a lot of shallow "ohh's and ahhs" but not a lot of excited committment, because hey, why bother if my users can't use it for 5 years?
I think it's valid in the C99 specs, which is the current standard for the C language.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
As for the underscore thing... many people agree with you, but this_little_thing is slightly more verbose (takes longer to type AND read) than thisLittleThing without adding content. But hey, that's another one of those religious issues that always flares up whenever the project coding standards document is released.
I'm not defending Grimes, because I honestly think he's lost his mind, but I'm looking at some of my very old Powerpoints when I, too, was involved in the very early (pre) betas, and, sure enough, there it is: COM+ 2.0.
In fact, I see COM+ 2.0 far more than COM3, prior to the change to NGWS.
Looking back further still, the original COM+ was more like COM+ 2.0 (with attributed-based programming extensions to C++, no less), but that got scaled back and the shipping version of COM+ was more akin to COM+MTS.
Yes, it's true. This man has no dick.
There is Python/tk. The problem is that TK sucks compared to wxWindows.
Researched the name? Hah! Have you ever seen how products get named in big companies?
/dev/null
It generally goes something like this:
1) developers work on product, calling it by one (informal) name
2) product gets close to release
3) marketing department sends out email to developers telling them they've come up with a name for the product, implying they'd like feedback
4) developers scream because the "formal" name is meaningless drivel that tells the user nothing
5) marketing department changes the name in a manner that has nothing to do with developer feedback, as all of that email went to
6) repeat 3-4 until marketing department has a name they like
7) release product
Java is not open. C# and the CLR are. They are ECMA standards.
I'm getting tired of correcting people about this, but I can't help myself. C# and the CLR ARE NOT OPEN. An organization has embraced them in their list of standards. That does not mean they can be changed by anyone and still be a standard. They are not documented any better or worse then Java and their implementations do not have to be open.
The only difference between these things being standards is that Microsoft can't change the interfaces and say they comply with the standard. Meanwhile Java can be changed at any time by Sun.
And if you still want to call the CLR open then don't forget many parts are patented. So having it as an "open" standard is irrelevant when you can easily be sued by its creator for using it.
Developers: We can use your help.
I'm not saying you shouldn't use C#, but here are some of the reasons I continue to use Java:
You could have had all the advantages you mentioned ages ago by using Delphi.
Uhm, perhaps years ago, when they were dicking with losers like VBScript, ASP, and ActiveX. But those are all old technologies, ones MS is no longer pushing.
Correct, they are now pushing new looser technologies like XAML. Thus the posters point since from the users point of view XAML looks very much like those other technologies - they go a website and encunter something unexpectedly powerful. With great power comes great responsibility, and that is what Microsoft has seemed to lack over time.
Even if they use XAML as a replacement for ASP.NET, it will completely render to industry standards on the front end, just like ASP.NET.
Render to what now? Do you know what XAML is? What standard would that render to? It's going to be a lot of XML (like XUL in fact) that describes a GUI app that renders on the screen using native controls, kind of like a really verbose scriptable AWT. Not like we've been down that road already...
But anway, XAML runs on the front end. It's totally a front-end technology, just like ActiveX in the way that the client is running code to make it happen. And while it might be more secure it's only as secure as whatever client is rendering the XAML code, and that calls into question again how secure is that code really in terms of what XMAL can call.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Exactly. I was really hoping that Avalon with .NET would become a new environment subsystem to replace Win32 in Longhorn. This is exactly the kind of thing that environment subsystems were designed to do: .NET is a new API, has (or should have) a completely seperate interface from Win32, and it will (supposedly) have an entirely different graphical and windowing system. Hey, even ReactOS is planning a Java environment subsystem, one not built on Win32.
.NET wouldn't have this problem: events are objects, and you can always add new properties to
Win32 was introduced in NT 3.1 to be easy to port using source code written for (dos) Win3.1 that followed all the Win16 API rules. Win16, IIRC, goes all the way back to Windows 1.0. Since then, layer after layer of compatibility has been added so that you can still compile different binaries that will run on Win1.0, 3.1, 95, NT, XP and everything in between using the same source code. Compatibility is nice, but forcing the main API to be compatible with all those previous versions is getting a little excessive. There should be wrapper libraries that covert the old API versions to the new ones without sacraficing the design of the new API's interface or implementation.
Win16 was never designed for long-term compatibility, and it shows. All windows are expected to be visible to all applications and allow unrestricted transmission of messages, including dangerous ones. NT works around this by dividing the window spaces into desktops, but desktops can't be used widely because the would break compatibility.
Note subtle differences between WM_XBUTTONDOWN, WM_LBUTTONDOWN, WM_NCXBUTTONDOWN, WM_NCLBUTTONDOWN, WM_NCHITTEST, and WM_INPUT. WM_L/R/MBUTTONDOWN were used in versions previous to 2000/ME to be compatible with Win16. The WM_XBUTTONDOWN is a more generic version introduced in 2000/ME. WM_NCHITTEST also sends click messages, but also includes movement and some special events also duplicated in WM_SYSCOMMAND, WM_ACTIVATE and WM_APPACTIVATE. WM_INPUT does the same things, but with handles and less pre-processing. The WM_NC* messages are special for non-client messages that haven't been captured. Juggling capture, focus and disabled windows is fun.
Each windows message has exactly two parameters: lparam and wparam. This can't be changed because it would break the fixed format of all the message functions. There are many creative ways to cram as much information into these two parameters as possible. The MSG structure has a few other fixed properties, like pt for screen coordinates which are sent even for messages that have nothing to do with coordinates, so some functions use it to pack more parameters.
This is completely untrue. There are a ton of languages that compile to java bytecode. The current list is almost 200 languages!
Parent and modders, please stop propagating this lie.
Have you ever tried to use a C code library with Java.. may as well pull your hair out now.. much nicer in C#.. that's probably my best example.. beyond that, they are more similar than different.
Michael J. Ryan - tracker1.info