From Win32 to Cocoa | The Coffeehouse

Ray6

Peter Bright is writing a few pages on why he decided to leave Win32 programming and head for the heavenly pastures of Cocoa development

What Microsoft could learn from Apple

More stuff that Microsoft could learn from Apple

He makes a lot of good points (and I say that as someone who isn't that impressed with Cocoa), but I think he's a little unfair in his description of people who develop Windows software.

stevo_
Human after all

Personally I don't write any desktop applications, my work is on servers and more recently silverlight as a smart client..

It makes sense to me that windows desktop dev isn't very unified.. of course its not, to unify would mean windows becomes really strict.. why remove features that a lot of people use? granted they should be pushed along and prompted by better tools..

OS X has that unique thing of apple being dictators to what they want people to do, but I don't think people will jump ship from windows just because applications on OS X look better..

Microsoft did WPF and xaml, developers cannot complain that they don't have the tools to compete really..

DigitalDud

The arguments really suck, this guy is obviously not much of a Windows developer.

Its really silly how he tries to bash the .NET class library (which is one of the nicest parts of .NET imo). The ONLY rationale he can come up with is WinForms is an obvious wrapper over Win32 and requires any UI updates be done in a single thread. Who cares? I'd love to hear one GUI framework that doesn't require updates from a single thread.

So for this one reason, .NET is clearly not an adequate replacement for the Win32 API. Then he bashes Win32 for being a stable platform with a long history and backwards compatibility.

Here's my take: This guy has casual experience with Windows developmment, messed around trying to write some programs, had some bad experiences with the documentation, and now goes and creates sweeping generalizations on how Windows development sucks, blaming his own inadequacies (a lack of knowledge on GUI coding) on the platform.

Ray6

stevo_ wrote:
Microsoft did WPF and xaml, developers cannot complain that they don't have the tools to compete really..

Very true, but I think that this is one of the lessons that Microsoft could learn here. I don't see that many applications that are based on their new tech.

Having said that, the OSX finder isn't written in Cocoa either....

Maddus Mattus
Do, or do not. There is no try. - Yoda

The stuff he wrote about .Net is unfounded and untrue. Pure blasphemy!

In my opinion this is just a Apple fanboy looking for some diggs.

ZippyV
Fired Up

Ray6 wrote:
What Microsoft could learn from Apple

More stuff that Microsoft could learn from Apple

What's there to learn about for Microsoft? The articles are just bashing Microsoft but doesn't tell much about Apple's api.

ManipUni
Proving QQ for 5 years!

As unfounded as a lot of his "Windows is dying" or "Windows Applications all suck" might be I do think he has a somewhat valid point.

The .Net Framework is actually a really well designed API and rather a pleasure to develop for - unlike Win32 which is a total nightmare.

Win32 is one of these things that's so old and so huge that sooner or later people will start to forget how to use large chunks of it or why they exist to begin with.

A lot of the Win32's little quirks are only known by really old engineers that have been fiddling with it for the last twenty or so years.

Often you'll run across one of these quirks and research back why it exists and come along something fun like "because back in Win16 on Windows 3.0 X Y Z" which is just damn scary.

I'd love to see Win32 and MFC killed. Put something designed for purpose in their place and set us up for the next twenty or so years.
PS - In theory* .Net Applications should work just fine if Win32 got ripped out and replaced.

*although that entirely depends on the application Smiley

sushovande
Smiley Face Sharp

DigitalDud wrote:

<sensible stuff>

Hear hear..

Frank Hileman
VG.net

In the mid 80s I walked into an office of a VAX/VMS developer. One wall was filled with documentation for the OS. I was happy to be using unix, which, at the time, was small and needed much less documentation.

I felt the same way about .net when it first appeared. Finally, to work on windows without all the hungarian, win32 complexity and fragility of low level C/C++.

Now the .net framework looks like that wall of VMS documentation. It has swollen enormously, not always with useful things (WPF looks useless for small devices).

I would like to see the .net framework reduced to just its core again, GC, basic system Types only, with all the "framework of the week" (WPF, WCF, etc) monster libraries downloaded on demand and dynamically linked.

I would also like to see more emphasis on old fashioned conservation of memory and CPU, especially in public object model designs, where these problems are impossible to fix after the fact.

Smaller libraries do not have to be less powerful. Just smarter. Smaller libraries are less likely to become obsolete. If they do become obsolete, it is less painful to ditch them, as the learning investment is smaller.

This would give windows developers a better fighting chance on low end machines, where the .net framework 3.5 is too heavy and hardware dependent.

ManipUni
Proving QQ for 5 years!

I don't understand his .Net rant (second link) at all.

I was waiting for him to actually reach some kind of point about the framework but all he really pokes at his some odd "three kinds or programmers" junk.

He made some vague reference to the fact that .Net is a single threaded UI but unless I'm mistaken that is the case for virtual all simple desktop applications.

He makes little attempt to explain what .Net stops the "C++ type" of developer from doing or in what way it is too simple for them.

Oh and his whole "Java is better" remarks are frankly rather laughable and nonsense.

I've found nothing Java can do that .Net can't... Although I have found a LOT .Net can do that Java can't. Plus Java is really bad for developing UIs.

PaoloM
Hypermediocrity

Guys, Peter probably forgot about Windows development more than you learn in a lifetime Smiley

I know him personally and, while a little "trigger happy", his technical skills and knowledge are absolutely top notch. If he has something to say, we'd better listen.

That said, characterizing an operating system and a programming framework by the age of available software is a a bit unfair. Yes, there are plenty of LOB apps that are ugly and barely maintained but they also bring in stupid amount of money to the companies that use them. Not everyone wants to redo their icons in 256x256 32bit and not everyone should either; if a piece of code does what you need, just leave it alone and keep raking in the money.

On the other hand, the paucity of choice in the OSX arena is barely mentioned Smiley

Most of his points are very valid and we should work towards giving each of our three main audiences (enterprise customers, developers, consumers) the best possible tools and environments we can. We're working on that Smiley

Maddus Mattus
Do, or do not. There is no try. - Yoda

Paolo,

Can you tell him that when he writes an article titled: 'What Y can learn from X', he is supposed to write and article that focusses on the points where X excels and how Y can learn from that.

This drivel reads as a rant, instead of providing constructive feedback. He highly annoys me when I read this article, and I dont think that can be his goal.

If he is top notch in Windows Win32 programming, maybe he should stick to that.

ManipUni
Proving QQ for 5 years!

PaoloM wrote:
If he has something to say, we'd better listen.

But he doesn't say anything... It just goes from one sound-bite to another without making any actual valid points using examples.

I might happen to agree with him about Win32 but as far as his .Net rant goes he doesn't really base it on anything. In fact it sounds almost like someone saying "I'm too l33t for that framework."

PaoloM wrote:
Guys, Peter probably forgot about Windows development more than you learn in a lifetime

Age and wisdom aren't the same thing. Age and insight absolutely aren't the same thing.

In fact in my experience age has a negative correlation to insight with a lot of you "old guys" being unable to really get in step with today.

brian.shapiro
things go on as always

I want to repeat my thoughts, that even if there are legitimate reasons why Microsoft doesn't want to use WPF themselves, I don't think it will really take off until Microsoft does use it in the shell and it sets a standard for all other developers.

typemismatch

Frank Hileman wrote:

I would like to see the .net framework reduced to just its core again, GC, basic system Types only, with all the "framework of the week" (WPF, WCF, etc) monster libraries downloaded on demand and dynamically linked.

Yes! Please! no more bloat Expressionless

PaoloM
Hypermediocrity

brian.shapiro wrote:
I want to repeat my thoughts, that even if there are legitimate reasons why Microsoft doesn't want to use WPF themselves, I don't think it will really take off until Microsoft does use it in the shell and it sets a standard for all other developers.

One thing is system programming, another thing is application development. WPF is very good at the second one, not so much (for now) at the first one.

PaoloM
Hypermediocrity

typemismatch wrote:

Frank Hileman wrote:
I would like to see the .net framework reduced to just its core again, GC, basic system Types only, with all the "framework of the week" (WPF, WCF, etc) monster libraries downloaded on demand and dynamically linked.

Yes! Please! no more bloat

No

As an application developer, I want to deploy one runtime and be done with that. No additional pieces, no optional components.

If the framework is installed, everything is there.

stevo_
Human after all

Not to mention that .NET is already broken up into various different assemblies anyway.. its not bloated because the picture you have of it in your head is complicated..

I do however think that naturally .NET has a bit of granular 'bloat', but stuff thats somewhat unavoidable.. like lots of pre-generics collections, or areas that could do with a 'if we knew what we know, and have now' scenarios..

As well as adding to .NET, I'd love it to be just as easy to see whats being removed from .NET, but I think this exists already (I'm sure I remember big lists of classes and such that have changed or gone from version to version)..

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

