Um, this is a joke, right? You teach at Harvard!!??? Now I know why we're losing all our jobs to offshoring. If this the best 'teaching' our educational system produce, we're really in trouble.
Seriously, it sound like your objections are just based on laziness - you don't want to look at extra code, documentation, etc. Too much work for you. Oh, that's another reason we're losing to offshore folks - laziness.
I guess we're illogical too. What does documentation have to do with unit testing? Can't you do one without the other???
My management is thinking of doing parallel development of the same app, with two teams in the U.S. (working in two different locations about 20 miles apart), and one or two teams working in India. Each team would simultaneously be working on different part of the same app. The project manager and users would be in the U.S. The app is a rewrite of a large legacy app. It will be rewritten in Java, JSP, servlets, EJB's, Oracle, etc.
Does anyone have any experience with this kind of approach?
Try JDE (Java Development Environment for Emacs). I've heard lots of great things about it. Don't let the fact that it works with emacs scare you away -- it seems really full featured -- stepping through code in multiple processes, class hierarchy displays, javadoc documentation for a class by hitting a hot key, etc.
OK, I totally agree with that. As long as you follow the OnceAndOnlyOnce rule rigorously, everything's kosher.
On a side note:
One legitimate criticism of 'classic' OO is that it places too much emphasis inheritence hierarchies. Some kinds of behavior, however, occurs at 'right angles' to the inheritence hierarchy. Common algorithms like sorting, or policy things like error logging, transactions, etc. These things tend to occurr all over the place, but don't always have a clear place in the inheritence hierarchy. Generic programming (templates) and aspect-oriented programming are two attempts to mitigate this problem; I think they hold a lot of promise.
"Specific is good, generic is bad. Building generic stuff takes longer and makes for unreadable code - don't do it unless you need it."
Really??? I think that generic programming is the missing key to effective code reuse. If I find myself sorting things over and over again, shouldn't I abstract that out into a generic sort algorithm, instead of having similar (but not identical) code littered all over the place? The latter would be a maintenence nightmare. If there's a bug in you're approach to sorting, you have to change it everywhere. It violates the OnceAndOnlyOnce rule.
Admittedly, coming up with something generic right up front is hard, and shouldn't be attempted. But refactoring similar code into generic functions or classes is a good thing.
Generic programming is orthogonal to OO programming. In OO, you try to capture business (and other) entities as objects -- Customer, Order, Item, etc. Generic programming lets you capture the abstractions that tend to occur at right angles to your business classes. For example, sorting customers, sorting orders, sorting items -- why not capture sorting as its own abtraction, rather than reimplementing CustomersList.sort(), OrdersList.sort(), ItemsList.sort(), etc? Wouldn't having one generic sort function that can do 'sort(CustomersList)', 'sort(OrdersList)', etc., be better? Aside from the code sharing issue, it's just cleaner to have one 'sort' abtraction.
Oh, and polymorphism over types is actually an instance of generic programming -- many different types have the same interface, so you can write a another method that takes the base type, and it operates on all the sub-types. It's generic.
I thought it was a very poorly written article. There are a lot of problems with OO that need exposing, but this article didn't do it.
For example, he gave two code examples, showing how one might calculate a tax using OO and procedural programming:
// BAD, COMPLICATED OO APPROACH///////////
Person P = new Person("Fred")
Tax T = new Tax()
// assign attributes to our person
P.x = foo
P.y = bar
P.z = blah()
// display tax amount
output T.calcTax(P)
He complains that the OO approach requires you to understand the Person class, and is more verbose. Regarding the latter, the OO code could look like this, using the Person constructor:
Person p("Fred", foo, bar);
Tax t;
output t.calcTax(p);
Or even:
output Tax(Person("Fred", foo, bar)).calcTax().
So, the OO approach needn't be that much more wordy that the procedural approach. In many cases, it's more concise.
Now on to the more substantial criticism, that the OO approach requires you to understand the Person class to calculate the tax. Well, the procedural approach requires you to understand the parameters to the calcTax() function, and to remember the proper order for the parameters. And, the parameters you pass to the calcTax() function are in essence the attributes of a person necessary to calculate the tax -- so conceptually, you have to know just as much about people and taxes in either approach. The OO approach just seperates the concept of Person from the concept of Tax more explicitly. If you change the way that you identify a person (perhaps by SSN or employee id instead by name), you change the person class, but neither the interface nor the implementation of the Tax class needs to change. For example:
Person p(1234);// construct from person key
Tax t(p);
t.calcTaxes();
In the procedural approach, the calcTaxes function would have to change.
There are many limitations of OO. The book "Generic Programming" discussed many of them, and demonstrates how generic programming tools (templates, code generators, etc.) can help alleviate them. Functional programming languages like ML take a different approach, which could be better than OO. But this guy seems to be advocating a return to traditional procedural (not functional) programming, which be a big step backwards.
Also, there are many know limitations of naive or traditional OO. For example, inheritence is overused by many programmers new to OO. Java's combination of strong typing and lack of generic programming facilities (no templates) forces programmers into creating overly complicated interface (pure abstract inheritence) hierarchies, since you can't easily create generic methods. So, Java encourages complicated interface hierarchies. But, the guy should read "Design Patterns" regarding why aggregation is often a better tool than inheritence. Saying the OO people think that the whole world can be represented in an inheritence hierarchy is attacking a straw man. Contemporary OO gurus don't think that way. Oh, and inheritence is not primarily a code reuse mechanism -- it's a typing mechanism.
Teach him mathematics. This will give him the logical foundation to do whatever he wants. Whatever 'cutting edge' stuff you attempt to teach him today will not be so cutting edge 15 years from now; but the math will alwasy be useful.
Parameterized types are templates in C++. They allow you to do generic programming.
With templates, you can write a function like this:
template
DataType max(DataType a, DataType b)
{ return (a>b ? a : b); }
This function returns an object by value, and is type safe. By type-safe, I mean that it require s that the two arguments and the return type all be the same (or compatible) types. For example, this would be a compiler error:
int x = 3;
complex c(3,4);
int y = max(x, c);// whoops -- different types!
This is actually impossible to do Java. You can't make it return a by-value object, and it's awkward to enforce the type constraints.
Templates allow generic programming, where you write functions and classes (think abstract data types) that are agnostic as to the exact type of some of their parameters. But, you still get compile-time type safety. Templates are great for container classes and algorithms. Container classes in Java are workable, but a bit awkward. You don't have compile-time type safety. The container's values get cast to Object going in, and have to be manually cast back to the desired type when getting an element from a collection. With C++ templates, you can declare containers of specific types, like 'vector' or 'vector'.
For example:
vector v(3);// three element vector of ints
v[0] = 45;
v[1] = 3;
v[2] = 4;
sort(v.begin(), v.end());// sort the whole vector
int first = v[0];// no need to cast
All of this is type-safe, and about as efficient as hand-written code.
Also note that the sort function is generic too -- it works for lots of different container types (like list), including container types you write, that the author of sort did not anticipate. Templates are very 'pluggable', both horizontally and vertically. Generic programming has a very different feel from OO programming. It's less hierarchical, easier to plug and play things piecemeal. Of course, you can still use a vector of MyPolyMorphicObject references,('vector to combine OO and generic programming.
There's a lot more to templates then what I just described. The STL is a great example of a powerful, flexible and efficient generic library. Some people say that ML's generic facilities are even better than C++'s. This may be true; I've never used ML. Other people say that you don't need templates at all, that the real problem is strong typing. In languages like Smalltalk, Python and Perl, you don't have to declare the types of arguments, so every thing is generic. Of course, you can get run-time errors if you pass in the wrong type. But you can also get run-time errors in Java if you try to cast to the wrong type.
Strong typing without templates is the worst of both worlds, in my opinion. If you're going to have strong typing (which I personally like), then you really must have support for templates or something like them. Otherwise you get the huge proliferation of complicated interface hierarchies that you see in Java, just to make sure that classes are useable various contexts. Templates decrease the need for multiple inheritence (or interfaces) somewhat.
My thoughts exactly. Red Hat, in their official comments (especially the one by Troan saying that 7.0 is much better than 6.0 or 5.0, implying that 7.0 might be worse than 6.2) seems to be implying that there is something special ('innovative') about the.0 releases (in addition to binary incompatibility with the previous major release, which is understandable). That's fine, but they should let users know more explicitly.
Well, you might think 7 is better and 6.2, and I might (or might not) agree with you. The point is, what does Red Hat think? The statement by Troan could be interpreted to mean that a.0 release is of lower quality than the previous non.0 release. Especially regarding number of bugs. Sure, 7.0 might have more bugs fixed, but how many more has it introduced? Is there a net improvement in reliability, or is it worse?
The point is, there seems to be a qualitative difference, in terms of the net number of bugs, between a.0 and a non.0 release. I guess we should expect this, but ordinary users aren't always going to realize that there's something magic about the.0 in the release -- that this implies risk, possibly more bugs. Since this seems to be the case, and Red Hat seems to be admitting this, why not make it more clear in the labelling of the release? Call it the "experimental, but really up to date" release or something. So people can know what kind of trade offs they're making.
"I don't compile things on my RHL7 box and expect to run it on older boxes."
Yes. But, you would expect that stuff compiled on RedHat 7.0 would work on RedHat 7.0, wouldn't you? I compiled Qt 2.2.1 on RH 7, and it doesn't work at all. It probablly has something to do with the C++ library or compiler, and there is a note on Troll tech's page that explains the problem, and recommends using the old gcc (gcc 2.95) and the old glibc.
I expect to be able to compile stuff and run it on the same box using the default compiler and glibc, and have it work. This is not always the case with RH 7. That's a problem.
"...Red Hat 7 is undoubtedly of higher quality then Red Hat 6.0 or 5.0."
-- Eric Troan, RedHat VP.
Does this mean that Red Hat 7 is of lower quality
than Red Hat 6.2? I think that is what the original poster was getting at. Not (just)
that 7.0 is binary incompatible with 6.2. That is to be expected, as you pointed out.
As a matter of fact, the Red Hat *.0 releases have been of lower quality (more buggy) than other
releases. But if this is now Red Hat's official policy, then they should say so on the box. Call
it "Red Hat Buggy Experimental Release 7.0 with Nifty New Features" or something. One (anyone,
not just a newbie) would assume that a higher
release number indicates higher quality; Troan's
statement seems to suggest otherwise.
Well, I don't think RedHat needs to work on the current rev (2.96) snapshot further, if that's what you mean. The 2.96 snapshot that ships with RH 7.0 works pretty well.
Gtk+ seems fairly object oriented to me, although I've only played with it.
Using an OO language does necessarily mean you are doing OO; conversely it is possible, although awkard, to do OO in a language that does not directly support OO (like C).
OO is more than just syntax. In gtk+, I can NOT do this:
Widget* w = new Button;
w->show();
Instead, I have to do something like this:
Widget* w = button_new();
widget_show(w);
The syntax is not OO, but the design is. Widgets are split up into an inheritance hierarchy, and the exact 'show' method is selected at run-time based on the concrete type of the object (run-time polymorphism).
I much prefer doing OO in a language that supports it directly. But ironcially, Gtk+, written in C, is actually much more object-oriented than MFC, which was written in C++.
I work with a lot of foreign programmers. While learning slang helps, I don't think it's a requirement. Knowing standard English is sufficient, as long as both sides work at building a rapport.
Well, who wants to write any software? The point is you have the freedom to do so if you want. You can't complain just because Troll Tech doesn't give everything to you.
The Unix version is free, the Windows version is not. Seems pretty clear to me.
There's nothing to prevent you from taking the Unix Qt sources and writing a free Windows version, however.
Re:WRONG ! Re:We have a level playing field
on
Qt Going GPL
·
· Score: 1
Oh God! You people will never give up.
Gnome is GPL'ed, not LGPL. So, come up with another reason why Qt is still bad.
(Incidentally, Stallman prefers the GPL over the LGPL. So, if Qt was LGPL'ed, the Stallmanistas would criticize Qt for that. GPL is the most politically correct license.)
Re:dept: its-about-frigging-time
on
Qt Going GPL
·
· Score: 1
"KDE and Qt's licenses are seen to be incompatible."
Soon that will be "were seent to be incompatible",
since they'll both be GPL. Yeah!
Re:KDE/GNOME war hurts developers...
on
KDE Strikes Back
·
· Score: 1
>> KDE's implementation requires recoding to make >> you're object network aware
Yes, but my understanding is that they could, at some future date, recode the backend of KParts to
make it network transparent (maybe via CORBA, when a stable, light, C++ supporting CORBA ORB becomes available), so no client code would have to change.
Actually, you can use Unicode with std::string. See the book "Standard C++ IOStreams and Locales" by langer and Kreft for details, or "The C++ Programing Language, 3rd Edition" by Stroustrup for an overview.
Slashdot Mirror
Um, this is a joke, right? You teach at Harvard!!??? Now I know why we're losing all our jobs to offshoring. If this the best 'teaching' our educational system produce, we're really in trouble.
Seriously, it sound like your objections are just based on laziness - you don't want to look at extra code, documentation, etc. Too much work for you. Oh, that's another reason we're losing to offshore folks - laziness.
I guess we're illogical too. What does documentation have to do with unit testing? Can't you do one without the other???
Sorry, I'm just flabbergasted.
My management is thinking of doing parallel development of the same app, with two teams in the U.S. (working in two different locations about 20 miles apart), and one or two teams working in India. Each team would simultaneously be working on different part of the same app. The project manager and users would be in the U.S. The app is a rewrite of a large legacy app. It will be rewritten in Java, JSP, servlets, EJB's, Oracle, etc.
Does anyone have any experience with this kind of approach?
"Echelon is the most effective internet censor network in the world."
How is Echelon an internet *censor*? Maybe, as you say, it reads everything (although I doubt it), but that's an invasion of privacy, not censorship.
Try JDE (Java Development Environment for Emacs). I've heard lots of great things about it. Don't let the fact that it works with emacs scare you away -- it seems really full featured -- stepping through code in multiple processes, class hierarchy displays, javadoc documentation for a class by hitting a hot key, etc.
Here's the url:
http://sunsite.dk/jde/
OK, I totally agree with that. As long as you follow the OnceAndOnlyOnce rule rigorously, everything's kosher.
On a side note:
One legitimate criticism of 'classic' OO is that it places too much emphasis inheritence hierarchies. Some kinds of behavior, however, occurs at 'right angles' to the inheritence hierarchy. Common algorithms like sorting, or policy things like error logging, transactions, etc. These things tend to occurr all over the place, but don't always have a clear place in the inheritence hierarchy. Generic programming (templates) and aspect-oriented programming are two attempts to mitigate this problem; I think they hold a lot of promise.
Good post. I have to disagree with one thing:
"Specific is good, generic is bad. Building generic stuff takes longer and makes for unreadable code - don't do it unless you need it."
Really??? I think that generic programming is the missing key to effective code reuse. If I find myself sorting things over and over again, shouldn't I abstract that out into a generic sort algorithm, instead of having similar (but not identical) code littered all over the place? The latter would be a maintenence nightmare. If there's a bug in you're approach to sorting, you have to change it everywhere. It violates the OnceAndOnlyOnce rule.
Admittedly, coming up with something generic right up front is hard, and shouldn't be attempted. But refactoring similar code into generic functions or classes is a good thing.
Generic programming is orthogonal to OO programming. In OO, you try to capture business (and other) entities as objects -- Customer, Order, Item, etc. Generic programming lets you capture the abstractions that tend to occur at right angles to your business classes. For example, sorting customers, sorting orders, sorting items -- why not capture sorting as its own abtraction, rather than reimplementing CustomersList.sort(), OrdersList.sort(), ItemsList.sort(), etc? Wouldn't having one generic sort function that can do 'sort(CustomersList)', 'sort(OrdersList)', etc., be better? Aside from the code sharing issue, it's just cleaner to have one 'sort' abtraction.
Oh, and polymorphism over types is actually an instance of generic programming -- many different types have the same interface, so you can write a another method that takes the base type, and it operates on all the sub-types. It's generic.
I thought it was a very poorly written article. There are a lot of problems with OO that need exposing, but this article didn't do it.
///////////
// assign attributes to our person
// display tax amount
// construct from person key
For example, he gave two code examples, showing how one might calculate a tax using OO and procedural programming:
// BAD, COMPLICATED OO APPROACH
Person P = new Person("Fred")
Tax T = new Tax()
P.x = foo
P.y = bar
P.z = blah()
output T.calcTax(P)
// SIMPLE, ELEGENT PROCEDURAL APPROACH
output CalcTax("Fred", foo, bar)
He complains that the OO approach requires you to understand the Person class, and is more verbose. Regarding the latter, the OO code could look like this, using the Person constructor:
Person p("Fred", foo, bar);
Tax t;
output t.calcTax(p);
Or even:
output Tax(Person("Fred", foo, bar)).calcTax().
So, the OO approach needn't be that much more wordy that the procedural approach. In many cases, it's more concise.
Now on to the more substantial criticism, that the OO approach requires you to understand the Person class to calculate the tax. Well, the procedural approach requires you to understand the parameters to the calcTax() function, and to remember the proper order for the parameters. And, the parameters you pass to the calcTax() function are in essence the attributes of a person necessary to calculate the tax -- so conceptually, you have to know just as much about people and taxes in either approach. The OO approach just seperates the concept of Person from the concept of Tax more explicitly. If you change the way that you identify a person (perhaps by SSN or employee id instead by name), you change the person class, but neither the interface nor the implementation of the Tax class needs to change. For example:
Person p(1234);
Tax t(p);
t.calcTaxes();
In the procedural approach, the calcTaxes function would have to change.
There are many limitations of OO. The book "Generic Programming" discussed many of them, and demonstrates how generic programming tools (templates, code generators, etc.) can help alleviate them. Functional programming languages like ML take a different approach, which could be better than OO. But this guy seems to be advocating a return to traditional procedural (not functional) programming, which be a big step backwards.
Also, there are many know limitations of naive or traditional OO. For example, inheritence is overused by many programmers new to OO. Java's combination of strong typing and lack of generic programming facilities (no templates) forces programmers into creating overly complicated interface (pure abstract inheritence) hierarchies, since you can't easily create generic methods. So, Java encourages complicated interface hierarchies. But, the guy should read "Design Patterns" regarding why aggregation is often a better tool than inheritence. Saying the OO people think that the whole world can be represented in an inheritence hierarchy is attacking a straw man. Contemporary OO gurus don't think that way. Oh, and inheritence is not primarily a code reuse mechanism -- it's a typing mechanism.
Teach him mathematics. This will give him the logical foundation to do whatever he wants. Whatever 'cutting edge' stuff you attempt to teach him today will not be so cutting edge 15 years from now; but the math will alwasy be useful.
You might also consider teaching him some music.
Some of my examples didn't get printed properly, leaving of the data type of the instantiations.
// three element vector of ints
vector v(3);
should have been:
vector<int> v(3);
Hopefully that makes things clearer -- the point is you declare the exact type of a container when you instantiate (use) it.
Should have used preview!
Parameterized types are templates in C++. They allow you to do generic programming.
// whoops -- different types!
// three element vector of ints
// sort the whole vector
// no need to cast
With templates, you can write a function like this:
template
DataType max(DataType a, DataType b)
{ return (a>b ? a : b); }
This function returns an object by value, and is type safe. By type-safe, I mean that it require s that the two arguments and the return type all be the same (or compatible) types. For example, this would be a compiler error:
int x = 3;
complex c(3,4);
int y = max(x, c);
This is actually impossible to do Java. You can't make it return a by-value object, and it's awkward to enforce the type constraints.
Templates allow generic programming, where you write functions and classes (think abstract data types) that are agnostic as to the exact type of some of their parameters. But, you still get compile-time type safety. Templates are great for container classes and algorithms. Container classes in Java are workable, but a bit awkward. You don't have compile-time type safety. The container's values get cast to Object going in, and have to be manually cast back to the desired type when getting an element from a collection. With C++ templates, you can declare containers of specific types, like 'vector' or 'vector'.
For example:
vector v(3);
v[0] = 45;
v[1] = 3;
v[2] = 4;
sort(v.begin(), v.end());
int first = v[0];
All of this is type-safe, and about as efficient as hand-written code.
Also note that the sort function is generic too -- it works for lots of different container types (like list), including container types you write, that the author of sort did not anticipate. Templates are very 'pluggable', both horizontally and vertically. Generic programming has a very different feel from OO programming. It's less hierarchical, easier to plug and play things piecemeal. Of course, you can still use a vector of MyPolyMorphicObject references,('vector to combine OO and generic programming.
There's a lot more to templates then what I just described. The STL is a great example of a powerful, flexible and efficient generic library. Some people say that ML's generic facilities are even better than C++'s. This may be true; I've never used ML. Other people say that you don't need templates at all, that the real problem is strong typing. In languages like Smalltalk, Python and Perl, you don't have to declare the types of arguments, so every thing is generic. Of course, you can get run-time errors if you pass in the wrong type. But you can also get run-time errors in Java if you try to cast to the wrong type.
Strong typing without templates is the worst of both worlds, in my opinion. If you're going to have strong typing (which I personally like), then you really must have support for templates or something like them. Otherwise you get the huge proliferation of complicated interface hierarchies that you see in Java, just to make sure that classes are useable various contexts. Templates decrease the need for multiple inheritence (or interfaces) somewhat.
Does anyone know if the whole book is available in a convenient tar file for download?
My thoughts exactly. Red Hat, in their official comments (especially the one by Troan saying that 7.0 is much better than 6.0 or 5.0, implying that 7.0 might be worse than 6.2) seems to be implying that there is something special ('innovative') about the .0 releases (in addition to binary incompatibility with the previous major release, which is understandable). That's fine, but they should let users know more explicitly.
Well, you might think 7 is better and 6.2, and I might (or might not) agree with you. The point is, what does Red Hat think? The statement by Troan could be interpreted to mean that a .0 release is of lower quality than the previous non .0 release. Especially regarding number of bugs. Sure, 7.0 might have more bugs fixed, but how many more has it introduced? Is there a net improvement in reliability, or is it worse?
.0 and a non .0 release. I guess we should expect this, but ordinary users aren't always going to realize that there's something magic about the .0 in the release -- that this implies risk, possibly more bugs. Since this seems to be the case, and Red Hat seems to be admitting this, why not make it more clear in the labelling of the release? Call it the "experimental, but really up to date" release or something. So people can know what kind of trade offs they're making.
The point is, there seems to be a qualitative difference, in terms of the net number of bugs, between a
"I don't compile things on my RHL7 box and expect to run it on older boxes."
Yes. But, you would expect that stuff compiled on RedHat 7.0 would work on RedHat 7.0, wouldn't you? I compiled Qt 2.2.1 on RH 7, and it doesn't work at all. It probablly has something to do with the C++ library or compiler, and there is a note on Troll tech's page that explains the problem, and recommends using the old gcc (gcc 2.95) and the old glibc.
I expect to be able to compile stuff and run it on the same box using the default compiler and glibc, and have it work. This is not always the case with RH 7. That's a problem.
"...Red Hat 7 is undoubtedly of higher quality then Red Hat 6.0 or 5.0."
-- Eric Troan, RedHat VP.
Does this mean that Red Hat 7 is of lower quality
than Red Hat 6.2? I think that is what the original poster was getting at. Not (just)
that 7.0 is binary incompatible with 6.2. That is to be expected, as you pointed out.
As a matter of fact, the Red Hat *.0 releases have been of lower quality (more buggy) than other
releases. But if this is now Red Hat's official policy, then they should say so on the box. Call
it "Red Hat Buggy Experimental Release 7.0 with Nifty New Features" or something. One (anyone,
not just a newbie) would assume that a higher
release number indicates higher quality; Troan's
statement seems to suggest otherwise.
Well, I don't think RedHat needs to work on the current rev (2.96) snapshot further, if that's what you mean. The 2.96 snapshot that ships with RH 7.0 works pretty well.
Gtk+ seems fairly object oriented to me, although I've only played with it. Using an OO language does necessarily mean you are doing OO; conversely it is possible, although awkard, to do OO in a language that does not directly support OO (like C). OO is more than just syntax. In gtk+, I can NOT do this: Widget* w = new Button; w->show(); Instead, I have to do something like this: Widget* w = button_new(); widget_show(w); The syntax is not OO, but the design is. Widgets are split up into an inheritance hierarchy, and the exact 'show' method is selected at run-time based on the concrete type of the object (run-time polymorphism). I much prefer doing OO in a language that supports it directly. But ironcially, Gtk+, written in C, is actually much more object-oriented than MFC, which was written in C++.
"Take a look at a major failure of Linux--its complete inability to produce anything resembling a coherent, useful desktop environment."
KDE would have to count as something that at least 'resembles' a useful desktop environment.
I work with a lot of foreign programmers. While learning slang helps, I don't think it's a requirement. Knowing standard English is sufficient, as long as both sides work at building a rapport.
Outsourcing, though, is a whole different thing.
Well, who wants to write any software? The point is you have the freedom to do so if you want. You can't complain just because Troll Tech doesn't give everything to you.
The Unix version is free, the Windows version is not. Seems pretty clear to me.
There's nothing to prevent you from taking the Unix Qt sources and writing a free Windows version, however.
Oh God! You people will never give up.
Gnome is GPL'ed, not LGPL. So, come up with another reason why Qt is still bad.
(Incidentally, Stallman prefers the GPL over the LGPL. So, if Qt was LGPL'ed, the Stallmanistas would criticize Qt for that. GPL is the most politically correct license.)
"KDE and Qt's licenses are seen to be incompatible."
Soon that will be "were seent to be incompatible",
since they'll both be GPL. Yeah!
>> KDE's implementation requires recoding to make >> you're object network aware
Yes, but my understanding is that they could, at some future date, recode the backend of KParts to
make it network transparent (maybe via CORBA, when a stable, light, C++ supporting CORBA ORB becomes available), so no client code would have to change.
Actually, you can use Unicode with std::string. See the book "Standard C++ IOStreams and Locales" by langer and Kreft for details, or "The C++ Programing Language, 3rd Edition" by Stroustrup for an overview.