Linked by Thom Holwerda on Mon 5th May 2008 12:53 UTC, submitted by Adam S
General Development A few weeks ago, Ars published part one in a series called "From Win32 to Cocoa: a Windows user's conversion to Mac OS X". In this series, Peter Bright details why he believes "Windows is dying, Windows applications suck, and Microsoft is too blinkered to fix any of it". Part one dealt with the history of both Windows and the Mac OS, and part two deals with .Net, the different types of programmers, and Windows Vista.
Order by: Score:
Nice read but KDE is better
by mohasr on Mon 5th May 2008 14:02 UTC
mohasr
Member since:
2006-07-14

the author indeed has some valid points , I can't argue with him , but if he's really looking for UI consistency and code reusability I'd advise him to look at KDE(4) , the level of code sharing and reusability is astonishing , and the look is consistence across all kde apps - except a few of course-.

Reply Score: 2

RE: Nice read but KDE is better
by sorpigal on Mon 5th May 2008 16:31 UTC in reply to "Nice read but KDE is better"
sorpigal Member since:
2005-11-02

The OP is correct. QT, and by extension KDE, has a very nice, clean API. I can't compare it to MacOS X as I am not familiar with theirs, but let me say this: If you're programming on Windows and don't want to deal with the platform nonsense, you can escape a lot of it by using QT. You gain some portability in the bargain.

But probably the article's author would not find QT a useful answer. His complaints mention win32 often, but he's not so much complaining about the strange/horrid GUI APIs as he is about the platform as a whole (e.g. file locations).

Reply Score: 3

RE[2]: Nice read but KDE is better
by tdemj on Mon 5th May 2008 20:26 UTC in reply to "RE: Nice read but KDE is better"
tdemj Member since:
2006-01-03

At one moment I seriously considered moving to Qt, I've even read the C++ GUI Programming with Qt book. There's one thing that stopped me in the end: the lack of 3rd party components. I couldn't find any.

It doesn't matter if you prefer .NET, Delphi or MFC, there are a dozen high quality visual component vendors out there, and 100s of freeware ones. For example, a fancy tree view, a collapsible panel, report builders, shell controls that look like Windows Explorer, charting, image viewer, just to mention a few.

I was unable to find anything for Qt.

I still think Qt is fantastic if your GUI is simple and basic, and when portability is important. But if you want to get the most out of a platform, nothing can beat a native front end + portable back-end combination.

Reply Score: 1

FishB8 Member since:
2006-01-16

Uh... Hello. You have this big ass giant "3rd party high quality visual component vendor" called KDE4 offering all kinds of fancy visual components to add on to QT4. For free. (KDE is more than just a desktop manager)

Reply Score: 1

TemporalBeing Member since:
2007-08-22

Uh... Hello. You have this big ass giant "3rd party high quality visual component vendor" called KDE4 offering all kinds of fancy visual components to add on to QT4. For free. (KDE is more than just a desktop manager)


Except companies have an issue when they're not willing to open source the product - it makes using KDE prohibitive. So, no that is not a very good answer.

However, it also makes for a good case for a company to come along and provide such for Qt. But, just to note - Qt makes it far easier to create such a platform compared to say Win32/MFC/etc.

Reply Score: 2

Morty Member since:
2005-07-06

Except companies have an issue when they're not willing to open source the product - it makes using KDE prohibitive. So, no that is not a very good answer.


It's actually a very good answer, since the add-on functionality you usually want to use from KDE resides in the libraries. And KDE libraries has always been LGPL or BDS licensed, making it unnecessary to open source applications using it. Making KDE a very good alternative.

However there already are several high quality extentions for Qt. They even used to be listed and linked from the Trolltech site, but it seem they have updated their website since last time I looked and I'm unable to find the page now.

Anyway one of the extentions, that has existed nearly forever(since the days of Qt 1) are Qwt.
http://qwt.sourceforge.net/index.html

From that page there are links to a few more:
http://qwtpolar.sourceforge.net/
http://qwtplot3d.sourceforge.net/

And you can look at the qt-apps site, there is a growing collection there:
http://www.qt-apps.org/index.php?xsortmode=new&xcontentmode=4298&pa...

Edited 2008-05-06 20:02 UTC

Reply Score: 2

C
by WorknMan on Mon 5th May 2008 14:11 UTC
WorknMan
Member since:
2005-11-13

Well, I can see why the guy doesn't like .NET if he likes coding in C/C++. Personally, I'd rather 69 with a grizzly bear while having king kong shoved up my ass than use either of those two languages.

Reply Score: 2

RE: C
by christianhgross on Thu 8th May 2008 11:18 UTC in reply to "C"
christianhgross Member since:
2005-11-15

LOL.... I completely agree with you. What I find extremely frustrating with OSX is that it is stuck in ObjectiveC and C++. I mean how 70's is that.

I started writing using the Commodore 64 so I have been around the bend a bit. Suffered through the memory model fiasco. BUT .NET is amazing. Actually even Java has it right that way. C++ and C is useful for low level system coding. As a general programming language forget.

I read the article and I thought what a piece of garbage. All fluff no stuff...

Reply Score: 1

Link to the article?
by Alex Forster on Mon 5th May 2008 14:22 UTC
Alex Forster
Member since:
2005-08-12

I can't believe I have to ask, but could you please actually link to the article? I'm on EDGE and it required like 3 extra 45+ second pageloads to find it myself.

Reply Score: 2

RE: Link to the article?
by Thom_Holwerda on Mon 5th May 2008 14:24 UTC in reply to "Link to the article?"
Thom_Holwerda Member since:
2005-06-29

The link is right there in the item. First paragraph, even.

Reply Score: 2

RE[2]: Link to the article?
by jonas on Mon 5th May 2008 14:51 UTC in reply to "RE: Link to the article?"
jonas Member since:
2005-07-08

The link in the first paragraph is to part 1, which is only mentioned as a leader. Part 2 is the main focus of the article here and is inexplicably linked in paragraph two even though there was every opportunity to link in paragraph one ("part two").

