Slashdot Mirror
How Microsoft Dropped the Ball With Developers
cremou writes "As part of an Ars Technica series on how one developer migrated from Windows to OS X (and why), this second article concentrates on how Microsoft bungled the transition from XP to Vista. The author looks at some unfortunate decisions Microsoft made that have made Windows an unpleasant development platform. '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... And it's not just third parties who suffer. It causes trouble for Microsoft, too. The code isn't just inconsistent and ugly on the outside; it's that way on the inside, too. 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 hard-coded locations, all sorts of things that it shouldn't do.'"
Good God how many re-run articles do we have to endure on Slashdot? This flamebait type of article is every 5 minutes.
Slashdot hates America, Religion and Microsoft. We get it already!
"It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hard-coded locations, all sorts of things that it shouldn't do."
Those are basically programming errors, not problems with the API. Don't get me wrong, I find Win32 to be a pain in the ass sometimes, but this article just reeks of flamebait.
The False God of Backward Compatibility has Microsoft by the short hairs. Even new programming environments like .Net have Win32, Win16, and DOS lurking right around the corner. There's no fresh start anywhere in the Microsoft environment, everything reeks of DOS.
Which would have been find if DOS (Win16, Win32, etc..) were a multi-platform, extensible OS to begin with -- but it wasn't. It was a quick hack that lives on and on.
I'm a developer that works primarily in Windows, with 15 years of heavy-hitting Unix programming experience behind me.
Get off my lawn.
You gotta admit, he has a point and illustrates it pretty well.
"Flyin' in just a sweet place,
Never been known to fail..."
What exactly is this guy recommending? He trumpets Apple for overhauling their platform and releasing a rapid succession of new OSes in order to advance the platform, which retaining absolutely no backwards compatibility. Meanwhile, Microsoft releases new runtimes for it's existing platforms, not requiring the purchase of a new OS, meanwhile retaining nearly full legacy support. How many 10 year old applications can you run on a new Macintosh right now, without relying on third-party emulators? You can count them on no hands. However, you can run the majority of 10, 15 and 20 year old Windows applications on Windows Vista.
.NET is hobbled due to Win32 is just silly. He targets WinForms specifically, which, sure, is a wrapper around Win32. But to claim that you need to know Win32 to program WinForms is just ludicrous. It makes me think that he's never programmed for either platform. WinForms hides the details of Win32 a great deal, and it's very rare to ever have to rely on platform invoke calls. And if WinForms is such a problem, why not use Gtk#? Or WPF? .NET is not one monotonous entity, and there are several UI libraries.
And to claim that
He complains that the Win32 API for finding a file size requires you to deal with two 32-bit values, stating that on Win64 that it should return a 64-bit value instead. Well, if he wasn't such an idiot, he could use the newer version of that same API which does return a 64-bit value, on Win32 and Win64.
All this dumb shit seems to do is claim that the platform should be constantly broken, because that would be the most convenient for him. If you think that the developer experience on Windows is bad then I posit that you've never programmed before, for any platform, ever. Either that or you are a fucking retard who has failed so badly as trying to hack together code that you're only possible saving grace is to write an inflammatory article and try to eek a living out of click ads.
It's actually kind of funny watching retards like this rant. They have no clue what they're talking about yet they are so sure that the problem must be something other than themselves. Fuckwits like this make it much easier for me to find work cleaning up after their garbage, and make a small fortune doing so.
I'm not exactly what you'd call a hardcore developer (I make games, not Applications), nor am I in any way familiar with developing on Mac OS X, but this article definitely seemed pretty inconsistent.
.Net framework. Nothing new there, but it's main complaint is that it's meant to be a shiny, new API, but it's roots are still buried deep within the old API's of Win32.
For those of you who CBA to RTFA, FYI here's a small summary of it:
It starts off saying there's basically 3 kinds of developers, 2 kinds that don't care what the code does as long as it works and 1 kind that cares deeply about "doing it right". It then says that this kind of developer doesn't matter because it's all hobbyists anyway. It says the first 2 kinds just want to get the job done and don't particularly want to or care to learn anything new to do it.
Next, the article has a complete bitchfest about the
Then it bitches a bit about said Win32 API, but it's main point is that you don't learn anything new, it's just the same thing you've been doing "for the last 15 years", as the summary points out.
Then, curiously, it states that this suits the first two kinds of developer just fine and this is where I get a bit confused. It's trying to bitch about the framework, it's trying to point out how it's flawed, but all it's really done is point out that it works just fine for the only developers that (in the article's own words) "matter".
This leads me to the conclusion that the author really was just trying to start a flame war but instead of coming up with a reasonable argument (Of which, on the Windows platform, there are many - just like any other), he sort of just throws in a few keywords, rambles on without re-reading what he's wrote and then finishes it off by bitching about some of the quirks of the platform, quirks that are only there because people REFUSE to do anything different than what they've been doing for the last 15 years.
In other words, he's blaming Microsoft for catering to lazy, underpaid developers.
Does that make them the bad guys? Not if you've got a multi-million $$$ business to run and want to keep costs to a minimum so you can give yourself a big raise at the end of the year.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Are you mad? The compiler itself is free with the platform (.NET Framework in its bin folder has programs called CSC and VBC. Run them sometime). The documentation is free to access. Visual Studio itself can be bought and paid for at anywhere between $500 and $1000 depending on the edition you want.
MSDN is just an added bonus because it gives access to every development oriented Microsoft product in existence, including Operating Systems, Servers, and Office. That sort of stuff for that price ($1000 or so I believe) is pretty good really.
I should probably also add that you can also write Windows apps for free using compilers like GCC and cygwin or similar, and IDEs like Eclipse - if you don't want to use Microsoft tools. It isn't necessary and never has been to use Visual Studio to make Windows apps.
Or to sum up the parent poster... "troll troll troll, troll troll troll troll".
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
nothing comes close to Visual Studio in terms of functionality, quality, and just being solid
Are you using the same Visual Studio I am? Because the one I use may have some decent functionality that you'd expect from an IDE, despite being crippled by a lousy interface (with some exceptions, they do some things very nicely). But when you're used to using Eclipse, Visual Studio feels like a cheap, buggy toy. I use both at my day job. I would never use Visual Studio unless paid to do so. Eclipse I use for fun on my hobby projects.
Yes, there are much worse IDE's than Visual Studio, but that doesn't mean its good.
#!/
Back before my current gig, I was a software developer for companies that hired me to do their work and for several packages I wrote for my own profit. This story comes from the programs I developed for my own profit.
Because the software I wrote was also licensed for source code if the user wanted it, I picked Visual Basic as the platform to use. I wanted to use Visual C, but you could more easly find programmers that could get by in Visual Basic than VC. I should have picked VC rather than VB for a lot of reasons, the main one being that if you had experience in VC, you were at least likely not to be a total idiot. Not so with VB. I found that VB programmers were idiots at the approximate rate of 7:10, while VC programmers were likely to be idiots at an estimated 1:10 ratio... which isn't to say that all VB programmers were idiots, only that they were cheaper labor, and therefore less likely to have a solid background in programming logic.
That said, we'll focus only on my own development problems, just so we are dealing with only one (possible) idiot... me. I started out with VB 2.x. The upgrade to 3.x went fine, with very few problems. When 4.0 came out, I found I had to rewrite about 20% of my code. Sure, there were conversion programs, but they didn't quite fit in with exactly what I wanted the program to do. It'd get it about 90% right, but then I'd have to slog through the rest of the automated code to correct that last 10%. It was faster to discard that code and re-write it.
Then 5.x came out. Only about 50% of my code still worked. And again, the automated process to "ease" transisition left something to be desired. When Visual Studio 6.0 came out, it was a nightmare. only 20% of the code ported. At that point, I sent the 5.x code out to all the people that bought the program (with source or not), and told them that the code was now moribund, I would not be maintaining it, and that I was releaseing the source code to the public domain (5 floppies included). As I recall, that was about 1998-1999 or so.
As late as March 2008, I've been contacted about the code. Of course, it's morphed far past anything I'd written, and I could only help with the general business case logic involved, not the actual code. But having to deal once again with Microsoft development tools, one would have to offer me far, far more money than it would be worth. No, I'm done with Microsoft "development" games. I'm done with school yard bullies trying to take my lunch money. I'm done, PERIOD, with closed source, whenever I have a choice.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
My understanding was that they didn't expect much of the PC market, so they threw together a bunch of cheap parts from other vendors and stamped their name on it. Based on their Apple II CP/M card, they asked MicroSoft for an OS instead of buying or writing one.
Do you even lift?
These aren't the 'roids you're looking for.
Holy shit, you've got to be kidding me! Even VS 2008 needs Resharper to even be close to Eclipse in functionality. Have you ever used a different IDE?
One of the nice things from this article was actually this nice screenshot of a selection of current versions of MS software running on Vista. The thing to notice is that not a single one of those applications has a GUI the same as any of the others. There are different toolkits, completely different look and feel, some have menus, some don't; it's a horrible, horrible mess. And yet despite that, we still get people complaining about GNOME vs. KDE and the clash of different toolkits and how that's what is holding Linux back. You can run GNOME and KDE apps side by side and, while they'll have differences, they'll sit together far more elegantly than the mishmash that is Windows. I think I'll have bookmark that screenshot so I can bring it up the next time a Windows fanboy starts decrying the excessive number of GUI toolkits on Linux.
Craft Beer Programming T-shirts
I'm not big on the M$ love. I'm a mac/linux proponent. However, I think that M$'s current problem with a really horrible API (I'm saying this having programmed for win32, GTK, QT, WX, and Cocoa) isn't an easy to solve problem.
They could pull an Apple, and completely redo their windowing system. Apple benefited from using NeXT's system, which was well thought out, uses a language well suited to windowing systems (objective-c), and could be altered based on previous user experience.
However, in doing so they would lose all compatibility they current have. Keeping compatibility, even if it creates a developer's nightmare, is in the end what keeps them on top of the market.
That is not to say it's not impossible for them to do so. Apple did provide a virtual machine to run old OS9 software with the first releases of OS X. However, since both Mac and Linux machines also have the same options (currently running Parallels on my machine), it would still take the clear advantage M$ has in the market away.
It's not clear whether their bad API spells the eventual doom of the company. The more pragmatic developers will still value making products that more people can use over writing nice looking code. Additionally, wrapper libraries, such as WxWidgets or Qt can help hide much of the ugliness.
So, you problem is that programmers make use of undocumented API calls. While "undocumented" does not always equal "unsupported", using them is just plain stupid. Whether it is Windows, Linux, MS-DOS, DR-DOS, OSux using the system in an undocumented/unsupported way is well, U N S U P P O R T E D. Don't blame the OS or the those that coded it, blame those that wrote against the API in an unsupported way.
RTFA turns out to be a effort in slogging through another of the author's attempts to explain why anyone on Windows is just benighted. He blames HIS short comings on the OS.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
People seem to be missing this particular point. He's not bashing Microsoft for third parties writing poor software. He's bashing them for accepting it, making it easy for them to screw up (or hard not to screw up), and never taking decent steps forward for fear of breaking third party crapware.
Does he have a point though?
I think the giveaway is when he says a screen shot is worth a thousand words, then his screen shot is of vista with the taskbar at the top, Im not saying nobody has the taskbar at the top but its just one of many signs that hes a fan of apple.
Im no programmer but the article seams short on facts & details and high on ms bashing & skimming.
Is the article right or is it just well presented trolling?
IranAir Flight 655 never forget!
Same as when IBM jumped the shark...
When they tried to force a product down the consumers throat that there was no perceived need for, which could be replaced by products that were not IP locked.
For you younguns IBM's was called Microchannel.
They ARE out to get you simply because They are in it for themselves and they don't care about you.
I have my taskbar at the top, because it effectively reverses the order of the start menu. This makes shutdown the bottom option, which is where it should be, as i use it precisely once per session.
Because some classes are static or sealed does not mean the CLR doesn't support full OO features. I known you recognize that but some people reading your post might misinterpret it so I'm clarifying. What it means is some class designers made some arguably bad decisions about how to allow their classes to be used. Sometimes the class designer is Microsoft. But I'm there with you buddy. If only I could count the number of times I've cursed a class designer because they didn't let me instance it. In the cases you mentioned I noticed you didn't talk about System.IO.FileInfo or System.IO.DirectoryInfo classes which are the instanceable counterparts of the static System.IO.File or System.IO.Directory classes you listed. Use the static classes for speed against multiple files and directories but if you want an instance wrapper around a file or directory you can easily do that with those other classes. As for the P/Invokes, well... I don't have a great answer except it's not a perfect world ... yet. .NET is a strong leap towards there.
Actually they could host it within citrix or similiar and rollout to the desktops. They are not locked into windows on the desktop.
"They're too demanding anyway. They're the ones who care about their tools and get upset when an API is badly designed. They're the ones who notice the inconsistencies and omissions and gripe about them."
Or maybe they accept that there is no such thing as the perfect piece of software. Maybe they understand that the software in question a lot of the time is there to support business and sometimes business requirements out weigh technical 'perfection'. I accept it as a fact of life... like taxes blogging about it won't change a thing.
"For example, there's a function called OpenFile. OpenFile was a Win16 function. It opens files, obviously enough. In Win32 it was deprecated--kept in, to allow 16-bit apps to be ported to Win32 more easily, but deprecated all the same."
And as a good developer you won't use it. Maybe a bad developer will but a bad developer will write bad code regardless of how many things you put in place to stop them. A developer should be able to use his discretion as to using this or not, taking into account his particular circumstances. Maybe it should be used for a quick dirty port while version '2.0' is under development. 'Get it in, get it running, minimise the business impact and we'll address these issues next major release' is something that commonly gets thrown around in enterprise by management... you know they guys that are paying for your services.
But if you use the same API in 64-bit Windows, it still gives you the pair of numbers, rather than just a nice simple 64-bit number. While this made some kind of sense on 32-bit Windows, it makes no sense at all on 64-bit Windows, since 64-bit Windows can, by definition, use 64-bit numbers.
This and other points in the article are such small non issues and are just gripes. Would it be nice to get 1x64 number? Yes. Does it make no sense? No. Looking deeper at things like reducing time to port 32bit to 64bit and associated costs in developer time/money it makes sense. I can happily live with it.
In 32-bit Windows, it was called system32. In 64-bit Windows it's called, er, system32 again. Because although there's an API call that programs can make to find out the name of the folder, there are enough programs that don't bother using it and just blindly assume that it's called system32.
Again... you can't stop bad programmers (a lot being 3rd parties) from making dumb mistakes... but you can try and reduce the impact. You can bet there are those purists just like the article author inside MS that hate this as well. But in the interest of having this work a decision was made, and i suspect not for MS's benefit. Again just live with it.
For example, dialog boxes in Windows have traditionally been poorly designed, because their buttons are given generic labels like "Yes" and "No," or "OK" and "Cancel,"
Microsoft have been going on about this for ages since 2001 actually. http://msdn.microsoft.com/en-us/library/ms997506.aspx
If you take the ranting and raving out of the article it has very little of value. If Mac or *nix had greater market share then we would see more bad software and API's in those environments as well. As it is some of the open source code I have seen is terrible. There is no way to prevent these issues economically, good programmers just accept them, code around them and move forward.
Users... the only thing keeping 1st level support from being the bottom feeders.
15 years ago, object oriented programming was still catching on, and the Pentium was brand-new. Computers were slow, people had about as much RAM as modern CPUs have cache. The Windows operating systems of the time were just starting to support 32-bit features. Pre-emptive multitasking was still 2 years away.
When it comes to using the extra power of modern hardware, it is easy to say "I want it to make everything 10 times faster". On the other hand, you could use that power to run a python interpreter, and make things 10 times easier for the programmer. Both are perfectly good uses of the more advanced hardware. But the latter is where you'll see the really innovative apps showing up. That's what Microsoft is missing out on when their platform still doesn't let you ignore the nitty-gritty details that you couldn't afford to ignore 15 years ago.
He has an axe to grind, but I'm not sure he has a point. For example, he talks about how .Net was supposed to insulate you from the vagaries of the Win32 interface,but failed. Then he talks about how the Win32 API returns the length of a file as two 32 values that have to be combined, instead of a 64 bit value. The part he leaves out is that .Net's system.IO.FileInfo does exactly what he wants... it returns the file length as a long 64 bit value. So why bring up the old 32 bit interface when you don't have to deal with it anymore? If that's the best he can do, his argument is in trouble.
Every mans' island needs an ocean; choose your ocean carefully.
"Vista and Office 2007 moving away from word lists (MENUS) is the right direction."
Quite right. The last thing I want in my word processor is words.
I can only say the featured article appears half-baked to me, and it's comical how Apple users always bring up GUI design issues, as if that was the most important thing in the world.
.NET flaws, when in fact the flaws are much bigger, and the short examples only give the impression that he has looked at them briefly at best. No mention of the GetFileSizeEx() function, for instance. The old GetFileSize() API was for NT 4 and Windows 95 and previous OSes (note how the older OSes have already been dropped from the platform compatibility list). GetFileSizeEx() API was new for Windows 2000, which is already over 8 years old.
.NET and Win32 in that article are true. The .NET framework has (or rather, had, because we're talking .NET Framework 3.5 now) some very weak concepts. Also, the documentation team is far behind with the documentation; there's a lot to be left desired in that area. The Win32 API is much better documented still. If you develop your own controls, you might run into problems with .NET, because native timers and carets are not directly supported, for instance (Win32 API calls are required for that).
;-)
I tried Apple's XCode IDE last year, and I was put off by it's total lack of good UI design. XCode's editor cannot be customized, has a hair-line thin text cursor that is barely visible and a weird keyboard layout that originated somewhere in the 80ies (on MacOS and Amiga systems), that is totally uncomfortable to use nowadays. No mention of this in the article.
Also, the article mentions minor aspects of perceived Win32 and
Also, as has already been mentioned here, the article omits WPF, which is a fairly important development by Microsoft. It enables programmers to create 3D applications in XML! I tried it a number of times and it seems pretty good to me.
But the core statements about
I've been developing mostly for Windows in the past 13 years, with the occasional UN*X and OS/2 thrown in, and I still find that all of them lack some of the flexibility and power of an AmigaOS, which I used and programmed on from 1986 to 2001. THAT would be the ideal development platform, because it allows unrestricted programming; sadly, Commodore folded in 1994, and not much good happened since then. GUI and development guidelines were followed by Amiga programmers voluntarily, out of interoperability concerns. All major (and many minor) applications had an ARexx scripting interface, for instance. GUI guidelines were often followed also, because the guideline manual (or chapter, in the older RKMs) was thin and easy to read. BTW, the Tool Info feature of the Workbench is still unmatched today. A user could easily configure their applications to their desires, or even configure the entire user experience to their liking, booting up Commodities (which were similar to Windows Services, except they supported user interfaces) as needed, that even sometimes changed how individual controls behaved. Tools like MagicMenu changed the entire menu system for all applications, and so on. Virtual memory and memory protection could be added by the user, and so on. There's much that needs to be said about the Amiga platform, that made it ideal for developers. For instance, the non-copying message system that was easily used to communicate between threads, making multithreaded applications easy, and that also served as an IPC mechanism.
I can tell you: On all so-called "modern platforms", everything is much, much more complicated than it needs to be. OS implementors only have to look at the things that have already existed, instead of reinventing the triangle-shaped wheel over and over.
FTA:
"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."
As we see from the Windows and Mac OS (pre-X) ecosystems, this is completely false. Developers are loathe to change custom-written code that they know works in order to implement some kind of link to the OS; and in many cases they'll let old versions of their program stop working when a new version comes out and replaces it.
Microsoft knew what they were getting into with Vista's backwards incompatibilities, and oh lordie how people complained. Consumers (and, it seems, developers, who should know better) often blame Microsoft when their new product breaks backwards compatibility, even if it's the program's fault for doing it the wrong way. For the most part, Windows developers are pragmatic, which is why they're working on Windows (the biggest install base), so whatever works is more or less good enough.
I will delight at what happens if Linux ever manages to get majority market share and it starts getting some of the less-skilled pragmatic developers.
This brings up the horrid Carbon/Cocoa Dear Mr. Warthog, (thats you TheNetAvenger) If you don't read anything else I've written read this. One of the main points of this article was to detail how maintaining backwards compatibility can actually hurt a platform and its developers instead of help them.
Apple and Microsoft are antitheses of each other in this regard. Apple has forced developers to move forward, kicking and screaming, over and over again, while maintaining a reasonable degree of backwards compatibility each step of the way, while Microsoft has to remain compatible to a million different quirks.
In the case of Apple, this includes two architecture changes, Moto 48xxx -> PPC -> x86, and a complete overhaul of their original API set, that became carbon, and the platform for the future based on objective C (and java at the beginning, but developers have spoken on that, and nobody sans Azureus wants it) that is cocoa.
I personally find it amazing that on a Intel Mac today you can (1) run programs that were originally coded for Mac System 7 running on Moto 48xxx with a moderate degree of work, and (2) run carbonized programs that were originally coded for OX X PPC on intel through emulation without any recode, and very little performance hit.
With regards to your claims about Adobe, I suggest you put your foot down, and next time do your homework.
Thank you Madonna. LoL Author doesn't realize Microsoft and IBM wrote most of the GUI and UI guidelines that OS X even uses today. I'm not going to argue who came up with the idea first, as it is completely irrelevant. As the author of the article clearly points out, what is important is now the guidelines themselves, but how well a company implements them. The author also clearly demonstrates how Microsoft is decade behind Apple in this regard, but is making an effort with Vista.
These claims are fully supported, you must be a blind ignorant fool not to see this. The author then jumps into UI consistency with dialog wording, and doesn't mention OS Xs lack of keyboard support. Oh you did see his support, you just choose to ignore it, how convenient. You then go on to provide further evidence of your ignorance by stating that OS X has no keyboard support???
Please do enlighten us, what is this device that I am typing on right now called??? OH yeah, a keyboard, DOH!!! Office 2007 is a new direction in GUI paradigms, and is WELL accepted in the business world. Perhaps the business world of borg cubes, but most of us here on planet earth find Office 2007 a product with interesting ideas, but very much so confusing for reasons author clearly demonstrates in his article.
You sir, are a warthog faced buffoon.
What languages do you use with Eclipse? Just Java? Because everything else I've tried with Eclipse totally sucked.
Everything I have read and heard about Microsoft suggests that they are cowboys.
Code first, design later. For example, I note with interest the amount of pain involved in trying to provide server protocol documentation for the EU. Some of the foot dragging is deliberate but some of it is that they don't have quality internal documentation.
There is a severe lack of direction and leadership at Microsoft. They are just not forward planning. As a result they are tearing themselves to pieces, doing the same work again and again.
meh
To make it more amusing those third party APIs slog through the win32 API hell so you don't have to.
I think that's why Microsoft is afraid of breaking the old APIs. Once you have to go through the pain of porting to a new API why not just go cross platform?
The problem is they know a lot of people aren't happy with Windows but it runs all their programs. Once the scrap that backwards compatibility and build something solid, despite the fact it may be their best OS ever, it's on a level playing field with the rest which means people have to find an alternative to their old programs and they might just pick something that isn't Windows and MS isn't having that.
Your link is all the more profound when one realizes that 90% of the posts on this thread are from defensive windows programmers. So, my question is, whence the hostility, man? When mac users/programmers say "Our platform is great!", windows users/programmers don't say "Ours is too!", but rather insist on "No, you suck!". Its always the same story. Just thought I'd point it out. Here is what I say: "Get a friggin' life! If your OS is so great, then there is no reason to say how every one else sucks because they think theirs is too." Or do you have some deeper issues with your OS that we don't know about and this is the source of your hostility? Perhaps if you talk it through you will be happier. Or maybe you could switch to a good OS. Just a suggestion. No need to get defensive about it.
Just callin' it like I see it.
Yeah, I think that Vista really demonstrates the Microsoft of today. They have a number of problems:
1. They aren't attracting the kind of people they once were, and many of the very good people have left. This exacerbates their other problems.
2. They are still trying to develop the same way they used to (cowboy), but are now finding that it does not scale well for the size of projects.
3. There seems to be a lack of long term direction, planning and vision. And by long term I mean as short as 3 years from now. This might be a result of 1.
meh
People who haven't given Visual Studio much of a chance often think Visual Studio is a piece of crap.
You must have had access to the sooper sekrit article with all the illustrations in it. The Ars article I read a blatent Mac fanboy bragging about Cocoa, with an extra two tacked-on pages of hyperbole and baseless accusations about how much .NET sucks, backed up with exactly 1 concrete example: that you have to know which Windows Forms operations are thread-safe (hint: none of them). He even finishes that thought by pointing out that most other GUI frameworks have exactly the same problem. I can probably rattle two dozen cases from memory in the old Win32 API where MS made obviously retarded design choices, but he can't even come up with a single actual .NET class method that he doesn't like when he's writing an article about it?
.NET and I love it. I usually find that the Framework already does anything I'd expect a base class library to do and a bunch more. The code I write against it is way more elegant than what I typically see from, say, your random GTK app. Is that because .NET is inherently better than gtk, glib, glibc, etc? No, I don't sit around whining about how Microsoft "blew it with developers" because they didn't write all my code for me... I spend my time writing good code.
I am in that third group of developers this article was supposedly written for. I absolutely abhor poorly written code, cheap workarounds, etc. And I make a living off
I too have "been there, done that" on a lot of platforms.
The term you are looking for is "enabler" - Microsoft is an Enabler for other applications to engage in bad practices, for users to engage in bad security.
As you say it makes a lot of people happy now, but look what else it has given us - lots of decrepit systems, and hundreds of thousands of zombies that make our lives miserable in other ways.
Sometimes even a business can't just be about making people happy, it has to be about moving the market as a whole to dry land when they see the flood coming.
Just like the Spiderman quote tells us.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
All his support for C could apply to
Certainly, because it's so trivial to call out to C from
I can't speak to the criticisms of the actual API itself. But that would seem to be more a criticism of
Although, glancing over at some of these, like the passing of two ints for the size of a file -- even on 32-bit Windows, that's kind of stupid. 64-bit integers may not have been fast, but they were certainly possible.
Don't thank God, thank a doctor!
it's been well documented that MS went back on their word to build a .Net based OS that started fresh.
And this is different from OS X... how? Apple has no intention of abandoning Carbon, its old, hairy Win32 equivalent. And Cocoa itself is just a slightly cleaned up NeXTStep. So, it's not like Apple has these magical, shiny, new APIs either.
If you can't even read his argument without getting mixed up, then your future is in trouble. (OTOH you have a bright future as a Slashdot poster. Not reading TFA is henceforth passé; reading it and getting it entirely wrong is the new standard.)
.NET. That's a problem with TFA.
.NET against Cocoa, nothing else.
No, he is saying that the argument is confused because it mixes up Win32 and
If you want to compare Windows and OS X as modern platforms, you need to compare the modern APIs, that is,
>> How this is different from a simple function in C is beyond me
It's no different. But do you really need it to be different or you are just a blind OOP fanatic ?
Describe the sin function. Why the hell should it need an instanced class ? Takes a number, spit a number everytime with the same logic. No different than the - operator.
I find the static class choice makes much more sense than instanced objects. OOP is a tool and a solution.. not THE solution everytime.
I don't think Microsoft wanted to be backward compatible, people - users wanted backwards compatibility.
It was same thing with processor architectures amd (x64) vs intel (IA-64). Intel's IA-64 (Iteron) is FAR superior architecture (256 GPR, register rename, register splitting, multiplexed operations, etc...) with no 8, 16 and 32-bit register functions for backwards compatibility. (Usage of emulator or additional 32bit core can be used to overcome this)
While x64 was just extension over IA-32 and current processors (Intel or amd x64) still have 8 and 16bit support functions (add ax, bx).
It happened because of you - users, who wanted to run your current (old) applications on new platform. Everyone loses, because we're using inferior architecture that supports 30year old applications. (yes, x64 is backwards compatible with 8088 processor which is asinine)
Having to drop into Win32 to call some legacy thing that no-one should really be doing but which you have to do for backwards compatibility, that I could sort of understand. But having to drop into Win32 to call new features that have only just been added? Anyone saying "stop using Win32, just use
We had a script kiddy here who made a horrid tangled mess, hard pathing everything, including to a directory called "Not_Used_Anymore". He didn't know better.
The horrors of hard pathing are alive and well.
Hard pathing is just coding in a path into your source like any other constant. Sometimes it makes sense to do it (small personal batch script for instance) and some will always do it where they shouldn't (in something compiled or large).
According to the article there are three types of developers: (I) the ones who bang Excel macros and Access databases together with VB (not very many), (II) in-house developers for large companies who program in whatever language is in demand (the vast majority), and (III) craftsmen-programmers who look for clean orthogonal programming tools and also program in their spare time (a few).
The article goes on to argue that Microsoft catered very well for categories (I) and (II), and not at all for category (III.)
Since I believe that the programmers who make stand-alone third-party applications mostly belong to category (II) I absolutely don't see how or why Microsoft supposedly "dropped the ball" for any developers except category (III). The article points to the messy API's of Win32 and the shadows that projects unto the .NET framework. Ok, fair enough, but who cares?
Not the end-users and not the managers. And they're the ones who determine where the money, and hence the bulk of the development effort goes. That means that what end-users actually see and care about, their _applications_ will continue to be in plentiful supply for MS-Windows.
Sorry, but the author will have to do a lot better to convince me that Microsoft shot itself in the foot as regards development effort. It's not the smartest thing that Microsoft could have done to alienate the craftsmen-programmers but I don't see how that puts a dent in their business.
I've been programming for over 20 years and yes, it's mostly MS bashing.
.NET is pretty cool. The IDE still needs some work, but it's one of the better ones I've worked in. C# is quite cool.
First off, you're obviously an MS basher (MS languages vs good languages? oh you mean C++?) Not sure what word you think MS went back on.
Past that..did you actually just suggest that MS scrap backward compatibility? Are you serious? Yes, the linux zealots would love that - they might actually have a chance at a desktop...because of the user revolt. I mean, you are suggesting that a company PISS OFF a good portion of it's base users. ROFL - so that's what linux needs to be on a level playing field? Weak, man, weak. That's a new approach...let's see...eliminate your base so we have a fair chance at the desktop. Please. Obviously you don't run a business.
One of the main reasons Windows is the way it is, is BECAUSE of the backward compatilibity requirement. If Linux actually HAD some desktop penetration, it too would have to cater to the businesses and people running 15 year old software that they can't seem to get rid of. But, alas, that's not much of a problem, is it?
Personally, I use whatever works - and it's alot easier to make money in the windows world. Say what you want, but if I'm going to write desktop software, I'll pick the desktop with the most users.
Your reply should be modded 'pandering'.
EK
No, he doesn't. Read about how he claims that the form thread synchronization mechanism is broken in .NET and will sometimes lie to you about what thread you're in which will cause your application to crash. This of course is news to us .NET developers who use the form thread synchronization in all of our multi-threaded applications and don't experience the FCL "lying" to us and we don't experience crashes because of false impressions that we're in the form thread. This is the kind of bug report I'd expect from a first year computer science student learning how to do form thread synchronization for the first time. His statements are complete horseshit, and it shows that this retard can't even accomplish the most basic tasks in .NET. Therefore, I ask who the hell is he to write a review of .NET versus Cocoa?
.NET platform to any of the other great platforms out there like Java and Cocoa:
.NET programming.
.NET with real code samples demonstrating them so we can point out his obvious errors and what a tool he is.
I think we could easily make that a litmus test for writing an article comparing the
If you can't figure out how to do basic form thread synchronization to allow worker threads to safely update your form's controls without claiming there's a flaw in the foundation class library, you are not qualified to write an article about
I won't even start on his biased slamming of enterprise systems development. It's clear that his knowledge of software engineering is limited to applications and he should just keep all other software engineering topics out of his mouth.
I'm sure Cocoa is an awesome enough development platform without needing this dumb ass to promote it through FUD and lies. I'd like to see him actually back up his claimed flaws in
Well, there is a good reason why it's not valid: because it makes .NET developers give a damn about HWNDs, message pumps, and the interactions between the two.
Other than that, he points out a bunch of flaws in Win32 and implies that they "leak intoOff the top of my head we have, for example:
Win32isms are abundant.
Further, your arguments that somehow cutting edge enhancements like Vista's new TxNTFS should magically appear inLet's just recap the argument, shall we?
1) Claim: Win32 is clunky and horrible
2) Response: Write in .NET
3) Claim: .NET can't do everything Win32 can do, forcing me to use Win32
4) Response: "your arguments [...] make no sense to me"
Look, if the argument is going to be "Don't use Win32, use .NET" then .NET has to do all the things that Win32 can do. So which is it?
Either I should be using .NET--in which case MS's failure to add new Win32 features to .NET is a problem--or I should be using Win32--in which case "use .NET" is not a suitable response to cited flaws with Win32. You can't have it both ways, so which is it to be?
I really should leave this one alone, but I just can't. This article is so unbelievably biased, it is truly amazing that a site like ars allows a series like these to exist. The person who's written this series has obviously no real programming knowledge on any platform.
.NET lightyears ahead of the competition right now. Writing these little misinformed articles is not going to change that.
Moreover the way he drops in his little falsehoods borders on intent. Each and every paragraph contains one or more blatant falsehoods. Going through all of them would take way to much time.
Apparantly this Peter Bright's tried to build some winforms stuff (and failed) and he's tried to open a file (and failed somehow). These are his two major arguments against the platform.
Let's try to introduce some facts. First of all the winforms library is indeed not multithreaded. This goes for most windowing libraries. Swing is an example that springs to mind but there are many more. Making it totally thread safe would introduce a lot of overhead, making everything much slower than it needs to be. If you need to use additional threads, there are well documented ways to do this. Maybe Pater should try it... Second of all the winforms library is a very very small part of the total api. Just saying there's lot of little other things, without going into any detail is a cheap way of making a bad point. No API is perfect but I would say given the alternatives out there it's easily one of the cleanest and well thought out api's I've used in the last 6 years. Furthermore, it the author could get his head out of his nether regions he might look in to WPF, WCF, C# 3.0 etc etc. All technologies that put
This person comes across as a total beginner. You know the type, probably programmed some stuff in c++ and now thinks he's a guru on everything. In reality he's an armchair programmer, writing knee yerk articles because he coulnd't get his file to open. A lot of programmers (myself included) go through a phase like this, most move on and start seeing the bigger picture. I guess some don't and just write articles about it.
I know the average slashdotter probably won't care about an anti-microsoft hit-piece but if you're confident about using linux or mac-osx (both of which I think are perfect alternatives btw) ask yourself, why would you need lies and falsehood's to attack the 'competition'.
Hurrah!
Make it buggy and as difficult as possible. That just gives me more work. I can always find a way to make my code work. Even if I have to write some assembly, or a port redirector. Call me a hacker - I don't care, that's a badge of honor.
If it were easy, anybody could do it. Keep it up Microsoft! You will keep me working and making a good wage for years to come. I like doing crossword puzzles too, and making things work on various Windows/Browsers/whatevers is just another puzzle people actually pay me to solve. It is all very cool. Just depends how you look at it.
- I live the greatest adventure anyone could possibly desire. - Tosk the Hunted
I'm curious as to why you're using any Win32 calls at all. I've been developing in C# for about three years now, and I can't ever remember making a single Win32 call. And I've been developing some fairly robust applications... i.e. multithreaded, networked, double buffered graphics, disk io access, numerical optmization algorithms, etc. The closest I ever came was when I was trying to figure out the size of the desktop, but eventually I figured out how to do that inside of .Net also. Everything else has been somewhere inside of .Net. Granted, sometimes it's been difficult to track down where in the API to find a particular function; sometimes I've had to write some wrappers and funky helper methods; but, I've never had to resort to a Win32 call. At the same time, I've *decided* not to make any Win32 calls, for portability purposes (as I want my apps to eventually be Microsoft free and be able to run on Mono). So, whenever I run across a place where I *could* use a Win32 call, I sigh, and then start looking for another way to achieve the same task within the .Net framework. Takes longer, requires more research, but keeps the application all within my own namespace and maintains portability and independence from a single vendor.
I mean this is just my two cents, but it sounds to me like you haven't made a design decision to NOT use Win32 calls; and thereby, when you run into a situation where you *could* make one, it's a valid option, and you use it.
(On the other hand, you design goals could be more in keeping with systems programming than applications programing; in which case, I would say... well, what did you expect?)