I had a Mac for a while. It didn’t really work for me, but I take the chacun a sont gout view of these things. If you like using a Mac and OSX, be my guest.
What I object to is some of the bull that’s written about Windows (or Linux).
There’s an article on ArsTechnica by a developer who switched from Windows to Cocoa development.In part 2, he decided to take on .net.
After a whole lot of wild, stupid, and frankly biased nonsense about the types of developers (only people who write packaged software for themselves count), he tries his hands at some facts:-
.NET isn’t like that. Although .NET can call C APIs (just like everything else can), the real objective is for all programming to reside in the .NET world. .NET is meant to be the entire platform, with all the different languages that people use living inside the .NET environment.
All programming? That’s why Visual Studio 2008 still compiles C++ for Win32?
This is why .NET has APIs for tasks like reading and writing files; in the .NET world you’re not meant to use Win32 to do these things, you’re meant to use .NET’s facilities for doing them.
Firstly, it’s a lot easier using .net’s facilities, and secondly, it’s better because it’s managed code.
Because everything now has to live “within” the .NET world, .NET has to be all things to all people. Well actually, that’s not true. It’s trying to be good enough for the first and second kind of programmer. The third type—well, just ignore them. They’re too demanding anyway.
The thing is that the first 2 groups are also demanding. It’s just a question of how you determine “demanding”. I build database driven websites and applications, and I’ve thrown a lot at .net, and it’s always delivered for me. So, from my perspective, I demanded and it delivered.
If you’re going to do 3d rendering, games development or write a search engine, you probably don’t want .net. You don’t want the overhead of managed code, and can probably afford the overhead of writing unmanaged code. But that’s a tiny proportion of the software development world.
But for data processing .net and vs.net just make your life easy. It makes you more productive. It means that instead of wasting your time hunting down memory leaks and sorting out pointers, you’re writing business logic and giving more value to your customers.
The .NET library is simple to the point of being totally dumbed down; it’s probably okay for the first and second groups, not least because they don’t know any better, but for the rest it’s an exercise in frustration. This frustration is exacerbated when it’s compared to .NET’s big competitor, Java. Java is no panacea; it too is aiming roughly at the middle kind of developer, which is understandable, as they’re the most numerous. But Java’s much more high-minded. It’s much stronger on concepts, making it easier to learn.
Such as? Oh no, he doesn’t say. “Dumbed down”? What the hell? Is the author suggesting there’s things that .net can’t do that Java can, because I’ve yet to find something. Maybe he means that .net just makes life easier.
There’s actually a lot in common between the two. Where there are differences, I’d not call either “wrong”, just “different”.
For example, .NET provides an API named Windows Forms for writing GUIs. Windows Forms is based heavily on the Win32 GUI APIs; the same GUI APIs that owe their design to Win16. To properly write Windows Forms programs, you need to know how Win32 works, because there are concepts from Win32 that make their presence felt in Windows Forms.
He’s talking about threads, and as someone who came from somewhere other than Win32, I picked up threads in a few hours. It’s not exactly a tricky concept.
There’s a way to test whether an update to a window needs to be sent to the thread that actually owns the window or not, along with a mechanism for sending the update to the window’s thread. Except this way doesn’t always work. Under some situations, it can tell you that you’re using the correct thread already even if you’re not. If the program then carries on and tries to perform the update, it may succeed or it may hang or crash the application.
Never had this, and never heard of this before. The author could have linked to some code that showed this…
These little issues are abundant. The .NET library does work. It more or less has all the main pieces you need, but it’s full of areas where you have to deal, directly or indirectly, with the obsolescent mediocrity of Win32.
I’d disagree with that. OK, it probably wraps some Win32 concepts, but it abstracts the heavy lifting. The only way to make .net concepts simpler would be to lose overall functionality.
If Win32 was a mess and .NET didn’t fix it, the other opportunity MS could have had was to fix it for Win64, the 64-bit Windows API. Porting a program to Win64 requires a recompile at the very least, and it can often require code changes to avoid doing things that are safe for 32-bit processors but not for their 64-bit brethren. Because of this necessary recompile, one would think that MS could surely have tidied things up a bit. Maybe not radically overhauled, but tidied up.
Why? Why would you want working functions removed so that you’d have to change your code to make it work? Backwards compatibility is what businesses that use .net, and even companies that build package software, want. Obviously, we want to use better functions, but we also want the luxury of not being forced to swap over.
I’ll give you a reason why: Photoshop CS4 64-bit. Windows is getting it, Mac OSX isn’t. The reason is that Photoshop is written in Carbon, and Apple decided at WWDC2007 to drop Carbon 64 (having a year earlier told developers that it would happen in Leopard). Which means a huge amount of rework to make it work with Cocoa.
Now, Microsoft annoyed a lot of VB6 developers when they brought in .net. They lost a lot of skills, and companies with VB had to consider their options. But at least they had a routemap that could be described as sensible. Microsoft made it clear to developers what would happen when they announced .net in 2002, and vb6 ended official support in March 2008. I’d prefer Microsoft kept supporting vb6, but 6 years isn’t too bad. Developers had plenty of notice.
While code deprecation can leave a lot of stuff lying around, it’s also what gives developers stability.
So Windows is just a disaster to write programs for. It’s miserable. It’s quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it’s all pain.
What’s the advantages of changing? Change should be about progress.
I thought before that Microsoft cared about people like me. But it doesn’t. And it makes programming on Windows painful. Microsoft is great at backwards compatibility—you can take really old programs and compile and run them on a brand new Windows—but terrible at design and terrible at providing a good experience.
I’ll gladly stick the knife into Microsoft where I see fit. Frontpage is horrible, Vista is a massive disappointment, they play fast and loose with standards. But if there’s one area where they are above the rest, it’s in development tools and environment. I’ve tried Eclipse, and it’s good, but it’s not a patch on VS.NET. I’ve seen XCode, and it’s not even close.
There’s a lot of software for Windows, a lot of business-critical software, that’s not maintained any more. And that software is usually buggy. It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hardcoded locations, all sorts of things that it shouldn’t do.
True. What the hell’s that got to do with Microsoft? I would say the same thing about Mac, but I’ve never heard of anyone doing data processing on Mac (I suppose Apple do).
Microsoft has all sorts of special behaviours it needs to preserve. This means that not only can it not make the API better—it can’t even easily make the API’s implementation better. It’s all too fragile.
Huh? Supporting old API calls means you can’t write new and improved ones? Since when?
There might not be as much third-party software for Mac OS X as there is for Windows (a pleasing operating environment can only do so much to mitigate a 3 percent market share), but the quality of the applications is a great deal better.
Such as? He doesn’t say.
Third-party developers on Mac OS X strive to make applications that work in a way that’s consistent with the OS itself, with first-party applications, and even with each other.
Like Windows? Microsoft long ago published a set of UI guidelines that many developers follow.
Regular updates to the OS keep developers on the upgrade treadmill; they work to make their applications fit in with the latest and greatest release, leveraging whatever new bells and whistles it provides, further improving the software ecosystem.
Like Adobe with Photoshop CS4 64-bit?
The UI guidelines certainly have the right idea. But they then get ignored. They get ignored by Vista itself. They get ignored by Microsoft’s flagship applications like Office. They get ignored by third parties.
Wow. Third parties ignore the UI guidelines. Bad Microsoft. Bad!
Recognizing the gap in functionality here, a third-party developer produced its own ribbon-like object that developers could embed into their programs to gain a ribbon user interface. Microsoft in turn bought the third-party object and is now distributing it to developers using the current version of Visual C++. Oh, yeah—it’s only for C++ developers. No ribbon for .NET developers.
Yeah. There’s only about 5 different ones to download off the net, each with source code.
So where does that leave me? I want to write nice applications. I want to be able to concentrate on my own code rather than fighting the API the whole time. I want my applications to fit in with the OS and work in a way that’s consistent with first-party applications and even other third-party programs. I want this because I think it leads to better software; it means I can spend my time creating innovative and useful software that people enjoy using. I really want to do this, but you know what? On Windows it’s just too damn hard.
Nonsense. .net’s very straightforward, and fast enough. Paint.net is almost entirely C# (except for some graphics filters that are written in C++) .Unless you’re doing something processor intensive, or writing something low level (like drivers) you don’t need anything else on Windows.
Ars is generally better than material like this. I’d be interested in a genuine side-by-side comparison, an article showing what they feel are the advantages of Cocoa over .net from an informed position. Convince people why it’s better by using real facts rather than this rubbish.
Tags: Uncategorized // 7 Comments »
RSS