The exact same thing was done in:

http://osnews.com/story/19712/Microsoft_Withdraws_Proposal_to_Acqui...
http://osnews.com/story/19710/Interview:_Jonathan_Schwartz_CEO_of_S...
http://osnews.com/story/19708/Slackware_12.1_Released
http://osnews.com/story/19706/Planet_GNOMEs_Lack_of_Love
http://osnews.com/story/19707/Bringing_Down_the_Language_Barrier_-_...
http://osnews.com/story/19705/McBride:_Linux_Is_a_Copy_of_UNIX
...

Some of these do not even feature any links on the main page. It certainly seems systematic; link past coverage or past events to give context to the actual news item, but bury the link to the news item and any blurbs about that in the following paragraphs so users have to 'read more' to see what's being commented on.

Reply Score: 6

RE[3]: Link to the article?
by Thom_Holwerda on Mon 5th May 2008 15:31 UTC in reply to "RE[2]: Link to the article?"
Thom_Holwerda Member since:
2005-06-29

Some of these do not even feature any links on the main page. It certainly seems systematic; link past coverage or past events to give context to the actual news item, but bury the link to the news item and any blurbs about that in the following paragraphs so users have to 'read more' to see what's being commented on.


Yup. I do this to prevent people from not reading the "read more". The "read more" on articles that we have been doing the past few weeks is a new element on OSNews, and I need to coerce people into seeing them, so they know it's there. It also prevent people from not seeing the whole picture; the new frontpage items on OSNews are far more general and less information-dense than they used to be - with information meaning information from the actual news article at hand. In other words, they are less meaningful, so you actually NEED the read more to gain a better understanding. The new style teasers generally contain nothing but a little history or background information on the topic at hand, but relatively little from the actual newsworthy article.

OSNews had turned into a glorified RSS feed with three lines teasers all over the place, no background information, no nothing, and an endless list of pointless test releases of Linux distributions, and meaningless items like "here's a review of GreatBSD 2.3.6.1.1.1a. Go read it." I've changed that. It's certainly not perfect yet, but give us time.

This is the new style for OSNews, which allows us to do more thorough items, with more information, and maybe an opinion or two. We've heard nothing but good responses, so everyone better get used to it ;) .

Edited 2008-05-05 15:36 UTC

Reply Score: 10

RE[4]: Link to the article?
by Alex Forster on Mon 5th May 2008 15:57 UTC in reply to "RE[3]: Link to the article?"
Alex Forster Member since:
2005-08-12

So OSNews is the Thom Tech Blog now? Seriously, how now is it different from a blog? I like link aggrregation, and I'm sure I'm not alone. To be frank, I really don't care about your take on the subjects. I'll form my own, thank you. I come for links. I also don't care that you offer your take,but it's very presumptuious to so openly try to force it on us.

Edited 2008-05-05 16:09 UTC

Reply Score: 13

RE[5]: Link to the article?
by TechniCookie on Mon 5th May 2008 17:46 UTC in reply to "RE[4]: Link to the article?"
TechniCookie Member since:
2005-11-09

I looked at a few of the recent post and discovered to my surprise that the My Take was nowhere to be found. I am glad that you listen to the criticism of your users and the new style of OSNews is in my opinion improved in many ways. Thanks! I have been against the My Take concept since it was introduced. It is unprofessional and irrelevant in that context. I have been reluctant to criticize it openly as OSNews is driven by volunteers and I don't want to demotivate an effort which I appreciate. But of course the editors take is still justified and absolutely relevant in the forums. Any way, keep up the good work!

Edited 2008-05-05 18:05 UTC

Reply Score: 4

RE[6]: Link to the article?
by Adam S on Mon 5th May 2008 18:09 UTC in reply to "RE[5]: Link to the article?"
Adam S Member since:
2005-04-01

I have been against the My Take concept since it was introduced. It is unprofessional and irrelevant in that context.


I think you're overreacting a little. We're going to make sure the main links are in the teaser going forward; we listened to feedback and made the approporate changes.

That said, there's nothing unprofessional about having a "My Take" section. First off, you don't have to read it. Secondly, the basis of this site is good discussion. All editorials are opinions, and I don't think it's over the line to start that discussion with legitimate, sincere reaction. Thirdly, most people like having a little more insight into many of the stories (or backstories). If they bother you, kindly opt out of the "Read More" section. If not, you get some extra stuff to read. Everybody wins.

Reply Score: 0

RE[4]: Link to the article?
by sorpigal on Mon 5th May 2008 16:26 UTC in reply to "RE[3]: Link to the article?"
sorpigal Member since:
2005-11-02


Yup. I do this to prevent people from not reading the "read more". The "read more" on articles that we have been doing the past few weeks is a new element on OSNews, and I need to coerce people into seeing them, so they know it's there.


And you don't see anything wrong with that? I rely on osnews to let me know when something related to my interests is happening. When it does I expect a link to the actual information. The "extra details" you provider are either a subset of the linked article, and thus not useful to me because I will be reading the article anyway, or are comments that should be posted in reply instead.

It also prevent people from not seeing the whole picture; the new frontpage items on OSNews are far more general and less information-dense than they used to be - with information meaning information from the actual news article at hand. In other words, they are less meaningful, so you actually NEED the read more to gain a better understanding.


Do you not see what's wrong with that? The summary *should* provide information, hopefully enough that I can decide whether I want to peruse the article in full. Forcing me to click once to decide whether I want to click again wastes my time. Give me sufficient information *and* a link up front!

The new style teasers generally contain nothing but a little history or background information on the topic at hand, but relatively little from the actual newsworthy article.
OSNews had turned into a glorified RSS feed with three lines teasers all over the place, no background information, no nothing, and an endless list of pointless test releases of Linux distributions, and meaningless items like "here's a review of GreatBSD 2.3.6.1.1.1a. Go read it." I've changed that. It's certainly not perfect yet, but give us time.


That's fine, even good. When something is posted that I am not familiar with I like the extra background describing it. But why is this a reason to remove the link to the article?

