You can do either. Either way you gain and lose. I personally have a hard time with the kitchen sink approach, preferring C as my programming environment. This leaves me in the cold as far as contributing to, say, mythtv, but then I can contribute to other projects, like lirc.
I think you should learn some scripting language, too.
It hurts to see people coding simple Perl one-liners in pages of C.
Pur differently, learning at least one "scripting" language would free up time
and energy so you could write more worthwhile C code.
As for the original poster:
I believe the Unix Way is alive and well, and that it will prevail.
More importantly, I believe it's the best and most fun way.
I stay away from monoliths, frameworks and cults.
My tools are shell script, Perl, Python and C++. C if I need to interface with
the many C people out there.
That covers most needs. Sed and awk have been eaten by Perl already.
Add to that knowledge of special-purpose tools like make, graphviz, gnuplot,
troff,... Generating input to those tools often makes a major programming
project boil down to a small perl script.
I was already cleaning up after other people's messes when I started my second job (in my early twenties) practically straight out of college. It's called maintenance programming, everyone (of every age and skill level) has to do it sooner or later, even if it's to their own code.
You make maintenance sound a bit negative.
I actually like it -- provided I have the power to do more than
apply band-aids. It's rewarding to start with a complete mess, apply one of a
handful of techniques, and end up with code which does the same thing,
but which is obviously correct.
I'm not sure why the community settled on spaces-only rather than tabs-only. Perhaps it was to accommodate users of lousy text editors that don't let you redefine tab width, or to accommodate users who like to print their code out or view it in console pagers, where tabs would get expanded to the unwieldy 8-space "standard".
Or accomodate users who aren't the one person who wrote the code and knew exactly
how he configured his text editor?
I am surprised that people still believe you can redefine the size of a tab from 8
without causing chaos.
I work on two code bases in parallel. One was written with TAB misconfigured as 4,
and I have to edit my ~/.emacs and start two copies to work with them at once.
Reindenting would be impolite, since that would break version control.
I'm sorry, but this whole TAB/SPACE thing would be a non-issue,
unless there were idiots who thought they could make TAB 2, 3, 4,.., wide.
"As much as I like Linux, I don't think I ever brought into the "unix" way. Communicating via text is fine, but it doesn't seem really efficient."
I have a background in traditional embedded systems and the idea that OS's like Linux actually call text-based command-line tools before the system boots boggles my mind.
Unix definitely served the needs of the times it was created in (i.e. small programs performing small tasks).
So the Unix way was fine in the 1970s but now, when we have so much CPU power so
we cannot find a way to waste it, it's too slow?
You may be trolling, but I say it anyhow:
process spawning is fast in Unix, and so is parsing text data and executing shell scripts.
None of this has been an issue for at least twenty years.
What good are multiple languages if all inter-language integration have to be funneled through some narrow C-like basic model?
Thirty years of success for us Unix users doesn't feel like a waste of time...
It's through C APIs I have access to thousands of libraries for various
tasks. I have them in Python, Perl and all other major scripting languages
too -- but only because those C APIs exist.
Sure, a richer interface than C function calls would have been nice.
But it would have failed, and I prefer something which works.
C works because it's a lowest common denominator which everyone who counts can agree on.
You are also ignoring the most useful inter-language integration:
pipelines, text file formats and communication using standard protocols
on top of TCP/IP. See The Art of Unix Programming for
additional arguments.
It may have been a little brighter last night, but the difference was almost certainly imperceptible. It was still an extremely marginal naked-eye object -- you need really dark skies to see it without binoculars or a telescope.
I see the comet tonight in my trusty East German Zeiss Jenoptem binoculars. It's a cloud, a bit more dim
than the Andromeda galaxy, but clearly visible even with the light pollution.
Neat.
As a bonus, I got to see Saturn again. I lost track of it in Gemini a few years back...
The 1 GB limitation is probably due to the way they have the kernel compiled. The Linux kernel has a 1 GB limitation unless you have High Memory enabled. If I remember correctly, the kernel runs faster if High Memory is disabled, which is why Dell probably has the kernel configured that way.
Doesn't sound quite right -- unless you're doing really weird things, very little CPU is spent
in the Linux kernel. Spending 0.2% or 0.3% of your CPU in the kernel isn't noticeable.
I can't tell much from the code on the link, but I do see #define used for constants which is no longer appropriate (yet is EXTREMELY common to see). C99 had the const keyword in it, probably even before that.
C got const much earlier; it was there in 1989.
And at least in the past, a static const int FOO was less useful than #define FOO,
it wasn't "constant enough" to define the size of an array.
But yes, you see macros too often.
Apple would've called it "iShare" or something else friendly and inviting. Who does MS hire to come up with those horrid, unwieldy names?
Maybe the same guy who came up with "HP OpenView Configuration Management Application Self-Service Manager".
It's so unwieldy, even making an acronym of it doesn't help: HPOVCMASSM.
(What it is? Kind of apt-get for Windows, done badly.)
Also, there's this thing called Java which has a portable VM, extensive, mature libraries and several languages to choose from... If only people wrote more applications for the Java platform. There is also WINE.
First, Java sux. Sure, it's a great idea, but in practice the performance, or lack thereof, kills it.
Java sux, but performance considerations do not kill Perl, Python,/bin/sh or any number of
other good languages.
What kills Java is that many Unix hackers don't like it. And all its bloody three-letter acronyms.
I've had the same problem with metafont. The 'f' is even closer to the 'v' than the 'c' is. And the worst thing is, you can't even kill mf with ctrl-c. You have to ctrl-z out of it, then `kill -9 %1`.
Sending SIGKILL around should be the last resort...
Ctrl-D appears to work as expected, although it leaves an annoying log file in the current directory.
Thankfully, I've never accidentally invoked Metafont.
We should also look at "Ender's Game" as a classic example of a moral issue presented in a sci-fi wrapper.
Listing examples is really damning SF with faint praise, at least if we're talking
printed SF. The genre stopped being meaningless, cheesy entertainment some time before WWII.
You can't work with CC effectively without 20-30 helper scripts.
Where do people get ideas like this?
I use CC effectively with one trivial Perl script.
It converts "my feature is on this branch off this label" descriptions into config specs
-- raw config specs are too complicated to handle, so you need a layer above them
which matches your CM process.
Yes, IBM/Rational should explain that to their customers. Or maybe make UCM not suck.
Hijacked/checked-out files is major pain.
Then you're not branching, like you're supposed to do, and a hijacked file is the *least* of your problems.
You cannot use CC as if it was CVS; a dynamic view is not a sandbox if you set it up
to silently show other people's possibly incomplete changes.
Dynamic views are great feature yet are completely useless.
Use them correctly for a few years, then report back.
The C++ Programming Language, 3rd Edition is pretty excellent.
While I agree that it's an excellent read, let's not jump the gun. Bjarne's 3rd edition does not teach C++ from the bare-ground up. This tome, as no other words seems to do justice to the words contained within, has been written almost entirely with generic programming in mind - that is, it begins by twisting the reader's mind with templates.
I don't own the 3rd edition, but I'm pretty sure
it doesn't focus on generic programming,
start with templates,
or try to twist anyone's mind.
It gets my vote as my favorite tech book for the
last few chapters about design, life as a programmer
and so on. Stroustrup deserves a lot of credit for that non-C++
part of the book.
When my uncle died, we inherited photos in boxes, photos in albums, and negatives, some 50+ years old. We don't know who many of the people are. I have scanned many of the significant photos - I assume they're significant because they're enlargements which would have been costly. The chances of the people being identified reduce every year as relatives die off.
[...]
There's a reason we change jobs, a reason we get new friends and lose old ones, a reason we grow old and die: it's because it's important to not be burdened by the past, burdened by our own legacy, to forget, to move on...
That's one opinion, but... don't you feel you're losing something valuable which cannot
be recreated?
We've gone through my grandparent's papers in recent years (although they died in the early 1980s).
There were photos:
my grandfather working in the fields,
his brothers as dressed-up immigrants in the USA,
my uncles playing soccer or fishing,
school photos from first grade where I knew some of the children as old men...
These are valuable to me.
I don't want to live as if there was nothing before me.
So we can blame him for giving Hubbard his start? Not something I'd brag about.;)
That was before Dianetics and Scientology. Hubbard was just a sci-fi author back then, before he found he could get rich by other means.
The only reason we're talking about Hubbard is ignorance.
We don't know enough
about what Ackerman really ought to be remembered for.
I know him mostly as an anthology editor.
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
Suppose you have a programmer who's 10x as fast as your benchmark standard guy at producing tested, debugged code that meets requirements, but slower at writing docs. Do you make him write docs, or attach a junior programmer to him for that purpose?
Maybe your "docs" isn't the same thing as his "documentation".
The former sounds much like "write a MS Word document full of boilerplate crap just to make
the process people happy, not to actually be helpful to anyone".
I think a useful guideline is: if you can delegate the documentation, it's not worth doing.
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness.
He did. In fact, he spent more time proving the program correct than it took to write, test, run, debug, and fix, the program, and then the proof still has to be checked for correctness. I learned the Dijkstra techniques for proving code. Even something as painfully simple as proving a loop invariant holds and would terminate was mind-numbingly difficult and tedious,
I disagree. That stuff has been really useful to me in my daily work.
Not formalized, but as a way to look at code.
I can usually look at a loop for a while (no pun intended) and see that it is correct,
or for which input states it's not. Others throw something together which happens to pass a
few sloppy unit tests, then forget about it and move on.
and still fails to be correct in the presence of concurrency.
If you choose to ignore concurrency even though you know there is
concurrency, that's your fault. Not some dead Dutch guy's.
Conversely, some rock stars are shaman-like figures for modern times. I'm picturing guys like Jimi Hendrix, Robert Plant, Iggy Pop, Peter Gabriel while in Genesis, David Byrne while in The Talking Heads (particularly in albums such as Remain In Light and Speaking In Tongues), Ian Astbury while in The Cult, Wayne Coyne of The Flaming Lips, most certainly extreme characters like GG Allin, or Wendy O. Williams of The Plasmatics. I'd even go out on a limb and place Freddie Mercury on my list.
All the talk out there regarding the "viral" nature of GPL code has confused a lot of otherwise very smart people. What happens is that they miss the dividing line between "the development" and "the use" of the programs.
Huh? Please elaborate on that.
I thought the whole point of the GPL was that there is no such dividing line:
if you're a user, you have the right to hack it too.
No, actually, line-based diff is almost entirely useless with written documents. You either have "soft" or "dynamic" word wrap (one line per paragraph), or "static" word wrap (newline on the end of each line). In the first case, a single change in a paragraph marks the *whole* paragraph as changed, and in the second case, a single change causes the paragraph to need to be re-wrapped and again the whole thing is marked as a change.
For written text (latex, html, or plain text), you probably need to use something like wdiff.
This isn't a problem in practice, if you use the formatters you mention (LaTeX, HTML).
Neither for plain text; you're supposed to have real \n breaks between lines in plain text,
and I rarely see any text files which don't.
Either people do not re-break the text when they edit a paragraph, in which case the diff is one line.
Or, they *do* re-break it (using M-q in emacs or whatever) and you have a full-paragraph diff.
That's not bad either; if two people have made changes to the same paragraph, it's probably
better that one of them is forced to review them; a change in the first sentence can
change the meaning of the second.
Pardon me if I'm wrong but isn't subversion entirely line based?
Yes, it works with text files. (You can store binary files but they can't be merged automatically.) So that does make it unsuitable for documents saved from a word processor, unless you save in text format and add the formatting as the last step.
Those of us who demand version control put that differently:
"So that makes word processors unsuitable for documents under version control".
As soon as you choose to use one instead of LaTeX, troff, HTML, MediaWiki markup or some XML variant,
you lock yourself (and the people you work with) into something, and out of other things
(real version control, spellcheckers, all Unix tools...)
And basic version control isn't hard. I do it all the time with my non-geek brother.
It's not hard to work together on a document:
type away, "svn up", review his changes (if any), resolve conflicts (if any, and find out
what misunderstanding makes us work on the same paragraph), "svn ci" with some sensible
description of what I've done, type away... and so on.
On a more serious note: I dislike emacs because it's a prime example of the "inner-platform effect". It's nearly as wrong as implementing an e-mail application in HTTP+HTML+CSS+JS.;)
There are some parallels, but webmail sucks and takes control away from the user.
Emacs doesn't lock you in.
This does not mean that I dislike the (default) UI of emacs, or the freedom to customize (in fact I love that freedom). Just please stop adding another useless but fat layer to it.
Fat layers? Those odd emacs things aren't layers, they are elisp code which just
sits around in your file system unless you pull it in.
Unless you speak of the character set and mixed-font support oddities.
I wonder if people really use emacs as their environment these days.
We have X and/or screen for multiple terminals with scrollback, searching and everything,
and the shells have better interactive features...
I use emacs as an advanced multiple-buffer text editor, and little else.
Slashdot Mirror
I think you should learn some scripting language, too. It hurts to see people coding simple Perl one-liners in pages of C. Pur differently, learning at least one "scripting" language would free up time and energy so you could write more worthwhile C code.
As for the original poster: I believe the Unix Way is alive and well, and that it will prevail. More importantly, I believe it's the best and most fun way. I stay away from monoliths, frameworks and cults. My tools are shell script, Perl, Python and C++. C if I need to interface with the many C people out there. That covers most needs. Sed and awk have been eaten by Perl already.
Add to that knowledge of special-purpose tools like make, graphviz, gnuplot, troff, ... Generating input to those tools often makes a major programming
project boil down to a small perl script.
You make maintenance sound a bit negative. I actually like it -- provided I have the power to do more than apply band-aids. It's rewarding to start with a complete mess, apply one of a handful of techniques, and end up with code which does the same thing, but which is obviously correct.
Or accomodate users who aren't the one person who wrote the code and knew exactly how he configured his text editor?
I am surprised that people still believe you can redefine the size of a tab from 8 without causing chaos. I work on two code bases in parallel. One was written with TAB misconfigured as 4, and I have to edit my ~/.emacs and start two copies to work with them at once. Reindenting would be impolite, since that would break version control.
I'm sorry, but this whole TAB/SPACE thing would be a non-issue, unless there were idiots who thought they could make TAB 2, 3, 4, .., wide.
So the Unix way was fine in the 1970s but now, when we have so much CPU power so we cannot find a way to waste it, it's too slow?
You may be trolling, but I say it anyhow: process spawning is fast in Unix, and so is parsing text data and executing shell scripts. None of this has been an issue for at least twenty years.
Thirty years of success for us Unix users doesn't feel like a waste of time ...
It's through C APIs I have access to thousands of libraries for various tasks. I have them in Python, Perl and all other major scripting languages too -- but only because those C APIs exist. Sure, a richer interface than C function calls would have been nice. But it would have failed, and I prefer something which works. C works because it's a lowest common denominator which everyone who counts can agree on.
You are also ignoring the most useful inter-language integration: pipelines, text file formats and communication using standard protocols on top of TCP/IP. See The Art of Unix Programming for additional arguments.
I see the comet tonight in my trusty East German Zeiss Jenoptem binoculars. It's a cloud, a bit more dim than the Andromeda galaxy, but clearly visible even with the light pollution. Neat. As a bonus, I got to see Saturn again. I lost track of it in Gemini a few years back ...
Doesn't sound quite right -- unless you're doing really weird things, very little CPU is spent in the Linux kernel. Spending 0.2% or 0.3% of your CPU in the kernel isn't noticeable.
C got const much earlier; it was there in 1989. And at least in the past, a static const int FOO was less useful than #define FOO, it wasn't "constant enough" to define the size of an array. But yes, you see macros too often.
Maybe the same guy who came up with "HP OpenView Configuration Management Application Self-Service Manager". It's so unwieldy, even making an acronym of it doesn't help: HPOVCMASSM.
(What it is? Kind of apt-get for Windows, done badly.)
Java sux, but performance considerations do not kill Perl, Python, /bin/sh or any number of
other good languages.
What kills Java is that many Unix hackers don't like it. And all its bloody three-letter acronyms.
Like scp(1) or rsync(1), then? Scp comes with any sensible ssh installation, and rsync is very widely used.
Sending SIGKILL around should be the last resort ...
Ctrl-D appears to work as expected, although it leaves an annoying log file in the current directory.
Thankfully, I've never accidentally invoked Metafont.
Listing examples is really damning SF with faint praise, at least if we're talking printed SF. The genre stopped being meaningless, cheesy entertainment some time before WWII.
Where do people get ideas like this? I use CC effectively with one trivial Perl script. It converts "my feature is on this branch off this label" descriptions into config specs -- raw config specs are too complicated to handle, so you need a layer above them which matches your CM process. Yes, IBM/Rational should explain that to their customers. Or maybe make UCM not suck.
Then you're not branching, like you're supposed to do, and a hijacked file is the *least* of your problems. You cannot use CC as if it was CVS; a dynamic view is not a sandbox if you set it up to silently show other people's possibly incomplete changes.
Use them correctly for a few years, then report back.
I don't own the 3rd edition, but I'm pretty sure it doesn't focus on generic programming, start with templates, or try to twist anyone's mind.
It gets my vote as my favorite tech book for the last few chapters about design, life as a programmer and so on. Stroustrup deserves a lot of credit for that non-C++ part of the book.
That's one opinion, but ... don't you feel you're losing something valuable which cannot
be recreated?
We've gone through my grandparent's papers in recent years (although they died in the early 1980s). There were photos: my grandfather working in the fields, his brothers as dressed-up immigrants in the USA, my uncles playing soccer or fishing, school photos from first grade where I knew some of the children as old men ...
These are valuable to me.
I don't want to live as if there was nothing before me.
The only reason we're talking about Hubbard is ignorance. We don't know enough about what Ackerman really ought to be remembered for. I know him mostly as an anthology editor.
Maybe your "docs" isn't the same thing as his "documentation". The former sounds much like "write a MS Word document full of boilerplate crap just to make the process people happy, not to actually be helpful to anyone". I think a useful guideline is: if you can delegate the documentation, it's not worth doing.
I disagree. That stuff has been really useful to me in my daily work. Not formalized, but as a way to look at code. I can usually look at a loop for a while (no pun intended) and see that it is correct, or for which input states it's not. Others throw something together which happens to pass a few sloppy unit tests, then forget about it and move on.
If you choose to ignore concurrency even though you know there is concurrency, that's your fault. Not some dead Dutch guy's.
But you missed the obvious -- Jim Morrison.
Life changing: yes. But let's make one thing clear: being adopted without knowing does not make your life a lie.
Huh? Please elaborate on that. I thought the whole point of the GPL was that there is no such dividing line: if you're a user, you have the right to hack it too.
This isn't a problem in practice, if you use the formatters you mention (LaTeX, HTML). Neither for plain text; you're supposed to have real \n breaks between lines in plain text, and I rarely see any text files which don't.
Either people do not re-break the text when they edit a paragraph, in which case the diff is one line.
Or, they *do* re-break it (using M-q in emacs or whatever) and you have a full-paragraph diff. That's not bad either; if two people have made changes to the same paragraph, it's probably better that one of them is forced to review them; a change in the first sentence can change the meaning of the second.
Those of us who demand version control put that differently: "So that makes word processors unsuitable for documents under version control".
As soon as you choose to use one instead of LaTeX, troff, HTML, MediaWiki markup or some XML variant, you lock yourself (and the people you work with) into something, and out of other things (real version control, spellcheckers, all Unix tools ...)
And basic version control isn't hard. I do it all the time with my non-geek brother. It's not hard to work together on a document: type away, "svn up", review his changes (if any), resolve conflicts (if any, and find out what misunderstanding makes us work on the same paragraph), "svn ci" with some sensible description of what I've done, type away ... and so on.
There are some parallels, but webmail sucks and takes control away from the user. Emacs doesn't lock you in.
Fat layers? Those odd emacs things aren't layers, they are elisp code which just sits around in your file system unless you pull it in. Unless you speak of the character set and mixed-font support oddities.
I wonder if people really use emacs as their environment these days. We have X and/or screen for multiple terminals with scrollback, searching and everything, and the shells have better interactive features ...
I use emacs as an advanced multiple-buffer text editor, and little else.