X has changed a lot from the early versions to the modern ones, and there have been numerous Window managers and operating environments over the years. I would have liked to have seen more discussion of that
They could have added a screenshot of a default X11 desktop, with twm, xbiff and xterm, at least.
Also, what about Sun's aborted alternative, Sunview?
Yeah, only it wasn't all that abortive. I was still using it in 1990/91; the Sun graphical workstations had been around
for many years by then, and our site still regarded X as an
experimental add-on.
Also, I disagree with "[Open Look, Motif and other X-based GUIs] were simple GUIs that attempted to mimic the appearance of Microsoft Windows...".
They were complex and powerful, not simple.
And I don't think their designers took Windows 2.0 or 3.0 seriously -- there were many GUIs around at the time if you wanted fresh ideas, and Windows was never one of the more impressive ones.
Quoting the man page of Ted Faber's implementation:
grap is an implementation of Kernighan and Bentley's language for type-
setting graphs, as described in ``Grap-A Language for Typesetting Graphs,
Tutorial and User Manual,'' by Jon L. Bentley and Brian W. Kernighan,
revised May 1991, which is the primary source for information on how to
use grap. As of this writing, it is available electronically at
http://www.kohala.com/start/troff/cstr114.ps
It ties in with TeX and troff rather than with fancy
word processors though.
The problem with Debian's philosophy of hanging onto old software, is that often this old software is obsolete and doesn't get patches or fixes anymore, so you're running insecure software.
To point out what should be well-known: the Debian guys provide those patches. That's pretty much what the Debian stable workflow means:
watch what happens to the packages upstream, and backport the security fixes. Do nothing else.
For me, this meant that during Woody, I could work my ass off in a different part of the country for two years, pretty much ignore maintenance on the server in the closet back home, and be reasonably sure it was safe. People running other distributions would have ended up with something unsupported there, or spent time and effort on one or more upgrades.
Like text editing, the specific methods and tools that different people use for file management can vary tremendously.
... which leads me to suggest that you shouldn't
spend too much time devising clever schemes for your users.
Encourage them to learn and to reconfigure for themselves.
Find, write, or rewrite a cheat sheet for the most common
stuff, and mention how to find the man pages.
Buy a handful of O'Reilly books (which title?) and sprinkle them throughout the officescape.
Navigating the directory hierarchy and editing the command line efficiently seem to be universal problems, so you might want to fine-tune the prompt, completion and editing keys a bit, and teach people that ^A, ^E and ^U exist. And ^R in bash.
I've seen so many people waste time retyping the same thing
over and over again...
Whatever you do, don't create a maze of global config files which source each other to pick up various clever configurations... you will get it wrong, especially when your site goes multi-OS, and noone will dare change their dotfiles for fear of breaking some important path or variable somewhere...
I really hate having parameters documented in a comment block above the function declaration, because it seldom gets updated when the function signature itself is changed.
I hate both that method and the alternative you describe, and I've had to use both.
Look at any random Unix manpage (Linux execve(2) for example, or strncpy(3)). I prefer to write and read complete
sentences about the arguments -- because they only make sense in relation to each other, you cannot explain one without
explaining the other.
In my experience, documentation that explains arguments enumeration-style often ends up saying obvious things about the arguments, and forgetting to say important things about the function itself.
I like Opera's "Notes" feature. Mark a piece of relevant text on the page you want to remember, and choose "Copy to note". The notes are collected in a long, flat, searchable list of quoted pieces of text, without title, and with a link back to the URL.
Surprisingly useful. I use it a lot more that the traditional bookmarks.
I don't think it's the processor time that the virus scanner takes up that annoys users, it's all the disk fragging that it does. Dual-core really isn't going to help much there.
Yes, of course this is the case. The massive disk I/O, plus what (at least in W2K) seems to be very bad disk caching/VM strategies is what makes antivirus scanners kill performance.
Tthe magazine article's writer should have known this.
I don't like the fact that if blocks end with 'fi', case blocks with 'esac', but loop block end with 'done'. Even more disturbing is the subblocks of a case statment. they end with ';;'. Where is the logic?...
Fish has a consistent block syntax borrowed from MATLAB...
This is how I always imagined csh got started, except s/MATLAB/C/... and we all know how that ended.
(Not that there isn't anything good about csh -- tcsh is my preferred shell, until I have the time to hack zsh to do tab completion the way I want it -- set autolist=ambiguous; set complete=enhance)
"Bad programming" has many points to it. I'd include using an old-fashioned language like C or C++ in a system which does not require huge speed or efficiency (which is almost everything these days). It increases the development time of a project, increases the code complexity, increases the chances of runtime bugs, and increases the potential severity of what bugs you do have.
C may be old-fashioned, but please don't
lump C++ in with it. Chances are you haven't even seen modern C++ source code, which in practice has
little to do with C source other than that you can link to C libraries easily.
That said, I'm all for programming in higher-order languages (e.g. Python) and I prefer to do
so, but some problems are better solved in C++ or
even C. It doesn't even have to be about efficiency; things like static type checking can
be essential in large programs when it's hard to
test all code paths.
I use C++. I don't literally use "assert" (which is a macro, not a statement in C++), beause in C++ it is throw-away code. It stops working once NDEBUG is undefined.
No, it stops working if you explicitly define NDEBUG.
Someone wrote that turning off checks in production code is like unbuckling your seatbelt when you leave the driveway. I read that, and believed it. So much for assert.
You seem to believe that assert calls magically disappear when you least expect them to. That is not true, of course. You control them.
For C++, Bjarne Stroustrup's book discusses assert() and how to replace it with exceptions. I would be surprised if BOOST didn't contain a wealth of assertion/design-by-contract support.
Also, I wouldn't quickly right off thin-client server systems as being technologically backwards. It takes some amount of neat tech to make a thin client seem as, or near as, rich as a full workstation.
You're from the Windows world, right?
Getting a few Unix servers to advertise themselves to a network of X terminals is trivial, and has been so for at least fifteen years.
I've worked at a company with such a setup, and I failed to see the disadvantages compared to having my own CPU and disk. And in that particular case, we usually had a dozen heavy simulations running on each server...
Just think long and hard when you design it. There's nothing annoying than having to overhaul your code becuase a function/class syntax has been changed.
And don't just think -- use the thing
for real-life work yourselves.
I cannot see how one can come up with a good interface without that feedback.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 1
the const keyword: if you want to make your codebase a whole lot safer, and compile AND run faster, const is great. (Yes I know it finally became part of the C language with the C99 standard...)
Yes, const is immensely useful. It's compiler-enforced documentation: "Hi, ny name is foo and I'm a function. I take this terribly complicated object as a parameter, but I don't intend to change it one bit, and I can prove it".
But it's not new in C99. It's in the C language since 1989. Just look at your not-exclusively-C99 <string.h> for examples.
If memory serves me right, it wasn't introduced into C until early C++ implementations had played around with it and shown that it worked, though.
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 1
One key difference that will never change and is important is C++ is weakly typed and Java is strongly typed.
People keep saying this, and I fail to understand why. C++ has a few implicit conversions: bool/integers, different integers to each other, char/integer, and one-directional between enums/integers and std::strings/const char *. And probably some more. That's a tiny, tiny fraction of all types used in your typical C++ program, and it's IMHO not enough reason to call the language "weakly typed" -- if this phrase has a meaning at all.
This means types are guaranteed at compile time where as in C++ you can do all types of great/terrible things.
Some of that is actually more common in Java than in C++, I think -- casting up from type Object to the type you think is right, and catch any problems at runtime.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
I might need to read that data 10 years from now. Of course, you could define a format and document it well, and provide an API to access it which will run on whatever system I am using 10 years from now, but let's face it, you won't.
And how is XML different here? The tags in the file don't magically describe the semantics...
Having implemented more or less the same data storage API on top of simple text files and XML, I can state that XML eats much less programmer time. All the parsing and worrying about funny characters was done for me by a library.
So I don't believe I'm trolling when I ask: can somebody explain to me why I shouldn't consider the failure of this to become a movie anything other than a benefit to mankind?
Because others feel different about the series, of course.
I remember watching part of the first season and finding it unremarkable. So I stopped watching until I think late in season two -- and then I got completely hooked. I still believe seasons three and four of B5 is some of the best TV I've seen. It certainly beats hyped movies like LoTR and the Star Wars prequels.
Examples: the whole Londo/G'Kar theme; the whole USA-turns-into-a-totalitary-state theme; Garibaldi's and Ivanova's stories...
I can't believe all of that is crap, when it affected me and others so much.
Watch your DVDs carefully. You might be missing out on something valuable.
I sincerely hope noone worries today about
a speed difference between those two expressions
(if we're talking C here;
there is no NULL in C++ or Java).
No reasonable compiler would miss that opportunity.
Personally, I prefer the !p form;
I find it is clearer to say "p is an invalid pointer" than saying "p is equal to the the NULL pointer".
It is interesting to talk about readability vs. optimization, but this example is way too simple to be interesting.
The biggest problem I have with programs, is the way they make you hop all over to input data. If you can just go from input box to input box, flowing continously, then its a good UI design. The biggest problem I have with data entry programs is that they force me to use them. The biggest usability gain I ever got was when I threw out a form-based GUI and let the application accept (after syntax checking) text files. Text files; these I can create by filling in templates in my favorite text editor, generate from scripts, or whatever. Your mileage may vary, of course.
Well, even Motif Window Manager lets you iconify running apps Motif? Hell, that functionality was in twm(1). It's always been there. Multiple desktops were the next step of course, and that's why I run ctwm(1). Maybe there's something better around the corner, and maybe not.
Tracy Kidder's "Soul of a New Machine"... is about managing small, highly motivated teams effectively.
Or about how to make people enjoy sacrificing themselves, burning themselves out, for a machine that's forgotten a few years later. I'm not sure that's a nice thing to do. It's a fascinating book, though. Fred Moody's I Sing the Body Electronic is similar.
Its always best... NOT to implement a saveMe() Method in every object i think
(Nitpick mode)... because there can be hundreds of +0 orcish daggers lying around the dungeon, and writing a save method for each of them is tedious.
You both mean classes, not objects. And I'm not sure this SRP principle is applicable here -- every object needs to be able to describe itself in some way if this is ever going to work.
Editing Java in vi is one of the biggest waste of time I can imagine.
Me too.
But I suspect the book covered vim, not vi.
That's a modern, good programmer's editor.
Personally, I've used Emacs for all kinds of
text editing for ten years, and I can't see why
I should learn another, inferior one just because I happen to be programming in Java rather than C, C++, Python or Perl at a certain point in time...
My then-girlfriend found African violets to be very very picky
It depends. I have a few Saintpaula rupicola which, basically, grow like weed. Much less sensitive than the hybrids which you usually see offered for sale.
Yes. Revision control is one of those brilliantly simple ideas which are hard to "get" unless you've used it. And I'm talking about even trivial things such as using RCS on a single file.
Developers who try to avoid revision control are very common. Developers who do it because they're told to, but never really use it to make their work easier -- I'd say that's the rule.
Also note that non-developers have almost as much to gain as developers from revision control. Basically, 0% of the people who write books or reports use revision control.
Slashdot Mirror
They could have added a screenshot of a default X11 desktop, with twm, xbiff and xterm, at least.
Also, what about Sun's aborted alternative, Sunview?
Yeah, only it wasn't all that abortive. I was still using it in 1990/91; the Sun graphical workstations had been around for many years by then, and our site still regarded X as an experimental add-on.
Also, I disagree with "[Open Look, Motif and other X-based GUIs] were simple GUIs that attempted to mimic the appearance of Microsoft Windows...". They were complex and powerful, not simple. And I don't think their designers took Windows 2.0 or 3.0 seriously -- there were many GUIs around at the time if you wanted fresh ideas, and Windows was never one of the more impressive ones.
grap is an implementation of Kernighan and Bentley's language for type- setting graphs, as described in ``Grap-A Language for Typesetting Graphs, Tutorial and User Manual,'' by Jon L. Bentley and Brian W. Kernighan, revised May 1991, which is the primary source for information on how to use grap. As of this writing, it is available electronically at http://www.kohala.com/start/troff/cstr114.ps
It ties in with TeX and troff rather than with fancy word processors though.
To point out what should be well-known: the Debian guys provide those patches. That's pretty much what the Debian stable workflow means: watch what happens to the packages upstream, and backport the security fixes. Do nothing else.
For me, this meant that during Woody, I could work my ass off in a different part of the country for two years, pretty much ignore maintenance on the server in the closet back home, and be reasonably sure it was safe. People running other distributions would have ended up with something unsupported there, or spent time and effort on one or more upgrades.
... which leads me to suggest that you shouldn't spend too much time devising clever schemes for your users. Encourage them to learn and to reconfigure for themselves.
Navigating the directory hierarchy and editing the command line efficiently seem to be universal problems, so you might want to fine-tune the prompt, completion and editing keys a bit, and teach people that ^A, ^E and ^U exist. And ^R in bash. I've seen so many people waste time retyping the same thing over and over again ...
Whatever you do, don't create a maze of global config files which source each other to pick up various clever configurations ... you will get it wrong, especially when your site goes multi-OS, and noone will dare change their dotfiles for fear of breaking some important path or variable somewhere ...
I hate both that method and the alternative you describe, and I've had to use both.
Look at any random Unix manpage (Linux execve(2) for example, or strncpy(3)). I prefer to write and read complete sentences about the arguments -- because they only make sense in relation to each other, you cannot explain one without explaining the other.
In my experience, documentation that explains arguments enumeration-style often ends up saying obvious things about the arguments, and forgetting to say important things about the function itself.
Surprisingly useful. I use it a lot more that the traditional bookmarks.
Yes, of course this is the case. The massive disk I/O, plus what (at least in W2K) seems to be very bad disk caching/VM strategies is what makes antivirus scanners kill performance. Tthe magazine article's writer should have known this.
This is how I always imagined csh got started, except s/MATLAB/C/ ... and we all know how that ended.
(Not that there isn't anything good about csh -- tcsh is my preferred shell, until I have the time to hack zsh to do tab completion the way I want it -- set autolist=ambiguous; set complete=enhance)
C may be old-fashioned, but please don't lump C++ in with it. Chances are you haven't even seen modern C++ source code, which in practice has little to do with C source other than that you can link to C libraries easily.
That said, I'm all for programming in higher-order languages (e.g. Python) and I prefer to do so, but some problems are better solved in C++ or even C. It doesn't even have to be about efficiency; things like static type checking can be essential in large programs when it's hard to test all code paths.
No, it stops working if you explicitly define NDEBUG.
Someone wrote that turning off checks in production code is like unbuckling your seatbelt when you leave the driveway. I read that, and believed it. So much for assert.
You seem to believe that assert calls magically disappear when you least expect them to. That is not true, of course. You control them.
For C++, Bjarne Stroustrup's book discusses assert() and how to replace it with exceptions. I would be surprised if BOOST didn't contain a wealth of assertion/design-by-contract support.
You're from the Windows world, right? Getting a few Unix servers to advertise themselves to a network of X terminals is trivial, and has been so for at least fifteen years. I've worked at a company with such a setup, and I failed to see the disadvantages compared to having my own CPU and disk. And in that particular case, we usually had a dozen heavy simulations running on each server ...
And don't just think -- use the thing for real-life work yourselves. I cannot see how one can come up with a good interface without that feedback.
Yes, const is immensely useful. It's compiler-enforced documentation: "Hi, ny name is foo and I'm a function. I take this terribly complicated object as a parameter, but I don't intend to change it one bit, and I can prove it".
But it's not new in C99. It's in the C language since 1989. Just look at your not-exclusively-C99 <string.h> for examples.
If memory serves me right, it wasn't introduced into C until early C++ implementations had played around with it and shown that it worked, though.
People keep saying this, and I fail to understand why. C++ has a few implicit conversions: bool/integers, different integers to each other, char/integer, and one-directional between enums/integers and std::strings/const char *. And probably some more. That's a tiny, tiny fraction of all types used in your typical C++ program, and it's IMHO not enough reason to call the language "weakly typed" -- if this phrase has a meaning at all.
This means types are guaranteed at compile time where as in C++ you can do all types of great/terrible things.
Some of that is actually more common in Java than in C++, I think -- casting up from type Object to the type you think is right, and catch any problems at runtime.
And how is XML different here? The tags in the file don't magically describe the semantics ...
Having implemented more or less the same data storage API on top of simple text files and XML, I can state that XML eats much less programmer time. All the parsing and worrying about funny characters was done for me by a library.
Two words for you: lex and yacc ...
Because others feel different about the series, of course.
I remember watching part of the first season and finding it unremarkable. So I stopped watching until I think late in season two -- and then I got completely hooked. I still believe seasons three and four of B5 is some of the best TV I've seen. It certainly beats hyped movies like LoTR and the Star Wars prequels.
Examples: the whole Londo/G'Kar theme; the whole USA-turns-into-a-totalitary-state theme; Garibaldi's and Ivanova's stories ...
I can't believe all of that is crap, when it affected me and others so much.
Watch your DVDs carefully. You might be missing out on something valuable.
Personally, I prefer the !p form; I find it is clearer to say "p is an invalid pointer" than saying "p is equal to the the NULL pointer".
It is interesting to talk about readability vs. optimization, but this example is way too simple to be interesting.
The biggest problem I have with programs, is the way they make you hop all over to input data. If you can just go from input box to input box, flowing continously, then its a good UI design.
The biggest problem I have with data entry programs is that they force me to use them. The biggest usability gain I ever got was when I threw out a form-based GUI and let the application accept (after syntax checking) text files. Text files; these I can create by filling in templates in my favorite text editor, generate from scripts, or whatever.
Your mileage may vary, of course.
Well, even Motif Window Manager lets you iconify running apps
Motif? Hell, that functionality was in twm(1). It's always been there. Multiple desktops were the next step of course, and that's why I run ctwm(1). Maybe there's something better around the corner, and maybe not.
Or about how to make people enjoy sacrificing themselves, burning themselves out, for a machine that's forgotten a few years later. I'm not sure that's a nice thing to do. It's a fascinating book, though. Fred Moody's I Sing the Body Electronic is similar.
(Nitpick mode) ... because there can be hundreds of +0 orcish daggers lying around the dungeon, and writing a save method for each of them is tedious.
You both mean classes, not objects. And I'm not sure this SRP principle is applicable here -- every object needs to be able to describe itself in some way if this is ever going to work.
"Let's hear it for the vague blur!"
Me too. But I suspect the book covered vim, not vi. That's a modern, good programmer's editor.
Personally, I've used Emacs for all kinds of text editing for ten years, and I can't see why I should learn another, inferior one just because I happen to be programming in Java rather than C, C++, Python or Perl at a certain point in time ...
It depends. I have a few Saintpaula rupicola which, basically, grow like weed. Much less sensitive than the hybrids which you usually see offered for sale.
Yes. Revision control is one of those brilliantly simple ideas which are hard to "get" unless you've used it. And I'm talking about even trivial things such as using RCS on a single file. Developers who try to avoid revision control are very common. Developers who do it because they're told to, but never really use it to make their work easier -- I'd say that's the rule.
Also note that non-developers have almost as much to gain as developers from revision control. Basically, 0% of the people who write books or reports use revision control.