PaoloM wrote:

No

As an application developer, I want to deploy one runtime and be done with that. No additional pieces, no optional components.

If the framework is installed, everything is there.

.NET 3.5 is already 200mb (with each version getting bigger) and it makes internet distribution really painful because a common 640kb dsl will need at least 40 minutes to download the framework and that time has to be added to the install time that on low end PCs could easily reach half an hour.

if you could ship your applications with the bare minimum .net libraries and the rest of the .NET framework could be downloaded on-demand when needed and the rest while the PC is idling then distribution would be far easier. nothing would have to be left optional, all of the framework would be downloaded sooner or later with application-required libraries getting the priority so the application could be used immediately.

you already have to declare all the namespaces (and implicitely their libraries) you're going to use in your .NET application so I don't think there would be any issues to know the required libraries the framework would have to download before loading the application modules.

brian.shapiro
things go on as always

YearOfTheLinuxDesktop wrote:

PaoloM wrote:
No

As an application developer, I want to deploy one runtime and be done with that. No additional pieces, no optional components.

If the framework is installed, everything is there.

.NET 3.5 is already 200mb (with each version getting bigger) and it makes internet distribution really painful because a common 640kb dsl will need at least 40 minutes to download the framework and that time has to be added to the install time that on low end PCs could easily reach half an hour.

