You mention Ruby (which is hardly "hyped" these days) and then you say "industry has a hard time catching on to Smalltalk". You haven't used Ruby have you?
Anyway, your comment essentially agrees with me. Academics are concerned with elegance and perfection. Engineers are concerned with whether something actually works, interoperates well, and solves the problem at hand.
Out of curiousity, exactly what did Smalltalk add to the field of remote invocation? And how was it better than what has come after? Smalltalk has influenced a lot of the best tools & techniques in software engineering, but RMI is one area where I hadn't noticed it having any impact.
I've found postings on/. where people tout all sorts of design tools, from languages like Java, Perl, Python, Ruby, and Smalltalk to design aids and processes like UML and eXtreme Programming. I'm in a Computer Science degree program, and I keep wondering what "improvements" over the last quarter century have actually brought progress to the key issue
All of the above. Each has brought improvements to some aspect to the development process in certain projects. Next question?
If it helps explain it at all, CORBA isn't known for being used by PHds. It's generally used by engineers in software companie3s trying to get real work done. Which is not to say that there's anything wrong with being a PHD; just that the academically oriented and the pragmatically oriented tend to use very different measures when determining a technology's worth.
Eiffel is on my list of languages to learn, and I've been wandering if the Free SmallEiffel is a complete, useful implementation; or whether the official EiffelStudio would be preferable. Anyone out there with experience in both?
...they're already hooked. I haven't had a windows PC in the house since I acquired stepkids (now ages 6 and 7), and so they didn't learn to expect it. Having once supported Windows computers for a living, I wasn't about to turn a couple of kids loose on one - I simply was not up to the maintenance headaches. With their own UNIX accounts I don't have to worry about them dragging the "windows" directory into the "trash can" or accidentally shutting down or just the general random crashiness of every MS OS I've worked with. They like The Gimp, and TuxPaint; Konqueror is in every way on par with IE these days for their web-surfing pleasure; and KDE is very easy to set up in a pretty, kid-friendly way. They haven't complained yet. If they ever start needing a lot of educational programs that Linux won't run I'll get them an iMac.
Blah blah blah failed idea blah blah unrealistic ivory tower academic fantasy blah blah cleaner in LISP yadda UNIX did this thirty years ago blah blah you should be using Python instead blah blah engineering methodologies are all crap blah blah no silver bullet blah blah C++ is for ninnies blah blah just start coding blah blah you should be using UML blah blah UML is worthless shite yadda yadda my company tried this and now I'm unemployed yackety schmackety snake oil blah blah this is the next revolution in software engineering yadda yadda that's a one-liner in Perl blah de blah there's no such thing as cross-platform blather blather the OMG ran over my dog, I wouldn't trust them mumble mumble you really should be reading the book by Hungadunga et. all babble babble duh, it's called the "Eggs Over-Easy" Pattern, stupid! burble snork why aren't you using W3C-standard XMLXSSTYXJW-XYZZY Transubstantiations? blah blah blah...
First of all, what is DHTML? Why not just call it "Scripting CSS and DOM with ECMAScript"? Calling it DHTML is confusing, because it makes it sound like a seperate version of HTML.
Honest question: there seems to be a lot of overlap between this book and other O'Reilly titles. Can anyone tell me why I would want this one rather than "HTML/XHTML, The Definitive Reference" and/or "Javascript, the Definitve Reference"?
Oh, great, and so thus we should kill off as many of the poor as possible so that drug companies can continue to make their money, huh?
No, it's people like you who would kill off the poor in third-world countries to satisfy your own notions of social justice. No government in history has ever equalled the kind of productivity that our competitive market creates - and you would take that productivity away from the search for lifesaving drugs.
As this article points out, one reason big drug companies are stepping away from AIDS drug innovation, at least, is because of AIDS activists and other anticorporate do-gooders. By forcing companies to practically give away their drugs to the third world, these misguided crusaders have removed all incentive from Big Medicine to research new AIDS drugs. Any new drug development requires an immense amount of R&D capital before a cent of profit can be made; and no intelligent CEO is going to throw billions at a product that'll wind up being either given away or copied illegally by third-world manufacturers.
That's exactly why a unified graphics toolkit is important - so that application programmers can stop wasting their time reinventing one-use unified GUI toolkits. Let the toolkit programmers write a unified toolkit once, and let the application programmers write their apps once for all backends.
I only suggested an "equivalent" to Windows.Forms because I don't know offhand whether Windows.Forms is a) part of the free ECMA standard; and b) suitably platform-agnostic that it could be usefully implemented in Gtk and Qt. If both of those are true, than I would *strongly* lean towards implementing Windows.Forms itself, since that signifigantly improve the chances of running.NET applications unchanged on Linux/etc.
Now, is this "wrapping SWF with Qt#" an actual plan? Sounds very interesting if it is.
Is not the requirement for such a plan to have both robust Qt# and Gtk# implementations? Saying that KDE and Gnome are duplicating their existing riff because both are working on interfaces for their respective toolkits for mono is jumping to conclusions.
Not necessarily. Using Qt# and Gtk# to implement the backends probably eases the impedence matching, but it also introduces yet another adapter layer (e.g. one to adapt Windows.Forms to Gtk#, one to adapt Gtk# to Gtk). The frontend has to call the actual Gtk/QT C/C++ libraries at some point, it's just a question of whether Windows.Forms is implemented directly in terms of those libraries, or mediated through another layer of Gtk#/Qt#. I'm not really prepared to make a value judgement of which is the "better" path.
Thanks for the reference to the Windows.Forms plans document though; I don't think I'd seen that before. The last impression I got was that Mono wasn't going to bother with Windows.Forms, at least not for the time being.
Very cool - but I want more
on
KDE Adopting Mono
·
· Score: 3, Insightful
This is an *excellent* sign, both of the ever-closer relationships of the GNOME and KDE people, and of good times ahead for coders..NET/Mono is a great step forward for hackers like me who want to be able pick the right language for the job, rather than being forced to choose the language that happens to have the needed libraries.
On the other hand, it looks like the GNOME and KDE teams are poised on duplicating the same rift that currently exists between free GUI toolkits. Rather than standardize on either Windows Forms or a similar alternative API, both projects are porting their own toolkit APIs to C#, in the form of Gtk# and Qt#. Which means that developers will *still* have to commit to one toolkit or the other for a given project, because the APIs are totally different.
The opportunity GNOME and KDE have with this agreement is huge: write a unified GUI API equivalent to Windows Forms, with both Gtk and Qt backends. Let developers write to the single API, and let end users view the results rendered by whichever toolkit they prefer. Yes, it would be a lot of work. Yes, it would involve a lot of impedence matching. Yes, for some applications it would still be necessary to use the underlying toolkit for effects which have no equivalent on the other toolkit. But the gains in Open Source productivity would be huge - a prime source of unnecessary duplication of effort, the idea that every good application has to be written twice, once for KDE and once for GNOME, would finally be eliminated.
Take the opportunity guys - the community will be thanking you for years.
I can't think of an O'Reilly book I own which isn't excellent. True, some of them are old classics like "UNIX Power Tools", and "Managing Projects with make". But their most recent books have been just as exemplary - the latest edition of the Camel book simply improves on the earlier editions. The "CVS Pocket Reference" is exactly what I needed for day-to-day CVS work. The latest edition of "Web Designer in a Nutshell" has a permanent spot on my desk now that I have a website.
I'd be jumping on the bandwagon without a second thought if this looked like something other than a couple of junior-high h4XX0r5' attempt at an impressive-sounding proclamation. As it is, I'd be a little embarrassed to put my name to it in it's current form. Hopefully the proposal itself is open-source and subject to bugfixes...?
All I can say is, now I don't feel quite so bad about missing out on all those.COM opportunities as I toiled away at my boring 'ole programming job at one of the largest defense contractors in the world...:-)
Nothing in the linux architecture prevents the problems that have plagued windows
Not true. In windows, the GUI code is intimately linked to the kernel, and cannot be separated out. In GNU/Linux, the two are completely divorced. To the kernel, X-Windows is merely another set of user-mode client processes - no more capable of bringing down the kernel than "grep" or Emacs. Theoretically, at least. In practice I have occasional X crashes that leave the system unusable - but these are most likely the fault of buggy video drivers f&*$ing with the hardware, not a kernel crash. As far as I can tell, even when this happens the kernel and other services are still ticking along happily - it's just unable to communicate with me.
True, the end result is the same (an unusable computer requiring a hard-reset) - but I know that if I ran a XFree86-free webserver on Linux I wouldn't even have to worry about the possibility of a GUI crash clobbering the system. The same cannot be said of NT/Win2000.
Refactoring has nothing to do with adding features or eliminating bugs. If you are doing either of those things, what you are doing is not refactoring. Refactoring is rearranging the internals of your code to eliminate duplication and increase modularity, without changing existing behaviour at all.
Slashdot Mirror
You mention Ruby (which is hardly "hyped" these days) and then you say "industry has a hard time catching on to Smalltalk". You haven't used Ruby have you?
Anyway, your comment essentially agrees with me. Academics are concerned with elegance and perfection. Engineers are concerned with whether something actually works, interoperates well, and solves the problem at hand.
Out of curiousity, exactly what did Smalltalk add to the field of remote invocation? And how was it better than what has come after? Smalltalk has influenced a lot of the best tools & techniques in software engineering, but RMI is one area where I hadn't noticed it having any impact.
All of the above. Each has brought improvements to some aspect to the development process in certain projects. Next question?
If it helps explain it at all, CORBA isn't known for being used by PHds. It's generally used by engineers in software companie3s trying to get real work done. Which is not to say that there's anything wrong with being a PHD; just that the academically oriented and the pragmatically oriented tend to use very different measures when determining a technology's worth.
Eiffel is on my list of languages to learn, and I've been wandering if the Free SmallEiffel is a complete, useful implementation; or whether the official EiffelStudio would be preferable. Anyone out there with experience in both?
...they're already hooked. I haven't had a windows PC in the house since I acquired stepkids (now ages 6 and 7), and so they didn't learn to expect it. Having once supported Windows computers for a living, I wasn't about to turn a couple of kids loose on one - I simply was not up to the maintenance headaches. With their own UNIX accounts I don't have to worry about them dragging the "windows" directory into the "trash can" or accidentally shutting down or just the general random crashiness of every MS OS I've worked with. They like The Gimp, and TuxPaint; Konqueror is in every way on par with IE these days for their web-surfing pleasure; and KDE is very easy to set up in a pretty, kid-friendly way. They haven't complained yet. If they ever start needing a lot of educational programs that Linux won't run I'll get them an iMac.
Blah blah blah failed idea blah blah unrealistic ivory tower academic fantasy blah blah cleaner in LISP yadda UNIX did this thirty years ago blah blah you should be using Python instead blah blah engineering methodologies are all crap blah blah no silver bullet blah blah C++ is for ninnies blah blah just start coding blah blah you should be using UML blah blah UML is worthless shite yadda yadda my company tried this and now I'm unemployed yackety schmackety snake oil blah blah this is the next revolution in software engineering yadda yadda that's a one-liner in Perl blah de blah there's no such thing as cross-platform blather blather the OMG ran over my dog, I wouldn't trust them mumble mumble you really should be reading the book by Hungadunga et. all babble babble duh, it's called the "Eggs Over-Easy" Pattern, stupid! burble snork why aren't you using W3C-standard XMLXSSTYXJW-XYZZY Transubstantiations? blah blah blah...
There, that should about cover it!
...and now everything looks like a nail. And the things that can't be made to look like nails he sees as unimportant.
It's a common enough malady among geniuses that have been too long surrounded by people telling them how smart they are.
First of all, what is DHTML? Why not just call it "Scripting CSS and DOM with ECMAScript"? Calling it DHTML is confusing, because it makes it sound like a seperate version of HTML.
Honest question: there seems to be a lot of overlap between this book and other O'Reilly titles. Can anyone tell me why I would want this one rather than "HTML/XHTML, The Definitive Reference" and/or "Javascript, the Definitve Reference"?
No, it's people like you who would kill off the poor in third-world countries to satisfy your own notions of social justice. No government in history has ever equalled the kind of productivity that our competitive market creates - and you would take that productivity away from the search for lifesaving drugs.
As this article points out, one reason big drug companies are stepping away from AIDS drug innovation, at least, is because of AIDS activists and other anticorporate do-gooders. By forcing companies to practically give away their drugs to the third world, these misguided crusaders have removed all incentive from Big Medicine to research new AIDS drugs. Any new drug development requires an immense amount of R&D capital before a cent of profit can be made; and no intelligent CEO is going to throw billions at a product that'll wind up being either given away or copied illegally by third-world manufacturers.
Now all they need is a 2-ton bag of popcorn...
He's been doing it, in print and online, many years longer than the word "blog" has existed.
Heh. I'm sure you'd like to think that's the truth. If it makes you happy, go on thinking it :-)
...it'll be longwinded, over-enthusiastic, and discarded as soon as Bruce moves on to his next programming fad.
At least, that's been my impression so far of Bruce "Shiny objects are neat!" Eckel.
...between software engineers and mere coders.
That's exactly why a unified graphics toolkit is important - so that application programmers can stop wasting their time reinventing one-use unified GUI toolkits. Let the toolkit programmers write a unified toolkit once, and let the application programmers write their apps once for all backends.
[See subject]
I only suggested an "equivalent" to Windows.Forms because I don't know offhand whether Windows.Forms is a) part of the free ECMA standard; and b) suitably platform-agnostic that it could be usefully implemented in Gtk and Qt. If both of those are true, than I would *strongly* lean towards implementing Windows.Forms itself, since that signifigantly improve the chances of running .NET applications unchanged on Linux/etc.
Now, is this "wrapping SWF with Qt#" an actual plan? Sounds very interesting if it is.
Not necessarily. Using Qt# and Gtk# to implement the backends probably eases the impedence matching, but it also introduces yet another adapter layer (e.g. one to adapt Windows.Forms to Gtk#, one to adapt Gtk# to Gtk). The frontend has to call the actual Gtk/QT C/C++ libraries at some point, it's just a question of whether Windows.Forms is implemented directly in terms of those libraries, or mediated through another layer of Gtk#/Qt#. I'm not really prepared to make a value judgement of which is the "better" path.
Thanks for the reference to the Windows.Forms plans document though; I don't think I'd seen that before. The last impression I got was that Mono wasn't going to bother with Windows.Forms, at least not for the time being.
This is an *excellent* sign, both of the ever-closer relationships of the GNOME and KDE people, and of good times ahead for coders. .NET/Mono is a great step forward for hackers like me who want to be able pick the right language for the job, rather than being forced to choose the language that happens to have the needed libraries.
On the other hand, it looks like the GNOME and KDE teams are poised on duplicating the same rift that currently exists between free GUI toolkits. Rather than standardize on either Windows Forms or a similar alternative API, both projects are porting their own toolkit APIs to C#, in the form of Gtk# and Qt#. Which means that developers will *still* have to commit to one toolkit or the other for a given project, because the APIs are totally different.
The opportunity GNOME and KDE have with this agreement is huge: write a unified GUI API equivalent to Windows Forms, with both Gtk and Qt backends. Let developers write to the single API, and let end users view the results rendered by whichever toolkit they prefer. Yes, it would be a lot of work. Yes, it would involve a lot of impedence matching. Yes, for some applications it would still be necessary to use the underlying toolkit for effects which have no equivalent on the other toolkit. But the gains in Open Source productivity would be huge - a prime source of unnecessary duplication of effort, the idea that every good application has to be written twice, once for KDE and once for GNOME, would finally be eliminated.
Take the opportunity guys - the community will be thanking you for years.
I can't think of an O'Reilly book I own which isn't excellent. True, some of them are old classics like "UNIX Power Tools", and "Managing Projects with make". But their most recent books have been just as exemplary - the latest edition of the Camel book simply improves on the earlier editions. The "CVS Pocket Reference" is exactly what I needed for day-to-day CVS work. The latest edition of "Web Designer in a Nutshell" has a permanent spot on my desk now that I have a website.
So - what titles would you warn against?
I'd be jumping on the bandwagon without a second thought if this looked like something other than a couple of junior-high h4XX0r5' attempt at an impressive-sounding proclamation. As it is, I'd be a little embarrassed to put my name to it in it's current form. Hopefully the proposal itself is open-source and subject to bugfixes...?
All I can say is, now I don't feel quite so bad about missing out on all those .COM opportunities as I toiled away at my boring 'ole programming job at one of the largest defense contractors in the world... :-)
Not true. In windows, the GUI code is intimately linked to the kernel, and cannot be separated out. In GNU/Linux, the two are completely divorced. To the kernel, X-Windows is merely another set of user-mode client processes - no more capable of bringing down the kernel than "grep" or Emacs. Theoretically, at least. In practice I have occasional X crashes that leave the system unusable - but these are most likely the fault of buggy video drivers f&*$ing with the hardware, not a kernel crash. As far as I can tell, even when this happens the kernel and other services are still ticking along happily - it's just unable to communicate with me.
True, the end result is the same (an unusable computer requiring a hard-reset) - but I know that if I ran a XFree86-free webserver on Linux I wouldn't even have to worry about the possibility of a GUI crash clobbering the system. The same cannot be said of NT/Win2000.
Refactoring has nothing to do with adding features or eliminating bugs. If you are doing either of those things, what you are doing is not refactoring. Refactoring is rearranging the internals of your code to eliminate duplication and increase modularity, without changing existing behaviour at all.