I also reckon that you believe WYSIWYG "html editors" have a place?
There very handy for editing tables. Editing tables doesn't really lend itself to hand-coding.
SQL is a backend issue, there are no reasons for it to be tied into a toolkit.. if so, it is the worst form of bloat.
You are one ignorant putz. Qt is not just a "GUI toolkit". THink of it as analogous to the java standard library, and you're closer to the mark. There's no rule that says Qt doesn't handle "back end" issues.
IDE.IDE.. hah, I'd like to see you use Kdevelop on a text terminal.
I'd like to see you run a GTK app on a text terminal. What's your point ?
Yes, I know. IDEs are useless piles of bloat and should rot in hell with Emacs.
A lot of people use IDEs to get real work done. That you don't find them useful is of peripheral relevance.
BASH, Vim, and gcc, make, and the gnu-utils are all one really needs for a development environment. Anything else is just bloat. I do agree that the auto-tools are quite nice
If you're doing any serious development, autoconf and libtoool are necessities.
However, anything that tries to make it possible for the non-coder to become a "h4x0r", writing their little AOL-"proggies" is just lame
AOL kiddies don't use C++. Sorry, any chimp can run g++ from the command line. An IDE like KDevelop is useful for building larger projects targetted to multiple with several files.
Have a nickle, get yourself a real computer.
Or maybe you should, if that poor little box of yours can't even run emacs!
My dual athlons are doing just fine thanks. Works wonders for parallel builds.
A GUI toolkit, like any library, should allow its objects to be created on the stack or on the heap.
Why ? What are the benefits of allowing this ? Having Qt widgets created on the stack simply does not make any sense, because an object created on the stack is destroyed when it goes out of scope. This is not sensible behaviour for a GUI program.
In the few cases where it does make sense (eg temporary dialogs), you can create the object on the stack (because the dialog is unparented)
QT does not. I don't see that as a feature.
Name just one concrete disadvantage of this. And explain why the disadvantage outweighs the benefits of having a consistent memory management policy (so you don't have to remember which widggets are managed and which aren't)
Re:I switched from Gtk-- to Qt
on
GTK-- vs. QT
·
· Score: 2
Of course, moc doesn't have all of these problems but it does do a significant amount of translation not visibile to the compiler.
I don't see how this is a problem in practice. I've made heavy use of Qt, and generated code hasn't made life any more difficult or confusing.
That said, moc was a fine solution to the C++ compiler problem back in its day. At this point, most compilers can handle the template code necessary to implement signals and slots within the language.
But why templates ? I suppose they might make people with a strong aversion to preprocessors feel better. There are a lot of potential pitfalls with templates (static typing, tight coupling, etc), so I'm sceptical.
Well, they do parts of it. std::string is a fine string class.
But most compilers don't ship a unicode version.
As for containers, one can have containers of pointers in the std C++ library provided they are wrapped in smart pointers like Boost's shared_ptr.
Reference counting is a terrible choice of memory management policy for GUI programming. The problem is that you are likely to get a lot of reference cycles in GUI programming (child widgets that know their parents being the obvious one, though there are less obvious ones also). Simply put, you don't want to have everything that knows a widget to have partial ownership, because for each widget, there is a natural owner -- the parent widget.
The policy Qt uses, where parent widgets manage their children is much smarter. Keep in mind the kinds of problems Qt is trying to solve. For what it's trying to do, a reference count based memory management strategy isn't very effective.
The "template bloat problem" should really be called the "template implementation problem." It's only because most std C++ library implementations follow the original SGI offering that we have bloat problems.
Yes and no. Template bloat is a fundamental problem with templates. You're right that the std library could be implemented better than SGI's version. Metrowerks already ship a std library that uses void* for pointers, only creates one instance of the tree balancing code in the map/set implementations.
I consider the lack of a memory management policy
to be a "Cism". In Qt, Widgets manage their parents. In GTK--, sometimes they do and sometimes they don't (talk about confusing, error prone and annoying!)
QT is a piece of trash on MY system, while Gtk runs really snappy.
First, the performance of GTK+ is peripheral, because we're discussing GTK--. Second, unless you have benchmarked it, you're just blowing smoke.
[snip: glade]
I've used that. Yes, it's pretty cool.
Re: QT forces non standard c++ use
on
GTK-- vs. QT
·
· Score: 2
Unfortunately, Qt's approach is not a good one. First of all, it really doesn't end up saving code size, since for most applications you'll want to have all of the basic container methods inlined anyway. And if they don't get inlined, then you pay a performance penalty.
You're sort of right. There's no free lunch, there's a tradeoff, which is to sacrifice inlining
for a reduction in template bloat, and coupling.
I disagree that one wants everything inlined
for "most applications". For applications that involve containers of pointers of widgets, the extra indirection does not pose an enormous problem (you are already choosing indirection by
using pointers and not values) IMO performance bottlenecks in a GUI application are more likely to appear in drawing methods, network overhead, and back-end computation. I've never found looking up a widget in a list to be a performance bottleneck in a GUI application.
Qt does have value based containers for the rare occasion that you simply can't afford the
indirection of the pointer based containers.
If the object in the container inherits from multiple base classes, you are guaranteed that multiple pointers to the same object (of different pointer type) will have different values on almost all C++ platforms. When you cast from derived to base class type, the compiler adjusts the pointer value if necessary to ensure that it's pointing to the right vtable.
I don't see why this is a problem. The exposed interface does not accept void* pointers, it would only accept base class pointers. The derived to void class never happens. You get a derived* to base* conversion (because the function prototype wants type base*), then a base* to void* conversion. I agree that it would be a problem if the exposed interface accepted void* or derived* pointers though.
BTW, this idiom isn't terribly revolutionary. Stroustrup recommends it, Lakos (large scale C++ design) recommends it, and Metrowerks actually use iit to implement pointer classes in their STL.
So when multiple inheritance is involved, you can easily take a pointer of derived class type, cast it to void*
No. The derived pointer would get converted to a base class pointer first.
Cheers,
Re:Mozilla (slightly OT too)
on
GTK-- vs. QT
·
· Score: 1
No compilation step? Who CARES! You only compile it once!
Have you ever worked on real software ? Compile it once ? ROFL. (note: but I agree with your comments re: slow and bloated)
QT is C++ from the ground up, GTK-- is wrapping GTK++.
So?
Among other things, it means that Qt has some useful documentation, while the C++ wrappers for GTK seem to have "second class" status. (source code is not documentation)
Use vim
Vim is not an IDE or a UI builder. It's a great text editor.
Maybe, maybe not.. and if so, who cares? Maybe some people like to have a lot of options/power at their disposal.
"Hard to use" is not the same as "more options/power". Of course, the options/power aren't much good anyway if they're not adequately documented.
Re:New GTK+
on
GTK-- vs. QT
·
· Score: 2, Insightful
Don't forget that an all-new GTK+ version is just coming out, a cleaner design,
If they're redesigning the toolkit with every major release, that's a bad sign. Qt has not changed substantially since 1.x, the main difference is that functionality has been added to a rock solid infrastructure.
BTW, when is the GTK documentation going to be available ? IMO if there isn't any documentation, it
doesn't even deserve to be called "1.0".
Re:I switched from Gtk-- to Qt
on
GTK-- vs. QT
·
· Score: 1
It actually uses the modern C++ language, including the C++ type system. This way you avoid the need for a preprocessor, and get static typechecking instead of "dynamic typechecking" (i.e. "the user does the checking"), which is the entire point of using C++ in the first place.
Dynamic typing happens to be very useful when developing GUI components. It tends to weaken coupling between different components and create less dependencies. It makes it easier to do things like run time loading of components.
As for the preprocessor, I don't see why it's a "bad thing".
It also use the standard C++ library instead of duplicating it poorly,
They don't "duplicate it", and they don't "do it poorly". The Qt collection classes are pointer based, which makes sense for Qt. Usually, pointer based containers are problematic, because of obvious memory management issues. In Qt, parent widgets own child widgets, so the container doesn't need to own its pointers. As for "poorly",
the Qt collection classes do a much better job
than STL of avoiding the "template bloat" problem
(they do this by using for the most part pointer
containers based on the void* implementation)
Re:QT forces non standard c++ use
on
GTK-- vs. QT
·
· Score: 1
How long before it has classes that do most of what Java can do?
You've got a pretty good sense of what Qt is about. Yes, the java library is a pretty good analogy. I suppose it already can do a lot of what the java library can. I hesitate to say "most of", because the java library is huge, and I don't pretend to understand it.
But Qt does provide sockets, database support, a plugin system, XML support, collection classes, open GL support, and threading.
Re: QT forces non standard c++ use
on
GTK-- vs. QT
·
· Score: 1
The big difference is that gtk-- is based on the C++ standard library, and so allows you do use familiar and efficient constructs like std::vector, std::string and so on.
I object to your use of the word "efficient". Qt's pointer based classes derive from the void* version, so the template code is a thin type-safety wrapper. STL classes on Linux cost anywhere from 40k per instance (stdd::list) to 90k per instance (std::map)
The Qt classes are much leaner because instead of duplicating code, most of the work is delegated to the void* container.
QT has reimplemented all those things as a rather dodgy set of proprietry classes, which lock you into, for example using QString rather than std::string throughout your application, or doing a lot of extraneous conversions every time you need to talk to the GUI.
This is not true at all. The only basic class Qt widgets make heavy use of is QString. Re that class, one can always communicate using char*
What is true is that Qt is not just a GUI toolkit. It's more analogous to the Java standard library than it is to (for example) Swing.
Re:If you want better cross platform support..
on
GTK-- vs. QT
·
· Score: 1
..make your application interface independant. The idea is to make your program a basic application that can run without a gui. The gui is then a plugin or something. That way you can take one application and write a gui using gtk, QT, win32, whatever you want and never have to rewrite the application.
This is a nice idea, but very difficult to do in practice, because it basically requires you to roll your own AWT. Moreover, being able to choose a GUI at runtime is aesthetically nice, but offers little practical utility.
IMO a simpler solution is to factor as much as possible of the core application logic into a library, so that the GUI is basically a "dumb wrapper" that delegates the real work to the library.
Sure, it puts downward pressures on domestic wages. And that's probably why big corps advocate it. But you can't have it both ways, I mean, if it's about paying less, then it's about paying less for the same skills, not paying less for less skills.
If that's what you think this is about, then you HAVE NOT read the site.
It's there in plain English:
Given the tragic events of September 11, 2001, all nonimmigrant visas should be immediately halted in the interest of national security.
Halting non-immigrant visas is slamming the doors shut.
BTW. I, for one, would rather see green cards issued in lieu of a bogus temporary visa.
I partly agree with this. But there are problems re: what to do in the interim (while the applicant is waiting for processing). The H1-B is not a satisfactory solution though. "shameh1b" identifies flaws in the program, but proposes a hysterical as opposed to a measured response.
I'm afraid the site was up long before the attacks.
I've seen it long before the attacks.
Ah, the ad hominem attack. I was wondering when we'd get to that. Based on the terms of debate, I guess you've just lost. And you show your arrogance by jumping to conclusions when you say what I think about you.
Sorry if I sounded blunt, and rushed to conclusions. I have little patience with those who make sweeping generalisations about the skills of H1-B workers though. You're confusing "arrogant" with "short tempered".
And you also jump to conclusions when you assume that I think I'm a software engineer.
Because there's no formal qualification or even a clear definition of "software engineer", it's a meaningless term. A lot of people who call themselves software engineers are actually programmers with inflated egos. That you are not a "software engineer" is a welcome mark of humility.
As for the age range thing, if you are already here, look around you.
I work in a university. Anyone under 40 is a kid here.
Certification brings with it a lot of baggage and beaurocracy. Certification is expensive and time consuming. Rigorous testing, and peer review, especially independent review are good things, but you can have too much of a good thing.
Sometimes, having an overbearing beaurocracy might be worth it. Anything related to medicine has to go through several layers of beaurocracy. Likewise, any experiments involving human subjects have to be reviewed and approved by a board of obsessive-compulsives.
Because it is a field where rigour in correctness and ethics are critical.
But I shudder to think of the implications of imposing the same level of beaurocracy on other fields
Sorry, that's not what is happening AT ALL. Many H1-B's don't have qualifications that would allow them to get a similar job in their own country.
It's all about lowering wages here.
There's a doublethink in the above. If the H1-B workers really are incompetent, then perhaps employers could hire incompetent Americans instead. If the employers want to pay less, and get less skilled workers, they can do this without recourse to legislation.
For legislation to be effective in lowering wages, it must be able to bring in cheaper workers with comparable skills to those they are replacing.
I've read the "shame H1B" URL. Shut the borders completely on the grounds of "national security" ? Shame on them for exploiting this tragedy to further their agenda.
PS I'm applying for a H1-B. I hold a Ph.D. I know a lot of other people who hold PhDs and are applying for H1-B visas. I don't work "ridiculous hours for ridiculous wages", and I'm probably not in "a certain age group".
I suppose you think you're better than me because you're a US citizen. And that I'm just a "code monkey", while you're a "software engineer". Keep dreaming, chump.
Maybe. I thought I was also describing a coder with better than average analysis, design, testing, and people skills. (Note that "coding" becomes maybe 1/5th of the total skill set.)
Design, testing and analysis is part of programming. There really isn't much of a role for people who don't understand and can't learn design, analysis and testing ( I suppose they can design web pages or something, but that's about it).
OTOH, management is a different issue. A programmer needn't be a good manager. An engineer needn't be a good manager either. Engineering and management are not the same thing.
PS: I don't see why we even have history as a course of study. The past is just that, past.
Wrong wrong wrong. Politicals, religion, philosophy, law, art, and economics are all founded upon precedent.
Why do we have capitalism, and is it a good thing ? Why do we need a bill of rights, and do we know that it will be honored ? By what rules do you compose beautiful music ? And why should/should you not adhere to such rules ? Why do we have public corporations and a stock market, isn't it all "a bit artificial" ? Is there a god ? What role can/should religion play in society ?
These questions aren't easy to answer, but a bit of historical perspective certainly provides some fascinating insights into all of them.
Software does not evolve. It is only patched. Look at some of the latest software and you will see remains of older software.
Over a long period of time, it does indeed change. When I was in elementary school, I used a computer. Its memory was 32k. The "word processor" was a text editor, and you sent formating characters to the printer by reading the printer users manual, and using a special "markup" command to send that sequence to the printer.
Between now and the time todays elementary school kids are enterring the job market, computers and computer software will change. The only question is "how".
Among other things, the Redhat install includes an easy (ipchains) firewall setup.
Linux is linux is linux. Redhat with ipchains and no daemons is as secure as any other distribution with a similar setup.
Instead, the "interfacing" seems to be left to suits, project managers who don't actually understand any of the coding. We're left with a gap to fill there.
The way I see a software engineer is as filling thag gap.
That still wouldn't make them an "engineer". What you are describing is a project manager with better than average technical skills.
Professionalization would keep standards higher in many ways- by keeping people out who are little more than code monkeys, but more importantly via the creation of a bona fide association with some real political power.
Actually, a lot of the H1Bs are qualified, because a lot of them use F1 (student) visas to get into the country in the first place. And the foreigners are more determined to go through such steps. If qualifications were so important, it would give companies all the more reason to choose a foreign national with a masters, than a US citizen who's graduated from a related degree (eg math or electrical engineering ).
You're not going to keep foreigners out by raising the bar.
Reference counts work reasonably well. There's a problem with not releasing circular structures,
but that doesn't keep Perl from being useful.
It doesn't prevent perl from being useful, but no language which uses reference counts is ever going to replace C or C++.
The problem with reference counts is that sometimes they cause more problems than they solve. A good example is in GUI programs, where a lot of objects might be mutually aware of each other. That's not to say that reference counts are not useful. Rather, forcing programmers to use reference counting to manage memory whether appropriate or not is problematic.
If you don't have garbage collection or reference counts, programs obsess on who owns what. A
basic problem of C and C++ is that it's essential to track who owns which objects and when
they're supposed to be released, yet the language offers no help whatsoever in doing so.
C++ givas the programmer the flexibility to choose a memory management strategy that suits the problem at hand. Sometimes pool allocation works. Sometimes reference counting works. Sometimes, parent/child management works.
It's very simple to implement reference counted classes in C++. It's certainly not necessary to exclusively use an "exclusive ownership" model in C++.
Almost every core dump, "bus error",
or "general protection fault" comes from that problem.
They come down to a lot of problems -- library incompatibilities, bounds errors, and other things can cause these problems. I think it's naive to assume that using reference counting for everything will just make the problem "go away". Writing reference counted code without memory leaks gets quite difficult when the data structures are more complex.
The URL you have is interesting, and I think for some types of problems, using an object system where you just reference count everything is probably a good idea. But I question its value as a cure-all.
Re:now all kde needs is a decent window manager.
on
KDE 3.0 Screenshots
·
· Score: 1
The/single/ thing that keeps me from running kde
is that cruddy excuse for a WM they/force/ you to
use.
Not true. The KDE libraries and applications work with any window manager.
I wish the KDE people published more binaries during the development, nightly or weekly builds
or something. Compiling all the stuff takes several days, and it's usually hellishly difficult to get
through compilations successfully.
During development, they want to focus on development, as opposed to packaging it for Joe Luser. If you want nightly boulds, you could always try CVS (-; If the builds don't work, that in itself is a good reason not to release binaries
At one time, I participated in some minor KDE development, but it was somewhat bothersome
that I could rarely get even kdelibs compiled easily. It made development a bit difficult
sometimes.
If you're participating in development, either stick with a given release or track the CVS tree. If it's really "minor development", you're probably better off doing the former.
Slashdot Mirror
There very handy for editing tables. Editing tables doesn't really lend itself to hand-coding.
SQL is a backend issue, there are no reasons for it to be tied into a toolkit.. if so, it is the worst form of bloat.
You are one ignorant putz. Qt is not just a "GUI toolkit". THink of it as analogous to the java standard library, and you're closer to the mark. There's no rule that says Qt doesn't handle "back end" issues.
IDE.IDE.. hah, I'd like to see you use Kdevelop on a text terminal.
I'd like to see you run a GTK app on a text terminal. What's your point ?
A lot of people use IDEs to get real work done. That you don't find them useful is of peripheral relevance.
BASH, Vim, and gcc, make, and the gnu-utils are all one really needs for a development environment. Anything else is just bloat. I do agree that the auto-tools are quite nice
If you're doing any serious development, autoconf and libtoool are necessities.
However, anything that tries to make it possible for the non-coder to become a "h4x0r", writing their little AOL-"proggies" is just lame
AOL kiddies don't use C++. Sorry, any chimp can run g++ from the command line. An IDE like KDevelop is useful for building larger projects targetted to multiple with several files.
Have a nickle, get yourself a real computer.
Or maybe you should, if that poor little box of yours can't even run emacs! My dual athlons are doing just fine thanks. Works wonders for parallel builds.
Why ? What are the benefits of allowing this ? Having Qt widgets created on the stack simply does not make any sense, because an object created on the stack is destroyed when it goes out of scope. This is not sensible behaviour for a GUI program.
In the few cases where it does make sense (eg temporary dialogs), you can create the object on the stack (because the dialog is unparented)
QT does not. I don't see that as a feature.
Name just one concrete disadvantage of this. And explain why the disadvantage outweighs the benefits of having a consistent memory management policy (so you don't have to remember which widggets are managed and which aren't)
I don't see how this is a problem in practice. I've made heavy use of Qt, and generated code hasn't made life any more difficult or confusing.
That said, moc was a fine solution to the C++ compiler problem back in its day. At this point, most compilers can handle the template code necessary to implement signals and slots within the language.
But why templates ? I suppose they might make people with a strong aversion to preprocessors feel better. There are a lot of potential pitfalls with templates (static typing, tight coupling, etc), so I'm sceptical.
Well, they do parts of it. std::string is a fine string class.
But most compilers don't ship a unicode version.
As for containers, one can have containers of pointers in the std C++ library provided they are wrapped in smart pointers like Boost's shared_ptr.
Reference counting is a terrible choice of memory management policy for GUI programming. The problem is that you are likely to get a lot of reference cycles in GUI programming (child widgets that know their parents being the obvious one, though there are less obvious ones also). Simply put, you don't want to have everything that knows a widget to have partial ownership, because for each widget, there is a natural owner -- the parent widget. The policy Qt uses, where parent widgets manage their children is much smarter. Keep in mind the kinds of problems Qt is trying to solve. For what it's trying to do, a reference count based memory management strategy isn't very effective.
The "template bloat problem" should really be called the "template implementation problem." It's only because most std C++ library implementations follow the original SGI offering that we have bloat problems.
Yes and no. Template bloat is a fundamental problem with templates. You're right that the std library could be implemented better than SGI's version. Metrowerks already ship a std library that uses void* for pointers, only creates one instance of the tree balancing code in the map/set implementations.
I consider the lack of a memory management policy to be a "Cism". In Qt, Widgets manage their parents. In GTK--, sometimes they do and sometimes they don't (talk about confusing, error prone and annoying!)
QT is a piece of trash on MY system, while Gtk runs really snappy.
First, the performance of GTK+ is peripheral, because we're discussing GTK--. Second, unless you have benchmarked it, you're just blowing smoke.
[snip: glade]
I've used that. Yes, it's pretty cool.
You're sort of right. There's no free lunch, there's a tradeoff, which is to sacrifice inlining for a reduction in template bloat, and coupling. I disagree that one wants everything inlined for "most applications". For applications that involve containers of pointers of widgets, the extra indirection does not pose an enormous problem (you are already choosing indirection by using pointers and not values) IMO performance bottlenecks in a GUI application are more likely to appear in drawing methods, network overhead, and back-end computation. I've never found looking up a widget in a list to be a performance bottleneck in a GUI application.
Qt does have value based containers for the rare occasion that you simply can't afford the indirection of the pointer based containers.
If the object in the container inherits from multiple base classes, you are guaranteed that multiple pointers to the same object (of different pointer type) will have different values on almost all C++ platforms. When you cast from derived to base class type, the compiler adjusts the pointer value if necessary to ensure that it's pointing to the right vtable.
I don't see why this is a problem. The exposed interface does not accept void* pointers, it would only accept base class pointers. The derived to void class never happens. You get a derived* to base* conversion (because the function prototype wants type base*), then a base* to void* conversion. I agree that it would be a problem if the exposed interface accepted void* or derived* pointers though.
BTW, this idiom isn't terribly revolutionary. Stroustrup recommends it, Lakos (large scale C++ design) recommends it, and Metrowerks actually use iit to implement pointer classes in their STL.
So when multiple inheritance is involved, you can easily take a pointer of derived class type, cast it to void*
No. The derived pointer would get converted to a base class pointer first.
Cheers,
Have you ever worked on real software ? Compile it once ? ROFL. (note: but I agree with your comments re: slow and bloated)
QT is C++ from the ground up, GTK-- is wrapping GTK++. So?
Among other things, it means that Qt has some useful documentation, while the C++ wrappers for GTK seem to have "second class" status. (source code is not documentation)
Use vim
Vim is not an IDE or a UI builder. It's a great text editor.
Maybe, maybe not.. and if so, who cares? Maybe some people like to have a lot of options/power at their disposal.
"Hard to use" is not the same as "more options/power". Of course, the options/power aren't much good anyway if they're not adequately documented.
If they're redesigning the toolkit with every major release, that's a bad sign. Qt has not changed substantially since 1.x, the main difference is that functionality has been added to a rock solid infrastructure.
BTW, when is the GTK documentation going to be available ? IMO if there isn't any documentation, it doesn't even deserve to be called "1.0".
Dynamic typing happens to be very useful when developing GUI components. It tends to weaken coupling between different components and create less dependencies. It makes it easier to do things like run time loading of components. As for the preprocessor, I don't see why it's a "bad thing".
It also use the standard C++ library instead of duplicating it poorly,
They don't "duplicate it", and they don't "do it poorly". The Qt collection classes are pointer based, which makes sense for Qt. Usually, pointer based containers are problematic, because of obvious memory management issues. In Qt, parent widgets own child widgets, so the container doesn't need to own its pointers. As for "poorly", the Qt collection classes do a much better job than STL of avoiding the "template bloat" problem (they do this by using for the most part pointer containers based on the void* implementation)
You've got a pretty good sense of what Qt is about. Yes, the java library is a pretty good analogy. I suppose it already can do a lot of what the java library can. I hesitate to say "most of", because the java library is huge, and I don't pretend to understand it. But Qt does provide sockets, database support, a plugin system, XML support, collection classes, open GL support, and threading.
I object to your use of the word "efficient". Qt's pointer based classes derive from the void* version, so the template code is a thin type-safety wrapper. STL classes on Linux cost anywhere from 40k per instance (stdd::list) to 90k per instance (std::map) The Qt classes are much leaner because instead of duplicating code, most of the work is delegated to the void* container.
QT has reimplemented all those things as a rather dodgy set of proprietry classes, which lock you into, for example using QString rather than std::string throughout your application, or doing a lot of extraneous conversions every time you need to talk to the GUI.
This is not true at all. The only basic class Qt widgets make heavy use of is QString. Re that class, one can always communicate using char*
What is true is that Qt is not just a GUI toolkit. It's more analogous to the Java standard library than it is to (for example) Swing.
This is a nice idea, but very difficult to do in practice, because it basically requires you to roll your own AWT. Moreover, being able to choose a GUI at runtime is aesthetically nice, but offers little practical utility.
IMO a simpler solution is to factor as much as possible of the core application logic into a library, so that the GUI is basically a "dumb wrapper" that delegates the real work to the library.
Sure, it puts downward pressures on domestic wages. And that's probably why big corps advocate it. But you can't have it both ways, I mean, if it's about paying less, then it's about paying less for the same skills, not paying less for less skills.
If that's what you think this is about, then you HAVE NOT read the site.
It's there in plain English:
Halting non-immigrant visas is slamming the doors shut.
BTW. I, for one, would rather see green cards issued in lieu of a bogus temporary visa.
I partly agree with this. But there are problems re: what to do in the interim (while the applicant is waiting for processing). The H1-B is not a satisfactory solution though. "shameh1b" identifies flaws in the program, but proposes a hysterical as opposed to a measured response.
I'm afraid the site was up long before the attacks.
I've seen it long before the attacks.
Ah, the ad hominem attack. I was wondering when we'd get to that. Based on the terms of debate, I guess you've just lost. And you show your arrogance by jumping to conclusions when you say what I think about you.
Sorry if I sounded blunt, and rushed to conclusions. I have little patience with those who make sweeping generalisations about the skills of H1-B workers though. You're confusing "arrogant" with "short tempered".
And you also jump to conclusions when you assume that I think I'm a software engineer.
Because there's no formal qualification or even a clear definition of "software engineer", it's a meaningless term. A lot of people who call themselves software engineers are actually programmers with inflated egos. That you are not a "software engineer" is a welcome mark of humility.
As for the age range thing, if you are already here, look around you.
I work in a university. Anyone under 40 is a kid here.
Sometimes, having an overbearing beaurocracy might be worth it. Anything related to medicine has to go through several layers of beaurocracy. Likewise, any experiments involving human subjects have to be reviewed and approved by a board of obsessive-compulsives. Because it is a field where rigour in correctness and ethics are critical. But I shudder to think of the implications of imposing the same level of beaurocracy on other fields
There's a doublethink in the above. If the H1-B workers really are incompetent, then perhaps employers could hire incompetent Americans instead. If the employers want to pay less, and get less skilled workers, they can do this without recourse to legislation.
For legislation to be effective in lowering wages, it must be able to bring in cheaper workers with comparable skills to those they are replacing.
I've read the "shame H1B" URL. Shut the borders completely on the grounds of "national security" ? Shame on them for exploiting this tragedy to further their agenda.
PS I'm applying for a H1-B. I hold a Ph.D. I know a lot of other people who hold PhDs and are applying for H1-B visas. I don't work "ridiculous hours for ridiculous wages", and I'm probably not in "a certain age group". I suppose you think you're better than me because you're a US citizen. And that I'm just a "code monkey", while you're a "software engineer". Keep dreaming, chump.
Design, testing and analysis is part of programming. There really isn't much of a role for people who don't understand and can't learn design, analysis and testing ( I suppose they can design web pages or something, but that's about it).
OTOH, management is a different issue. A programmer needn't be a good manager. An engineer needn't be a good manager either. Engineering and management are not the same thing.
Wrong wrong wrong. Politicals, religion, philosophy, law, art, and economics are all founded upon precedent.
Why do we have capitalism, and is it a good thing ? Why do we need a bill of rights, and do we know that it will be honored ? By what rules do you compose beautiful music ? And why should/should you not adhere to such rules ? Why do we have public corporations and a stock market, isn't it all "a bit artificial" ? Is there a god ? What role can/should religion play in society ?
These questions aren't easy to answer, but a bit of historical perspective certainly provides some fascinating insights into all of them.
Over a long period of time, it does indeed change. When I was in elementary school, I used a computer. Its memory was 32k. The "word processor" was a text editor, and you sent formating characters to the printer by reading the printer users manual, and using a special "markup" command to send that sequence to the printer. Between now and the time todays elementary school kids are enterring the job market, computers and computer software will change. The only question is "how".
Among other things, the Redhat install includes an easy (ipchains) firewall setup. Linux is linux is linux. Redhat with ipchains and no daemons is as secure as any other distribution with a similar setup.
That still wouldn't make them an "engineer". What you are describing is a project manager with better than average technical skills.
Actually, a lot of the H1Bs are qualified, because a lot of them use F1 (student) visas to get into the country in the first place. And the foreigners are more determined to go through such steps. If qualifications were so important, it would give companies all the more reason to choose a foreign national with a masters, than a US citizen who's graduated from a related degree (eg math or electrical engineering ). You're not going to keep foreigners out by raising the bar.
It doesn't prevent perl from being useful, but no language which uses reference counts is ever going to replace C or C++. The problem with reference counts is that sometimes they cause more problems than they solve. A good example is in GUI programs, where a lot of objects might be mutually aware of each other. That's not to say that reference counts are not useful. Rather, forcing programmers to use reference counting to manage memory whether appropriate or not is problematic.
If you don't have garbage collection or reference counts, programs obsess on who owns what. A basic problem of C and C++ is that it's essential to track who owns which objects and when they're supposed to be released, yet the language offers no help whatsoever in doing so.
C++ givas the programmer the flexibility to choose a memory management strategy that suits the problem at hand. Sometimes pool allocation works. Sometimes reference counting works. Sometimes, parent/child management works. It's very simple to implement reference counted classes in C++. It's certainly not necessary to exclusively use an "exclusive ownership" model in C++.
Almost every core dump, "bus error", or "general protection fault" comes from that problem.
They come down to a lot of problems -- library incompatibilities, bounds errors, and other things can cause these problems. I think it's naive to assume that using reference counting for everything will just make the problem "go away". Writing reference counted code without memory leaks gets quite difficult when the data structures are more complex.
The URL you have is interesting, and I think for some types of problems, using an object system where you just reference count everything is probably a good idea. But I question its value as a cure-all.
Not true. The KDE libraries and applications work with any window manager.
During development, they want to focus on development, as opposed to packaging it for Joe Luser. If you want nightly boulds, you could always try CVS (-; If the builds don't work, that in itself is a good reason not to release binaries
At one time, I participated in some minor KDE development, but it was somewhat bothersome that I could rarely get even kdelibs compiled easily. It made development a bit difficult sometimes.
If you're participating in development, either stick with a given release or track the CVS tree. If it's really "minor development", you're probably better off doing the former.