From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e60606080751k6435daebs943d094b338b21f8@mail.gmail.com> Date: Thu, 8 Jun 2006 07:51:32 -0700 From: "David Leimbach" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] gcc on plan9 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <70EC82CA-FDA3-46E6-94B0-AB25939C375F@telus.net> Topicbox-Message-UUID: 613b14fc-ead1-11e9-9d60-3106f5b1d025 > > > > OOP isn't pointless - but most supposed OOP code is just a poor > > excuse not to understand your flow control. My annoyance is that the > > cult of re-use that is associated with most OOP proselytization makes > > the code bloat hugely - I'm as guilty of that as the next guy. > > Compare the STL hash implementation with the the elf hash table > > implementation - the latter works in 20 lines of code, the former > > requires 769 lines of near-opaque code. Sure, it extends to any > > object you have, but the development cost was huge. It's good to > > have it, but then people mimic that style with substantially less re- > > usable constructs that aren't nearly as functionally stable as > > hash_map and hash_set. > > you're really on to something here. > > 768/20 ~= 40. that may be a good proof that hash tables can't be abstracted from > the stuff hashed. > > i'm not convinced by OOP -- at least in the sense that leads to STL hash tables. I don't understand why people say OOP and STL in the same sentence. Just because code is encapsulated and isolated to a class, does not make that code OO. In fact, currently, none of the STL classes are even safe to derive new classes from, based on the fact that none of them have virtual destructors. I'd call STL containers and algorithms an attempt at parametric polymorphism which has been handled better in almost any Functional Programming language I've ever seen than in C++. > > interfaces like those provided by plan 9 fileservers are much more compelling. > /dev/draw seems to me much more object-oriented than anything i've seen in > c++ or java. it's ironic that the oop crowd seems to be the biggest poo-pooers > of plan 9. > I know people who think files should be for files, and that's it. That abstracting the filesystem to mean anything else is almost as bad as overloading operators in C++. I can kind of understand the complaint. in C++ for example you've got things like C = A + B; If A and B are objects of classes, this could mean a lot of different things as you must define operator + for that class. A and B don't even have to be of the same classes, and the same goes for C. Without knowing about the data types, it's not really possible to know all the possible side effects, exceptions, allocations (needless copies that might be immediately thrown out and how different compilers might interpret those) etc for a single expression. In fact there are a lot of different function calls and code paths that could imply. The same might be said (though I think with less confusion) when someone says: echo eject > /dev/ could be confusing because the file interface and syntax by which we operate on it is also overloaded. Now think about Mac OS X again. Sure it's unix underneath, but does grandma even know or care about that? Probably not. One of my best friends is a graphic artist who uses it every day. He asked me about Terminal.app one day (which would get him a shell and expose him to a whole other world of functionality). I told him to ignore it, that for him, it'd be opening up the wrong can of worms. For some, ignorance really is bliss. And never needing to touch the shell and still be productive is actually a dream come true. Dave > - erik >