"..two simple reasons: the web and class libraries (C++ and Java, among others."
Yup. Writing gui's used to be incredibly mungy, using the Windows API/MFC, or Xlib/Xt. (Motif was OK). Now, however, we've got Java Swing, Qt, Tk, Gtk+, wxWin, and Delhi/C++ Builder's VCL (very nice to use even without the ide tools). All of these libraries make it simple to write gui apps in code, without using wizards. (Of course, Delphi comes with wizards also).
I think you hit the nail on the head. These tools tend to be great at one specific thing, but not very flexible.
One of the things these tools do is generate code. Code generators can be fairly brittle -- great for one-off jobs, but difficult to maintain.
I think Delphi has the best approach. Delphi generates very little code, just stubs and stuff. All the graphical info is saved in some sort of resource file that gets linked into the.exe. It's data, not code.
I think that 4GL tools still have a place for developing quick guis. We're starting to see really thin clients that are often generated by tools (like JBuilder or Visual Cafe), which talk to EJB or CORBA middle-ware stuff written in a tradional programming lanugages like C++, Java, Python, etc.
I do wonder, though, if Qt would attract more Windows developers with a lower license fee. Of course Qt has the right to charge whatever they want, and if you know that you're going to be selling something commercially, the price is not that much. But I'm thinking of the Windows hackers who shell out their own money for a copy of Visual C++, VB, Delphi, etc. (I used to be one of them, before I converted to Linux/Open Source). Troll Tech might make up in volume what they lose in price.
Also, a lot of Qt/Kde developers might release free as in beer versions of their apps for Windows, if the Qt license didn't cost that much.
"In Java, keeping a resource for the entire lifetime of an object is bad programming style since you cannot know for sure when the object is going to be destroyed or even when it gets out of scope (potentially a long time). That's why it would be bad style in Java to release resources in the destructor (you needlessly occupy resources)."
Exactly. I know that -- in Java you don't know exactly when destructors will be called, so you can't use them to manage resources. You can't truly encapsulate a resource as an object via Java. I'm not saying I would try to do this in Java. I might want to, but I can't. In Java, if you needed to control exactly when a resource gets freed (and this happens, especially for non-memory related resources), you have to use try..finally, not the destructor (since it won't do what you want). C++ is nicer than Java is this respect.
Please tell me where I have made inaccurate statements about Java. I think I understand Java's approach to resource allocation, destructors, etc., pretty well.
"I don't see how the destructor mechanism guarantees anything since you still have to make sure it is called yourself."
In C++, the destructor is ALWAYS called when the object goes out of scope. You NEVER have to call destructors yourself; it's usually considered very bad form to do so. That's why destructors provide a guarantee in C++. So, you don't need try...finally in C++ -- the destructor takes the place of the finally block. Destructors are always called (guaranteed), and you know exactly when they will be called. You can accomplish the same thing in Java with try...finally, but you have to litter your code with try...finally blocks. In C++, a resource is encapsulated as an object, and you only have to write the cleanup code in the destructor once. And you NEVER have to call it yourself. I repeat -- you do NOT have to make sure its called yourself. Destructors are automatically called when the variable goes out of scope.
I'm not sure how pointing out the differences between Java and C++ regarding resource handling (and having an accurate understading of those differences) translates into trying to do C++ style programming in Java. Undestanding the differences between the two languages would seem to be the way to AVOID misapplying approaches that are appropriate in one language to the other. Perhaps if I misunderstood C++ as much as you do, that would make me a more "Java" style programmer?
"Obviously you are unaware of the finalize method you can declare to do exactly what you want."
I think he wants to be able to ensure that a resource gets freed immediately when an object goes out of scope. You can't do that with finalize. Finalize just guarantees that the resource will get freed sometime.
For example, lets say I have an object that opens a file. I could use finalize to make sure the file gets closed, but I'm not sure when that's going to happen. That file might be and important resource that I want to get freed immediately after my object goes out of scope (and can't possibly use the file anymore), so that other objects can open the file. C++'s destructor mechanism guarantees that; finalize just guarantees that the file will be closed sometime before the program exits.
"I protest against your qualification of Java as a 'dumbed down' language."
Fair enough. Java is a good, and powerful language. I personally enjoy programming in C++ more, since it has some features, like templates and the STL, that I really like.
You're right Java packages and C++ namespaces are not exactly the same. Java's packages has some nice things about it, like package-local variables. I think this is similar to using file-local static (or anonymous namespace) variables in C/C++, but better since it's not dependent on the header/source file distinction. On the other hand, C++ namespaces are a completely logically concept that allow you to spread a namespace across multiple files and directories as one sees fit (but of course one could misuse this feature).
I don't see what the big deal is over Java interfaces versus C++ pure virtual classes. They are exactly the same concept. The slight difference, as you mention, is that a Java interfaces may not contain implementation. But you can achieve the same effect in C++ just by not putting any implementation into your pure base class. Java makes this explicit, yes, so score one point for Java. On the other hand, C++ lets you build up incrementally to a concrete class, adding some more implementation in each derived (but still abstract) class. So, C++ gets a point for flexibility.
Interfaces are not a feature that Java has and C++ lacks. Both languages support the concept, with some syntatic differences. Arguing which approach is better is hair-splitting. Interspaces exist in Java to make up for a feature that C++ has and Java doesn't -- multiple inheritence. The Java approach is simpler and less prone to abuse. The C++ approach offers more flexibility, if used properly. In general, where C++ opts for power and flexibility, at the cost of added complexity, Java opts for simplicity, at the cost of some power and flexibility. Java is gradually getting more and more complicated, however. The newest version of the Java "standard" is several times the size of the C++ standard.
"The crux is that you filter all pointers that end up as UNDEFINED, from lists in the variable association list. The C++ version had to take out the pointers of arrays in derived classes one by one which led to quadratic behavior.)"
Um, are you aware of the fact that C++ has an association list type, std::map?
The guy responding to you was pretty harsh. But, he was essentially correct. The contorted examples you gave really did indicate that you don't understand (or prefer not to use) the newer elements in C++ like templates, function objects and the STL.
However, I don't think that anyone is saying that C++ is the perfect language for everything. For dynamic tweakability, it's hard to beat lisp dialects (look at the success of Emacs) or Python, as you indicate. I might even go so far as to say that one should prefer simpler, dynamic languages except in areas where performance becomes and issuue. That's why it's often good to use two languages on a project -- a fast language for the 'engine', and a dynamic language that supports easy configuration for the rest.
"Packages [in Java] can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages)."
It's the same with namespaces in C++:
namespace Foo { class Bob {}; }
namespace Bar { class Bob; }
Namespaces can also be nested. They're not quite the same as Java packages (namespaces are strictly a logical concept, and can be spread across several files), but still they are very useful.
Personally, I enjoy coding in C++ more than Java, mainly because of templates and the STL. The STL really changes ones approach to programing. Java's lack of template is a significant omission to me. I also appreciate the static type checking in C++. I don't see what the big deal is with interfaces vs. abstract classes -- they are equivalent concepts.
It seems that your argument is that people who don't know what they are doing can screw up worse in C++ than they can in Java. This is probably true, and I can see why corporations would prefer a "dumbed down" language. But, I do know what I'm doing, and I prefer using a language that gives me lots of options.
My biggest gripe with Java is that is proprietary. I prefer using a language that isn't controlled by a single company.
The biggest problem with C++ is the way that most programmers use it -- using c strings instead of std::string, c arrays instead of vectors, etc. This is a matter of education.
Do you foresee any major or minor additions to the Standard C++ library in five years? Minor additions might include hash_map, hash_set; major additions could include automatic garbage collection, serialization, meta-programming thingies like reflection.
o Iterators don't know about their container objects
How is this a problem? The idea with iterators is that that you don't need to know about the containers to write algorithms that use them; you just need to know about the iterators. If you find yourself wanting to get at the container from the iterator, something is probably wrong with your algorithm, or understanding of the STL.
o The incompatability between STL iterators and, say, string
iterators
The string class was implemented before the STL proper. This main explain part of the problem. I wish the string class had been completely rewritten with the STL in mind, instead of just retrofitted. But, this would have broken backwards-compatibility. The string class is my least favorite part of the C++ Standard Library.
o Missing operator+/operator- on non-random access iterators (yes, I know about advance)
The idea is that things that could be very inefficient won't compile using the obvious approach, like trying to do random access style arithmetic on non-random access iterators. Of course, you could write your own one-line + operator that used advance.
I agree with you on the string class, but not on the other two. I'm glad that operator+ doesn't work on non-random access iterators. But, you're not happy about it. This is obviously one area where you can't please everyone.
--
Some little people have music in them, but Fats, he was all music, and you know how big he was. -- James P. Johnson
-- Steve Molitor smolitor@erac.com "Emacs is the Computer"
You need some intellectual shortcuts to make these decisions.
True enough. But one of the best things about the book is the resources section at the end, giving pointers on where to learn more when you need to. Also, this book serves as a good intellectual shortcut -- it gives short descriptions of lots of different approaches and techniques (XP, Test First Design, prototypes vs. tracer bullets, etc.), so you can pick the approach that makes the most sense for you and then go to the resources section for more info.
2. "Pragmatism" is sometimes a code word for "I have no values, morals or ethics ". I just do "whatever works" and I don't worry about any kind of idealistic consistency.
The title put me off a little also. But the book really does have some core beliefs about programming. It says that programming is a noble craft worth learning well, that clarity, simplicity and flexibility are important.
-- Steve Molitor smolitor@erac.com "Emacs is the Computer"
Would it be possible to run the server and client on the same box..
I don't think so. You might be able to run something like VMware to boot an NT session, and then connect from the Linux session to the Windows session, but there wouldn't be much point to that, since you could already run Windows programs from the VMWare windows session.
-- Steve Molitor smolitor@erac.com "Emacs is the Computer"
However, how do you do these unit test thingies for User Interface? A lot of the testing theory in XP is based on the assumption that test results are quantifiable (i.e. the 'leave it at 100% testing accuracy so the next team know what broke' stuff) and automated. How do we do this for UI?
I think this is a common problem. I don't know much about this myself, since I'm working on the middle-ware portion of a 3-tier project. But, at least on our project, the testing people always have trouble setting up automated regression tests for the gui. If someone changes the layout of the screen, all the old tests fail. I don't know if they're using the testing tool wrong, or what. Does anyone have any experience with this problem?
-- Steve Molitor smolitor@erac.com "Emacs is the Computer"
...but C was the property of AT&T and quite controlled by AT&T (mainly Richie) until well after the standards process was in full swing. Anyone see the early release of the "2nd edition K&R"? It is full of not quite polite footnotes about stupid things that were just wrong from the ANSI C committee. Most of those things are not in the current ANSI C. Sun could do the same thing with Java if they chose too.
Part of the problem with C was that Dennis Ritchie was not involved in the standardization process; Bjarne Stroustrup headed up the C++ standardization effort.
-- Steve Molitor smolitor@erac.com "Emacs is the Computer"
You picked a really bad example. GCC was way behind in C++ compared to egcs. If there hadn't been a fork, we may never had gotten a decent C++ compiler. Of course, you may not like C++. But it's a widely used, important language that many open source projects depend on. In the end, of course, gcc and egcs merged back together. I can't see anything but good stuff resulting from the fork.
Most software written is custom software written in-house, or contracted out but written specifically for the company's needs. This stuff will continue no matter what.
What's the best book for experienced Linux users and programmers? I thinking of something like a Linux "Bible", one place to go to look up info on sticky configuration issues and other stuff.
Will this force Qt to lower the price for the Windows version of their library? Right now, Qt is really the only slick and modern compiled (i.e. besides Java) widget library that runs on both Windows and Linux, so they can charge a lot for it (> $1000 for the Windows version -- of course the [LU]inux version is free). But Delphi/C++ Builder on Windows goes for $99 - $400 (depending on the flavor), and it's a lot more than just a widget library.
The article said the Linux version would "share the visual component library within their frameworks." On Windows, the VCL is a native widget library (among other things), so I guess they'll be native on Linux too. But that's just a guess!
The VCL wraps a few Windows common controls, like file and print dialogs. I'm not sure what they'll do about those on Linux, since Gnome and KDE have different common controls.
...according to Dvorak. Try telling that to HR people trying to find programmers to hire. It should be easy, according to Dvorak.
The nature of the computer business is shitfting, however. Shifting away from shrink-wrapped software and into custom solutions, and open source.
"Without the Net, the computer business would have been in the toilet years ago." What a stupid statement. That's like saying without railroads, the locomotive engine would have died out.
Slashdot Mirror
"..two simple reasons: the web and class libraries (C++ and Java, among others."
Yup. Writing gui's used to be incredibly mungy, using the Windows API/MFC, or Xlib/Xt. (Motif was OK). Now, however, we've got Java Swing, Qt, Tk, Gtk+, wxWin, and Delhi/C++ Builder's VCL (very nice to use even without the ide tools). All of these libraries make it simple to write gui apps in code, without using wizards. (Of course, Delphi comes with wizards also).
I think you hit the nail on the head. These tools tend to be great at one specific thing, but not very flexible.
.exe. It's data, not code.
One of the things these tools do is generate code. Code generators can be fairly brittle -- great for one-off jobs, but difficult to maintain.
I think Delphi has the best approach. Delphi generates very little code, just stubs and stuff. All the graphical info is saved in some sort of resource file that gets linked into the
I think that 4GL tools still have a place for developing quick guis. We're starting to see really thin clients that are often generated by tools (like JBuilder or Visual Cafe), which talk to EJB or CORBA middle-ware stuff written in a tradional programming lanugages like C++, Java, Python, etc.
Yes.
I do wonder, though, if Qt would attract more Windows developers with a lower license fee. Of course Qt has the right to charge whatever they want, and if you know that you're going to be selling something commercially, the price is not that much. But I'm thinking of the Windows hackers who shell out their own money for a copy of Visual C++, VB, Delphi, etc. (I used to be one of them, before I converted to Linux/Open Source). Troll Tech might make up in volume what they lose in price.
Also, a lot of Qt/Kde developers might release free as in beer versions of their apps for Windows, if the Qt license didn't cost that much.
Doxygen and DOC++ are available. They're like javadoc for C++, I assume they would work for straight C.
They're both GPL, I believe.
I use Doxygen on my projects; it works out pretty well.
I think KDE uses something called KDOC, which is built on doxygen.
"In Java, keeping a resource for the entire lifetime of an object is bad programming style since you cannot know for sure when the object is going to be destroyed or even when it gets out of scope (potentially a long time). That's why it would be bad style in Java to release resources in the destructor (you needlessly occupy resources)."
Exactly. I know that -- in Java you don't know exactly when destructors will be called, so you can't use them to manage resources. You can't truly encapsulate a resource as an object via Java. I'm not saying I would try to do this in Java. I might want to, but I can't. In Java, if you needed to control exactly when a resource gets freed (and this happens, especially for non-memory related resources), you have to use try..finally, not the destructor (since it won't do what you want). C++ is nicer than Java is this respect.
Please tell me where I have made inaccurate statements about Java. I think I understand Java's approach to resource allocation, destructors, etc., pretty well.
"I don't see how the destructor mechanism guarantees anything since you still have to make sure it is called yourself."
In C++, the destructor is ALWAYS called when the object goes out of scope. You NEVER have to call destructors yourself; it's usually considered very bad form to do so. That's why destructors provide a guarantee in C++. So, you don't need try...finally in C++ -- the destructor takes the place of the finally block. Destructors are always called (guaranteed), and you know exactly when they will be called. You can accomplish the same thing in Java with try...finally, but you have to litter your code with try...finally blocks. In C++, a resource is encapsulated as an object, and you only have to write the cleanup code in the destructor once. And you NEVER have to call it yourself. I repeat -- you do NOT have to make sure its called yourself. Destructors are automatically called when the variable goes out of scope.
I'm not sure how pointing out the differences between Java and C++ regarding resource handling (and having an accurate understading of those differences) translates into trying to do C++ style programming in Java. Undestanding the differences between the two languages would seem to be the way to AVOID misapplying approaches that are appropriate in one language to the other. Perhaps if I misunderstood C++ as much as you do, that would make me a more "Java" style programmer?
"Obviously you are unaware of the finalize method you can declare to do exactly what you want."
I think he wants to be able to ensure that a resource gets freed immediately when an object goes out of scope. You can't do that with finalize. Finalize just guarantees that the resource will get freed sometime.
For example, lets say I have an object that opens a file. I could use finalize to make sure the file gets closed, but I'm not sure when that's going to happen. That file might be and important resource that I want to get freed immediately after my object goes out of scope (and can't possibly use the file anymore), so that other objects can open the file. C++'s destructor mechanism guarantees that; finalize just guarantees that the file will be closed sometime before the program exits.
"I protest against your qualification of Java as a 'dumbed down' language."
Fair enough. Java is a good, and powerful language. I personally enjoy programming in C++ more, since it has some features, like templates and the STL, that I really like.
You're right Java packages and C++ namespaces are not exactly the same. Java's packages has some nice things about it, like package-local variables. I think this is similar to using file-local static (or anonymous namespace) variables in C/C++, but better since it's not dependent on the header/source file distinction. On the other hand, C++ namespaces are a completely logically concept that allow you to spread a namespace across multiple files and directories as one sees fit (but of course one could misuse this feature).
I don't see what the big deal is over Java interfaces versus C++ pure virtual classes. They are exactly the same concept. The slight difference, as you mention, is that a Java interfaces may not contain implementation. But you can achieve the same effect in C++ just by not putting any implementation into your pure base class. Java makes this explicit, yes, so score one point for Java. On the other hand, C++ lets you build up incrementally to a concrete class, adding some more implementation in each derived (but still abstract) class. So, C++ gets a point for flexibility.
Interfaces are not a feature that Java has and C++ lacks. Both languages support the concept, with some syntatic differences. Arguing which approach is better is hair-splitting. Interspaces exist in Java to make up for a feature that C++ has and Java doesn't -- multiple inheritence. The Java approach is simpler and less prone to abuse. The C++ approach offers more flexibility, if used properly. In general, where C++ opts for power and flexibility, at the cost of added complexity, Java opts for simplicity, at the cost of some power and flexibility. Java is gradually getting more and more complicated, however. The newest version of the Java "standard" is several times the size of the C++ standard.
"The crux is that you filter all pointers that end up as UNDEFINED,
from lists in the variable association list. The C++ version had to
take out the pointers of arrays in derived classes one by one which
led to quadratic behavior.)"
Um, are you aware of the fact that C++ has an association list type, std::map?
The guy responding to you was pretty harsh. But, he was essentially correct. The contorted examples you gave really did indicate that you don't understand (or prefer not to use) the newer elements in C++ like templates, function objects and the STL.
However, I don't think that anyone is saying that C++ is the perfect language for everything. For dynamic tweakability, it's hard to beat lisp dialects (look at the success of Emacs) or Python, as you indicate. I might even go so far as to say that one should prefer simpler, dynamic languages except in areas where performance becomes and issuue. That's why it's often good to use two languages on a project -- a fast language for the 'engine', and a dynamic language that supports easy configuration for the rest.
You said:
"Packages [in Java] can be nested and the package is part of the class name (which makes it possible to have class names with the same name in different packages)."
It's the same with namespaces in C++:
namespace Foo {
class Bob {};
}
namespace Bar {
class Bob;
}
Namespaces can also be nested. They're not quite the same as Java packages (namespaces are strictly a logical concept, and can be spread across several files), but still they are very useful.
Personally, I enjoy coding in C++ more than Java, mainly because of templates and the STL. The STL really changes ones approach to programing. Java's lack of template is a significant omission to me. I also appreciate the static type checking in C++. I don't see what the big deal is with interfaces vs. abstract classes -- they are equivalent concepts.
It seems that your argument is that people who don't know what they are doing can screw up worse in C++ than they can in Java. This is probably true, and I can see why corporations would prefer a "dumbed down" language. But, I do know what I'm doing, and I prefer using a language that gives me lots of options.
My biggest gripe with Java is that is proprietary. I prefer using a language that isn't controlled by a single company.
The biggest problem with C++ is the way that most programmers use it -- using c strings instead of std::string, c arrays instead of vectors, etc. This is a matter of education.
Steve Molitor
My question:
Do you foresee any major or minor additions to the Standard C++
library in five years? Minor additions might include hash_map,
hash_set; major additions could include automatic garbage collection,
serialization, meta-programming thingies like reflection.
Thanks
How is this a problem? The idea with iterators is that that you don't need to know about the containers to write algorithms that use them; you just need to know about the iterators. If you find yourself wanting to get at the container from the iterator, something is probably wrong with your algorithm, or understanding of the STL.
iteratorsThe string class was implemented before the STL proper. This main explain part of the problem. I wish the string class had been completely rewritten with the STL in mind, instead of just retrofitted. But, this would have broken backwards-compatibility. The string class is my least favorite part of the C++ Standard Library.
The idea is that things that could be very inefficient won't compile using the obvious approach, like trying to do random access style arithmetic on non-random access iterators. Of course, you could write your own one-line + operator that used advance.
I agree with you on the string class, but not on the other two. I'm glad that operator+ doesn't work on non-random access iterators. But, you're not happy about it. This is obviously one area where you can't please everyone.
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
True enough. But one of the best things about the book is the resources section at the end, giving pointers on where to learn more when you need to. Also, this book serves as a good intellectual shortcut -- it gives short descriptions of lots of different approaches and techniques (XP, Test First Design, prototypes vs. tracer bullets, etc.), so you can pick the approach that makes the most sense for you and then go to the resources section for more info.
The title put me off a little also. But the book really does have some core beliefs about programming. It says that programming is a noble craft worth learning well, that clarity, simplicity and flexibility are important.
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
I don't think so. You might be able to run something like VMware to boot an NT session, and then connect from the Linux session to the Windows session, but there wouldn't be much point to that, since you could already run Windows programs from the VMWare windows session.
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
I think this is a common problem. I don't know much about this myself, since I'm working on the middle-ware portion of a 3-tier project. But, at least on our project, the testing people always have trouble setting up automated regression tests for the gui. If someone changes the layout of the screen, all the old tests fail. I don't know if they're using the testing tool wrong, or what. Does anyone have any experience with this problem?
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
Part of the problem with C was that Dennis Ritchie was not involved in the standardization process; Bjarne Stroustrup headed up the C++ standardization effort.
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
You picked a really bad example. GCC was way behind in C++ compared to egcs. If there hadn't been a fork, we may never had gotten a decent C++ compiler. Of course, you may not like C++. But it's a widely used, important language that many open source projects depend on. In the end, of course, gcc and egcs merged back together. I can't see anything but good stuff resulting from the fork.
Most software written is custom software written in-house, or contracted out but written specifically for the company's needs. This stuff will continue no matter what.
What's the best book for experienced Linux users and programmers? I thinking of something like a Linux "Bible", one place to go to look up info on sticky configuration issues and other stuff.
Any opinions?
Limited in what way? It seems pretty flexible to me.
Will this force Qt to lower the price for the Windows version of their library? Right now, Qt is really the only slick and modern compiled (i.e. besides Java) widget library that runs on both Windows and Linux, so they can charge a lot for it (> $1000 for the Windows version -- of course the [LU]inux version is free). But Delphi/C++ Builder on Windows goes for $99 - $400 (depending on the flavor), and it's a lot more than just a widget library.
The article said the Linux version would "share the visual component library within their frameworks." On Windows, the VCL is a native widget library (among other things), so I guess they'll be native on Linux too. But that's just a guess!
The VCL wraps a few Windows common controls, like file and print dialogs. I'm not sure what they'll do about those on Linux, since Gnome and KDE have different common controls.
"one of the reason why you don't find so much tools like javadoc for c++)" --
Doxygen, Doc++ and KDoc are all variations of Javadoc for C++.
...according to Dvorak. Try telling that to HR people trying to find programmers to hire. It should be easy, according to Dvorak.
The nature of the computer business is shitfting, however. Shifting away from shrink-wrapped software and into custom solutions, and open source.
"Without the Net, the computer business would have been in the toilet years ago." What a stupid statement. That's like saying without railroads, the locomotive engine would have died out.