This is the new style for OSNews, which allows us to do more thorough items, with more information, and maybe an opinion or two.


It's fine that the system "allows" you to do more thorough items, but I am not seeing that. I am seeing "requires readers to waste their time" on perfectly routine items where details are *not* required.

We've heard nothing but good responses, so everyone better get used to it ;) .


You're hearing a negative response now. Please stop hiding article links! Add "read more" pages to you heart's content, if you must. You could just post a comment like everybody else, but power is meant to be abused. Doesn't bother me. Just don't let this fancy new feature of yours allow you to lose perspective on what you're doing here: I don't come here to read your commentary, I come to find out what's going on in the OS and related world. If it's not original reporting then I *just* want the link to the source material.

Reply Score: 9

RE[5]: Link to the article?
by sbergman27 on Mon 5th May 2008 16:56 UTC in reply to "RE[4]: Link to the article?"
sbergman27 Member since:
2005-07-24

I agree with sorpigal's post.

Reply Score: 3

RE[5]: Link to the article?
by Thom_Holwerda on Mon 5th May 2008 17:06 UTC in reply to "RE[4]: Link to the article?"
Thom_Holwerda Member since:
2005-06-29

Please stop hiding article links!


Noted.

Like I said, we're testing the waters with this stuff - it's just as new to you as it is new to us. I'm trying out different methods, different formats, and such things take time. You can't expect us to get everything right in one go, especially seeing how small a team we actually are, doing everything in our free time.

I'll see what I'll do with the article links. I'm talking to a lot of readers on the 'new style' all the time, every day, to see what they like and don't like. Your considerations will be taken into account just like everyone else's.

Edited 2008-05-05 17:07 UTC

Reply Score: 2

RE[6]: Link to the article?
by joshv on Mon 5th May 2008 18:14 UTC in reply to "RE[5]: Link to the article?"
joshv Member since:
2006-03-18

Thom, how much time does it take to insert the relevant link in the summary? Do you need to run it by a committee? How is it that these things take time?

If content is not original, put the link to the original content in the summary - why is that so hard? If most of your content is not original, you ARE an aggregator, don't pretend to be something you aren't.

If you want to be more like Ars (and I can tell you do), work on creating more original content, which you have been doing lately - and I appreciate it - but don't dork around creating lengthy summaries that people are "coerced" (your word) into reading because the links are buried in them.

If people want to just click through to the links, that's what they are going to do. If you try to stop them, they are just going to leave. Your attitude toward your users is very wrong-headed.

If you want people to read the full article text, do something simple like making a simple "Read more" link that takes you to a combined full article and comment listing - like just about everybody else does it (well, except for Ars - and I really don't like the way they do it, but at least they do place the relevant links in their summary)

Reply Score: 3

RE[7]: Link to the article?
by Thom_Holwerda on Mon 5th May 2008 18:20 UTC in reply to "RE[6]: Link to the article?"
Thom_Holwerda Member since:
2005-06-29

do something simple like making a simple "Read more" link that takes you to a combined full article and comment listing - like just about everybody else does it


That's actually something more people have been saying, and it sounds like a darn good idea to me. There are issues though, such as how to handle 'real' articles, as they can be much longer and multi-paged, making placing the comments somewhere more difficult.

I'll bring this up on the crew m-l!

Reply Score: 2

Yawn
by Kabal on Mon 5th May 2008 14:31 UTC
Kabal
Member since:
2005-07-09

Where are the facts that the .NET api suffered as a result of catering to these imaginary 3 groups of programmers that we all somehow fit into?

Marshalling events onto the UI thread? Oh how can we cope. It's all Win32's fault and the sky is falling. Windows forms in 1.0/1.1 wasn't the best but these days its pretty awesome. It's far from being a BAD api. Infact the sheer scope of things you can do in a consistant manner without ever having to leave standard .NET libraries is pretty ridiculous.

Reply Score: 5

RE: Yawn
by christianhgross on Thu 8th May 2008 11:20 UTC in reply to "Yawn"
christianhgross Member since:
2005-11-15

The worst part is that Java Swing does the exact same thing...

Reply Score: 1

Not portable
by agrouf on Mon 5th May 2008 14:39 UTC
agrouf
Member since:
2006-11-17

Using non portable code is retarded.
Use some toolkit like QT or something. Direct calls to Win32 or Cocoa is retarded, unless you do it is very well defined section of your project that are small and easy to change when you need to port.

Reply Score: 2

RE: Not portable
by FunkyELF on Mon 5th May 2008 15:02 UTC in reply to "Not portable"
FunkyELF Member since:
2006-07-26

XCode?

Is XCode free with OSX? I know if you're making commercial software QT can be expensive. $4k per developer.

Although, if you're making commercial software that doesn't generate at least $4k revenue per developer you have problems anyway.

Reply Score: 4

RE[2]: Not portable
by protagonist on Mon 5th May 2008 15:56 UTC in reply to "RE: Not portable"
protagonist Member since:
2005-07-06

Last time I dl'd it, it was free. Check here.

http://developer.apple.com/tools/download/

Be warned, it is a 1GB+ dl. :-)

Reply Score: 3

RE[2]: Not portable
by tyrione on Mon 5th May 2008 21:49 UTC in reply to "RE: Not portable"
tyrione Member since:
2005-11-21

XCode?

Is XCode free with OSX? I know if you're making commercial software QT can be expensive. $4k per developer.

Although, if you're making commercial software that doesn't generate at least $4k revenue per developer you have problems anyway.


I believe this is intentionally meant to be sarcastic, but yes Xcode is free. So are all the APIs. If you want Support you can buy contracts or register as a Select or Premiere Developer and get your focus noted.

Reply Score: 2

RE[2]: Not portable
by evangs on Tue 6th May 2008 05:43 UTC in reply to "RE: Not portable"
evangs Member since:
2005-07-07


Although, if you're making commercial software that doesn't generate at least $4k revenue per developer you have problems anyway.


