Small error here: the G5 is a wired mouse with adjustable weights, but the G7 is a wireless mouse w/o adjustable weights, it features a pair of unloadable batteries (that you push in the batt loader e.g. you never run out of batteries)
Maybe it's just me, but a dual core notebook seems a little wierd. As internet connections speed up we do more and more on the server, the notbook (phone, trio, etc) becomes more of a slow single core type system IMO. Dual core notebooks will use a lot of batery too. I'd rather have a thinner client than that.
See the top tier designer/web geeks (even though they mostly use Apple machines) and "unstuck" alpha geeks in general (unstuck as in "don't spend their whole life in a basement), most of them make extensive use of laptops for all kinds of task including computation-intensive or coding, and quite a few of the designer/web crew even moved from the "desktop + laptop" to "full laptop". Given the fact that they run things like Photoshop or Illustrator on their boxes, with an optional Apache and a pair of interpreters (PHP, Ruby) plus the backed DBs if needed, these guys DO need more power. And more power for a longer time.
While you may not see a use for it (and will therefore be able to buy cheaper weaker laptops) other people do need it.
Cosmetically speaking, the Raptor X pays homage to the DIY crowd that enjoys things such as clear PC cases with... well, a transparent cover. Though the actual top plate remains a jet-black aluminum compound, the portion that actually sits atop the spindle assembly, constructed from polycarbonate, permits a clear view of the drive's interior. To further the product's unique appearance, WD investigated incorporating an LED into the device but ruled it out due to engineering constraints.
Long story short, no LED for yuo
(and about the price thing, you're paying the window+jet black casing $50 extra over the regular version of the drive)
Given the fact that the version with plexi has half the MTBF of the regular version for (at best) the same price, the window does make it expensive (potentially, as far as WD is concerned).
I'm pretty sure OP mentioned Raid5, I strongly suggest you to look it up since it has near Raid0 speed with security on top at a minimal cost overhead.
With a clear cover, you can look to see if the heads are actually moving, and whether they're moving to the correct position.
Exactly! Only retards don't know the physical position of their data on each of the 3-platters drive of their RAID array!
Come on, the only diagnostic that this would help you do is "heads don't move, drive is dead" or "heads ripped through the platter, box full of junk, drive is dead" and last time I checked it wasn't necessary to open the disk to see that it was dead.
Not with blinking lights, neons, stripes and other transparent panels, because... let's face it... the other family members don't give a flying fuck about a transparent christmas tree in midsummer.
Nice looking cases such as the Lian-Li stuff is a whole other matter (because they just, you know, actually look good on top of being high quality) which we're not discussing here, you see.
Actually, it's exactly as difficult as the second case. I gave the same problem twice in different guises. You can't be sure that ++ really means to add 1. There could be an overloaded operator++ involved, and it might do absolutely anything.
Aah, perfectly true, I had forgotten about the potential overloading of that operator and stand corrected
But the first case would in fact be extremely simple to implement:
extract the value of the property (call the getter method under the hood), send the retrieved value to the function, add "1" to the retrieved value, call the setter method of the property.
Here you are, done, I don't see the issue here, this is completely trivial.
The second case would prove more problematic philosophically: shall we send the method a reference to the property object itself, or to the value retrieved from it? Sending the property object would probably break the type system, so we'd have to go with the object retrieved (makes sense). Luckily, languages implementing properties don't have that kind of insanity, so the issue is moot.
(Final note: calling C++ "elaborate" may be going a bit too far, Smalltalk, Ruby or Python seem much more "elaborate" to me.)
That's an excellent argument for goto. I expect to see more of it in your code.
I'm sorry to say that I currently use goto-less languages (although I expect a patch to implement come-from in them soon). That said, goto is indeed a tool and has it's uses despite the hatred of Dikjstra and Wirth for it, see the Linux Kernel code for uses of goto. I would use gotos if I coded in languages allowing it and if the situation required it.
When properties are in use, they can make things happen that make no sense.
How about blaming the designer of the api/lib/whatever for his misuse/abuse of properties instead of the properties mechanism itself?
This is due to the community of the language rather then the language itself. It seems like the Ruby community learned the right lessons from perl and build GEM.
That I perfectly agree, Python Eggs are clearly not in the same league as Ruby's Gems, and it's a shame...
It looks cleaner, but it can introduce hidden bugs. Just one person using 4-tabs vs. everyone else using 4 spaces leads to a mysterious bug, since the interpreter takes every tab to be a 8-tab.
The interpreter will more than likely whine because of indentation mismatch.
And tell you where it happens, so that you can nicely normalize indentation (your editor can do that can't it?)
I'm sure any large Python development crew can tell you that this ended up being a problem for them at some point.
And I sure hope that every Python development crew (large or not) has minimum style guidelines in which a single indentation style is specified and required. And uses PyLint/PyChecker to check for that kind of issues.
Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).
Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.
Properties are worthless and good at hiding side effects.
Properties are a tool, their main goal is to ensure a pure abstraction of the class interface (properties are virtual members, meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that, and at allowing clean and straightforward construct with readable syntaxes.
As every tool (C++ operator overloading debacle), they can be abused, badly. That doesn't mean they're *bad*, no more than an oven is inherently bad just because you can burn babies alive in it.
Ruby and Python are more or less equivalent languages, extremely similar in most constructs and ways of life, and rougly 90% of the "differences" between the languages boil down to syntactic sugar.
And please, I beg you, don't bring Blocks in this by saying something as stupid as "woohoo, blocks are liek magic, no one else has it, they're cruise control for greatness", blocks are anonymous functions period (in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects), the concept is more than 30 years old... (and not OO at all, meaning that the "top of the line" feature of the OO herald language is purely functional).
Ruby is an extremely fine dynamically strongly typed language with an extreme object orientation, Python is likewise. None of them is "better than the other one" in an absolute sense and claiming the opposide is stupid, the one you choose is purely a matter of taste. You prefer Ruby? good for you, I prefer Python, and that makes neither "the ultimate language".
This fucking ruby hype is becoming extremely tiring, and doesn't help Ruby.
Slashdot Mirror
Small error here: the G5 is a wired mouse with adjustable weights, but the G7 is a wireless mouse w/o adjustable weights, it features a pair of unloadable batteries (that you push in the batt loader e.g. you never run out of batteries)
but that mouse gets the prize, it's ugly as a sin and looks badly built...
See the top tier designer/web geeks (even though they mostly use Apple machines) and "unstuck" alpha geeks in general (unstuck as in "don't spend their whole life in a basement), most of them make extensive use of laptops for all kinds of task including computation-intensive or coding, and quite a few of the designer/web crew even moved from the "desktop + laptop" to "full laptop". Given the fact that they run things like Photoshop or Illustrator on their boxes, with an optional Apache and a pair of interpreters (PHP, Ruby) plus the backed DBs if needed, these guys DO need more power. And more power for a longer time.
While you may not see a use for it (and will therefore be able to buy cheaper weaker laptops) other people do need it.
Well, from TFA, Lenovo's preproduction T60 with Centrino Duo has a 5h battery life, and does accept an extra battery in the extension slot.
Although they couldn't test it, the Anandtech guys clearly stated they didn't doubt the thing could go beyond 9h battery life total...
Quote of the StorageReview article;
Long story short, no LED for yuo
(and about the price thing, you're paying the window+jet black casing $50 extra over the regular version of the drive)
Actually, the StorageReview article on the Raptor150/RaptorX states that both versions are backed with a 5 year warranty.
Oh, and the regular unit is $300 to boot btw, so that shiny window means you're paying $50 extra (+17%) for basically nothing.
Given the fact that the version with plexi has half the MTBF of the regular version for (at best) the same price, the window does make it expensive (potentially, as far as WD is concerned).
I'm pretty sure OP mentioned Raid5, I strongly suggest you to look it up since it has near Raid0 speed with security on top at a minimal cost overhead.
Exactly! Only retards don't know the physical position of their data on each of the 3-platters drive of their RAID array!
Come on, the only diagnostic that this would help you do is "heads don't move, drive is dead" or "heads ripped through the platter, box full of junk, drive is dead" and last time I checked it wasn't necessary to open the disk to see that it was dead.
Not with blinking lights, neons, stripes and other transparent panels, because... let's face it... the other family members don't give a flying fuck about a transparent christmas tree in midsummer.
Nice looking cases such as the Lian-Li stuff is a whole other matter (because they just, you know, actually look good on top of being high quality) which we're not discussing here, you see.
As in "Car tuning is all about being cool and different", e.g. a redneck passion for the ones at the top of the `peoples who have no life` pyramid?
In this case, not only dies the drive cost more indeed (compared to the regular version), but the MTBF is halved or something...
And it's not even like you can really take a look at your drive when it's screwed in it's cage...
Bah, I guess that if that one works the next move they'll do is sell hard drives with leds inside the drive...
That's the job of the police, the guys switching there are the [i]military police[/i] guys
In other news, Steve Ballmer has vowed to Fucking Kill(TM) the French military police.
Aah, perfectly true, I had forgotten about the potential overloading of that operator and stand corrected
Duh, well, C++ doesn't have properties anyway.
But the first case would in fact be extremely simple to implement: extract the value of the property (call the getter method under the hood), send the retrieved value to the function, add "1" to the retrieved value, call the setter method of the property.
Here you are, done, I don't see the issue here, this is completely trivial.
The second case would prove more problematic philosophically: shall we send the method a reference to the property object itself, or to the value retrieved from it? Sending the property object would probably break the type system, so we'd have to go with the object retrieved (makes sense). Luckily, languages implementing properties don't have that kind of insanity, so the issue is moot.
(Final note: calling C++ "elaborate" may be going a bit too far, Smalltalk, Ruby or Python seem much more "elaborate" to me.)
I'm sorry to say that I currently use goto-less languages (although I expect a patch to implement come-from in them soon). That said, goto is indeed a tool and has it's uses despite the hatred of Dikjstra and Wirth for it, see the Linux Kernel code for uses of goto. I would use gotos if I coded in languages allowing it and if the situation required it.
How about blaming the designer of the api/lib/whatever for his misuse/abuse of properties instead of the properties mechanism itself?
That I perfectly agree, Python Eggs are clearly not in the same league as Ruby's Gems, and it's a shame...
The interpreter will more than likely whine because of indentation mismatch.
And tell you where it happens, so that you can nicely normalize indentation (your editor can do that can't it?)
And I sure hope that every Python development crew (large or not) has minimum style guidelines in which a single indentation style is specified and required. And uses PyLint/PyChecker to check for that kind of issues.
You shoot yourself in the foot and blow the whole leg up to the hip (but including your groin) in the process.
Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).
Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.
Ah, so every language should be fucking sloppy and should then add constructs to remove the sloppyness for you to accept to use them?
Ever thought about using a language designed without the sloppyness in the first place?
Properties are a tool, their main goal is to ensure a pure abstraction of the class interface (properties are virtual members, meaning that the outside of the object cannot know and doesn't care wether an attribute is "real" or "virtualized" and they're very good at that, and at allowing clean and straightforward construct with readable syntaxes.
As every tool (C++ operator overloading debacle), they can be abused, badly. That doesn't mean they're *bad*, no more than an oven is inherently bad just because you can burn babies alive in it.
Sorry, I have.
Ruby and Python are more or less equivalent languages, extremely similar in most constructs and ways of life, and rougly 90% of the "differences" between the languages boil down to syntactic sugar.
And please, I beg you, don't bring Blocks in this by saying something as stupid as "woohoo, blocks are liek magic, no one else has it, they're cruise control for greatness", blocks are anonymous functions period (in the Functional Programming sense of the term, e.g. functions with closures that are first-class objects), the concept is more than 30 years old... (and not OO at all, meaning that the "top of the line" feature of the OO herald language is purely functional).
Ruby is an extremely fine dynamically strongly typed language with an extreme object orientation, Python is likewise. None of them is "better than the other one" in an absolute sense and claiming the opposide is stupid, the one you choose is purely a matter of taste. You prefer Ruby? good for you, I prefer Python, and that makes neither "the ultimate language".
This fucking ruby hype is becoming extremely tiring, and doesn't help Ruby.
End of the rant