if you could ship your applications with the bare minimum .net libraries and the rest of the .NET framework could be downloaded on-demand when needed and the rest while the PC is idling then distribution would be far easier. nothing would have to be left optional, all of the framework would be downloaded sooner or later with application-required libraries getting the priority so the application could be used immediately.

you already have to declare all the namespaces (and implicitely their libraries) you're going to use in your .NET application so I don't think there would be any issues to know the required libraries the framework would have to download before loading the application modules.

that is sort of moot when .NET becomes part of the Windows API, is included with windows, and updated via system udpates

Dexter

Frank Hileman wrote:

I would like to see the .net framework reduced to just its core again, GC, basic system Types only, with all the "framework of the week" (WPF, WCF, etc) monster libraries downloaded on demand and dynamically linked.

Sorry but last time I checked WPF and WCF where separate assemblies and not a part of mscorlib.dll or System.dll. And that means dynamically linked.

YearOfTheLinuxDesktop wrote:

.NET 3.5 is already 200mb

Not 100% correct. The real download size when you install it from Internet is somewhere around 40-60 mb. That 200 mb thingie is a package that contains .NET versions for both x86 and x64 and I think the Vista version too (Vista needs different packages). Not to say that there isn't an issue here but it appears that they intend to provide a better setup this summer:

http://weblogs.asp.net/scottgu/archive/2008/02/19/net-3-5-client-product-roadmap.aspx