Generating an additional $4k revenue can be difficult if you're a small shop or a solo developer. Generating an additional $4k per developer if you're a large software house can be really prohibitive.

If you already have millions of lines of Win32 code, it can be very difficult to embark on a rewrite. For better or for worse, Win32 is like COBOL. It's there, it's hard to remove, and most people just end up dealing with it.

Reply Score: 5

RE[3]: Not portable
by andrewg on Tue 6th May 2008 12:24 UTC in reply to "RE[2]: Not portable"
andrewg Member since:
2005-07-06

Lets do some math. Assuming a uniform salary of $60,000 per annum the ratio would be 1 develop:15 QT licenses. If you make the salaries more realistic its worse. So if QT for large developer teams if QT makes your programmers 1/15 more productive you break even at worst.

So to me it looks like $4,000 is cheap for large teams.

Reply Score: 4

RE[4]: Not portable
by agrouf on Tue 6th May 2008 13:55 UTC in reply to "RE[3]: Not portable"
agrouf Member since:
2006-11-17

Where I live, a developer costs between €60 to €100 for an hour ($90 to $150). For $4000, you have one cheap developer for one week, or less if the developer is not cheap (that is maximum 1/52 of the year). If the developer has a salary of $60000, it is not what he costs. There are a lot of other costs like training him on new technologies, etc. Moreover, check monster. A developer in New York for instance is more like $110k to $130k
Sure, you can have developers in India for half the price, but then, you can buy QT licences for half the price in India.

Edited 2008-05-06 14:08 UTC

Reply Score: 2

RE[2]: Not portable
by agrouf on Tue 6th May 2008 10:30 UTC in reply to "RE: Not portable"
agrouf Member since:
2006-11-17

It is not as expensive as porting your code from win32 to cocoa or from cocoa to win32, unless your project has 100 lines of code or less. $4k is one developer for one week. For any project bigger that 30 man days, $4k for a truly portable toolkit is well worth it for your code will be way less expensive to maintain.

Reply Score: 2

RE: Not portable
by jasutton on Mon 5th May 2008 16:47 UTC in reply to "Not portable"
jasutton Member since:
2006-03-28

I agree totally. I've been using Qt 4.x for the past several months for a few side projects, and it's wonderful how consistent it is across the three big platforms with little-to-no effort on my part as the programmer.

Reply Score: 3

v Inconsistency
by p13. on Mon 5th May 2008 14:57 UTC
...
by Hiev on Mon 5th May 2008 16:01 UTC
Hiev
Member since:
2005-09-27

I'd really like to know what kind of programs the author of the article develop, if his problem is that he can't make vane animations or pretty programs then hey, use WPF.

Now for someone who is looking for writing layered data applications witch customers don't give a damn about being the most pretty program but they care reliability and scalability then excuse me but MS solutions and tools are excelent.

I see the author just biased to the ramification of "make it pretty" and not to the ramification of "make it reliable".

Edited 2008-05-05 16:03 UTC

Reply Score: 1

RE: ...
by apoclypse on Mon 5th May 2008 16:16 UTC in reply to "..."
apoclypse Member since:
2007-02-17

His issue is consistency which shoudl be an issue to anyone who has to program for windows. He gave plenty of examples of this and even gets literal and shows a pic of how inconsistent MS is just on their UI design alone, so you can imagine their api isn't much better.

Reply Score: 4

RE[2]: ...
by Hiev on Mon 5th May 2008 16:19 UTC in reply to "RE: ..."
Hiev Member since:
2005-09-27

You mean consistent on looks?
consistent in API?

Cause the API is pretty much consisten, now if his problem if the look, then big deal, there are tons of priorities before reaching looks.

Reply Score: 1

Thought it was a well written article
by suryad on Mon 5th May 2008 17:21 UTC
suryad
Member since:
2005-07-09

I am a Java developer and that too not an OS nor desktop app writer. I work on enterprise applications and I can see where this author is coming from. As much as I like my work programming in Java can be frustrating because of its verbosity and boiler plate code. Granted that is not what the author was talking about directly but I definitely understand him about the deprecation stuff he was talking about. Java is chock full of those...still its getting faster and faster...and better...so thats all I can really ask. Too bad Java is not performant as C/C++ resulting in fast desktop apps or else it would really be a nice language for most developers I think...though I think Java bytecode can be compiled to .exe nowadays wiht some third party tool.

Reply Score: 2

Win32 API
by ebasconp on Mon 5th May 2008 17:31 UTC
ebasconp
Member since:
2006-05-09

I do not want to start a flamewar, but IMHO, the Win32 API is one of the bests APIs written ever; to develop it, they considered a lot of very important things, like API backward compatibility, ABI backward compatibility, error handling, etc.

Ok, it has inconsistencies, but they are the result of a lot of years put in production.

I agree the Win32 API is hard to use, but it does not turn it into a bad product, having a C API of such huge size brings its own complexities.

Reply Score: 1

RE: Win32 API
by Alex Forster on Mon 5th May 2008 17:45 UTC in reply to "Win32 API"
Alex Forster Member since:
2005-08-12

I would agree that it is a very impressive C API, but the author is comparing it to Cocoa, which is incredibly consistent and logical, object oriented, much more full featured than Win32, protects the programmer from himself in many many cases, runtime-typesafe, and produces native object code. The two really don't compare.

Reply Score: 6

RE: Win32 API
by sanctus on Mon 5th May 2008 19:35 UTC in reply to "Win32 API"
sanctus Member since:
2005-08-31

It looks like you're in the second group.

Reply Score: 2

RE: Win32 API
by siride on Mon 5th May 2008 20:50 UTC in reply to "Win32 API"
siride Member since:
2006-01-02

This is probably the first time I've seen anyone defend the Win32 API as being well-designed and clean. I guess if it's the only API you've ever used, you might think that. Then again, there was a time when it was the only API I ever used and I still thought it was a pile of shite.

Reply Score: 5

RE[2]: Win32 API
by ebasconp on Mon 5th May 2008 21:42 UTC in reply to "RE: Win32 API"
ebasconp Member since:
2006-05-09

