And yes, I don't care about single thread performance as I care about multithread performance. Single thread performance has been good enough for desktop for almost a decade, and the only CPU intensive task I do is running those pesky `make -j X` commands.
You don't mean multithread, exactly. Make isn't multithreaded; it uses real processes.
As usual with all other topics, check out what Debian has been doing for more than a decade.
Pretty much every release this century has some dedication to devs who died since the last release.
That's different: that's a dedication inside the very thing the deceased was working on, made by and for the community she was a member of.
You don't see Debian releases dedicated to some member's grandparent, although we can be sure the members have loved ones and sorrows like everyone else.
So here's another vote for not doing anything like that.
Java doesn't have yield as a keyword. That is not its philosophy to add lots of keywords (like C++), but instead to be like C and add such functionality to libraries (standard libraries in Java's case).
Huh? Both C and C++ add a handful of keywords per *decade*, and focus growth on the libraries, not the core language.
The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition.
This is totally non-sensical. Those libraries would have become abandonware without the transition, as their authors had ceased to maintain them at any rate.
I doubt that's what happened in most cases. Seems more likely that the authors are like me: they're in the Python 2.x world, run computers with Python 2.x as the default version, and see no compelling reason to migrate, especially if it would mean maintaining two branches of their library.
Here's how I explain version control to non-techies: "Remember that time you had to work on a group project and you started writing a word document in MS Office and then you passed it out to the group while you still worked on it and then you got four more versions back with corrections and updates and you just started cursing out your computer? Yeah. Believe it or not, they fixed that problem for software a very long time ago and it's dirt cheap. In fact, if developers follow simple rules, those versioning nightmares you had with your group's powerpoint and other Microsoft files never happens."
That's a good one, because it stresses that it's a tool for collaboration.
But it's incomplete: it doesn't describe many important features. Off the top of my head:
Being able to isolate unrelated work tasks (typically via per-feature branches)
Being able to safely experiment, then revert if it doesn't work out.
Peer review.
Situation awareness: asking questions like "what am I about to change now?", "what did I change last week?", "what did Bob really do yesterday?"
Fast and reliable access to older versions.
Human-readable documentation of the change history, by commit messages.
Variant management, e.g. doing maintenance on a released version while continuing with new development.
Wikipedia has a very good description and definition of Revision Control.
However, I just typically explain it like this: It's like Apple's Time Machine for source code.
Two problems with that: most people have never used Time Machine (whatever that is) and revision control is *not* just for source code!
Git's tagline is "everything local". But is that a good idea? Every developer has the company's entire codebase (including history) on his laptop. Which means it's just a tar and an scp away from delivering to his next place of employment.
If you can work with the code at all, you can also tar and scp it.
That's true no matter if you use Git, CVS, ClearCase or any other version control tool out there.
The only thing that's worse with Git is theft of the laptop, but all companies I know of use full hard disk encryption anyway!
I don't understand how code versioning has to be coupled with deployment? You have no test environment, as you said... so just make releases and deploy them manually. Since you are going straight to production, you had better be there in person to roll it back if you screwed up. Right? So, SVN should be all you need...
I used to, as a single programmer, use SVN, but I found it nothing but a burden. It left files all over the place, and was really not convenient when no interlocking with another programmer is needed. Now I just make a tarball of everything at obvious breakpoints and store it away.
As a single programmer, I find version control invaluable, and wouldn't tolerate such a working environment. I haven't used SVN so I cannot comment on it, but both RCS and CVS have been universally available since the 1980s, and don't "leave files all over the place". I quickly learned to ignore the RCS/ and CVS/ subdirectories.
A modern version control tool like Git lets the single programmer name and describe her work progress; check what she did yesterday; review changes before commiting them; branch for experimental work; work from multiple computers or directories at will; easily keep backups;... and many things I forget.
Hmm. I prefer the central server, actually, because that's only one place I need to back up. I'll look into git in the future though
Huh? There is only one place to back up with Git too! And in fact the usual way to do backups is to 'git clone' that one and 'git fetch' from it regularly.
The only complication is that in the other repositories you must remember to 'git commit' *and* 'git push', or you'll just add versions locally; they don't reach the central repo.
The documents are sent to someone, manipulated and sent on further. Everyone in the chain (up and down, several thousand people) would have to stop using Microsoft Office, all because I asked? What you are proposing is, frankly, a utopian paradise. It isn't going to happen.
Yes, they should stop using MS Office!
It's a prison in so many ways.
For example the chain mail scenario you describe; the sane way to do such things is a wiki page, or a text file of some kind in Git or some other version control system. Recording changes; making sure everyone who should contribute has contributed; finding out exactly what each person contributed... that's a computer's job.
Sane workflows aren't just for programmers.
And it's a Windows prison. At my workplace most people are better off with a Linux desktop -- we're all engineers and spend 90% of our time remotely logged in to Unix servers anyway. But someone 15 years ago decided we should write documents in Word and use Exchange for mail, and that's the only reason we're tied to Windows.
Finally, most uses of Office I see are gratituous. Like if I get a.doc or.xls in the mail -- 99% of the time it could just as easily have been text directly in the mail. Excel has its real uses (spreadsheets) but most.xls files I see are just tables, easily recreated in a mail with a fixed-width font (or HTML if you're willing to abanding plain text mail).
I'm a Mac user. Linux desktops are bloody intolerable for me, because they mimic Window's crappy UI badly.
There are many Linux desktops, and most don't look like Windows at all. Twm-style desktops *predate* Windows 3.11.
Tabbed window managers like xmonad are what all the young people at my workplace use, and they don't look like anything else I've seen.
I have to get work done
Part of my problem understanding the problem is I don't understand the relationship between "desktop" and "getting things done". I need
a window manager (preferably with virtual desktops)
a way to launch my favorite applications
a way to shut down the computer
a way to use my photos as the desktop background
Everything from a classic 1989 X11 desktop to Windows Vista does that. What else do you need to get work done, in the responsibilily area of the "desktop"?
That is one of my major complaints. When time is short and changes are being made fast and furiously, or prototyping is being done, time spent commenting comes out of time getting something completed under a harsh deadline... which means comments are often not updated to reflect the new state of the code.. and incorrect comments can often be worse then no comments at all.
I don't belive that's a valid excuse.
Decent (e.g. not too detailed) comments are close to the code you're changing, and take very little time to change.
At the very least you can quickly add an XXX or remove comments which are no longer correct.
Also, at least where I work there's a review stage. We never ship something immediately to customer after an all-night hacking session. Then it's rather easy (for the reviewer and for you) to see that a function has been changed heavily yet the docs stayed the same.
if you can't fit the documentation into your method (and variable names), that method is likely too long and complicated.
People are fond of saying that, but that's not helpful.
We live in an imperfect world.
We modify old code which isn't perfectly designed.
New code which we write can't always be made perfect either.
Comments can be a quick and safe way to make it tolerable.
I don't ever want to hear the excuse "this sucky code I wrote isn't commented, but that's because perfect code doesn't need comments!"
Going even further - good code generally doesn't need a whole lot of commenting. If you are struggling with this problem of how to display comments, then that says a LOT more about your code than your comments.
(That said, trying to deal with a legacy system, comments can be helpful.)
You realize, of course, that the new code you write today is the legacy code of tomorrow?
I'm actually not a big fan of validating inputs. I find proper escaping is a much more effective tool, and validation typically leads to both arbitrary restrictions of what your fields can hold and a false sense of security. It's why you can't put a + sign in e-mail fields, or [...]
That's not validation! That is trying (and failing, because you are too ignorant to read an RFC) to guess what some other software wants, even if it's none of your business.
A well-formed mail address is, for most purposes, one which/lib/sendmail will not complain about.
That does of course not mean you shouldn't validate data meant to be interpreted by *you*. It's simple: if you need to interpret it, you need to validate it. Hell, you *are* validating it by intrepreting it, even if you do a lousy job.
Those old floppies were resilient. I have floppies from the late 70's which are still perfectly usable today, while 3.5" floppies from just a decade ago no longer work. You'd think that the harder shell would make them more resilient, but not even close. I guess the low density of the old floppies makes them more reliable.
The 720K (880K on an Amiga) 3.5" disks seem pretty reliable to me. I suspect either (a) HD made the difference, or (b) production quality went down towards the end of the floppy era.
Don't mistake me here - I would rather have open source any day of the week. But I'd like to see statistics showing the "shelf-life" of FOSS software versus closed, paid-for-software.. I'd be genuinely curious if more usage is gotten out of community supported tools over closed-source.[...] it just happens to be that money is a great motivator for people maintaining things.
As far as I can tell, it isn't.
Based on the commercial software I see, money means Dilbert-style operations with incompetent and disinterested programmers, pushing out buggy software which doesn't meet my actual needs.
(There are exceptions: the Opera browser; the Amazon web site, and... can't think of any other right now.)
Seems like for work that you just need to knock out, you might be even better off offshoring, or at least hiring new grads instead of seniors.
That reminds me of the *many* times I've seen qualified people ready to do job X, but it gets assigned to some newbie instead. Newbie does it badly, and the qualified people get to clean up the mess afterwards. That last phase is likely to take more time than if they had been allowed to do it right from the beginning.
Why this notion that the person who can do better than a half-assed job, is *overqualified* to do it?
Save Calibri and Arial for the technical manual but make sure your marketing literature is covered in Baskerville.
Calibri and Arial are sans-serif fonts.
Isn't it generally accepted that ordinary paragraph text on paper is much less readable in sans-serif?
For screen reading I prefer something like Arial, but I also prefer to make that choice myself. I.e. use something like HTML and let the user decide the default font.
How about/On The Beach/ by Nevil Shute. Written at the height of the cold war, it starts at a point in time where everything in the world is dead or soon to be because of a nuclear war, except Australia, South Africa, and Southern South America. [snip]
In the post-nuclear holocaust genre, Edgar Pangborn's/Davy/ cycle needs to be mentioned.
New England pushed back to the Middle Ages, with witch-hunts, slavery, religious fanaticism and everything... and no way out because the natural resources were used up in the 20th century, and anything which has to do with science or technology (like medicine, or glasses) is banned. The protagonists in his story tend to be poets and artists, and they are always crushed in the end, with whatever they had to say forgotten.
Swedish writer P C Jersild wrote a similar story, "Efter floden". Also detailed, and depressing as hell.
Almost anything by James Tiptree, Jr. AKA Raccoona Sheldon AKA Alice Bradley Sheldon.
Seconded.
Tiptree used her/his considerable talent to explain exactly why everything turns to shit in the end, and to explain it in dozens of different ways.
(But I also wonder what kind of SF the OP reads if it's full of "happy endings"? As far as I can tell, SF has been basically pessimistic since Hiroshima.)
Slashdot Mirror
And yes, I don't care about single thread performance as I care about multithread performance. Single thread performance has been good enough for desktop for almost a decade, and the only CPU intensive task I do is running those pesky `make -j X` commands.
You don't mean multithread, exactly. Make isn't multithreaded; it uses real processes.
As usual with all other topics, check out what Debian has been doing for more than a decade. Pretty much every release this century has some dedication to devs who died since the last release.
That's different: that's a dedication inside the very thing the deceased was working on, made by and for the community she was a member of. You don't see Debian releases dedicated to some member's grandparent, although we can be sure the members have loved ones and sorrows like everyone else.
So here's another vote for not doing anything like that.
By the way GIT was developed by Linus Torvalds and he's Swedish, so it's not the USA we'd have to 'get back'.
He's Finnish, not Swedish.
Finnish, and of the minority there who speak Swedish.
Java doesn't have yield as a keyword. That is not its philosophy to add lots of keywords (like C++), but instead to be like C and add such functionality to libraries (standard libraries in Java's case).
Huh? Both C and C++ add a handful of keywords per *decade*, and focus growth on the libraries, not the core language.
You get more with the carrot than with the stick, so unless you're employing a group of starving donkeys I suggest cold, hard cash.
People are different. Many would just want their job to suck less, to be more interesting, containing fewer artificial obstacles and so on ...
The trouble with Python 3 is that nobody took responsibility for converting the third-party libraries. Many major libraries became abandonware in that transition.
This is totally non-sensical. Those libraries would have become abandonware without the transition, as their authors had ceased to maintain them at any rate.
I doubt that's what happened in most cases. Seems more likely that the authors are like me: they're in the Python 2.x world, run computers with Python 2.x as the default version, and see no compelling reason to migrate, especially if it would mean maintaining two branches of their library.
Here's how I explain version control to non-techies: "Remember that time you had to work on a group project and you started writing a word document in MS Office and then you passed it out to the group while you still worked on it and then you got four more versions back with corrections and updates and you just started cursing out your computer? Yeah. Believe it or not, they fixed that problem for software a very long time ago and it's dirt cheap. In fact, if developers follow simple rules, those versioning nightmares you had with your group's powerpoint and other Microsoft files never happens."
That's a good one, because it stresses that it's a tool for collaboration. But it's incomplete: it doesn't describe many important features. Off the top of my head:
Wikipedia has a very good description and definition of Revision Control. However, I just typically explain it like this: It's like Apple's Time Machine for source code.
Two problems with that: most people have never used Time Machine (whatever that is) and revision control is *not* just for source code!
Git's tagline is "everything local". But is that a good idea? Every developer has the company's entire codebase (including history) on his laptop. Which means it's just a tar and an scp away from delivering to his next place of employment.
If you can work with the code at all, you can also tar and scp it. That's true no matter if you use Git, CVS, ClearCase or any other version control tool out there. The only thing that's worse with Git is theft of the laptop, but all companies I know of use full hard disk encryption anyway!
I don't understand how code versioning has to be coupled with deployment? You have no test environment, as you said... so just make releases and deploy them manually. Since you are going straight to production, you had better be there in person to roll it back if you screwed up. Right? So, SVN should be all you need...
I used to, as a single programmer, use SVN, but I found it nothing but a burden. It left files all over the place, and was really not convenient when no interlocking with another programmer is needed. Now I just make a tarball of everything at obvious breakpoints and store it away.
As a single programmer, I find version control invaluable, and wouldn't tolerate such a working environment. I haven't used SVN so I cannot comment on it, but both RCS and CVS have been universally available since the 1980s, and don't "leave files all over the place". I quickly learned to ignore the RCS/ and CVS/ subdirectories.
A modern version control tool like Git lets the single programmer name and describe her work progress; check what she did yesterday; review changes before commiting them; branch for experimental work; work from multiple computers or directories at will; easily keep backups; ... and many things I forget.
Hmm. I prefer the central server, actually, because that's only one place I need to back up. I'll look into git in the future though
Huh? There is only one place to back up with Git too! And in fact the usual way to do backups is to 'git clone' that one and 'git fetch' from it regularly.
The only complication is that in the other repositories you must remember to 'git commit' *and* 'git push', or you'll just add versions locally; they don't reach the central repo.
The documents are sent to someone, manipulated and sent on further. Everyone in the chain (up and down, several thousand people) would have to stop using Microsoft Office, all because I asked? What you are proposing is, frankly, a utopian paradise. It isn't going to happen.
Yes, they should stop using MS Office! It's a prison in so many ways. For example the chain mail scenario you describe; the sane way to do such things is a wiki page, or a text file of some kind in Git or some other version control system. Recording changes; making sure everyone who should contribute has contributed; finding out exactly what each person contributed ... that's a computer's job.
Sane workflows aren't just for programmers.
And it's a Windows prison. At my workplace most people are better off with a Linux desktop -- we're all engineers and spend 90% of our time remotely logged in to Unix servers anyway. But someone 15 years ago decided we should write documents in Word and use Exchange for mail, and that's the only reason we're tied to Windows.
Finally, most uses of Office I see are gratituous. Like if I get a .doc or .xls in the mail -- 99% of the time it could just as easily have been text directly in the mail. Excel has its real uses (spreadsheets) but most .xls files I see are just tables, easily recreated in a mail with a fixed-width font (or HTML if you're willing to abanding plain text mail).
I'm a Mac user. Linux desktops are bloody intolerable for me, because they mimic Window's crappy UI badly.
There are many Linux desktops, and most don't look like Windows at all. Twm-style desktops *predate* Windows 3.11. Tabbed window managers like xmonad are what all the young people at my workplace use, and they don't look like anything else I've seen.
I have to get work done
Part of my problem understanding the problem is I don't understand the relationship between "desktop" and "getting things done". I need
Everything from a classic 1989 X11 desktop to Windows Vista does that. What else do you need to get work done, in the responsibilily area of the "desktop"?
That is one of my major complaints. When time is short and changes are being made fast and furiously, or prototyping is being done, time spent commenting comes out of time getting something completed under a harsh deadline... which means comments are often not updated to reflect the new state of the code.. and incorrect comments can often be worse then no comments at all.
I don't belive that's a valid excuse. Decent (e.g. not too detailed) comments are close to the code you're changing, and take very little time to change. At the very least you can quickly add an XXX or remove comments which are no longer correct.
Also, at least where I work there's a review stage. We never ship something immediately to customer after an all-night hacking session. Then it's rather easy (for the reviewer and for you) to see that a function has been changed heavily yet the docs stayed the same.
if you can't fit the documentation into your method (and variable names), that method is likely too long and complicated.
People are fond of saying that, but that's not helpful. We live in an imperfect world. We modify old code which isn't perfectly designed. New code which we write can't always be made perfect either. Comments can be a quick and safe way to make it tolerable.
I don't ever want to hear the excuse "this sucky code I wrote isn't commented, but that's because perfect code doesn't need comments!"
Going even further - good code generally doesn't need a whole lot of commenting. If you are struggling with this problem of how to display comments, then that says a LOT more about your code than your comments.
(That said, trying to deal with a legacy system, comments can be helpful.)
You realize, of course, that the new code you write today is the legacy code of tomorrow?
I'm actually not a big fan of validating inputs. I find proper escaping is a much more effective tool, and validation typically leads to both arbitrary restrictions of what your fields can hold and a false sense of security. It's why you can't put a + sign in e-mail fields, or [...]
That's not validation! That is trying (and failing, because you are too ignorant to read an RFC) to guess what some other software wants, even if it's none of your business. A well-formed mail address is, for most purposes, one which /lib/sendmail will not complain about.
That does of course not mean you shouldn't validate data meant to be interpreted by *you*. It's simple: if you need to interpret it, you need to validate it. Hell, you *are* validating it by intrepreting it, even if you do a lousy job.
Those old floppies were resilient. I have floppies from the late 70's which are still perfectly usable today, while 3.5" floppies from just a decade ago no longer work. You'd think that the harder shell would make them more resilient, but not even close. I guess the low density of the old floppies makes them more reliable.
The 720K (880K on an Amiga) 3.5" disks seem pretty reliable to me. I suspect either (a) HD made the difference, or (b) production quality went down towards the end of the floppy era.
Don't mistake me here - I would rather have open source any day of the week. But I'd like to see statistics showing the "shelf-life" of FOSS software versus closed, paid-for-software.. I'd be genuinely curious if more usage is gotten out of community supported tools over closed-source.[...] it just happens to be that money is a great motivator for people maintaining things.
As far as I can tell, it isn't. Based on the commercial software I see, money means Dilbert-style operations with incompetent and disinterested programmers, pushing out buggy software which doesn't meet my actual needs. (There are exceptions: the Opera browser; the Amazon web site, and ... can't think of any other right now.)
Seems like for work that you just need to knock out, you might be even better off offshoring, or at least hiring new grads instead of seniors.
That reminds me of the *many* times I've seen qualified people ready to do job X, but it gets assigned to some newbie instead. Newbie does it badly, and the qualified people get to clean up the mess afterwards. That last phase is likely to take more time than if they had been allowed to do it right from the beginning.
Why this notion that the person who can do better than a half-assed job, is *overqualified* to do it?
I don't like the spacing between the f and t, aesthetically, but I like clean lines and simple designs so it works pretty well for me.
The ft ligature looks more and more weird the more I look at it. I'm not sure it's a good idea to have those in a logo.
She learns how to do things by the positions that things are at on the screen, and if they move, she needs to learn all over again.
She is learning the wrong way! (doesn't she want to barely understand what she's doing?)
Yeah. The grandparent should configure granny's computer to randomize the keymap once a week. That'll teach her not to rely on visual cues.
Save Calibri and Arial for the technical manual but make sure your marketing literature is covered in Baskerville.
Calibri and Arial are sans-serif fonts. Isn't it generally accepted that ordinary paragraph text on paper is much less readable in sans-serif?
For screen reading I prefer something like Arial, but I also prefer to make that choice myself. I.e. use something like HTML and let the user decide the default font.
How about /On The Beach/ by Nevil Shute. Written at the height of the cold war, it starts at a point in time where everything in the world is dead or soon to be because of a nuclear war, except Australia, South Africa, and Southern South America. [snip]
In the post-nuclear holocaust genre, Edgar Pangborn's /Davy/ cycle needs to be mentioned.
New England pushed back to the Middle Ages, with witch-hunts, slavery, religious fanaticism and everything ... and no way out because the natural resources were used up in the 20th century, and anything which has to do with science or technology (like medicine, or glasses) is banned. The protagonists in his story tend to be poets and artists, and they are always crushed in the end, with whatever they had to say forgotten.
Swedish writer P C Jersild wrote a similar story, "Efter floden". Also detailed, and depressing as hell.
Almost anything by James Tiptree, Jr. AKA Raccoona Sheldon AKA Alice Bradley Sheldon.
Seconded. Tiptree used her/his considerable talent to explain exactly why everything turns to shit in the end, and to explain it in dozens of different ways.
(But I also wonder what kind of SF the OP reads if it's full of "happy endings"? As far as I can tell, SF has been basically pessimistic since Hiroshima.)