YearOfTheLinuxDesktop
Seven of Niner! Resistance is Futile!

brian.shapiro wrote:

that is sort of moot when .NET becomes part of the Windows API, is included with windows, and updated via system udpates

just like programming will be in a hundred years when AI will start programming itself.

seriously we're still a dozen years away before an hypothetical windows with .NET updated through WU would entirely replace XP and vista market. until then programmers will have to force users to waste hours downloading a framework that is getting bigger with each major release. I remember that a few years ago when dialup connections were still widespread that many programmers who were distributing their applications through internet preferred C++ to VB because of its "large" runtime libraries that would have disadvantaged their applications against smaller c++/delphi ones and it looks like nothing has changed.

Ion Todirel
buuu

YearOfTheLinuxDesktop wrote:
you already have to declare all the namespaces (and implicitely their libraries) you're going to use in your .NET application so I don't think there would be any issues to know the required libraries the framework would have to download before loading the application modules.

there is a simplier way, assembly manifest

figuerres
???

YearOfTheLinuxDesktop wrote:

brian.shapiro wrote:
that is sort of moot when .NET becomes part of the Windows API, is included with windows, and updated via system udpates

just like programming will be in a hundred years when AI will start programming itself.

seriously we're still a dozen years away before an hypothetical windows with .NET updated through WU would entirely replace XP and vista market. until then programmers will have to force users to waste hours downloading a framework that is getting bigger with each major release. I remember that a few years ago when dialup connections were still widespread that many programmers who were distributing their applications through internet preferred C++ to VB because of its "large" runtime libraries that would have disadvantaged their applications against smaller c++/delphi ones and it looks like nothing has changed.

or the developer can send the user an install disk with all the required bits...

*if* the dev offers the app as a download and the user want's to download the app then how is that MSFT's error?

Now if I were offering an app for sale I would offer a download or a disk.

I would take some time to package each method (download,disk) so that the user would not have any nasty surprises.

this might even include looking at the user-agent browser string to see if they have .net installed, asking them what download speed they have and trying to make sure they get what they paid for.

same thing used to happen with VB 4,5,6 where you had to give the user the vbruntime dll.

not to say that a better install of .net would be a bad idea....

just that it's not "the end of life as we know it".

Shining Arcanine

DigitalDud wrote:
Its really silly how he tries to bash the .NET class library (which is one of the nicest parts of .NET imo). The ONLY rationale he can come up with is WinForms is an obvious wrapper over Win32 and requires any UI updates be done in a single thread. Who cares? I'd love to hear one GUI framework that doesn't require updates from a single thread.

I did not read the guy's argument, but I have never been able to understand why the .NET libraries must be used from within .NET. Why is it not possible to simply use them in C++ much like you would use the standard template libraries or any other libraries written in native code?

It really makes no sense to me why Microsoft would make .NET's libraries so restrictive in how you can use them (i.e. they must be used by managed code, native code need not apply), especially with Steve Ballmer's "Developers, Developers, Developers" mantra.

Then again, I never could really understand proprietary languages. Java is another fine example of a proprietary language that I do not understand. Why Java must be compiled for the JVM and not a real processor, or more accurately, why is it so strongly discouraged that Java programs run on anything other than the JVM? Also, why is the JVM so biased towards Java and that better languages, like C++, need not apply? I suppose the same could be said for .NET's intermediate language.

I really do not understand this trend of proprietary languages bundling together a few different concepts that deviate dramatically from well established practices and try to force them collectively on people. The idea of a virtual processor that makes any program compile for it run on any system is great, but why ensure that only one language works on it? The idea of having many useful libraries bundled with each other is great, by why force managed code on people? The idea of managed code is great, but why force a dependency on one huge conglomeration on people? These things are very good when taken alone, but when taken together, some of the benefits that they have individually become disadvantages.

Perhaps, I am misunderstanding something, but as far as I can tell, that is how things are and they make no sense to me.