<sarcasm>
Do you code in Visual Basic?
</sarcasm>

The Win32 API is a structured, C API, period.

You will not find some object oriented (though the UI functions use 'classes', polymorphic or generic stuff) on that API because it was not thought in an OO world.

Being a C API, is one of the bests C APIs ever; you can run in Windows Vista that old HelloWorld.exe compiled in your Windows 95 box.

Reply Score: 4

RE[3]: Win32 API
by siride on Mon 5th May 2008 23:26 UTC in reply to "RE[2]: Win32 API"
siride Member since:
2006-01-02

The fact that Win95 programs (some of them at least) can still run on Vista is not a testament to the greatness of the Win32 API, but rather to the huge amount of work Microsoft spent making sure things are backwards compatible.

I don't think an API that has at least three methods of memory allocation that all exist because "well, that's how things were in 1988" can ever be considered a good API.

Reply Score: 2

RE[4]: Win32 API
by ebasconp on Tue 6th May 2008 00:43 UTC in reply to "RE[3]: Win32 API"
ebasconp Member since:
2006-05-09

If an API defines several data structures, it is a very common practice to provide three allocators and "releasers", one per each data structure, that is the way how the things in C work.

These are really good things about the win32 api:

* Backward compatibility
* Consistency (being consistent in Java or C# is quite easier than in C because some portion of the consistency comes with the class hierarchies)
* Good error handling (ok, exception handling is better, but C does not provide such thing and I consider the win32 error handling good)
* Stable (it is very hard, almost impossible that the API by itself gets crashed)
* Scalable (ok, you can argue here about a lot of decisions taken to keep the backward compatibility and the new data structures to extend the current functionality, but, come on, mark a method as @deprecated has been a very common design decision in the OO world too).
* Good security (a lot of functions have been thinking on give or block permission to use).
* Seamless UNICODE support. In the front-end, you just use one function, and depending on your project configuration, you will be using the Unicode version FunctionW or the non-unicode FunctionA version of Function.

ok, you cannot compare the Java or C# object models to this huge set of functions, but IMHO, all the weaknesses in the Win32 API come from the implementation language (C) and not from the API design (programming using GObject in the bare metal is as tedious as programming in win32).

I am a java guy and I like a lot the Java APIs (Swing is the most beautiful API found outthere) but talking about Windows and its Win32 API, the engineers that created it deserve a lot of respect.

Reply Score: 2

RE[5]: Win32 API
by evangs on Tue 6th May 2008 05:57 UTC in reply to "RE[4]: Win32 API"
evangs Member since:
2005-07-07


* Backward compatibility


That can be a good or a bad thing. Why is WPARAM 32 bit and not 16 bit? I thought WORDs were 16 bit and DWORDS are 32 bits? Oh wait, WPARAMs and LPARAMs go all the way back to Win16 and they're still here. They made sense in a Win16 world where WPARAM was 16 bit and LPARAM is 32 bit. The make no sense today when both parameters can be 32 bit or 64 bit, depending on what OS you're running.


* Consistency


Consistently verbose and overly engineered. How many functions do you come across that pass a series of NULLs and when you check the documentation, it tells you to always pass NULL as this functionality will be added in the future. 20 years down the line, you are still passing NULL.


* Stable


That's nothing to do with the API. When people talk about API stability, they mean an API that doesn't change much. Runtime stability is unrelated to API stability.



* Scalable


You're joking right? It's such a verbose API. A simple task like creating a new window takes lines and lines of code. The code size of a Win32 project grows tremendously fast. I'd hardly call that scalable.


* Good security (a lot of functions have been thinking on give or block permission to use).


uh ... what?


* Seamless UNICODE support. In the front-end, you just use one function, and depending on your project configuration, you will be using the Unicode version FunctionW or the non-unicode FunctionA version of Function.


True, thats a good thing about the Win32 API.

I code in Win32 everyday (ATL/WTL specifically). Not a day goes by when I do not wish that we went Qt or some other more sensible library.

Reply Score: 3

alban
Member since:
2005-11-15

I am not saying that Windows is not a truly horrid mess, but Apple also lacks perfection.
Unless you have only just started using OSX you would notice that Apple have consistently broken their own user interface guidelines over time and they also support some pretty vile event driven legacy APIs - They even write key components like iTunes and the Finder using them. And Why does QuickTime seem like its own world?
And what is going on with Java?
It seems less than perfect on either side of the fence.
Maybe the grass is just always greener on the other side.

Reply Score: 1

thumbs up
by SK8T on Mon 5th May 2008 20:50 UTC
SK8T
Member since:
2006-06-01

good article

Reply Score: 1

Crazy..
by gonzo on Mon 5th May 2008 23:51 UTC
gonzo
Member since:
2005-11-10

But the library the .NET "API" used for such diverse tasks as writing files, reading data from databases, sending information over a network, parsing XML, or creating a GUI the library is another story altogether.
The library is extremely bad.


And then he never explains what exactly is wrong with it.

The guy is 100% crazy. Or simply ignorant. Like, what exactly is wrong with reading data from database in .NET?

Edited 2008-05-05 23:52 UTC

Reply Score: 4

The author is an idiot
by ciplogic on Tue 6th May 2008 00:12 UTC
ciplogic
Member since:
2006-12-22

The author is probably a weak programmer, a student level in the first year, and he lost three points:
- because .NET is based on Win32 API and is visible in behavior it is a naturally thing. The API does not matter on behavior, the files and database APIs are much cleaner than the predecessors, so no need to argue with it, if you compare with similar technologies till the moment, like COM, Win32 raw API. And is comparable with Cocoa on matter that even an integer is an object (so you can write in .NET somelike: 64.ToString() ).
- the 64 bit programming means mostly bigger address space, not bigger arithmetics. 64 bit integer are rarely used in 64 bit programming. Why? Cause SSE3 can process in one step 8 integers of 32 bits, and only 4 integer on 64. 64 bit programming is used to break the 2GB limit of most memory allocators and that's all.
- the backward compatibility is keep cause of the same reason that exists GTK1 even today and is patched. Some software still use it. So deprecation doesn't necessarily mean that will be removed in +1 version, but means that is a bad practice to use it. One more thing, the deprecated functions are typically implemented using the recommended function, so you will get a performance hit when you use the deprecation. But in rest, there is no waste to have an extra function, to let the old code to still compile.

Reply Score: 1

RE: The author is an idiot
by sanctus on Tue 6th May 2008 13:45 UTC in reply to "The author is an idiot"
sanctus Member since:
2005-08-31


The author is probably a weak programmer, a student level in the first year, and he lost three points:

This kind of comment doesn't make you a better programmer, nor it gives more credit to your post.


- because .NET is based on Win32 API and is visible in behavior it is a naturally thing. The API does not matter on behavior, the files and database APIs are much cleaner than the predecessors, so no need to argue with it, if you compare with similar technologies till the moment, like COM, Win32 raw API. And is comparable with Cocoa on matter that even an integer is an object (so you can write in .NET somelike: 64.ToString() ).
- the 64 bit programming means mostly bigger address space, not bigger arithmetics. 64 bit integer are rarely used in 64 bit programming. Why? Cause SSE3 can process in one step 8 integers of 32 bits, and only 4 integer on 64. 64 bit programming is used to break the 2GB limit of most memory allocators and that's all.

What are you talking about? The fact that .Net was base on win32 is why the author think it's flaw. And I don't see your point about 64bit, it's completely unrelated to the article, plus it add nothing to support your claim.


- the backward compatibility is keep cause of the same reason that exists GTK1 even today and is patched. Some software still use it. So deprecation doesn't necessarily mean that will be removed in +1 version, but means that is a bad practice to use it. One more thing, the deprecated functions are typically implemented using the recommended function, so you will get a performance hit when you use the deprecation. But in rest, there is no waste to have an extra function, to let the old code to still compile.

No! backward compatibility was keep because it was so badly design and poor programmers took many bad habit from it, that they're no other choice.

Your argument for GTK1 is the perfect example of what the author is talking about. Break compatibility for greater good. You CANT use GTK1 code against GTK2 library, you have to explicitly import GTK1 libraries. But if GTK was .net, they would have incoporated GTK1 inside GTK2 for full backward compatibility. But at the really high cost of inconsistency, complexity and maintenance nightmare.

Reply Score: 3

RE: The author is an idiot
by google_ninja on Tue 6th May 2008 15:16 UTC in reply to "The author is an idiot"
google_ninja Member since:
2006-02-05

I agree 100%, but I will add on to that

1. .net 3.0 came out in early 2007. Why is he still talking about WinForms a year and a half later? The reason is because he is trying to prove a point, and that WPF kicks cocoa around the block when it comes to flexibility and power in UI design

2. he talks about the inflexibility of the framework, but doesn't give any supporting reasons for that belief. The whole thing is heavily based on the provider model, and I have yet to find a situation where I have not been able to implement an interface and completely change the behavior of the higher level apis.

3. he talks about the inflexibility of the framework compared to java when it comes to enterprise archetecture. Someone must not have told him, but the java API BLOWS for enterprise archetecture, that is why the java community has come up with so many replacement frameworks. LINQ2SQL may not be perfect, but it kicks the living crap out of EJBs any day, which don't even fit in very well with modern ideas (like SOA).


4. He slams microsofts handling of 64bit, but fails to mention that .net will compile an optimized version of native code for your specific cpu at install or first run, compared to apples solution of just bloating your executables by shipping with multiple binaries for all architectures stiched together.



Now, lets look at cocoa

Obj-C is ancient. That doesn't make it bad, but the entire industry has moved in a completely different direction. It is basically bringing back a less popular version of smalltalk and calling it modern.

Cocoa changes radically from version to version, which is a developer nightmare, especially for large software.

There is an attempt for grand unified one size fits all APIs (which he slams in .net), they are just nowhere near as complete OR consistent. Show me how to do web services with cocoa, and I'll show you how to do them with WCF (hands down the best service platform at this point in time)

Reply Score: 2

RE[2]: The author is an idiot
by sanctus on Tue 6th May 2008 15:51 UTC in reply to "RE: The author is an idiot"
sanctus Member since:
2005-08-31


1. .net 3.0 came out in early 2007. Why is he still talking about WinForms a year and a half later? The reason is because he is trying to prove a point, and that WPF kicks cocoa around the block when it comes to flexibility and power in UI design

Maybe the author will come up with this in part 3.
But it looks you also trying to prove a point. WPF kicks cocoa arount the block? I don't have any experience with WPF, except reading the documentation. But I fails to see how you explain it, or back it up .


3. he talks about the inflexibility of the framework compared to java when it comes to enterprise archetecture. Someone must not have told him, but the java API BLOWS for enterprise archetecture, that is why the java community has come up with so many replacement frameworks. LINQ2SQL may not be perfect, but it kicks the living crap out of EJBs any day, which don't even fit in very well with modern ideas (like SOA).

Kicks the living crap? Seriously you blame the author in point 2 that the doens't backup is claim, why don't you?
You're right about java, but aren't the both equal?


4. He slams microsofts handling of 64bit, but fails to mention that .net will compile an optimized version of native code for your specific cpu at install or first run, compared to apples solution of just bloating your executables by shipping with multiple binaries for all architectures stiched together.

He slams the result of a whole inconsistency and development philosophy. Optimization is nice, but completely useless when you start including C++ librairies into the mix. The author talk about the ribbon as an example. But if they open the door with this, many others will follow.

As for apple packages, this is a package containing both libraries. So it will not load everything in memory. Linux is the same with /usr/lib32 and /usr/lib64, a link /usr/lib aiming the system default.

But maybe syswow64 is a better place to make future hardcode link for 32 bit libraries...

Reply Score: 2

RE[3]: The author is an idiot
by google_ninja on Tue 6th May 2008 17:15 UTC in reply to "RE[2]: The author is an idiot"
google_ninja Member since:
2006-02-05

But it looks you also trying to prove a point. WPF kicks cocoa arount the block? I don't have any experience with WPF, except reading the documentation. But I fails to see how you explain it, or back it up .


1. WPF uses an incredibly powerful xml based content model. A silly example of this would be something like <Button><Textbox /><Button> to make a button with a textbox in the middle, but it illustrates the point well. This is possible in other UI frameworks, but is typically alot more difficult.

2. WPF uses an incredibly powerful databinding model. It also takes a bit to wrap your head around, but once you do you don't really want to go back to anything else. If you want to see a good example of this, here is a blog post on how to turn a listbox into a to scale representation of the solar system using data templating http://www.beacosta.com/blog/?p=40

3. The tooling for WPF blows XCode out of the water. The designer in visual studio is fanstastic, unlike the winforms designer which only caters to people who don't want to know what is going on, the WPF designer accomidates people who want more control over the code. AND there is a tool for designers to directly modify the UI called Expression Blend. This allows the designer to work in parallel with the developer, and actually make changes in the actual code file, as opposed to emailing a mockup in photoshop.

There is alot more, but those are the three big ones, that to my knowledge do not exist on any other UI platform.

Kicks the living crap? Seriously you blame the author in point 2 that the doens't backup is claim, why don't you?
You're right about java, but aren't the both equal?


I did back this one up, the author praised java while bashing .net. I brought up that doing things The Microsoft Way (WCF and LINQ), makes SOA a joy to work with, as opposed to doing things the Sun Way which is only really appropriate for the absolute largest of enterprise apps. I also brought up the provider model, which allows very high level easy to use APIs (like user authentication) out of the box, but allowing for a great deal of flexibility in implementation details if you choose to roll your own provider.

The difference between .net and java is the java community process moves at the pace of a sloth, and MS has shown a very good history so far of rolling modern ideas into the framework and its languages (extension methods, lambdas, real generics, WCF, etc).

Where java shines is that the community has a good decade or so on the dotnet one, and they have already solved many of the issues we are still figuring out. It does not shine on technical merit.

As for apple packages, this is a package containing both libraries. So it will not load everything in memory. Linux is the same with /usr/lib32 and /usr/lib64, a link /usr/lib aiming the system default.


You are right, but since when is shipping two binaries better then compiling an optimized one on the fly? Linux's /usr/lib32 /usr/lib64 is a cleaner version of Program Files/Program Files (86), but that speaks more about how horrible the MS deployment story used to be then the way it is now. If you are using .net (the standard for almost a decade at this point), the whole thing becomes moot.

But maybe syswow64 is a better place to make future hardcode link for 32 bit libraries...


I am not defending microsofts legacy 32-bit on 64-bit story, it is an ugly hack. I am pointing out that you shouldn't throw stones in a glass house, because apples story is just as hacky.

Reply Score: 2

RE[4]: The author is an idiot
by Alex Forster on Tue 6th May 2008 19:34 UTC in reply to "RE[3]: The author is an idiot"
Alex Forster Member since:
2005-08-12

I just ordered a book on XAML, mostly because of that link. I don't do much .NET programming, but I loved the early Channel 9 videos on XAML, and I'm incredibly interested in it as a UI framework.

Edited 2008-05-06 19:37 UTC

Reply Score: 2

RE[5]: The author is an idiot
by google_ninja on Tue 6th May 2008 21:44 UTC in reply to "RE[4]: The author is an idiot"
google_ninja Member since:
2006-02-05

Yeah, I'm a web guy and I have never been interested at all about UI before XAML.

The chris sells oreilly book is pretty much the standard "Hello, world" book at this point. Beatriz Costa's blog (where that link came from) is an absolute goldmine on databinding and datatemplating. Once you have the basics down, I would highly recommend starting at the first post and reading them all if you want to do anything even remotely data-centric.

For me personally, the big thing has been unlearning alot of concepts I picked up from other UI frameworks I have used. It is closer to xhtml then anything else, but only at the most basic of levels.

Reply Score: 1

RE[4]: The author is an idiot
by Francis Kuntz on Wed 7th May 2008 07:31 UTC in reply to "RE[3]: The author is an idiot"
Francis Kuntz Member since:
2006-09-23

It seems that the .Net expert Kevin Hoffman is not thinking like you. He just said at the last WWDC that Cocoa and Xcode just blows .net and visual studio.

.Net vs Cocoa for Developers.
Despite being an expert in .Net but brand new to the Cocoa platform, Hoffman said the time to complete his project was much faster on Cocoa. The same project took only one third the time, despite his having far more experience with Vista's .Net frameworks than Apple's Cocoa. He also noted:

The user experience developed was better by default on Mac OS X. As a programmer and 'not a designer,' Hoffman says he approached user interface development with some trepidation, needing to seek out help from professional designers on the Vista end.

Under Cocoa however, Hoffman says he found Apple's visual development tools very accessible, while Microsoft's visual interface builder tool in Visual Studio was 'so poor I turned it off.'


And as we said, he wrote the books ....
Hoffman has been working with Microsoft's technologies for many years, and was an early adopter of Vista's new Windows Presentation Foundation and the .Net 3.0 framework since their release to developers back in 2003. He has literally wrote the book on a series of Microsoft development subjects from ADO.NET to C# to SharePoint.


you should also take a look at the 'MVC Design Patterns in Cocoa and .Net.' section ...

http://dotnetaddict.dotnetdevelopersjournal.com/roughlydrafted.htm

Edited 2008-05-07 07:33 UTC

Reply Score: 3

RE[5]: The author is an idiot
by google_ninja on Wed 7th May 2008 12:18 UTC in reply to "RE[4]: The author is an idiot"
google_ninja Member since:
2006-02-05

This guy may have been a big MS guy, but any bias he may have once had has completely shifted, and that is evident in his talk. I have seen that before, and alot of it has to do with the overall quality of the OS, rather then the actual dev tools.

That being said, he does have some points.

MVC

Obj-C by its nature pushes you towards very clean architecture, .net by its nature pushes you towards VB6 style RAD "everything in the code behind". Any .net developer worth his chops is going to use Model-View-Presenter for win/webforms, or Model-View-ViewModel for XAML, but some of the tools actually encourage sloppyness. On this point, I think he is bang on. (why I mention it first ;-) )

