Joel on Software
-
My impression on his understanding of object-oriented programming is based primarily on the fact that he dismisses it as a productivity booster. In reality, object oriented APIs have been a huge productivity boost. Compare using a COM object API to using a Win32 API. It adds a whole other dimension to the API. Even before .NET, we were realising the power of OO. IMO, if someone cannot grasp that, then they do not understand OO. Secondly, while Joel has experience in C++, and that certainly qualifies as a language with object-oriented features, it is hardly proof that he knows OO. Programming in C++, Joel may or may not have good OO experience. Given that Joel states that he has experience in VB6, ASP and C++, I doubt that he has had the chance to really grow in that area. Regarding memory leaks, yes I have tracked down a few. Yes, it took some time. But it was nothing compared to the time I spent in actual development, so it did not have any more effect on my productivity than other non-trivial bugs.
Steven Campbell wrote: Compare using a COM object API to using a Win32 API. It adds a whole other dimension to the API This I just don't understand. Do you mean that plain-vanilla COM-programming is more productive than Win32 API-programming? This can't be true, so I must assume that you mean any COM-wrapper above developing COM on the API-level. Well, that COM-development on the API-level is less productive than using a class wrapper might very well be because the COM-API is so... badly designed from the beginning (well, complicated, rather). It would certainly have been possible to design an easier interface without OO. OO is a productivity boost in the same way as a well-designed non-OO interface is a productivity boost - and the opposite is definitely true as well. Steven Campbell wrote: IMO, if someone cannot grasp that, then they do not understand OO. If you don't grasp that OO is a productivity boost, you don't understand OO. So, by definition, if I say that OO is not a productivity boost, then I just don't understand it. Now, that is unfair reasoning - either I must agree with you, or I don't understand :-)
-
I asked my mom, she has no idea what either of those 2 things are! So far, my representative sample supports my view. :eek: There I go again, making unverifiable statements. No Nick, I do not have any studies to back that up. In future I'll try use less "absolute" language so as not to obscure my point. ;P
Steven Campbell wrote: I asked my mom, she has no idea what either of those 2 things are! So far, my representative sample supports my view. hehehe there you go, proof positive. ;-) I actually agree with your point though, right now CAS doesn't make a lot of sense when client apps are currently being run with full permission on Windows 98/ME/XP machines. But CAS will make a whole lotta sense once rich client .NET apps are deployed from a web server or even run in a semi-trusted environment. This is actually possible right now (again, almost nobody knows this) but you can put a .NET assembly on a web server and run it from Internet Explorer in a semi-trusted environment, making use of CAS. This will become more apparent once .NET 2.0 rolls around with its "ClickOnce" deployment (or whatever buzzword they're using for it now). And further down the road, it will become inevitably visible when Longhorn is released. #include "witty_sig.h"
-
I agree that Microsoft is screwing up the API, however I doubt that web based GUIs will be the solution for most application. What really irks me is how they have screwed up access to the underlying hardware, and continue to make things more and more dificult. Abstraction is great, until it prevents me from getting the job done.
It didn't work with Java, and here we go again :-)
-
I asked my mom, she has no idea what either of those 2 things are! So far, my representative sample supports my view. :eek: There I go again, making unverifiable statements. No Nick, I do not have any studies to back that up. In future I'll try use less "absolute" language so as not to obscure my point. ;P
Steven Campbell wrote: I asked my mom, she has no idea what either of those 2 things are! So far, my representative sample supports my view. You've got me there! :laugh: Steven Campbell wrote: There I go again, making unverifiable statements. No Nick, I do not have any studies to back that up. In future I'll try use less "absolute" language so as not to obscure my point. Not trying to start a war here, I just wanted to make it a point that many people do know about these things and do use them, however it is probably not the majority by any means. - Nick Parker
My Blog | My Articles -
Nick Parker wrote: I thought he said something about not being experienced in .NET in the article... I don't remember seeing anything like that, just a lot of griping about how .NET isn't backward compatible (which should be obvious since it never existed before) and a few others things. Whether he said he knew it or not, it certainly isn't right to lament something you don't understand. It just makes the author sound ignorant. To note, though, I do read Joel's comments from time to time ( I actually did read that Unicode link you sent me a long time back and learned a thing or two - like about UCS-4 :eek: ). I'm not saying the article was bad, just that there's a few things with which I heartily disagree. Plus, if he things Microsoft's changing APIs are bad, at least they're well documented. Try reading *nix man pages lately? :) And if people - like he mentioned regarding Apple - are using undocumented features than they do so at their own risk. At least Microsoft has been mindful of that and has tried to maintain backward compatibility, even with undocumented APIs. That's no small feet.
Microsoft MVP, Visual C# My Articles
Heath Stewart wrote: Plus, if he things Microsoft's changing APIs are bad, at least they're well documented. I completely agree! - Nick Parker
My Blog | My Articles -
Steven Campbell wrote: I asked my mom, she has no idea what either of those 2 things are! So far, my representative sample supports my view. You've got me there! :laugh: Steven Campbell wrote: There I go again, making unverifiable statements. No Nick, I do not have any studies to back that up. In future I'll try use less "absolute" language so as not to obscure my point. Not trying to start a war here, I just wanted to make it a point that many people do know about these things and do use them, however it is probably not the majority by any means. - Nick Parker
My Blog | My Articles -
wow have u misunderstood the whole point of his article? users dont care what api is running the same as i dont care what my mechanic does to fix my car ... just make it run i have always said that .NOT presents a zero value proposition to most people and very many developers ... i get the feeling that longhorn is turning into an os/2 fiasco
>> i have always said that .NOT presents a zero value proposition Uh Oh... better call those idiots over at the Linux Mono project and tell them to shut id down! What the hell were they thinking !!? ;P:laugh::laugh: http://go-mono.com/[^]
"No matter where you go, there your are." - Buckaroo Banzai
-pete
-
>> i have always said that .NOT presents a zero value proposition Uh Oh... better call those idiots over at the Linux Mono project and tell them to shut id down! What the hell were they thinking !!? ;P:laugh::laugh: http://go-mono.com/[^]
"No matter where you go, there your are." - Buckaroo Banzai
-pete
-
It didn't work with Java, and here we go again :-)
-
-
-
Sorry that was a low blow. I hit you right in the Linux :laugh::laugh::laugh:
"No matter where you go, there your are." - Buckaroo Banzai
-pete
:-D what im trying to say (and have more clearly in my mind after a shower) is that writing software shouldnt be made too easy ... like brain surgery or flying airplanes it should require some skill and knowledge ... the ms approach of making it almost easy enuff for my mom to write software is all wrong ihmo i doubt i would be any more productive writing in vb.net or c# or whatever.not than i am in mfc / php / sql as i have all my code libraries etc that i know work and i know my tools thats why there in no value proposition (again imho) in what ive seen of longhorn so far ... there is nothing it can do that i cant do already and it will cost me a small fortune to upgrade everything do ms _really_ think the corporates are going to spend that kind of $$ on longhorn upgrades??!!?? i seriously doubt it since (in case nobody noticed) we're still up to our necks in recession [edit] thats why most of the work i seem to be getting is LAMP type projects ... oss saves real money [/edit]
-
Steven Campbell wrote: Compare using a COM object API to using a Win32 API. It adds a whole other dimension to the API This I just don't understand. Do you mean that plain-vanilla COM-programming is more productive than Win32 API-programming? This can't be true, so I must assume that you mean any COM-wrapper above developing COM on the API-level. Well, that COM-development on the API-level is less productive than using a class wrapper might very well be because the COM-API is so... badly designed from the beginning (well, complicated, rather). It would certainly have been possible to design an easier interface without OO. OO is a productivity boost in the same way as a well-designed non-OO interface is a productivity boost - and the opposite is definitely true as well. Steven Campbell wrote: IMO, if someone cannot grasp that, then they do not understand OO. If you don't grasp that OO is a productivity boost, you don't understand OO. So, by definition, if I say that OO is not a productivity boost, then I just don't understand it. Now, that is unfair reasoning - either I must agree with you, or I don't understand :-)
Do you mean that plain-vanilla COM-programming is more productive than Win32 API-programming? Yes. For example, I have programmed against DAO, RDO, ADO, and ADO.NET (all object-based APIs). Before that, I programmed against the ODBC API, (which was not object-based). I spent months writing a wrapper around that API, so that I would be able to write the rest of the application without worrying about the database details. So, my experience has been that plain APIs tend to be all about power, and not about usability. Object-based APIs tend to have the opposite focus (although they can still maintain all the power). Sorry about the if someone cannot grasp that, then they do not understand OO statement. Its been a long day. I hate it when other people make blanket statements like that :-O
-
Navin wrote: ... though I disliked his stick-shift analogy. Once you've driven a stick-shift for a while, it's just as easy to drive as an automatic. And they usually cost less, and certainly are cheaper to work on, and since they weigh less, get better gas mileage. Hey, what about the fun factor of driving a stick-shift? :) - Nick Parker
My Blog | My Articles -
:-D what im trying to say (and have more clearly in my mind after a shower) is that writing software shouldnt be made too easy ... like brain surgery or flying airplanes it should require some skill and knowledge ... the ms approach of making it almost easy enuff for my mom to write software is all wrong ihmo i doubt i would be any more productive writing in vb.net or c# or whatever.not than i am in mfc / php / sql as i have all my code libraries etc that i know work and i know my tools thats why there in no value proposition (again imho) in what ive seen of longhorn so far ... there is nothing it can do that i cant do already and it will cost me a small fortune to upgrade everything do ms _really_ think the corporates are going to spend that kind of $$ on longhorn upgrades??!!?? i seriously doubt it since (in case nobody noticed) we're still up to our necks in recession [edit] thats why most of the work i seem to be getting is LAMP type projects ... oss saves real money [/edit]
>> and have more clearly in my mind after a shower Now i need one... a cold one >> software shouldnt be made too easy >> it should require some skill and knowledge Yes !! YAAEESSS !!! oh i just... :-O That has always been my worst problem with VB and others like Delphi and now we have .NET in any language. Wait until you have to work with some Drag n Drop "look ma I'm a programmer" that doesn't know a thread from a shoelace. Ok... now i should receive plenty'o flames
"No matter where you go, there your are." - Buckaroo Banzai
-pete
-
Interesting read, rather lengthy but interesting none the less. What is your opinion? How Microsoft Lost the API War[^] - Nick Parker
My Blog | My ArticlesMy thoughts on the article ranged from "that's interesting" to "Joel is wrong here" to "wait, what was the article about again?" I have to admit that Joel has interesting things to say, but sometimes I think that the interesting parts of his writing distract people from the fact that he isn't making a point and he's gone off on some irrelevant tangent because he got distracted by something else he wanted to say. "Microsoft's crown strategic jewel, the Windows API, is lost... the Windows API is no longer of much interest to developers. The goose that lays the golden eggs is not quite dead, but it does have a terminal disease, one that nobody noticed yet... People don't really care much about operating systems; they care about those application programs that the operating system makes possible... [P]eople buy computers for the applications that they run, and there's so much more great desktop software available for Windows than Mac that it's very hard to be a Mac user. And that's why the Windows API is such an important asset to Microsoft." At this point, I thought he was going to talk about how WINE and Mono are bringing Windows applications to other platforms - therefore undermining the need to buy Windows. Outside developers, who were never particularly happy with the complexity of Windows development, have defected from the Microsoft platform en-masse and are now developing for the web. Paul Graham, who created Yahoo! Stores in the early days of the dotcom boom, summarized it eloquently: "There is all the more reason for startups to write Web-based software now, because writing desktop software has become a lot less fun. If you want to write desktop software now you do it on Microsoft's terms, calling their APIs and working around their buggy OS. Sorry, but the web is a piss-poor development platform. To say that developers think the web is better than working with Windows APIs and "their buggy OS" is totally wrong. But, what would you expect a dotcommer to say? He's still selling the dotcom idea. I think .NET is a great development environment and Avalon with XAML is a tremendous advance over the old way of writing GUI apps for Windows. The biggest advantage of .NET is the fact that it has automatic memory management. At this point, he disses OO, and praises automatic memory management. While I disagree with him on this point, I have to think, "Microsoft is going towards automatic memory management - so Joel is saying Microsoft is making positive changes in their pro
-
>> You can literally start a small company with 5 developers Great, we really needed more of that attitude. "All it takes to produce a software product is..." Those ... are .... sorry i just puked, nasty words.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
Look, he was just exhibiting some enthusiasm :suss:.
Software Zen:
delete this; -
Interesting read, rather lengthy but interesting none the less. What is your opinion? How Microsoft Lost the API War[^] - Nick Parker
My Blog | My ArticlesNick Parker wrote: Interesting read Really? I found it dull, meandering, and impossible to determine what the point of it all was. Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog
-
Nick Parker wrote: Interesting read Really? I found it dull, meandering, and impossible to determine what the point of it all was. Marc Microsoft MVP, Visual C# MyXaml MyXaml Blog
Marc Clifton wrote: Really? I found it dull, meandering, and impossible to determine what the point of it all was. You’re not the only one, I don't necessarily agree with everything Joel said, but I did think it was an interesting take on the matter. I thought it was interesting to hear everyone's opinions about it, either way. Thanks for your comments Marc! :-D - Nick Parker
My Blog | My Articles -
Do you mean that plain-vanilla COM-programming is more productive than Win32 API-programming? Yes. For example, I have programmed against DAO, RDO, ADO, and ADO.NET (all object-based APIs). Before that, I programmed against the ODBC API, (which was not object-based). I spent months writing a wrapper around that API, so that I would be able to write the rest of the application without worrying about the database details. So, my experience has been that plain APIs tend to be all about power, and not about usability. Object-based APIs tend to have the opposite focus (although they can still maintain all the power). Sorry about the if someone cannot grasp that, then they do not understand OO statement. Its been a long day. I hate it when other people make blanket statements like that :-O
Steven Campbell wrote: > Do you mean that plain-vanilla COM- > programming is more productive than Win32 API- > programming? Yes. This definitely goes against my experience. COM-development on the SDK-level is not something I would recommended as a starter for the unexperienced, while plain Win32 SDK-programming (say, for example, writing DLLs to take something at least remotely similar - "component creation" in this case) is nothing special. As for db-APIs, I really think that you would find a majority of unsuspecting programmers prefering to learn ODBC, BDE or whatever, over using DAO or ADO without the help of Wizard generated code. So, I'm not so sure OO is a productivity boost. The major benefit, in my experience, is the ease of division of labour in larger projects, and also code reuse. In my experience, it seems like it's easy to grasp the fundamentals (after hearing some silly examples on vehicles, cars and motorcycles :-)), after that, the learning curve gets steeper than for non-OO development.