Slashdot Mirror
Miguel de Icaza Debates Avalon with an Avalon Designer
Karma Sucks writes "In an interesting debate with a Microsoft employee, Miguel points out some crucial flaws in Microsoft's Avalon strategy. Perhaps the most shocking revelation is the absolutely horrendous inheritence hierarchy exposed by the Avalon API. Miguel himself is clearly not amused, saying 'We do not want to waste our time with dead-end APIs as we are vastly under-resourced, so we must choose carefully.'"
That's not so weird. Everyone oohs and aahs when there's a slashdot article about OSS 3D desktops, myself included.
.
I think desktop apps flipping around in 3D and all the new ways you could work with apps would be cool.
But DirectX isn't right for the task, it's too low level. Too much DX code only works on ATi or nVidia, too many vendor specific extensions and shitty drivers. It's great for tweaking the crap out of Doom 3 so it goes as fast as it can, but it would suck if some pixel shader operation that only works on Geforces blowed up my coding session
Avalon is higher level, not trying to implement the latest hardware tweaks and gizmos, just base functionality you can count on across the board.
There's no redundancy, the way I see it. Two different tools for two different tasks.
I don't need no instructions to know how to rock!!!!
Chris Anderson replied with the following in regard to ignoring standards.
Interestingly enough, we never "ignored" standards. We spent a huge amount of time understanding and evaluating the existing standards. SVG and CSS both were passed on because they weren't adaquate to meet our needs. WinFX is a platform for the next decade or longer - we can't start with a base that doesn't meet our needs.
What a load of shit. That mentality is where the "embrace and extend" came from. It might not meet Microsoft's needs, but CSS and SVG are the bloody standards that people are using! What do they know about the coming decade that we don't?
What Chris said pretty much flies in the face of the entire paragraph that Miguel wrote! Look:
I understand why someone would invent their own version of SVG or their own version of CSS: those standards can be difficult to implement, and growing your own version is a lot simpler than having to adapt an existing model to a new model.
I would have probably done the same if I had been in their position: its easy. But I would think that Microsoft has a higher responsibility towards the developer base that must create tools that interop with third party components: creating a new standard for graphics just because its `easy' is not really a good answer.
Implementing SVG might have problems and limitations, but the advantages outweight these problems: there are plenty of tools today to produce and consume it and it fits better with the rest of the industry. A benefit that Avalon users will not have and will just partition the industry again for a fairly poor reason.
Standards are there for a reason. If Microsoft doesn't like them they can see figure 1. I have a feeling that Microsoft may not dislike the standards themselves, they just don't like the fact that they're not their standards.
-kidlinux.
More-so, the "most difficult" layout manager is actually the simpler. GridBag. Even if I assign the constraints and add widgets in haphazard order, so long as i set the x and y right, they go in the right place. It is almost like html in how it works, except html requires ordering of the statements.
So please, tell me.. why is swing difficult? It's overwhelming because people don't do graphical stuff from the getgo, just like tk and what not. The difference is, swing just makes sense. Now it's not to say others DON'T make sense. perl/tk makes a lot of sense too, but the oop in perl is weak, so it's easier to make tpyos and screw things up once in a blue moon... especially sans strict.
-
ping -f 255.255.255.255 # if only
Excuse me, but a monolithic kernel is nothing remotely similar to Microsoft's abomination. Linux and other UNIX systems are modular operating systems that are built in layers. You have the raw kernel, you have some userspace daemons that are close to the kernel, then come the userspace programs (which are completely separate). If you find a hole in Mozilla, that won't let you hijack the system.
On windows, many of the key userland APIs are directly tied into the lowest levels of the operating system. This is great for Microsoft, who can just tell the FTC that "no, we can't remove Internet Explorer/Media Player/Instant Messenger from Windows". This isn't so great for its users, since a hole in one of those applications often yields control of the system in unpredictable ways.
The microkernel versus monolithic kernel is a pretty old debate. The main problem with microkernels, as far as I understand, is that they are much more difficult to develop. Yes, the complexity is encapsulated, but the message passing stuff can get very hairy. My opinion: if both approaches work well, who cares?
As in FSF Gnu Hurd?
In the limit of taking your sweet time getting the architecture right, you risk something else coming along and getting enough of it right to scratch the feature itch before you do; from that point your market irrelevance is proportional to the difference in delivery dates.
No one is in a hurry to get on the wrong track, but assuming your competitors aren't totally stupid there is an equally unpleasant consequence for being the last one out of the station.
The average programmer doesn't care the the hierarchy is 10 or 11 levels deep (well at least until the next avalon release comes out). But Microsoft should care, and Ximian also cares. Very deep inheritance hierarchies are tough to maintain. Inheritance is a pretty intimate binding of two classes and changes higher up in the hierarchy sometimes have disasterous changes down the line. From a talk that I heard Stroustrup give, he doesn't care for them much either. (I didn't attend this one, but I imagine it is the same based on the slides.)
In this day and age, the commonly accepted wisdom is that you break functionality into interfaces and you write shallow helper classes to degalate to for common implementations of those interfaces. (C# is quite possibly the best language there is for supporting this architecture.) This way you don't force the user to use implementations they don't want when they want to program to a particular interface in your system.
If you look at the code for eclipse, you'll see a good example of this design in action.
Facts are meaningless. You could use facts to prove anything that's even remotely true! -Homer Simpson
"It's only the company as a whole that's done anything truly wrong."
Huh? How did the company do the wrong things without the humans that work for the company?
Everybody who works for MS has to shoulder the blame/credit for everything MS does. They all help whether directly or indirectly. You don't get a pass just because you are nice guy, your salary is what it is because your company is an asshole and the people who run your company are immoral bastards.
evil is as evil does
I have to take exception to that. The GUI subsystem most certainly is integrated into the kernel - not only does it run in kernel mode but its location there basically makes objects like menus, windows, images ... even metafiles (!) kernel level objects which can be created in one process and then passed to another and used there. Applications rely on this ability.
Don't forget crap like the registry running in kernel mode as well.
I mean, how on earth do you define integrated into the kernel if not by applications expecting it to be there?