Designer

He said that he was unable to design an interface, and because of that he liked the XCode designer, because it spat out better UIs by default. I say that any developer who does UI design in any way needs to read a few books on the subject, because if you don't you are simply not doing your job well. Sure, a professional usability expert is going to do a BETTER job then you, but that doesn't mean that you can just abdicate all responsibility as a UI developer.

As someone who is not a designer, but a programmer who takes all aspects of his work seriously and has learned the fundamentals of good design, I would take winforms designer over the xcode one any day, and I am not even talking about WPF, because it really takes things to the next level (as I have mentioned elsewhere).

He does have a point about core animation though, it is nice to have some canned, standard effects to work with that people can get used to seeing. Since we are still in the early stages of WPF (it just came out last year, visual studio 2008 was the first version with tools for it), I still have hopes.

Data Access

from the site

Isolated storage in an object relational system won't be offered for .Net until later this year, forcing developers to use XML flat files, or jump up to full blown SQL Express work, a large burden to put upon desktop application developers.


That is misleading. Ignoring LINQ (which is out now, and it rocks), we have had OR/Ms on .net for years now, and I don't know of anyone using raw ADO.net for a very long time. My personal favorite (pre LINQ) has been subsonic http://subsonicproject.com/, but the most popular is probably NHibernate http://www.hibernate.org/343.html.

