But are we the ones who should be concerned about ease?Originally Posted by Elysia
Again... is it not our job to do the complex work of making it easy for the end user?
LOL... Not even in C++ with a gazillion bytes of framework...You can't escape reality...
As I said before, the more complexity you put in your application, the more bugs there will be. Yes, it is our job to abstract it from the user. But it is also our job to make the user happy.
If there are already tools available, why not use them?
If you had a choice between using a screwdriver and an automated electric screwdriver, which would you use? Clearly, the electric one would allow us to get the job done faster, and with more accuracy.
One can make the same argument about WinAPI...
If the OS already provides you the tools you need, why not use them?
Given the number of times I've pulled out my trusty Philips screwdriver and tightened every bolt and screw installed with automated screwdrivers on Chinese production lines... I'm having a very hard time answering that one... (Seriously... it seems that everything I work on these days is made in China and every last screw is undertightened.)If you had a choice between using a screwdriver and an automated electric screwdriver, which would you use? Clearly, the electric one would allow us to get the job done faster, and with more accuracy.
Because it's inferior.
"Hey, look, it's cold outside! Let's store our food outside instead of the freezer!"
It is a wrapper yes, but who says something like that couldn't have been implemented instead of the way winapi is currently implemented? That is the huge difference. Winapi is probably a wrapper over kernel-code anyway so the whole wrapper point really doesn't stick. Especially combined with my second point below.
Speed isn't really an issue either, since alot of the time spent in a win32 application is idling just waiting for messages anyway.
Edit: I see alot of my thoughts have already been conveyed by Elysia after my initial post.
Second edit: I can't really see how one can argue that a more complex library should be used when there are other better designed libraries providing more functionality in a form that is much easier for the programmer to handle and use. "The best tool for the job" is an expression often used by programmers, and it applies to libraries aswell. In todays day and age WinAPI is losing out to other libraries that are better designed for todays usage, both in easy-to-use when doing the initial programming but also in maintaining a program.
A huge part of a programs life-span is maintaining it and must be taken in account when making decisions. I do not and never will beleive a pure WinAPI application is easier to both program the initial application and to maintain, than a program written in a more modern library.
Last edited by Shakti; 03-13-2011 at 09:29 AM.
Consider that most of your frameworks --wrappers, etc.-- actually call WinAPI functions... If the WinAPI is so inferior, how can your frameworks possibly be any better?
A house is no better than the wood it's made from...
You misunderstand what I mean by inferior. It isn't that WinAPI produces inferior results--it does not. It is inferior in such a way that it is difficult to use to attain the correct results. The libraries simply the getting results right part.
Because the wrapper exposes the relevant parts in a more programming-friendly environment that allows the programmer to use the underlying library in an easier way to produce more robust application less prone to bugs. An open-source library (mentioning open-source because many of the biggest GUI libraries are opensource) is probably peer-reviewed many times harder than any code written by a programmer at a company.
With your logic C isn't really useful since its just a "wrapper" for assembly, and assembly is just a wrapper for binary code anyway so by your logic binary code is the way to go when programming.
A house is no better than the wood it's made from, but a house with a crappy blueprint and layout is still crap, no matter how good the wood is.
Actually WinAPI is a collection of DLLs. Some of the functions will, indeed be kernel calls, but most are just library functions... much like your wrappers.
I'm not saying you don't have a point... you do.I can't really see how one can argue that a more complex library should be used when there are other better designed libraries providing more functionality in a form that is much easier for the programmer to handle and use. "The best tool for the job" is an expression often used by programmers, and it applies to libraries aswell. In todays day and age WinAPI is losing out to other libraries that are better designed for todays usage, both in easy-to-use when doing the initial programming but also in maintaining a program.
However; --and this is where I get a little giggle every time this comes up-- WinAPI is, itself, merely a set of libraries.... In effect you're arguing "My toy's better than your toy" and I think we both know the obvious retort to that... "Is NOT"... "Is SO"...
Y'know what, I can make the same claim in reverse... But in reality it's a question of familiarity. I've seen WinAPI programmers who look at third party libraries in disbelief... and next to him is a library fan looking at WinAPI in disbelief... Both are overwhelmed by what they are not familiar with...A huge part of a programs life-span is maintaining it and must be taken in account when making decisions. I do not and never will beleive a pure WinAPI application is easier to both program the initial application and to maintain, than a program written in a more modern library.
Now that I can agree with. The libraries do simplify your job somewhat.
But you started off claiming that WinAPI itself introduced bugs into programs... Apparently not thinking what lies underneath your wrapper libraries...
Last edited by CommonTater; 03-13-2011 at 09:55 AM.
Yes, and I still claim that using WinAPI in its raw form introduces bugs into programs. More so than using 3rd party libraries.
Take my word for this... You do not want to get me started on Open Source projects... Let me just remind you of the old saw: "Too many cooks spoil the broth".
Don't try so hard... You're point is heard... I disagree but I have definately heard you.With your logic C isn't really useful since its just a "wrapper" for assembly, and assembly is just a wrapper for binary code anyway so by your logic binary code is the way to go when programming.
A house is no better than the wood it's made from, but a house with a crappy blueprint and layout is still crap, no matter how good the wood is.
Shall I repeat my previous point about where bugs come from?
Yes, it is hard to argue in any other way really. But I think you will find more programmers switching from WinAPI to some other library that wraps it than you will find programmers switching from a wrapping library to WinAPI. I know it's a crappy argument really but in my mind this says something about WinAPI in comparison with the other libraries.
The difference I think is that if they were both to use the other (library fan use WinAPI and the winapi fan use the library) for say a week I think in many cases the library fan would go back to the library and the WinAPI fan would probably also concede that the library is easier (better).Y'know what, I can make the same claim in reverse... But in reality it's a question of familiarity. I've seen WinAPI programmers who look at third party libraries in disbelief... and next to him is a library fan looking at WinAPI in disbelief... Both are overwhelmed by what they are not familiar with...
Humans like to do things the easy way and once you get somebody to try the easy way its easy to stick with it. The reverse can not be said.
No, they are not logical.Shall I repeat my previous point about where bugs come from?
Yes I think open-source has problems, too many cooks can definately be one of them. That doesn't mean there are some seriously peer-reviewed open source libraries that are better than the underlying library they wrap.
Not trying hard at all really.Don't try so hard... You're point is heard... I disagree but I have definately heard you.
Bad programmers produce bugs yes, but is that a reason for not making the life as easy as possible, and give and let programmers use every tool available to produce bug-free code?Shall I repeat my previous point about where bugs come from?
Just because programmers create the bugs doesn't mean we shouldn't provide any tool available to prevent that. And a library that is less prone to produce buggy code is one of those tools.
It also says quite a bit about programmers, too...
Nobody's going to blame them for taking the path of least resistence, it's done all the time. But there is no denying the impact on the craft... A lot of "dumbing down" as programmers increasingly have less and less understanding of the systems they motivate...
In the mid-1980s when I began to incorporate computers into my professional life (instead of the hobby they'd been until then) the big grumble about Programmers was "They just don't seem to understand the hardware"
Now it's fast becomming: "They just don't seem to understand the software..."
