...the idea of putting business critical data in a Raid 0 config is IMHO just plain crazy.
It really isn't necessarily that crazy to mirror stuff..
You need backups for business-critical data anyway; the things true RAID* gives you protection from are only a part of the spectrum of things that can go wrong. If you have a good backup policy and don't care so much about high availability that you'd get from RAID, but you do care about performance (maybe you're doing video editing or something, I dunno), then mirroring might make sense.
* 'RAID 0' is really a misnomer, and really shouldn't be called RAID. The 'R' stands for 'redundant', and RAID 0 is really 'anti-redundant'. The original RAID paper described RAID levels starting with RAID 1. So what I call 'true RAID' above is RAID with redundancy.
Interesting. Where is it? I was trying to find out what I was missing, fired up VirtualBox and Office 2007, but there was no such thing. I get to chose between 'Print', 'Full Screen', 'Web','Outline', 'Draft'.
To be honest I didn't know it was changed; I haven't used Office 2007 very much. From a cursory look, 'normal' mode seems to have been renamed to 'draft' for that version....I have been doing everything on OpenOffice for the last 10 years, including the complete layout for a book published recently; without problems.
From a personal view, this wouldn't really be a deal breaker, but moving from Word to Writer just has a bunch of these small issues. Wasted space with margins... a track changes feature inferior to the one in Word 2000... little things like that. None are a deal breaker, but put together they mean that, for me, there's basically no incentive to use OO. I already have MS Office around (I would argue that PowerPoint, especially 2007, is substantially superior to Impress) so it's not like I'm saving on cost.
I mean, I do a lot of work on my laptop. As Thinkpad tablet, it's got a small screen -- 1024x768. The distance between the baseline of the last line of text on page n and the top of the line on n+1 is about 172 pixels for me (I don't think I've messed with the default settings much), which is 22.5% of my vertical real estate! I'm not one to obsess over vertical space all that much, but that's just too much. Even on my brand spanking new 22" LCD that's 16% of the vertical space.
Now, that said, I'm not very invested in it... It's been over a year since I really used any word processor (as distinct from Emacs + Latex or Asciidoc).
In theory, yes, it can be fixed. In practice, you get stuff like this, which is a request to add something like Word's 'normal' mode, or at least a way to collapse the top and bottom margins of a page -- an issue that has over 200 votes for fixing, dozens of people reporting that this is a blocker for their use of OO, and, at least in terms of visible progress, the issue has been ignored for over 7 years.
I read somewhere (maybe in the Hitchhiker's Guide series?) of some company that released the exact same product every year. They would change only the version number, which was prominent somewhere on whatever item it was. People would keep buying it every year just so their friends don't see last year's version on their thing, which was considered unfashionable or poor.
Having to pay $100> for a new controller+game for each release borders on extortion
What? At least for the 360 version, the same Guitar Hero controllers work for GH2, GH3, GH4, Rock Band, and RB2. Also the PC version of GH3 (& I presume 4).
The Rock Band controllers don't work for the GH games, but they are at least portable from RB to RB2. My understanding is that on the PS3 the GH->RB transition doesn't work either. But even these are still a far cry from having to buy new controllers each release...
The multiple folders thing is a bit annoying, but you don't need a card reader to see that. I have a 350D myself, and have no problems with plugging the thing in and going into the camera's file system to DCIM\ folders and copying them to the hard drive.
Since almost all webpages are designed to be tall, reducing the amount of vertical space to display them is stupid.
Whatever; I almost never have a problem with screen real estate. Sure, maybe I can fit a line and a half less than you at one time or something like that, and so have to scroll one extra screenful if the page is 40 screens long.
But at the same time, I have 16 tabs open right now. (My usage pattern is a bit different on this computer than some others, but it's unusual for me to have more than that many open in one window. I tend to go tab cleaning when it gets that many; in fact, I closed 6 tabs while going through and counting them, so I'm down to 10 now.) The current height of my tab bar is ~24 px. 16*24 is 384 pixes, so those tabs would take 384 pixels of vertical height if arranged on the left (if they are kept the same size). But I estimate ~768 pixels of height are available even within the page, and if you dropped the tab bar from the top and if I closed the find bar at the bottom, this would increase a bit more. If the tabs are even just 100 pixels wide (seems narrow to me for 1", but that depends on your resolution of course), that means 100*(768-384)=38,000 pixels would be completely unused if the tab bar was at the left. (Unless you wanted to do the annoying auto-hide thing as someone else said, or cover up the page.) We're talking like 4 square inches -- AT LEAST -- of completely wasted space. If we say I only have 10 tabs open and I include the amount I gave the tab bar and find bar, and give the width 128 px instead of 100 (that's the width of my tabs right now, with 10 open across the top; it's a decent size) then we're at 5.7% of wasted space.
I'll take using an extra 24 pixels of height to get 0 truly wasted space.
And I don't get where you came up with sideways text. You must have a lot of crazy stuff in your ass to be able to pull things like that out.
It's called "imagining implementation choices". I didn't say you'd require sideways text, just that it was an option (that would avoid the wasted space in the above analysis).
If you are a serious UI designer, and you first priority is not *C*H*O*I*C*E*, then you are a failure at your job and have so stop working *right now*. (Second priority is good *defaults*. But never hard-code stuff!)
This is an extremely one-sided viewpoint. There is a point where you should stop giving customization options (at least without writing code or using code someone else wrote as a plugin). Suppose I want the toolbar diagonally across the screen. Should there be a customization option for that? Or a rainbow across the background of the URL text box?
No, the job of the UI designer isn't to provide choice to the user... it's to determine where it's appropriate to provide choice to the user.
In this particular case, it's probable that "tabs-on-top" or "tabs-on-bottom" is an appropriate choice unless for some reason it would take an inordinate amount of effort to actually implement that for some reason.
So I don't want to argue that this is the case here, but I would say that, in fact, it can be very easy for a designer to use "the user can change this" as a crutch for bad design. (Of course, it can also be very easy to go the other way.)
I don't understand why people don't like the tabs on top of the location bar. The location bar (and all the navigation buttons) pertain to the currently loaded TAB, therefore, it is logical that they are nested below the tab. Each tab has a different location, therefore, they get their own location bar.
This makes sense. At least for me, it's not mainly the tabs-on-top specifically I don't like, but rather the cannibalization of the title bar. It becomes narrower and harder to hit, it doesn't blend in with the other programs, and it doesn't show the title of the current page.
It'd take some getting used to, but tabs-on-top with a full title bar would probably still be okay. That said, there is one other benefit: most of the time when I use the mouse to interact with a non-page element of Firefox, it's the tab bar. Putting that closer to the main page means it's slightly closer.
Agreed... I'm all for configurability, so making something like the tabs-on-top or your tabs-on-left options being a choice would be fine and dandy. But making either the only choice is a good way to get me to stop using Firefox.;-)
Ugh, I hate UI elements that appear and disappear like that. I had the taskbar on auto-hide on my laptop (which only has a 1024x768 screen) and decided it wasn't even worth it there, even though that would have been present in every application.
Browsers have the added problem of me using ctrl-tab/ctrl-shift-tab to change between tabs a lot, but doing that non-blindly requires seeing where the tab is that you want. A hidden tab list would slow that down.
Definitely. There are a lot of people out there (like you) who really like the Chrome UI, and a lot of people out there (like me) who really dislike it. Probably more than anything else, UI preference is a very personal thing.
There are definitely costs with making new options, but this is the sort of option that would make FF much more attractive to quite a number of people but be so contentious I don't think making it default would be a good idea, so it's a good thing for an option.
The problem with tabs down the side is you either get (1) vertical text or (2) tabs that are as wide as they are above the window in which case the tab list takes up a HUGE proportion of the screen real estate, virtually all wasted unless you actually have a couple dozen tabs in one window to start eating up the available rows.
Neither of these options are very good IMO; I'd rather spend a few pixels of vertical height then have to read sideways text.
(Incidentally, this is why I never liked the taskbar on the side of the screen either. Maybe I should give it another shot with Windows 7 now that the taskbar is a little more icon-based and less word-based.)
Just as a counterpoint, I decidedly don't like the tabs-on-top design, don't use Chrome in part because of that UI, and would probably switch to Opera if Firefox didn't make tabs-on-bottom an option.;-)
Of course they do.. it's the price/performance decision between an iMac and a Mac Pro.
But Apple confuses the issue by adding a TON of other price/performance decisions there too. Upgradablity, separate monitors, etc. Heck, even within the iMac line the monitor size is a little tied to the amount of RAM and hard drive (you can get 2 GB of memory or 320 GB of hard drive with the 20" only), and the video card is tied to the processor speed (can't get a 2.66 GHz processor with the GeForce). Want a quad core? You have to get the Mac Pro. Heck, remember the black iBook? The color black is tied to the higher specs! (And actually, that last one is really probably less ridiculous to me.)
I haven't looked at prebuilt computers in a long time, but I'm pretty sure I've never seen anyone tie the different components of the system together to the same extent that Apple does. You tend to get much more orthogonality between the components with other companies.
Since when are a Core 2 Duo and Nehalem 3000 series processor anywhere near each other in price or performance? I'm assuming you also didn't account for the difference in price/performance between DDR2 and DDR3.
You're missing the point though... the parent's point is that Apple doesn't let you make the price/performance decision between a Core 2 and a Nehalem, or between DDR2/3.
When I built my system, I was able to look at the cost of DDR2 and DDR3 RAM and decide that the cost of DDR3 wasn't worth it. If you reject the iMac, Apple doesn't let you make that decision. I didn't seriously consider the Xeons, but I was able to choose the Core 2 when I built my computer. If you reject the iMac, Apple doesn't let you make that decision.
Basically if you want a decently upgradable system from Apple, your only choice is the Mac Pro. And for most people, it's going to be very very hard to say that the price/performance tradeoff is in favor of the Nehalem and DDR3.
My personal theory is that the author wanted, at least a little bit, for the "score" to come out a "tie." When it was 5-4, he added the "name" category to make it so.
(I don't think I actually think that, but it is a convenient explanation.)
It forces one to keep nested ifs to a minimum, the bane of testing and reading comprehension.
My biggest problem with 80-character limits is that if you have reasonably descriptive identifiers, they tend to be a little long, and so it's not all that hard to go beyond 80-characters even if you are only a couple levels deep in code. If you're in a language with function definitions inside of a class like Java or Python, you've already got two levels of indent to your function body before you've even started writing actual code! With 8 character indents, that's 20% of your line width already gone. If you have an if statement in two nested for loops (not at all unreasonable), that's 5 indent levels and half of your line width! If you then make a function call with two parameters, save the return value, and your average variable length is 8 characters, you're at 80 characters; and that's not even that long of a line, even for someone like me who likes to use a lot of explicit temporaries.
The other thing is I tend to view line breaks as having a pretty high cost, especially if there are a couple related lines in a row. If you are doing similar operations two or three times in a row, it's nice to see the parallel structure, and adding line breaks obscures that quite a bit. (I used to try to line up operators in such cases, but I rarely do that any more.:-))
Actual changesets (so no more of tools saying "well, these two files were updated at about the same time with the same log message, so they're probably part of one logical commit)
Consistent numbering across versions (so you can just refer to a number instead of a time if you want the revision as of a particular point). Related to the first point; they're sort of two ways of looking at the same issue.
You can actually do some stuff (in particular diff and stat/-nq up) without repository access (big for me because of me doing a non-trivial amount of work on the bus with no internet access, and also being too lazy to figure out how to get TortoiseCVS to not ask me for my SSH password every time)
You can rename files without losing version history across the rename. (SVN isn't quite ideal here; other systems do it better. But it's still way better than CVS's "delete the file and make a new one".)
Directories are versioned, so you can delete directories for real (instead of the "empty directory is not there" CVS thing, which causes a few problems), rename directories without going through a crapload of hassle, etc.
All of these are, IMO, pretty significant benefits to Subversion over CVS.
RE: git-push, this is the same with all VCSs, until you commit to a remote repository your work is in danger. The difference between DVCS and traditional ones is that you *know* its not committed until you commit it, with a DVCS some people will think that its safe once committed, not realising its not safe until its pushed upstream.
Getting your code to a server that is well-and-truely backed up and such is only a small part of why you commit. You also commit so you can look at the revision history; you also commit so that one commit == one change; you also commit so that you can make experimental changes locally but don't want to wipe out a legitimate fix.
I like fine-grained commits (that one commit == one change), and I have a fairly long bus ride in. There have been times where I've wanted to do two or three commits during a single bus ride.
As for the user getting confused... well, let's just say that you have less faith in the developers than I do. This is not a hard concept to get used to, even if you're used to the centralized model. Personally, I suspect you're far, far more likely to forget to CVS ADD a file (if I had a dime...) than to forget to push upstream.
Surely they sell such a thing in the USA?
I'm not aware of any, and I'd be very surprised given what a clusterfu*k our wireless service here in the states are.
It's not. But nor is code that uses goto in the idiom that FourthAge posted above.
My objection to that code is that if you do even just three or four allocations, you start getting very large indentations pretty fast, especially if you like 8-character indentations. (They get pretty long even with 4, which is what I like!) This causes a problem if you restrict yourself to 80-columns.
Arguably this is a problem with restricting yourself to 80 columns, but that's not entirely unreasonable even if I'd rather the limit be ~100. But guess how many your code uses? Your longest line is 109, longer even than my longer preference. Even if you use 4-character indentations, your longest line is still 80 characters.
If you reformat your code to use 8-character indentations and 80-character column limits, your code would become a bit uglier as you'd have to wrap four lines (a couple of which don't really have a good breaking point), and hence a little harder to understand on its face.
By contrast, the original code fits entirely within 80 characters (admittedly only just) without anything remotely like an awkward line break.
Further, in some sense it doesn't entirely follow the flow of the code. Perhaps this is a vice and not a virtue, but I tend to think of places where there's an unusual condition (like a failed allocation) as not on the same "level" as normal control flow. In this sense, I would think of that procedure as basically linear "with some provisions for exceptional conditions". In that sense, your proposal of the cascaded ifs doesn't really match my mental model of how the code behaves -- the indentation of the normal code changes depending on how many exceptional conditions might arise, and there's not really any reason why it should by that model. By contrast, the original code matches it.
(Incidentally, "linear with some provisions for exceptional conditions" is basically how I'd write it either in a language that supports exceptions or a language that has RAII. In the former case, there's a decent chance do just one try block for the body of the function, and in the associated catch test to see if each item is allocated in turn. (This doesn't match the structure of the real code exactly, but it's closer to it than it is to your nested-if code.) In the latter case, you'd have basically the real kernel code except that the deallocation would be in the RAII objects' destructors. Again, no nested ifs.)
And at 20-30 USD/month, that will very quickly become much more than £30.
I'm sorry, I misspoke. 20-30 USD is what you will pay for internet access from your phone. From a quick read of AT&T's site, the cheapest reasonable (i.e. has a limit > 10MB/month) plan they offer that allows tethering is either $40 or $60/month.
The trouble with this is that you have to worry about your laptop crashing, being broken or stolen.
No you don't; you just do a "git push" when you get somewhere with internet. You have to do this anyway if you're working with other people.
Today, with a £30 usb wireless dongle, you can commit changes no matter where you are.
Where do you live that you can get internet access while on the bus?
I mean, I could, but only through a cell phone plan. And at 20-30 USD/month, that will very quickly become much more than £30.
The lack of internet access isn't a good enough reason to advocate a distributed VCS. They have plenty of other good aspects to them, but being able to easily hoard changes locally is more a disadvantage than anything.
I guess we have different opinions. For the sorts of things I work on (things that are just me, and relatively small groups of of people), being able to work disconnected is IMO probably the biggest benefit. (It's at least #2; if so, #1 is the fact that distributed VCSs are almost always much better at branching than CVS/SVN. But there's really no reason this needs to be the case while being able to work disconnected is basically an innate feature to DVCS.)
Slashdot Mirror
till you break them and contaminate the room in mercury. Professional remediation is about $3000.
You forgot to finish your thought with "if you compeletely and unjustifiably overreact.
Yes, of course. /me goes to crawl under a rock
...the idea of putting business critical data in a Raid 0 config is IMHO just plain crazy.
It really isn't necessarily that crazy to mirror stuff..
You need backups for business-critical data anyway; the things true RAID* gives you protection from are only a part of the spectrum of things that can go wrong. If you have a good backup policy and don't care so much about high availability that you'd get from RAID, but you do care about performance (maybe you're doing video editing or something, I dunno), then mirroring might make sense.
* 'RAID 0' is really a misnomer, and really shouldn't be called RAID. The 'R' stands for 'redundant', and RAID 0 is really 'anti-redundant'. The original RAID paper described RAID levels starting with RAID 1. So what I call 'true RAID' above is RAID with redundancy.
Interesting. Where is it? I was trying to find out what I was missing, fired up VirtualBox and Office 2007, but there was no such thing. I get to chose between 'Print', 'Full Screen', 'Web','Outline', 'Draft'.
To be honest I didn't know it was changed; I haven't used Office 2007 very much. From a cursory look, 'normal' mode seems to have been renamed to 'draft' for that version. ...I have been doing everything on OpenOffice for the last 10 years, including the complete layout for a book published recently; without problems.
From a personal view, this wouldn't really be a deal breaker, but moving from Word to Writer just has a bunch of these small issues. Wasted space with margins... a track changes feature inferior to the one in Word 2000... little things like that. None are a deal breaker, but put together they mean that, for me, there's basically no incentive to use OO. I already have MS Office around (I would argue that PowerPoint, especially 2007, is substantially superior to Impress) so it's not like I'm saving on cost.
I mean, I do a lot of work on my laptop. As Thinkpad tablet, it's got a small screen -- 1024x768. The distance between the baseline of the last line of text on page n and the top of the line on n+1 is about 172 pixels for me (I don't think I've messed with the default settings much), which is 22.5% of my vertical real estate! I'm not one to obsess over vertical space all that much, but that's just too much. Even on my brand spanking new 22" LCD that's 16% of the vertical space.
Now, that said, I'm not very invested in it... It's been over a year since I really used any word processor (as distinct from Emacs + Latex or Asciidoc).
In theory, yes, it can be fixed. In practice, you get stuff like this, which is a request to add something like Word's 'normal' mode, or at least a way to collapse the top and bottom margins of a page -- an issue that has over 200 votes for fixing, dozens of people reporting that this is a blocker for their use of OO, and, at least in terms of visible progress, the issue has been ignored for over 7 years.
I read somewhere (maybe in the Hitchhiker's Guide series?) of some company that released the exact same product every year. They would change only the version number, which was prominent somewhere on whatever item it was. People would keep buying it every year just so their friends don't see last year's version on their thing, which was considered unfashionable or poor.
Surely you're thinking of calculus texts?
Having to pay $100> for a new controller+game for each release borders on extortion
What? At least for the 360 version, the same Guitar Hero controllers work for GH2, GH3, GH4, Rock Band, and RB2. Also the PC version of GH3 (& I presume 4).
The Rock Band controllers don't work for the GH games, but they are at least portable from RB to RB2. My understanding is that on the PS3 the GH->RB transition doesn't work either. But even these are still a far cry from having to buy new controllers each release...
The multiple folders thing is a bit annoying, but you don't need a card reader to see that. I have a 350D myself, and have no problems with plugging the thing in and going into the camera's file system to DCIM\ folders and copying them to the hard drive.
Since almost all webpages are designed to be tall, reducing the amount of vertical space to display them is stupid.
Whatever; I almost never have a problem with screen real estate. Sure, maybe I can fit a line and a half less than you at one time or something like that, and so have to scroll one extra screenful if the page is 40 screens long.
But at the same time, I have 16 tabs open right now. (My usage pattern is a bit different on this computer than some others, but it's unusual for me to have more than that many open in one window. I tend to go tab cleaning when it gets that many; in fact, I closed 6 tabs while going through and counting them, so I'm down to 10 now.) The current height of my tab bar is ~24 px. 16*24 is 384 pixes, so those tabs would take 384 pixels of vertical height if arranged on the left (if they are kept the same size). But I estimate ~768 pixels of height are available even within the page, and if you dropped the tab bar from the top and if I closed the find bar at the bottom, this would increase a bit more. If the tabs are even just 100 pixels wide (seems narrow to me for 1", but that depends on your resolution of course), that means 100*(768-384)=38,000 pixels would be completely unused if the tab bar was at the left. (Unless you wanted to do the annoying auto-hide thing as someone else said, or cover up the page.) We're talking like 4 square inches -- AT LEAST -- of completely wasted space. If we say I only have 10 tabs open and I include the amount I gave the tab bar and find bar, and give the width 128 px instead of 100 (that's the width of my tabs right now, with 10 open across the top; it's a decent size) then we're at 5.7% of wasted space.
I'll take using an extra 24 pixels of height to get 0 truly wasted space.
And I don't get where you came up with sideways text. You must have a lot of crazy stuff in your ass to be able to pull things like that out.
It's called "imagining implementation choices". I didn't say you'd require sideways text, just that it was an option (that would avoid the wasted space in the above analysis).
And it's not like sideways text in sideways tabs are unprecedented.
If you are a serious UI designer, and you first priority is not *C*H*O*I*C*E*, then you are a failure at your job and have so stop working *right now*.
(Second priority is good *defaults*. But never hard-code stuff!)
This is an extremely one-sided viewpoint. There is a point where you should stop giving customization options (at least without writing code or using code someone else wrote as a plugin). Suppose I want the toolbar diagonally across the screen. Should there be a customization option for that? Or a rainbow across the background of the URL text box?
No, the job of the UI designer isn't to provide choice to the user... it's to determine where it's appropriate to provide choice to the user.
In this particular case, it's probable that "tabs-on-top" or "tabs-on-bottom" is an appropriate choice unless for some reason it would take an inordinate amount of effort to actually implement that for some reason.
So I don't want to argue that this is the case here, but I would say that, in fact, it can be very easy for a designer to use "the user can change this" as a crutch for bad design. (Of course, it can also be very easy to go the other way.)
I don't understand why people don't like the tabs on top of the location bar. The location bar (and all the navigation buttons) pertain to the currently loaded TAB, therefore, it is logical that they are nested below the tab. Each tab has a different location, therefore, they get their own location bar.
This makes sense. At least for me, it's not mainly the tabs-on-top specifically I don't like, but rather the cannibalization of the title bar. It becomes narrower and harder to hit, it doesn't blend in with the other programs, and it doesn't show the title of the current page.
It'd take some getting used to, but tabs-on-top with a full title bar would probably still be okay. That said, there is one other benefit: most of the time when I use the mouse to interact with a non-page element of Firefox, it's the tab bar. Putting that closer to the main page means it's slightly closer.
Agreed... I'm all for configurability, so making something like the tabs-on-top or your tabs-on-left options being a choice would be fine and dandy. But making either the only choice is a good way to get me to stop using Firefox. ;-)
Ugh, I hate UI elements that appear and disappear like that. I had the taskbar on auto-hide on my laptop (which only has a 1024x768 screen) and decided it wasn't even worth it there, even though that would have been present in every application.
Browsers have the added problem of me using ctrl-tab/ctrl-shift-tab to change between tabs a lot, but doing that non-blindly requires seeing where the tab is that you want. A hidden tab list would slow that down.
Definitely. There are a lot of people out there (like you) who really like the Chrome UI, and a lot of people out there (like me) who really dislike it. Probably more than anything else, UI preference is a very personal thing.
There are definitely costs with making new options, but this is the sort of option that would make FF much more attractive to quite a number of people but be so contentious I don't think making it default would be a good idea, so it's a good thing for an option.
The problem with tabs down the side is you either get (1) vertical text or (2) tabs that are as wide as they are above the window in which case the tab list takes up a HUGE proportion of the screen real estate, virtually all wasted unless you actually have a couple dozen tabs in one window to start eating up the available rows.
Neither of these options are very good IMO; I'd rather spend a few pixels of vertical height then have to read sideways text.
(Incidentally, this is why I never liked the taskbar on the side of the screen either. Maybe I should give it another shot with Windows 7 now that the taskbar is a little more icon-based and less word-based.)
Just as a counterpoint, I decidedly don't like the tabs-on-top design, don't use Chrome in part because of that UI, and would probably switch to Opera if Firefox didn't make tabs-on-bottom an option. ;-)
Of course they do.. it's the price/performance decision between an iMac and a Mac Pro.
But Apple confuses the issue by adding a TON of other price/performance decisions there too. Upgradablity, separate monitors, etc. Heck, even within the iMac line the monitor size is a little tied to the amount of RAM and hard drive (you can get 2 GB of memory or 320 GB of hard drive with the 20" only), and the video card is tied to the processor speed (can't get a 2.66 GHz processor with the GeForce). Want a quad core? You have to get the Mac Pro. Heck, remember the black iBook? The color black is tied to the higher specs! (And actually, that last one is really probably less ridiculous to me.)
I haven't looked at prebuilt computers in a long time, but I'm pretty sure I've never seen anyone tie the different components of the system together to the same extent that Apple does. You tend to get much more orthogonality between the components with other companies.
Since when are a Core 2 Duo and Nehalem 3000 series processor anywhere near each other in price or performance? I'm assuming you also didn't account for the difference in price/performance between DDR2 and DDR3.
You're missing the point though... the parent's point is that Apple doesn't let you make the price/performance decision between a Core 2 and a Nehalem, or between DDR2/3.
When I built my system, I was able to look at the cost of DDR2 and DDR3 RAM and decide that the cost of DDR3 wasn't worth it. If you reject the iMac, Apple doesn't let you make that decision. I didn't seriously consider the Xeons, but I was able to choose the Core 2 when I built my computer. If you reject the iMac, Apple doesn't let you make that decision.
Basically if you want a decently upgradable system from Apple, your only choice is the Mac Pro. And for most people, it's going to be very very hard to say that the price/performance tradeoff is in favor of the Nehalem and DDR3.
My personal theory is that the author wanted, at least a little bit, for the "score" to come out a "tie." When it was 5-4, he added the "name" category to make it so.
(I don't think I actually think that, but it is a convenient explanation.)
It forces one to keep nested ifs to a minimum, the bane of testing and reading comprehension.
My biggest problem with 80-character limits is that if you have reasonably descriptive identifiers, they tend to be a little long, and so it's not all that hard to go beyond 80-characters even if you are only a couple levels deep in code. If you're in a language with function definitions inside of a class like Java or Python, you've already got two levels of indent to your function body before you've even started writing actual code! With 8 character indents, that's 20% of your line width already gone. If you have an if statement in two nested for loops (not at all unreasonable), that's 5 indent levels and half of your line width! If you then make a function call with two parameters, save the return value, and your average variable length is 8 characters, you're at 80 characters; and that's not even that long of a line, even for someone like me who likes to use a lot of explicit temporaries.
The other thing is I tend to view line breaks as having a pretty high cost, especially if there are a couple related lines in a row. If you are doing similar operations two or three times in a row, it's nice to see the parallel structure, and adding line breaks obscures that quite a bit. (I used to try to line up operators in such cases, but I rarely do that any more. :-))
What bits were big changes?
The changes I care about?
All of these are, IMO, pretty significant benefits to Subversion over CVS.
RE: git-push, this is the same with all VCSs, until you commit to a remote repository your work is in danger. The difference between DVCS and traditional ones is that you *know* its not committed until you commit it, with a DVCS some people will think that its safe once committed, not realising its not safe until its pushed upstream.
Getting your code to a server that is well-and-truely backed up and such is only a small part of why you commit. You also commit so you can look at the revision history; you also commit so that one commit == one change; you also commit so that you can make experimental changes locally but don't want to wipe out a legitimate fix.
I like fine-grained commits (that one commit == one change), and I have a fairly long bus ride in. There have been times where I've wanted to do two or three commits during a single bus ride.
As for the user getting confused... well, let's just say that you have less faith in the developers than I do. This is not a hard concept to get used to, even if you're used to the centralized model. Personally, I suspect you're far, far more likely to forget to CVS ADD a file (if I had a dime...) than to forget to push upstream.
Surely they sell such a thing in the USA?
I'm not aware of any, and I'd be very surprised given what a clusterfu*k our wireless service here in the states are.
How is this so hard to understand?
It's not. But nor is code that uses goto in the idiom that FourthAge posted above.
My objection to that code is that if you do even just three or four allocations, you start getting very large indentations pretty fast, especially if you like 8-character indentations. (They get pretty long even with 4, which is what I like!) This causes a problem if you restrict yourself to 80-columns.
Arguably this is a problem with restricting yourself to 80 columns, but that's not entirely unreasonable even if I'd rather the limit be ~100. But guess how many your code uses? Your longest line is 109, longer even than my longer preference. Even if you use 4-character indentations, your longest line is still 80 characters.
If you reformat your code to use 8-character indentations and 80-character column limits, your code would become a bit uglier as you'd have to wrap four lines (a couple of which don't really have a good breaking point), and hence a little harder to understand on its face.
By contrast, the original code fits entirely within 80 characters (admittedly only just) without anything remotely like an awkward line break.
Further, in some sense it doesn't entirely follow the flow of the code. Perhaps this is a vice and not a virtue, but I tend to think of places where there's an unusual condition (like a failed allocation) as not on the same "level" as normal control flow. In this sense, I would think of that procedure as basically linear "with some provisions for exceptional conditions". In that sense, your proposal of the cascaded ifs doesn't really match my mental model of how the code behaves -- the indentation of the normal code changes depending on how many exceptional conditions might arise, and there's not really any reason why it should by that model. By contrast, the original code matches it.
(Incidentally, "linear with some provisions for exceptional conditions" is basically how I'd write it either in a language that supports exceptions or a language that has RAII. In the former case, there's a decent chance do just one try block for the body of the function, and in the associated catch test to see if each item is allocated in turn. (This doesn't match the structure of the real code exactly, but it's closer to it than it is to your nested-if code.) In the latter case, you'd have basically the real kernel code except that the deallocation would be in the RAII objects' destructors. Again, no nested ifs.)
And at 20-30 USD/month, that will very quickly become much more than £30.
I'm sorry, I misspoke. 20-30 USD is what you will pay for internet access from your phone. From a quick read of AT&T's site, the cheapest reasonable (i.e. has a limit > 10MB/month) plan they offer that allows tethering is either $40 or $60/month.
The trouble with this is that you have to worry about your laptop crashing, being broken or stolen.
No you don't; you just do a "git push" when you get somewhere with internet. You have to do this anyway if you're working with other people.
Today, with a £30 usb wireless dongle, you can commit changes no matter where you are.
Where do you live that you can get internet access while on the bus?
I mean, I could, but only through a cell phone plan. And at 20-30 USD/month, that will very quickly become much more than £30.
The lack of internet access isn't a good enough reason to advocate a distributed VCS. They have plenty of other good aspects to them, but being able to easily hoard changes locally is more a disadvantage than anything.
I guess we have different opinions. For the sorts of things I work on (things that are just me, and relatively small groups of of people), being able to work disconnected is IMO probably the biggest benefit. (It's at least #2; if so, #1 is the fact that distributed VCSs are almost always much better at branching than CVS/SVN. But there's really no reason this needs to be the case while being able to work disconnected is basically an innate feature to DVCS.)