Also, .net has pretty good XML APIs, and very good XML serialization APIs, so using XML isn't quite the nightmare that was implied.



Anyways, I have said in a whole bunch of places now that I don't think that obj-c/cocoa is bad. I am really not trying to say that. If I were doing audio apps, or image manipulation apps for a living, I would probably have gone the apple way. But it is far from being modern, and it has a hell of alot of liver spots on it that drive me around the bend. to quote Rory Blythe

The last time I dealt with a header file and felt OK about it was in 1992


Edited 2008-05-07 12:20 UTC

Reply Score: 3

RE[2]: The author is an idiot
by tyrione on Tue 6th May 2008 20:13 UTC in reply to "RE: The author is an idiot"
tyrione Member since:
2005-11-21

I agree 100%, but I will add on to that

1. .net 3.0 came out in early 2007. Why is he still talking about WinForms a year and a half later? The reason is because he is trying to prove a point, and that WPF kicks cocoa around the block when it comes to flexibility and power in UI design

2. he talks about the inflexibility of the framework, but doesn't give any supporting reasons for that belief. The whole thing is heavily based on the provider model, and I have yet to find a situation where I have not been able to implement an interface and completely change the behavior of the higher level apis.

3. he talks about the inflexibility of the framework compared to java when it comes to enterprise archetecture. Someone must not have told him, but the java API BLOWS for enterprise archetecture, that is why the java community has come up with so many replacement frameworks. LINQ2SQL may not be perfect, but it kicks the living crap out of EJBs any day, which don't even fit in very well with modern ideas (like SOA).


