Okay, it probably wasn't the best example, I know there are plenty of GUI programs that can do the particular manipulation I described, and do it very well. On the other hand, GUI systems which can perform arbitrary complex file manipulations are much rarer.
People keep talking about GUI data-manipulation systems with the power of command pipelines started from the Unix shell. Once someone has got something working that's half as flexible as the Unix command line (and as easy to write new programs which integrate seamlessly into the system) I'll be more than glad to give it a try.
For now, however, I firmly believe that the command line has it's place, and I'm sure there'll be at least a few xterms on my desktop for a long time to come.
It's a while since I read the original article now, but it really didn't give me the impression that he was trying to universally bash GUIs -- Quite the opposite, he freely admitted that he ran X on his Unix machines. What he was trying to emphasise was something that most Unix users take for granted, while others have forgotten it: the command line still has it's own unique power, and plenty of users.
As just a simple example, today a friend complained to me that a fairly sophisticated program was refusing to import his data. I eventually tracked the problem down to lines being terminated with CRLF, when the program was just expecting LF. Luckily he was using a unix machine and a quick
tr -d "\r" < file.dat > file.nocr.dat
and everything was sorted out. That kind of simple file manipulation can be really awkward on a pure GUI. Of course, I realise that the program should have been more tolerant about its input data. But it wasn't, and there wasn't anything we could do about it. The command line saved hours of worry and hassle.
Of course, the converse is also true. There are many kinds of applications which do require a GUI. Fortunately, Unix users can get the best of both worlds. Let's just enjoy that position.
It's a while since I read the original article now, but it really didn't give me the impression that he was trying to universally bash GUIs -- Quite the opposite, he freely admitted that he ran X on his Unix machines. What he was trying to emphasise was something that most Unix users take for granted, while others have forgotten it: the command line still has it's own unique power, and plenty of users.
As just a simple example, today a friend complained to me that a fairly sophisticated program was refusing to import his data. I eventually tracked the problem down to lines being terminated with CRLF, when the program was just expecting LF. Luckily he was using a unix machine and a quick
tr -d "\r" file.dat >file.nocr.dat
and everything was sorted out. That kind of simple file manipulation can be really awkward on a pure GUI. Of course, I realise that the program should have been more tolerant about its input data. But it wasn't, and there wasn't anything we could do about it. The command line saved hours of worry and hassle.
Of course, the converse is also true. There are many kinds of applications which do require a GUI. Fortunately, Unix users can get the best of both worlds. Let's just enjoy that position.
It's nice to see that there's going to be some kind of resolution for the `what compiler should I use' question. But I can't help feeling that it's just a little bit arrogant for the GNU project to come along and `accept' other people's work, when their own compiler project was obviously going nowhere fast. On this basis, of course it's possible to say that n% of code in a Linux distribution is GNU code. But shouldn't be the emphasis really be on getting some hacking done, not adding the GNU stamp of aproval to something we already know to be a good compiler supported by a healthy and active development team?
Code-bloat is a valid concern. There's a strong argument that we really shouldn't need PII-350s with 10gig hard discs. That said, I do agree with your main point: this isn't an excuse for techno-luddism. The solution to code-bloat is to write small, self-contained modules (something the Mozilla people now seem to have got the hang of rather well).
It's amazing to see so many negative reactions to an announcement which, to my mind, just confirms the commitment of mozilla.org to interesting, creative, hacking. This doesn't mean extra delay and bloat before we see a release browser. Really.
Mozilla work on all kinds of projects beyond the direct push towards the codebase for Netscape 5.0. All those handy development tools, for a start. Plus oddballs such as ElectricalFire and Grendel. This is just another idea that's being bounced around. I really don't expect it to take away programmer time from work on the main browser core. But on the otherhand, maybe some of us would like to hack on this.
Complaining won't do any good -- if you don't want to code, just sit back and wait for 5.0, then use it however you like. Or don't, if you prefer, it doesn't really matter. On the other hand, if you do want to take control then get coding, or documenting, or testing, or whatever takes your fancy. This can be your project just as much as it is AOL's. Get to it.
But, they are right when they say it is crappy. I do understand that writting a browser is a huge task, but, if you look at other projects like KDE and gnome (other HUGE tasks), they are delivering something.
Once you start looking closely at what Mozilla offers, I think you'll that it's at least as big a project as the DEs, maybe even bigger. Yet it's only been seriously off the ground for six months or so. The DEs took a lot longer than that, and are still getting a lot of polishing done to them.
Okay, M4 had plenty of bugs. But look a little deeper and there was also plenty of stuff which works great, and works today. It's getting there.
Anyway, even if they can't get back their old market share under windows, we Unix users still need a decent browser from somewhere...
A lot of people have said something to this effect -- but actually the original source which Netscape released was more-or-less functional (albeit rather awkward to build). It's only quite recently that the NGLayout-based system has overtaken the `classic' Mozilla in terms of functional features. But realistically, the chances of the average coder coming in and hacking Mozilla Classic without taking weeks to get up to speed were negligable. The new code is a lot smaller and tidier: it may not be perfect, but at least new coders have a chance with it.
The Mozilla project has now reached the stage where new coders have the choice between hacking existing modules or working on completely new ones (Necko, for instance). Hopefully it can now make good progress, to a 5.0 release and beyond.
I replaced the aging RedHat installation on my main workstation with Debian 2.1 the other day, and yes, it's a very nice distribution. And in some ways I think the package management is done nicer.
Once the main installation was done, getting KDE going took about five minutes:).
It depends very much what you want to do with them. For simple integer stuff they can work quite well, but remember: a) they have no floating point hardware and b) their memory bus is limited to 32 bits @66MHz, or only a third of the bandwidth a Pentium II can manage, and a rather meagre fraction of the latest Alphas.
A new architecture would be cool, especially if it's MIPS based. But remember, processor price/performance isn't necessarily what matters. Get decent-quality standard motherboards which take your processors in the shops at less that $150 and you're probably onto a winner.
With Linux you need to compile an SMP-aware kernel. With 2.0 you need to uncomment a line in the makefile. 2.2 (which is well worth it if you're using SMP) just has a configuration switch. NT is much the same, I believe, except you just need to install the SMP kernel off the install discs.
Applications generally don't need to know or care about SMP, unless you have some specific program which only launches extra threads if you tell it to. e.g. gmake, which will benefit from being invoked with the flag -j
Why do you want SMP? If there are lots of `medium-size' jobs (e.g. serving CGI to vast numbers of users) it's worthwhile. If you just want to do your own work, you're only likely to really get the best of it if you write custom software.
I don't think I'd ever recommend 2x P200 instead of 1x PII, unless you already have a lot of the bits you need and feel like building a budget SMP box for fun. Of course, if you already have a PII and still need more then SMP obvious becomes a much better prospect.
Erm, does anyone bother static-linking things these days (yes, yes, I know you need to once in a while, but...). Somehow I don't think it'll make any difference.
Although anyway Corel may stick to their decision to use WINE, rather than switching to Twine.
First of all, they don't have to release source unless they distribute binary software. They haven't broken any licences yet, as far as I can tell.
Secondly, I very much doubt you'll get anything terribly exciting out of the patches they've applied to Linux -- most of the kernel is really pretty portable these days, the main bits which aren't are all hardware-related, and a lot of these can just be ditched when you're running on a simulator.
Of course, I'm sure a lot of people would like to take a peek at the compiler. Not least Intel and everyone else who's struggling to write a decent compiler for Merced. I suspect they'll be keeping the important parts of that under their hats though, at least for the time being.
...given that they have themselves done a (fairly reasonably) Windows box for OS/2. Yes, I know that's a slightly different situation, but even so...
He seems a little anti-Java, too, which is not at all the way IBM as a whole seems to be doing. Earlier poster has it right, this guy really isn't authorative.
Neither were really intended for doing graphical/windowed stuff. Tcl, on the other hand, has a mature, fast, cross-platform windowing toolkit. And there happen to already be Tcl/Tk plugins available for both Netscape and IE.
Personally I like Java quite a lot. But once in a while I get the feeling that Tcl is still a better-developed system for writing secure, windowed, cross-platform code. And I sure wish I knew why people were so scathing of it.
Programming will certainly change a lot over that time scale (not sure about disappear, people have been predicting that for a while now...). Even so, I'd say that whatever happens, the skills that make you a hacker are about the best preperation she is likely to get for whatever the future may throw at her.
You can pass-by-reference perfectly well using upvar. No, it's not the way C handles things, but so what?
I know Tcl does look very strange to people trying it for the first time after C or the like. That doesn't necessarily mean it's inaccessible to the novice programmer. I suggested it because, with Tk, it allows a newcomer to do a lot (especially graphics) very quickly. Tk canvases are really no harder to use than logo turtle graphics, and can do an awful lot more. Most Basics (haven't looked at Visual Basic myself but...) can't come close.
I'd be interested to know the answer to this one too. My feeling is that probably the best way to learn is the way we all did---by writing programs, plain and simple. When I was learning there were magazines with lots of listings to type in and debug---I guess these days books will have to do instead.
As for languages, I'm not sure Basic is really the answer any more---it looks horribly primitive. Java might be nice, although still a bit complicated. Actually the best bet might be (of all things) Tcl. I know it looks strange but for a first-timer this doesn't really matter. It's simple and (with Tk) you can do all kinds of cool graphics and windowing stuff right from day one.
Slashdot Mirror
People keep talking about GUI data-manipulation systems with the power of command pipelines started from the Unix shell. Once someone has got something working that's half as flexible as the Unix command line (and as easy to write new programs which integrate seamlessly into the system) I'll be more than glad to give it a try.
For now, however, I firmly believe that the command line has it's place, and I'm sure there'll be at least a few xterms on my desktop for a long time to come.
Ooops, sorry for the duplicates -- I thought I was hitting preview, and must have submitted instead :(.
As just a simple example, today a friend complained to me that a fairly sophisticated program was refusing to import his data. I eventually tracked the problem down to lines being terminated with CRLF, when the program was just expecting LF. Luckily he was using a unix machine and a quick
and everything was sorted out. That kind of simple file manipulation can be really awkward on a pure GUI. Of course, I realise that the program should have been more tolerant about its input data. But it wasn't, and there wasn't anything we could do about it. The command line saved hours of worry and hassle.Of course, the converse is also true. There are many kinds of applications which do require a GUI. Fortunately, Unix users can get the best of both worlds. Let's just enjoy that position.
As just a simple example, today a friend complained to me that a fairly sophisticated program was refusing to import his data. I eventually tracked the problem down to lines being terminated with CRLF, when the program was just expecting LF. Luckily he was using a unix machine and a quick
and everything was sorted out. That kind of simple file manipulation can be really awkward on a pure GUI. Of course, I realise that the program should have been more tolerant about its input data. But it wasn't, and there wasn't anything we could do about it. The command line saved hours of worry and hassle.Of course, the converse is also true. There are many kinds of applications which do require a GUI. Fortunately, Unix users can get the best of both worlds. Let's just enjoy that position.
It's nice to see that there's going to be some kind of resolution for the `what compiler should I use' question. But I can't help feeling that it's just a little bit arrogant for the GNU project to come along and `accept' other people's work, when their own compiler project was obviously going nowhere fast. On this basis, of course it's possible to say that n% of code in a Linux distribution is GNU code. But shouldn't be the emphasis really be on getting some hacking done, not adding the GNU stamp of aproval to something we already know to be a good compiler supported by a healthy and active development team?
Code-bloat is a valid concern. There's a strong argument that we really shouldn't need PII-350s with 10gig hard discs. That said, I do agree with your main point: this isn't an excuse for techno-luddism. The solution to code-bloat is to write small, self-contained modules (something the Mozilla people now seem to have got the hang of rather well).
Mozilla work on all kinds of projects beyond the direct push towards the codebase for Netscape 5.0. All those handy development tools, for a start. Plus oddballs such as ElectricalFire and Grendel. This is just another idea that's being bounced around. I really don't expect it to take away programmer time from work on the main browser core. But on the otherhand, maybe some of us would like to hack on this.
Complaining won't do any good -- if you don't want to code, just sit back and wait for 5.0, then use it however you like. Or don't, if you prefer, it doesn't really matter. On the other hand, if you do want to take control then get coding, or documenting, or testing, or whatever takes your fancy. This can be your project just as much as it is AOL's. Get to it.
Okay, M4 had plenty of bugs. But look a little deeper and there was also plenty of stuff which works great, and works today. It's getting there.
Anyway, even if they can't get back their old market share under windows, we Unix users still need a decent browser from somewhere...
The Mozilla project has now reached the stage where new coders have the choice between hacking existing modules or working on completely new ones (Necko, for instance). Hopefully it can now make good progress, to a 5.0 release and beyond.
Once the main installation was done, getting KDE going took about five minutes :).
A new architecture would be cool, especially if it's MIPS based. But remember, processor price/performance isn't necessarily what matters. Get decent-quality standard motherboards which take your processors in the shops at less that $150 and you're probably onto a winner.
Applications generally don't need to know or care about SMP, unless you have some specific program which only launches extra threads if you tell it to. e.g. gmake, which will benefit from being invoked with the flag -j
I don't think I'd ever recommend 2x P200 instead of 1x PII, unless you already have a lot of the bits you need and feel like building a budget SMP box for fun. Of course, if you already have a PII and still need more then SMP obvious becomes a much better prospect.
Although anyway Corel may stick to their decision to use WINE, rather than switching to Twine.
...that the Mozilla guys have scheduled some ;).
downtime in half an hour or so. Presumably in
anticipation of being slashdotted
Secondly, I very much doubt you'll get anything terribly exciting out of the patches they've applied to Linux -- most of the kernel is really pretty portable these days, the main bits which aren't are all hardware-related, and a lot of these can just be ditched when you're running on a simulator.
Of course, I'm sure a lot of people would like to take a peek at the compiler. Not least Intel and everyone else who's struggling to write a decent compiler for Merced. I suspect they'll be keeping the important parts of that under their hats though, at least for the time being.
He seems a little anti-Java, too, which is not at all the way IBM as a whole seems to be doing. Earlier poster has it right, this guy really isn't authorative.
Personally I like Java quite a lot. But once in a while I get the feeling that Tcl is still a better-developed system for writing secure, windowed, cross-platform code. And I sure wish I knew why people were so scathing of it.
Programming will certainly change a lot over that time scale (not sure about disappear, people have been predicting that for a while now...). Even so, I'd say that whatever happens, the skills that make you a hacker are about the best preperation she is likely to get for whatever the future may throw at her.
I know Tcl does look very strange to people trying it for the first time after C or the like. That doesn't necessarily mean it's inaccessible to the novice programmer. I suggested it because, with Tk, it allows a newcomer to do a lot (especially graphics) very quickly. Tk canvases are really no harder to use than logo turtle graphics, and can do an awful lot more. Most Basics (haven't looked at Visual Basic myself but...) can't come close.
As for languages, I'm not sure Basic is really the answer any more---it looks horribly primitive. Java might be nice, although still a bit complicated. Actually the best bet might be (of all things) Tcl. I know it looks strange but for a first-timer this doesn't really matter. It's simple and (with Tk) you can do all kinds of cool graphics and windowing stuff right from day one.