I *HATE* inline comments, stuff like resolution in your viewer can seriously fuck up the way the mail is displayed causing confusion about what belongs where.
Do you hate inline comments done badly by Outlook, or also inline comments done right,
like they used to be before HTML-formatted mail? The ones Outlook goes out of its way to break?
I'm not particularly fond of "see my comments below in red", "see my comments below in blue",... either.
Also when you do inline comments people getting into the conversation later on will have a hard time figuring out what belongs where and who said what, having replies going on top means it's easy to see who wrote what earlier.
I'm often Cc:ed late in top-posted conversations, and they are not much better.
Scrolling down to the bottom. No, they're talking about something else there.
Why is this mail 235K? Oh, everyone's mail disclaimer and BMP company logo has been repeated
over and over again. Did anyone trim the irrelevant crap? -- No. Did they change the subject line
when the subject changed? -- No.
The truth is, I guess, that it takes carefulness and taste from the authors to keep
a discussion readable.
A few thoughts (in no particular order), without having read many of
the other comments.
Accept that it will be painful at first, and that you'll feel stupid a lot of the time.
The original developers probably didn't 'get' all of this code at
any one time, either. I'm the "original developer" in such a scenario right
now, and I cannot always answer detailed questions in any other way than
"I wrote it like that, saw that I could trust it, knew that I could
go back to it when needed, and then chose to forget the details".
Find a personal channel to the requirements and/or users. If you don't know what the code is supposed to do, you're fscked. And I don't mean what some paper says it should do, but what the *users* expects it to do. (I'm assuming there is a user base, and you're job is to push changes to them.)
Don't piss off those users. Be their friend, listen to them, understand their needs.
In return you can get things like better bug reports, better help testing new features, and
a big motivational factor.
Basic hygiene, if the original developers missed it:
turn on all compiler warnings, use tools like valgrind on the code.
Fix the build system if it sucks.
Learn tools to navigate the code *efficiently*, if you don't already.
For me they are
the Unix tools: emacs, find, grep, perl, nm and make. Probably others work
on other platforms and for other languages. I've never tried any new-fangled tools for that,
and doubt they work well, but your mileage may vary.
After working with the code for a while, you'll see patterns in it.
So that when you fix a certain feature, you'll see which subsystems probably aren't
involved and which ones can probably be trusted to do their job (even if they suck).
With a 4"'er, you're not going to get any detail out of Jupiter or Saturn. No cloud bands on Jupiter -- just the moons as points of light. Saturn will look like [this] or [this] if you're lucky.
I don't have my 1983 notebook with me, but I could have sworn I saw banding on Jupiter.
And Saturn definitely looks better than those dark blurs in your links.
But really we're only talking about that because the poster Has a Telescope and Thus Must Use It.
The cool stuff is to look at an unpolluted night sky in general:
the constellations,
the Milky Way,
the different colors of the stars,
planets (letting the kids guess which one you see), meteors, Polaris, the Pleiades, the Andromeda galaxy.
For that, a telescope is just in the way. What you need for that the naked eye,
and binoculars for some of the time.
Could I go out on a limb here and ask why error handling is considered a black art, requiring truckloads of books to understand? I've done well following a few basic rules;
1. Know exactly what the system call does before you use it.
2. Check the return value of every one.
3. Check the permissions when you access a resource.
4. Blocking calls are a necessary evil. Putting them in the main loop is not.
5. Always check a pointer before you use it. ...
*Detecting* the problem isn't hard. What's hard is *handling* it -- and there was nothing about that on your list. Hint: calling abort(2) is not always acceptable.
For anyone familiar with the basics of unit testing but struggling to implement it in real world scenarios, I'd strongly recommend xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros.
Aargh! They managed to mention unit tests, patterns and refactoring in the same title!
Also, I really dislike xUnit, as I've seen it wedged into Python's unittest module and CPPUnit (C++).
It's a horrible design which just gets in the way -- I don't understand what valid reasons a book has to rely on it (except buzzword compilance).
The idea is not only that automated testing is good, but that testable code is fundamentally better because it needs to be loosely coupled.
And loosely coupled code is fundamentally better *why*?
"Because it can be easily unit tested" is the only argument I can swallow...
Loose coupling was a popular catchphrase in the early 1990s (along with Software Reuse),
but that kind of thinking is the source of lots of overly-general and vague code.
The subtext of this article is that you should forget about letting users create content on the Internet, because all they do is create junk and try to scam good honest people. Just leave the content creation to the institutions, and media conglomerates who know how to do it. It's safer that way, and you'll like it.
You're reading too much into it, and you are also misled by the misquote in the,/ title.
The article said "95% of user-generated posts on Web sites are spam or malicious",
probably meaning postings in forums, "comments" and stuff like that.
They're not saying plain web pages by *authors* who aren't faceless corporation drones
are crap.
I love how prefixing anything with "Method and apparatus for implementing..." makes the obvious sound non-obvious, at least to an (un)reasonable person.
Yeah, and it invokes the image of a dude with a handlebar moustache circa 1890 carrying some complicated machine
made of brass and polished hardwood into the patent office.
The thing is, I don't see really any benefit for this. Google docs doesn't exactly offer more features, most netbooks come with at least 20 gigs of storage (even the SSD based ones) and performance is only increasing.
Can you still get SSD netbooks? I see none for sale here.
My old Acer Aspire One came with a 8GB one, and OpenOffice.
(Of course, that Lin-pus stuff was useless so I blew it all away, and installed Debian.
Without OpenOffice; if you like word processors, you're probably better off with Windows.)
"I had to rip out all the ATI drives I'm getting from rpmfusion"
So you were not only using a test OS but you even merged it with third party providers and you still are surprised because things breaks. [etc]
And also, *his* problem that he's buying hardware with no free driver support,
rewarding hardware vendors who try to make life hard for their users.
(Apart from that, I don't see "running in 2D" as a big enough problem to make me cash out $$$ for Windows 7.
Isn't it simpler and cheaper to buy a non-broken graphics card?)
I think it works better for a phone than a computer. We're use to our computers being open, just finding software ourselves online or browsing computer software aisles and reading the backs of boxes.
Phones, for the most part, have always been closed boxes, [...]
Exactly. That's why I refuse to use a phone for anything but making calls
-- I'm not used to being locked up and kept in the dark.
The computers I've used have always been hackable and programmable.
But he most definitely would have to be classified something today. I mean, you really can't be just Calvin (or Tom, or Bill) any more. You need to be classified.
I really doubt anyone was thinking in "what type of kid is Calvin" terms when the comic was first released...
No, but I remember thinking "oh boy, this Calvin guy is going to be really fucked up
by the time he's fifteen". There was always that dark side of C&H to me.
The finger certainly points in the direction of the chinese. HOWEVER, It could just as easily be the US, the chinese rights groups or any other group looking to discredit china.
Google "Tiananmen Square Massacre" or "Tibet". Seems to me that those activists don't have to
manufacture any proof.
It is really unfortunate the IDE's let people change the tab setting and even more unfortunate that IDE's like Eclipse and IntellJ come with it incorrectly set to 4 spaces. This has the effect of totally buggering the code when viewed in any context other than one with the same settings. Printers and most code viewers use an 8 character tab stop.
Yes things work fine if you forbid mixing tabs and spaces in indent but, in my experience this does not work in practice.
Especially not since Eclipse also enables indent-with-TABs by default -- if you have to tell everyone
to reconfigure their editors anyway, you might as well tell them to fix their TAB width.
(I have never actually seen it stated before that Eclipse comes with broken TAB settings,
but we have had a lot of problems at work with broken code, which could be traced to Eclipse users.
I just found it hard to believe a major IDE could be that broken by default.
Unfortunately, *they* don't see the problem and the rest of us cannot find our way in Eclipse's myriad
of configuration options.)
This is 2010, why are we sill saving code in dumb text files like in 1960?
Because binary formats are unpopular, and any other format is well, just a text file.
I'd argue that XML is a binary format for all practical purposes.
All your normal tools for handling text files are useless with it,
so you need custom-made tools. Just like with a binary format.
"Dumb" text files gives us freedom. Freedom to choose our own tools,
freedom to let different tools cooperate, that kind of stuff.
That's the somewhat circular argument that works either way around - mandate one convention then have someone different use the other and your convention is broken and things don't look right. The difference is that "use tabs as the convention" lets you be flexible with indent width between developers
Seriously, you people who argue for this one must all use IDEs and never let the code out of the IDE.
In my world, code gets
copy&pasted into mail, Usenet, README files, various document formats
run through less(1), grep(1) etc and viewed on a Unix terminal
diffed and merged in various tools
printed on paper (rarely)
With "indent with TABs" as a rule, I'd have to look at the code with an 8-space indent
in almost all of the cases above, because even though text editors often have the modify-the-tab-width
feature, most tools *don't*. Even if they had, there's no way I'd reconfigure my whole environment
every five minutes between the normal 8-width-TAB mode and a shorter one like 4.
I think most people agree that an 8-spaced indent width is hell to read, regardless of
programming language.
As it is now, tabs are a total mess. Go take a look at any open source project that has more than one contributor. You'll find all sorts of mixed space+tabs indentations.
I don't doubt that there are spaces hidden in many blocks of TAB-indented code, and vice versa.
I just have never seen that as a problem. But I don't misconfigure my editor with tab-width!=8.
People who misconfigure will see a mess.
I hope that's educational for them: it shows clearly that you cannot misconfigure your tab-width
and cooperate with others.
Not in plain text without any metadata for describing the TAB settings used.
I can remember two or three science fiction stories that had flying cars. No more. In all of them very few owned such a vehicle. Most of them are from the 1940's.
What kind of SF was that?
Seems to me that half of Philip K Dick's stories had flying cars. (With the hero stuck in traffic
jams on his way to work, and contemplating suicide.)
Git, mercurial, monotone, etc. are all ready nice, and do pretty much the same thing, but it's annoying to have to use the one that the project leader decides on.
I can't help reading that as "Git, mercurial, monotone, etc. are all ready nice, and do pretty much the same thing, but I want to use a different one which I think is much better and which noone actually *working* in the project wants to use".
If you think they all do the same thing, why not use the one other's are using?
My biggest problem with much of OSS is that the documentation is terrible. Try figuring out what the *right* way to do a "poll" type call on Linux is
You mean poll(2)?
It's not Linux's job to provide free tutorials for programming against the POSIX APIs.
That's what you buy "Advanced programming in the Unix environment" for.
If you're referring to the poll(2) man page, don't expect it to be a tutorial.
(There is a select_tut(2) man page, but that's a rare exception.)
Sorry, Elastic Tabstops solve nothing. That is just yet another way of interpreting a tab character. The problem with tabs is the tab character itself and the fact that different rendering mechanisms interpret it differently. If you type a tab in an editor which renders it as an 8-character indentation and I view it in an editor which renders it as a 4-character indentation, then what I see is not what you intended.
Sure -- because you have misconfigured your tools.
It's not my fault -- just as its not my fault the text is upside-down if you have turned your monitor
upside down.
(But as you see I agree that "Elastic Tabstops" is a bad idea.)
The only thing which works consistently is to use a fixed-width font and space characters for indentation. Any programmer who doesn't grasp this and who puts tabs into his code is obviously not a good rational thinker and is thus probably not a very good programmer.
No, rational thinking here would be: TAB is useless unless everyone interprets it the same.
Terminal emulators, printers and all sane program defaults choose 8 spaces, therefore I should
use 8-spaced TABs, and ignore people who modify their tools to use some other setting -- they have
already fscked it up for themselves and will not notice the extra pain.
Perhaps the GP planned to unzip his skin down the back, peel it forward, and present his entire "surface area" to the sun? ** shudder **
There are lots of options; the human body is flexible. Remember that Goatse guy?
I bet there are other areas of the human body which can be slowly trained and stretched over time,
until finally you are able to zip down your pants and fold out your bright green, photosyntesizing scrotum.
(Oh, how I miss alt.tasteless from the early 1990s...)
It would be insightful if it were talking about something else.
Using the command line to read email is hardly a 'good' way to go about it.
It works and is usable for some, but even most shell users use 'a gui' like Pine or the like.
OK, so mailx(1) isn't the perfect mail client (didn't support MIME, last time I checked).
But Nasa using Outlook, a sucky client tied with a proprietary interface to MS Exchange -- what's up with that?
Slashdot Mirror
Do you hate inline comments done badly by Outlook, or also inline comments done right, like they used to be before HTML-formatted mail? The ones Outlook goes out of its way to break? I'm not particularly fond of "see my comments below in red", "see my comments below in blue", ... either.
I'm often Cc:ed late in top-posted conversations, and they are not much better. Scrolling down to the bottom. No, they're talking about something else there. Why is this mail 235K? Oh, everyone's mail disclaimer and BMP company logo has been repeated over and over again. Did anyone trim the irrelevant crap? -- No. Did they change the subject line when the subject changed? -- No.
The truth is, I guess, that it takes carefulness and taste from the authors to keep a discussion readable.
I don't have my 1983 notebook with me, but I could have sworn I saw banding on Jupiter. And Saturn definitely looks better than those dark blurs in your links.
But really we're only talking about that because the poster Has a Telescope and Thus Must Use It. The cool stuff is to look at an unpolluted night sky in general: the constellations, the Milky Way, the different colors of the stars, planets (letting the kids guess which one you see), meteors, Polaris, the Pleiades, the Andromeda galaxy. For that, a telescope is just in the way. What you need for that the naked eye, and binoculars for some of the time.
*Detecting* the problem isn't hard. What's hard is *handling* it -- and there was nothing about that on your list. Hint: calling abort(2) is not always acceptable.
Aargh! They managed to mention unit tests, patterns and refactoring in the same title!
Also, I really dislike xUnit, as I've seen it wedged into Python's unittest module and CPPUnit (C++). It's a horrible design which just gets in the way -- I don't understand what valid reasons a book has to rely on it (except buzzword compilance).
And loosely coupled code is fundamentally better *why*? "Because it can be easily unit tested" is the only argument I can swallow ...
Loose coupling was a popular catchphrase in the early 1990s (along with Software Reuse), but that kind of thinking is the source of lots of overly-general and vague code.
You're reading too much into it, and you are also misled by the misquote in the ,/ title.
The article said "95% of user-generated posts on Web sites are spam or malicious",
probably meaning postings in forums, "comments" and stuff like that.
They're not saying plain web pages by *authors* who aren't faceless corporation drones
are crap.
Yeah, and it invokes the image of a dude with a handlebar moustache circa 1890 carrying some complicated machine made of brass and polished hardwood into the patent office.
Can you still get SSD netbooks? I see none for sale here. My old Acer Aspire One came with a 8GB one, and OpenOffice. (Of course, that Lin-pus stuff was useless so I blew it all away, and installed Debian. Without OpenOffice; if you like word processors, you're probably better off with Windows.)
And also, *his* problem that he's buying hardware with no free driver support, rewarding hardware vendors who try to make life hard for their users.
(Apart from that, I don't see "running in 2D" as a big enough problem to make me cash out $$$ for Windows 7. Isn't it simpler and cheaper to buy a non-broken graphics card?)
Exactly. That's why I refuse to use a phone for anything but making calls -- I'm not used to being locked up and kept in the dark. The computers I've used have always been hackable and programmable.
No, but I remember thinking "oh boy, this Calvin guy is going to be really fucked up by the time he's fifteen". There was always that dark side of C&H to me.
Google "Tiananmen Square Massacre" or "Tibet". Seems to me that those activists don't have to manufacture any proof.
Especially not since Eclipse also enables indent-with-TABs by default -- if you have to tell everyone to reconfigure their editors anyway, you might as well tell them to fix their TAB width.
(I have never actually seen it stated before that Eclipse comes with broken TAB settings, but we have had a lot of problems at work with broken code, which could be traced to Eclipse users. I just found it hard to believe a major IDE could be that broken by default. Unfortunately, *they* don't see the problem and the rest of us cannot find our way in Eclipse's myriad of configuration options.)
I'd argue that XML is a binary format for all practical purposes. All your normal tools for handling text files are useless with it, so you need custom-made tools. Just like with a binary format.
"Dumb" text files gives us freedom. Freedom to choose our own tools, freedom to let different tools cooperate, that kind of stuff.
Seriously, you people who argue for this one must all use IDEs and never let the code out of the IDE. In my world, code gets
With "indent with TABs" as a rule, I'd have to look at the code with an 8-space indent in almost all of the cases above, because even though text editors often have the modify-the-tab-width feature, most tools *don't*. Even if they had, there's no way I'd reconfigure my whole environment every five minutes between the normal 8-width-TAB mode and a shorter one like 4.
I think most people agree that an 8-spaced indent width is hell to read, regardless of programming language.
I don't doubt that there are spaces hidden in many blocks of TAB-indented code, and vice versa. I just have never seen that as a problem. But I don't misconfigure my editor with tab-width!=8. People who misconfigure will see a mess. I hope that's educational for them: it shows clearly that you cannot misconfigure your tab-width and cooperate with others. Not in plain text without any metadata for describing the TAB settings used.
What kind of SF was that? Seems to me that half of Philip K Dick's stories had flying cars. (With the hero stuck in traffic jams on his way to work, and contemplating suicide.)
I can't help reading that as "Git, mercurial, monotone, etc. are all ready nice, and do pretty much the same thing, but I want to use a different one which I think is much better and which noone actually *working* in the project wants to use". If you think they all do the same thing, why not use the one other's are using?
You mean poll(2)? It's not Linux's job to provide free tutorials for programming against the POSIX APIs. That's what you buy "Advanced programming in the Unix environment" for.
If you're referring to the poll(2) man page, don't expect it to be a tutorial. (There is a select_tut(2) man page, but that's a rare exception.)
s/ in gdb//
Sure -- because you have misconfigured your tools. It's not my fault -- just as its not my fault the text is upside-down if you have turned your monitor upside down. (But as you see I agree that "Elastic Tabstops" is a bad idea.)
No, rational thinking here would be: TAB is useless unless everyone interprets it the same. Terminal emulators, printers and all sane program defaults choose 8 spaces, therefore I should use 8-spaced TABs, and ignore people who modify their tools to use some other setting -- they have already fscked it up for themselves and will not notice the extra pain.
There are lots of options; the human body is flexible. Remember that Goatse guy? I bet there are other areas of the human body which can be slowly trained and stretched over time, until finally you are able to zip down your pants and fold out your bright green, photosyntesizing scrotum.
(Oh, how I miss alt.tasteless from the early 1990s ...)
Wasn't that what Larry Wall was doing at the JPL when he invented Perl?
OK, so mailx(1) isn't the perfect mail client (didn't support MIME, last time I checked). But Nasa using Outlook, a sucky client tied with a proprietary interface to MS Exchange -- what's up with that?