4. He slams microsofts handling of 64bit, but fails to mention that .net will compile an optimized version of native code for your specific cpu at install or first run, compared to apples solution of just bloating your executables by shipping with multiple binaries for all architectures stiched together.



Now, lets look at cocoa

Obj-C is ancient. That doesn't make it bad, but the entire industry has moved in a completely different direction. It is basically bringing back a less popular version of smalltalk and calling it modern.

Cocoa changes radically from version to version, which is a developer nightmare, especially for large software.

There is an attempt for grand unified one size fits all APIs (which he slams in .net), they are just nowhere near as complete OR consistent. Show me how to do web services with cocoa, and I'll show you how to do them with WCF (hands down the best service platform at this point in time)


Really? The entire industry has moved away from MVC/KVC modeling which are inherent strengths of ObjC and Cocoa?

Please. They've moved towards it. I laugh at CORBA when it was bludgeoning the industry with using it and ignoring NeXT and their worthless MVC/DO/PDO Models for OOA/OOD.

Where are we now? Truly amazing that every language, especially C# and Java act as if they've invented the whole MVC paradigm.

C++ with Trolltech are using it extensively as does KDE.

Do you give credit to NeXT/Apple, specifically ObjC/Cocoa or it's elder Smalltalk?

Never.

What a joke.

Reply Score: 3

RE[3]: The author is an idiot
by google_ninja on Tue 6th May 2008 20:48 UTC in reply to "RE[2]: The author is an idiot"
google_ninja Member since:
2006-02-05

Obj-C didn't invent MVC, smalltalk did. I have never really implied that anyone else came up with that pattern. Smalltalk was a great language in its time, if it weren't for the huge performance issues, we would probably be using things that are very similar in syntax.

The fact is we are not.

I am talking more about how much of the syntax and ideas are either just really old and outdated (method prototyping, header files, multiple inheritance), or just odd and quirky (messaging, posing, categories, forwarding, etc).

Now, odd and quirky are far from being the same thing as bad, I actually specifically said that I wasn't saying it was bad. But it is being passed off by mac guys as modern, which it is not. You can trace a natural evolution in syntax both for the statically typed languages (c++ - java - c#) or dynamically typed languages (perl - python - ruby). You see alot of syntax in the language hasn't really been used in anything serious for about 20-25 years now.

And I'm just talking syntax, im not even going to bring up things like (proper) GC or sandboxing.

Edited 2008-05-06 20:54 UTC

Reply Score: 2

RE[4]: The author is an idiot
by tyrione on Wed 7th May 2008 04:58 UTC in reply to "RE[3]: The author is an idiot"
tyrione Member since:
2005-11-21

No s*** sherlock. Clearly you have a reading deficiency as I pointed out that MVC came from Smalltalk. NeXT extended it and included Delgates and later Bindings ala KVC.

Reply Score: 3