According to my C - A Reference Manual, 4th Ed by Harbison and Steele, the FILE psuedo-object is part of the C language specification. I cannot actually create a completely opaque object in C. I cannot derive a myFILE pseudo-object that extends the FILE psuedo-object. I do agree that you can create a mostly opaque object in C.
GTK widgets are implemented in an object oriented fashion.
However, they are implemented in standard C. This greatly improves portability and stability over using current generation C++ compilers; however, it does mean that the widget writer has to pay attention to some of the implementation details. The information common to all instances of one class of widgets (e.g., to all Button widgets) is stored in the class structure.
The bold emphasis is mine and underscores my point. GTK/GTK+ is written in C which does not support syntactic OO. Sure, you can put any sort of OO wrapper on top of C and call it "object-oriented", but I wonder why C++ or Java or any object-oriented language was invented? Why not write everything in C?
Notice too that the if you use the GTK+ widget library, you have to pay attention to some of the implementation details. In a object-oriented language, I do not have to pay attention to any implementation details. This save me time (and money) when I build my program.
IMHO - forcing C into an object-oriented paradigm is a waste of time because you end up writing so much code to support it, rather than letting the language specification deal with the implementation details. Given this point, I wonder if an object-oriented C is actually object-oriented at all, since you have to write a library to support your "version" of object-oriented. In this case, there is no guarantee (via language specification) that the object-oriented C library that I write tommorrow will work with your object-oriented C library. This is the point of object-oriented languages such as Java or C++. So, if you want objects, I think you are better off to use an object-oriented language.
The C language cannot solve every programming problem in a reasonable manner. IMHO, it is not reasonable to reinvent an "object-oriented" library that is not supported by the language specification.
Good points. I gave my understanding of the commonly "accepted" tenets of OO. BTW-I have implemented OO systems in Java, not C++.
The black box is not a requirement, only an example. The example was to illustrate the concept of encapsulation -- something ANSI/ISO C just cannot do.
As far as multi-dispatched - What about the observer-observable pattern? I was not aware that message systems required a particular cardinality of recipients.
Finally, some of your Eiffel examples only seem to refine the some of the points I made previously. For example, the notion of a class is 'encapsulation'. The pre/post/invariants have been suggested for procedural programming (my CS 101 Pascal book from 1989). The granularity of access does not take away the fact that OO systems restrict access (regardless of the levels of restriction).
Caveat emptor - I do speak out of ignorance because I know nothing about Eiffel!
I'm well aware of that fact. KMenuBar is implemented using QMenuBar.
No you're not, otherwise you would not have said:
Speaking of which, if your wonderful object oriented system lets you reuse code, rather than reimplement it, why does KDE choose to define its own KMenuBar class?
To complain that gtk+ and gnome both have ways to display a menu is a little unfair, given that Qt and KDE do the same.
I am not complaining about a lack of options. I am complaining about the fact that KDE reuses code and GNOME reinvents it. Clearly, you do not understand the difference.
You seem to be falling into the trap, though, of thinking that gtk+ isn't object oriented just because it's written in C. In fact, it is.
I am not falling into a trap, because I know that C is not object-oriented!. There are 4 commonly accepted tenets required for a language to be object-oriented:
Abstraction
- Simply the model in question, i.e., make it more abstract to simply the building of the model.
Encapsulation
- Hide the implementation details. As the user of a class, you don't have to worry about how it works, you just use it through its interfaces as a black box.
Inheritance
- The ability to reuse components. (collary is 'polymorphism')
Messaging
- Components use messages to communicate. Passing data around to functions does not consitute a message, BTW.
I think you will agree that C only supports Abstraction. Thus, it is not object-oriented. In addition, your example of 'reuse' of the gtk_menu_new() is not actually reuse because I cannot (in C) create a derived class: johanns_gtk_menu_new() and inherit the functions from gtk_menu_new().
Nice try, but the majority (60%) of the energy from el Sol is IR (Infrared Radiation), which is not blocked out by clouds. You know IR has the type of radiation used by your remote controls. You can't see it, but it is a significant part of the spectrum. The problem is that IR is kept in by clouds when it is re-radiated. The main indicator of this re-radiation of IR is night time temperatures. This is the greenhouse effect.
You should be worried. Actually, when our generation (currently 20 - 30) is about 60, the weather and environment could be really dicey. My hope is that hydrogen will become the major energy source in the next 10 years so that greenhouse gas production drops significantly (especially for automobiles - a major cause of carbon release). If this doesn't happen, you better start praying.
Warning: Those with sarcasmaphobia should not read or moderate this post.
Well, if you consider the httpd interface, which *is* the WWW not innovative, then I would have to agree. Of course, then there's NCSA, which begat Netscape...
What about make, rcs, xmake, PERL, Python? I am sure you think some company created them, right?
How about bind, (it translates IP addresses to domain names)? I am sure another came up with that one, too. Of course you realize everyone on the planet uses some form of Berkeley Bind, right? That must be from that Berkeley, Inc. I keep hearing about.
Of course, don't think that new implementations of old ideas are not innovative, right? Like KDE or GNOME.
My point: you don't seem to be aware that a lot of (IMHO) innovative software has been created and released under the GNU General Public License (GPL). Some folks like to say 'Open Source' cause it's cute. Nevertheless, this software is innovative (technically) and your freedom to use and distribute it has not been impeded (it is, in fact, *protected* by the GPL). Wow! Seems pretty innovative to me.
Apparently, you do not understand the value of many groups working on similar projects. For example:
competition - Like it or not, developers are highly competitive. They want their code to rule.
niches - Each of the databases has a different niche. The fact is that MySQL and PostgreSQL are not comparable on numerous features. This is a matter of design philosophy, not implementation. (As an example, check out the MySQL documentation about Foreign Key constraints).
innovation - A corollary to 'competition'. How many times have you used a piece of software that begged for some innovation? Want that missing feature? Then code it. This is why Free software is so innovative - it gives you the freedom to innovate. If this means 'forking a project', then so be it.
Finally, you seem to think that just because software is Free, that means people will cooperate. There are differences in design, implementation, technical leadership. Differences cannot always be overcome 'for the good of the community'. We still are human (thank God), so we differ in our opinions.
I broke most of your rules of thumb when I wrote a web server monitoring application (in Java). It was a single developer with a simple task -- Query web servers in the field, collect their current statistics text file, parse the file, and display it in a grid inside a window application.
Thanks to the excellent Java libraries, I used sockets, threads, observer-observable to write this AWT application (they didn't want swing) in 2600 lines. IMHO, the OO patterns simplified the implementation so that it became trivial. BTW-The majority of the 2600 lines was from the chessy AWT event model. The core logic was in two classes at about 500 lines total.
Well, I work in one of those shops that has gone totally OO and is better for it. We are a financial institution and our code involves rigorous manipulation of financial data. This system was implemented in C and C++. We hired a real OO architect, converted to java, completed team designs and the result is a much better system. Since then, I have worked on other projects that utilize OOA/OOD and implement in Java. The result is faster implementation, fewer bugs, and a better translation of the business logic into code.
I was hoping you would provide some evidence for your bias against OO. What were the problems (not anecdotes) that led to your belief?
As far as your comment on OO training and relevance to the real world, I agree. Much of our success is derived from the combination of well educated and experienced engineers (I am one of the most junior engineers with 5+ years as software engineer), an experienced chief architect (who has implemented dozens of OO systems), and old fashioned elbow grease! Let me recommend one OOA/OOD book that actually has real world problems and life cycles. Applying UML and Patterns by Larman. Check it out, you may find it more useful than much of the academic OO drivel on the market.
Finally, I am not one of those folks who thinks OO is a silver bullet. I happen to model in the Relational Database arena often to know that OO and RDBMS are not a clean mix. I was as skeptical as you - until we designed and implemented a system with so few problems that it was shocking. These experiences taught me that OO is meritable and has too many positive ideas to throw out with the bath water.
Based on your reported experience with OO in C++ and your apparent disdain that OO "creates bloated, useless code", I wonder what kinds of systems were you building that caused this opinion?
My experience with OO is that depending on the lifespan of the code, OO will produce more stable and maintainable systems. Unfortunately, you have to add some up front time for analysis and design or the implementation will be poor. But, isn't this true of any system (procedural or OO)? Now, if you have a simple problem that you can solve with 50 lines of PERL, then I agree: why bother with OO implementation?
Don't take this as a flame, because I am not trolling. I am just surprized that someone with 6 years of C++ and Java. Maybe there is a lack of OOA and OOD in your shop to benefit from OO implementations? Thoughts?
Actually, you can interchange KDE and GNOME applications if you have both the QT and GTK libraries installed. For example, I can run Dia or Gimp whilst using KDE. Hell, I have run KDE applications using FVWM.
Your comment is a common misconception about the power of the X windows environment. If you want to know why, read this page.
--
The Scourge of Entitlement & Technology Whores
on
Hacker Crackdown?
·
· Score: 1
This whole RIAA-MPAA-Napster-GNUTella, et al., is starting to piss me off. How is it that programmers are to be liable for users who feel entitled to free music, movies, or whatever?
It is hard for me to understand why so many technology whores think that because some code is free, now everything related to media is free. I still have to pay for a lot of 'content', such as programming books from O'Reilly. I would not try to steal them (even if I could) because I feel they are valuable. Sure, I could go around reading the PERL man pages or Java Docs (all freely available), by I am still willing to pay legitimate authors for legitimate works.
I know, most of the Napster users are 'just trading music'. At whose expense? Based on the exaggerated Salon article, it appears that the expense of 'just trading music' will cost all of us our freedom.
Is 'free' music really worth it? I wonder...
Finally, it is ironic to me that the technology whores want the copyright laws to help them distribute their code (if the whores actually write code), yet want to abandon them for some free tunes.
P.S. I know some of you on/. are not 'technology whores', but according to the Salon article, 87% of the songs on Napster are copyrighted, so you do the math.
Although I will admit that I'd wear a t-shirt with RMS on it in the vein of those stupid Che Guevara t-shirts, especially if it looked just like the Che shirts. It'd give the commies something to think about.
Fred Moody is the author of I Sing the Body Electronic: A Year with Microsoft on the Multimedia Frontier and of The Visionary Position: The Inside Story of the Digital Dreamers Who Made Virtual Reality a Reality.
...[S]ybase will NOT load database dumps made on different platforms...
BTW - This is the case for most (all?) RDBMSes. The short answer is that binary database files (they store the data) are platform dependant.
Some RDBMSes, like Oracle, allow you to specify the block size of your binary database files. But even if you have 2 files with the same block size, they may not be transferable between databases.
There is no per-user costs for Interbase 6.0. According to their new license, you are free to distribute and modify the database.
Interbase does provide optional support contracts. Last I looked it was US$100 for 30 days of installation support, US$250 per support incident, or US$3150 per year for unlimited support.
Slashdot Mirror
According to my C - A Reference Manual, 4th Ed by Harbison and Steele, the FILE psuedo-object is part of the C language specification. I cannot actually create a completely opaque object in C. I cannot derive a myFILE pseudo-object that extends the FILE psuedo-object. I do agree that you can create a mostly opaque object in C.
--
Notice too that the if you use the GTK+ widget library, you have to pay attention to some of the implementation details. In a object-oriented language, I do not have to pay attention to any implementation details. This save me time (and money) when I build my program.
IMHO - forcing C into an object-oriented paradigm is a waste of time because you end up writing so much code to support it, rather than letting the language specification deal with the implementation details. Given this point, I wonder if an object-oriented C is actually object-oriented at all, since you have to write a library to support your "version" of object-oriented. In this case, there is no guarantee (via language specification) that the object-oriented C library that I write tommorrow will work with your object-oriented C library. This is the point of object-oriented languages such as Java or C++. So, if you want objects, I think you are better off to use an object-oriented language.
The C language cannot solve every programming problem in a reasonable manner. IMHO, it is not reasonable to reinvent an "object-oriented" library that is not supported by the language specification.
Later
--
Good points. I gave my understanding of the commonly "accepted" tenets of OO. BTW-I have implemented OO systems in Java, not C++.
The black box is not a requirement, only an example. The example was to illustrate the concept of encapsulation -- something ANSI/ISO C just cannot do.
As far as multi-dispatched - What about the observer-observable pattern? I was not aware that message systems required a particular cardinality of recipients.
Finally, some of your Eiffel examples only seem to refine the some of the points I made previously. For example, the notion of a class is 'encapsulation'. The pre/post/invariants have been suggested for procedural programming (my CS 101 Pascal book from 1989). The granularity of access does not take away the fact that OO systems restrict access (regardless of the levels of restriction).
Caveat emptor - I do speak out of ignorance because I know nothing about Eiffel!
--
No you're not, otherwise you would not have said:
To complain that gtk+ and gnome both have ways to display a menu is a little unfair, given that Qt and KDE do the same.
I am not complaining about a lack of options. I am complaining about the fact that KDE reuses code and GNOME reinvents it. Clearly, you do not understand the difference.
--
I am not falling into a trap, because I know that C is not object-oriented!. There are 4 commonly accepted tenets required for a language to be object-oriented:
I think you will agree that C only supports Abstraction. Thus, it is not object-oriented. In addition, your example of 'reuse' of the gtk_menu_new() is not actually reuse because I cannot (in C) create a derived class: johanns_gtk_menu_new() and inherit the functions from gtk_menu_new().
Later
--
Nice try, but the majority (60%) of the energy from el Sol is IR (Infrared Radiation), which is not blocked out by clouds. You know IR has the type of radiation used by your remote controls. You can't see it, but it is a significant part of the spectrum. The problem is that IR is kept in by clouds when it is re-radiated. The main indicator of this re-radiation of IR is night time temperatures. This is the greenhouse effect.
You should be worried. Actually, when our generation (currently 20 - 30) is about 60, the weather and environment could be really dicey. My hope is that hydrogen will become the major energy source in the next 10 years so that greenhouse gas production drops significantly (especially for automobiles - a major cause of carbon release). If this doesn't happen, you better start praying.
--
Well, if you consider the httpd interface, which *is* the WWW not innovative, then I would have to agree. Of course, then there's NCSA, which begat Netscape...
What about make, rcs, xmake, PERL, Python? I am sure you think some company created them, right?
How about bind, (it translates IP addresses to domain names)? I am sure another came up with that one, too. Of course you realize everyone on the planet uses some form of Berkeley Bind, right? That must be from that Berkeley, Inc. I keep hearing about.
Of course, don't think that new implementations of old ideas are not innovative, right? Like KDE or GNOME.
My point: you don't seem to be aware that a lot of (IMHO) innovative software has been created and released under the GNU General Public License (GPL). Some folks like to say 'Open Source' cause it's cute. Nevertheless, this software is innovative (technically) and your freedom to use and distribute it has not been impeded (it is, in fact, *protected* by the GPL). Wow! Seems pretty innovative to me.
--
Apparently, you do not understand the value of many groups working on similar projects. For example:
Finally, you seem to think that just because software is Free, that means people will cooperate. There are differences in design, implementation, technical leadership. Differences cannot always be overcome 'for the good of the community'. We still are human (thank God), so we differ in our opinions.
--
Suck. I love the name. It's interesting (and unoriginal?) that Business Week did a story about this topic on July 17, 2000.
--
I broke most of your rules of thumb when I wrote a web server monitoring application (in Java). It was a single developer with a simple task -- Query web servers in the field, collect their current statistics text file, parse the file, and display it in a grid inside a window application.
Thanks to the excellent Java libraries, I used sockets, threads, observer-observable to write this AWT application (they didn't want swing) in 2600 lines. IMHO, the OO patterns simplified the implementation so that it became trivial. BTW-The majority of the 2600 lines was from the chessy AWT event model. The core logic was in two classes at about 500 lines total.
--
Well, I work in one of those shops that has gone totally OO and is better for it. We are a financial institution and our code involves rigorous manipulation of financial data. This system was implemented in C and C++. We hired a real OO architect, converted to java, completed team designs and the result is a much better system. Since then, I have worked on other projects that utilize OOA/OOD and implement in Java. The result is faster implementation, fewer bugs, and a better translation of the business logic into code.
I was hoping you would provide some evidence for your bias against OO. What were the problems (not anecdotes) that led to your belief?
As far as your comment on OO training and relevance to the real world, I agree. Much of our success is derived from the combination of well educated and experienced engineers (I am one of the most junior engineers with 5+ years as software engineer), an experienced chief architect (who has implemented dozens of OO systems), and old fashioned elbow grease! Let me recommend one OOA/OOD book that actually has real world problems and life cycles. Applying UML and Patterns by Larman. Check it out, you may find it more useful than much of the academic OO drivel on the market.
Finally, I am not one of those folks who thinks OO is a silver bullet. I happen to model in the Relational Database arena often to know that OO and RDBMS are not a clean mix. I was as skeptical as you - until we designed and implemented a system with so few problems that it was shocking. These experiences taught me that OO is meritable and has too many positive ideas to throw out with the bath water.
Later.
--
Based on your reported experience with OO in C++ and your apparent disdain that OO "creates bloated, useless code", I wonder what kinds of systems were you building that caused this opinion?
My experience with OO is that depending on the lifespan of the code, OO will produce more stable and maintainable systems. Unfortunately, you have to add some up front time for analysis and design or the implementation will be poor. But, isn't this true of any system (procedural or OO)? Now, if you have a simple problem that you can solve with 50 lines of PERL, then I agree: why bother with OO implementation?
Don't take this as a flame, because I am not trolling. I am just surprized that someone with 6 years of C++ and Java. Maybe there is a lack of OOA and OOD in your shop to benefit from OO implementations? Thoughts?
--
Want more on 'society', try NPR. Or one of the hundreds of news / society sites on the net.
BTW, what is "Yes we should just be beated down!" supposed to mean?
--
Valid point.
--
Considering the number of comments in this story relative to /. HOF, then this story does not 'got lots of comments'.
--
Does this story *really* fit into 'News for Nerds. Stuff that matters.'?
--
Actually, you can interchange KDE and GNOME applications if you have both the QT and GTK libraries installed. For example, I can run Dia or Gimp whilst using KDE. Hell, I have run KDE applications using FVWM.
Your comment is a common misconception about the power of the X windows environment. If you want to know why, read this page.
--
This whole RIAA-MPAA-Napster-GNUTella, et al., is starting to piss me off. How is it that programmers are to be liable for users who feel entitled to free music, movies, or whatever?
It is hard for me to understand why so many technology whores think that because some code is free, now everything related to media is free. I still have to pay for a lot of 'content', such as programming books from O'Reilly. I would not try to steal them (even if I could) because I feel they are valuable. Sure, I could go around reading the PERL man pages or Java Docs (all freely available), by I am still willing to pay legitimate authors for legitimate works.
I know, most of the Napster users are 'just trading music'. At whose expense? Based on the exaggerated Salon article, it appears that the expense of 'just trading music' will cost all of us our freedom.
Is 'free' music really worth it? I wonder...
Finally, it is ironic to me that the technology whores want the copyright laws to help them distribute their code (if the whores actually write code), yet want to abandon them for some free tunes.
P.S. I know some of you on /. are not 'technology whores', but according to the Salon article, 87% of the songs on Napster are copyrighted, so you do the math.
--
LOL! Moderate this up! You're killing me!
--
Hi, I'm Fred Moody. I am a tool.
--
Oh yeah? Well, I coded it in assembler when I was 3. :-)
--
Worried about security? Then don't use this system.
--
BTW - This is the case for most (all?) RDBMSes. The short answer is that binary database files (they store the data) are platform dependant.
Some RDBMSes, like Oracle, allow you to specify the block size of your binary database files. But even if you have 2 files with the same block size, they may not be transferable between databases.
--
There is no per-user costs for Interbase 6.0. According to their new license, you are free to distribute and modify the database.
Interbase does provide optional support contracts. Last I looked it was US$100 for 30 days of installation support, US$250 per support incident, or US$3150 per year for unlimited support.
Refer to Interbase.com for more details.
--
FWIW - PHP 4.0 also supports native Interbase connections.
--