A credit card is a lot larger than a flash card though.. Imagine your camera with an additional credit-card-sized reader on it - mine would certainly be significantly bigger than it is.
I don't think it's going to compete too well with flash-based solutions since it's just too big. It's more likely to be (as other people have pointed out) a new, bigger replacement for floppy and zip drives.
iPods currently go up to 20Gb I believe - if a 100Mb one of these new cards is around the $10-$15 mark, then a 5Gb one is going to be around $500, and that's just using a linear scale which these things never do. Note, the article does not say $15 for 5Gb!
So I don't think this is going to compete with iPod/Archos style MP3 players in a hurry.
This site mentions a 5Mb/s transfer rate which I guess would be more than enough for DVD movies.
However, it says that this figure is for the 100Mb version and that it "scales" to the 5Gb version. What does that mean, I wonder? It will be 50 times faster for the 5Gb version? I don't think so, somehow - 50 times slower? That might be pushing it for DVD usage at 100Mb/sec..
I can't find anything to say how fast these drives are, and whether they could sustain the speed of transfer necessary for a DVD movie.
Also, the article says they start at 100Mb and go up to "as much as" 5Gb, so that price of $15 may just be for the 100Mb version, at which point it doesn't sound quite so attractive.
Although not identical to the Finnish laws on copyright, the UK government are attempting to pass a law which could theoretically affect a nursery school teacher singing to infants.
I've been wondering for some time why the Save Farscape lobby isn't pushing for a straight-to-DVD release on season 5. I'd put up a lot of money in advance for that (but I won't spend a lot just to subsidise some huge TV company to make it when they'll end up raking in the profits..).
If the TV networks won't carry it, try a different distribution channel!
OK, truce on the flamewar/interesting discussion/however you want to put it. I would look back at this conversation in the context of my original point - which was that it is not *necessary* to know the deeper stuff in order to use something adequately - I think you'll note that even in my original message I said that a deeper knowledge can bring some benefits, and I'd hate to argue that it would never be of benefit - I share your views on bloated code and that' not what I meant at all - you may have misunderstood me.
"Necessary" and "beneficial" are two different concepts.. When I said "I do not need to know that" I mean I can manage without it - I did not at all intend to imply that I shouldn't learn it, or even that I wouldn't benefit from learning it, just that I didn't *need* to in order to perform the task adequately.
Also: there is a big difference between "feature bloat" and "maintainable code", just as there is (often) a big difference between "maintainable code" and "heavily optimised code". I can easily argue that making code maintainable and re-usable is not at all the same as making it bloated, particularly in applications development. Re-usable code can make the source tree smaller because you're not forever having to re-invent the wheel. Abstraction for the programmer does not automatically mean lack of performance for the user, especially when you try to define "performance" a bit more generically in terms of what the user expects, rather than just straight speed of response.
Real-time stuff and embedded systems are a completely different kettle of fish - there every resource has to be rationed carefully, whether processor time or memory usage. I said this in the original post...
OK, maybe you can shave 10% execution time by writing some obfuscated code - but what's the point if the next engineer down the line doesn't understand it, or can't re-use it to do what he/she wants because it has become too specialised?
Time-to-market and ease of maintenance are equally important as the last few ounces of performance (Note: I'm only talking about the last few ounces which you can get by knowing about the underlying electronics - the rest is just good programming and I would assume any decent software engineer can make obvious choices - obviously performance is important!).
Surely this is just a case of flagging one of the undo states as a permanent version..? It's not exactly rocket science.
I agree with you that the user probably has a concept of a "finished version" - although I question how close this is to the different saved files people end up with at the moment. Some kind of document managing filesystem should be able to handle this - you just flag the particular undo states for each version.
I think that argument only works down to a certain level, no matter what the technology is. Obviously, as a software engineer, I have a fairly good understanding of how computers work. However, if pushed, my deep knowledge about the electronics which make up a CPU and the underlying technology is pretty weak. I don't need to know this stuff for the application development I do in Java or C++. If I did embedded systems programming the situation might be very different. Also, if I did know this stuff I might write better programs, perhaps, but I don't *need* to know in order to write adequate, functional code which performs half-decently, is easy to maintain and re-use.
In the Microwave Oven example, I don't think it is at all obvious to joe user how it works. All they know is that they can set it for a specific length of time, and maybe different power levels, and that it heats stuff up. I go a few steps beyond that in that I have a chemical physics degree (from a long time ago!) so that (if I dig deeply!) I can remember stuff about molecular orbitals and energy absorption etc.. but I still don't know exactly how the microwaves are produced because I never asked anyone - nor do I need to in order to get my hot ready meal every evening (I work long hours, OK? don't hassle me over my eating habits!:).
(before you all start explaining microwave ovens to me I really don't want to know - if I did I could work it out for myself or look it up!)
So, I maintain that a user really only needs to go as deep as required for the job they are doing, or possibly a tiny bit deeper for that little extra understanding. In the case of someone using a computer for word processing they need to know how to turn the machine on, how to start the word processor and how to type - they don't need to know about disk caches, or saving in blocks rather than bytes, or CPU cycles.. Knowing about these things does nothing to help them do their job. There's no reason *why* they should have to know these things - computers are there to help people, after all, not to hinder them.
It's the job of the software engineer (and the product manager, and maybe the UI designer) to make life as easy as possible for the user, based on the known knowledge that user has.
For example, the need to save a document. This is not a bad thing if done properly, in fact, it helps (forces) the users to understand how the actual machine works (it writes periodically to the disk, and not one character at a time).
With modern technology, why shouldn't it write one character at a time to the disk? Or at least write it into the disk cache.. I know it's less than optimal but your word processor isn't going to stress the system out by doing this on a modern PC, and it would be much more intuitive to the user (assuming that the user wasn't already familiar with having to press the "save" button.).. and why should the modern user understand how the machine works anyhow? I don't know how my microwave oven generates microwaves (although I could find out easily enough if I needed to) but it doesn't prevent me from heating up ready-meals..
On the contrary, my dear Watson. What if I change something in my Word document, but later on decides it was no good and wish to discard it? Nope, sorry. My old document is already rewritten with no turning back. Or is he suggesting that everyone should always make a copy of a document before editing it, just in case? Wouldn't THAT seem terrible unintuitive?
Like an eraser, or a bottle of tippex, that's what the "undo" button is there for. All this means is that the save process has to be a bit more sophisticated and store the last n changes.
Q.
Re:Important point that the review might have miss
on
Design Patterns
·
· Score: 2
For instance, you might have 're-discovered' the visitor pattern yourself and used it several times, but without the nomenclature of this book it was very hard to actually talk about that design with other developers.
The flip side of this is that the code you wrote to access your database used to log web site vistors confuses the hell out of the same developers when they see your "Visitor" object..
Seriously, the number of times I've chosen a class name for perfectly good reasons only to find out it conflicts with a design pattern name is frustratingly large.
It gets to the stage where whole swathes of the English language have been removed from the programming namespace by the people who write pattern books.
Patterns are great in their place, but we are in danger of having too many and they can't solve all the world's problems. Stop creating more patterns and using up more valuable English words before all my variables and classes become "flirble", "glarble" and "dooberry"..!!
... and there was me thinking that my presentation skills and general understanding of the industry were the key points in communicating with my less technical colleagues.
Obviously I'm wrong, and as soon as I start wearing a suit and tie everyone will understand me much more easily.
So you can't see the difference in meaning between "I am coming to the opinion that" and "I think that"..? The difference is subtle, I'll grant you, but there is a significant difference. If I had said "I think that" it would be false - I *don't* think that, but I'm getting to the stage where I might do soon...
I'm not defending my grammar, by the way - I'm sure it's terrible. After all MS Word is forever telling me everything I type is wrong..
Slashdot Mirror
Looks like one too, to me - I think Sony just found a clever way of marketing a big laptop..
Q.
A credit card is a lot larger than a flash card though.. Imagine your camera with an additional credit-card-sized reader on it - mine would certainly be significantly bigger than it is.
I don't think it's going to compete too well with flash-based solutions since it's just too big. It's more likely to be (as other people have pointed out) a new, bigger replacement for floppy and zip drives.
iPods currently go up to 20Gb I believe - if a 100Mb one of these new cards is around the $10-$15 mark, then a 5Gb one is going to be around $500, and that's just using a linear scale which these things never do. Note, the article does not say $15 for 5Gb!
So I don't think this is going to compete with iPod/Archos style MP3 players in a hurry.
Q.
Actually the spec says "5MB" which I took to mean 5MByte, not 5Mbit, which would be plenty for a DVD. But yes, if it's 5Mbit that's not so good..
:)
My fault for mis-quoting a small "b"
Q.
This site mentions a 5Mb/s transfer rate which I guess would be more than enough for DVD movies.
However, it says that this figure is for the 100Mb version and that it "scales" to the 5Gb version. What does that mean, I wonder? It will be 50 times faster for the 5Gb version? I don't think so, somehow - 50 times slower? That might be pushing it for DVD usage at 100Mb/sec..
Q.
I can't find anything to say how fast these drives are, and whether they could sustain the speed of transfer necessary for a DVD movie.
Also, the article says they start at 100Mb and go up to "as much as" 5Gb, so that price of $15 may just be for the 100Mb version, at which point it doesn't sound quite so attractive.
Q.
.... and here is what I believe to be the text of the bill.
(I know, bad form to reply to my own post - apologies..)
Q.
Although not identical to the Finnish laws on copyright, the UK government are attempting to pass a law which could theoretically affect a nursery school teacher singing to infants.
Here is some info, and here is the online petition protesting against this.
Q.
I've been wondering for some time why the Save Farscape lobby isn't pushing for a straight-to-DVD release on season 5. I'd put up a lot of money in advance for that (but I won't spend a lot just to subsidise some huge TV company to make it when they'll end up raking in the profits..).
If the TV networks won't carry it, try a different distribution channel!
Q.
... for this guy.
Q.
You probably know people who own assault rifles.
I guarantee that none of my close friends own assault rifles.
Q.
OK, truce on the flamewar/interesting discussion/however you want to put it. I would look back at this conversation in the context of my original point - which was that it is not *necessary* to know the deeper stuff in order to use something adequately - I think you'll note that even in my original message I said that a deeper knowledge can bring some benefits, and I'd hate to argue that it would never be of benefit - I share your views on bloated code and that' not what I meant at all - you may have misunderstood me.
"Necessary" and "beneficial" are two different concepts.. When I said "I do not need to know that" I mean I can manage without it - I did not at all intend to imply that I shouldn't learn it, or even that I wouldn't benefit from learning it, just that I didn't *need* to in order to perform the task adequately.
Also: there is a big difference between "feature bloat" and "maintainable code", just as there is (often) a big difference between "maintainable code" and "heavily optimised code". I can easily argue that making code maintainable and re-usable is not at all the same as making it bloated, particularly in applications development. Re-usable code can make the source tree smaller because you're not forever having to re-invent the wheel. Abstraction for the programmer does not automatically mean lack of performance for the user, especially when you try to define "performance" a bit more generically in terms of what the user expects, rather than just straight speed of response.
Real-time stuff and embedded systems are a completely different kettle of fish - there every resource has to be rationed carefully, whether processor time or memory usage. I said this in the original post...
Q.
Efficiency is a state of mind :)
OK, maybe you can shave 10% execution time by writing some obfuscated code - but what's the point if the next engineer down the line doesn't understand it, or can't re-use it to do what he/she wants because it has become too specialised?
Time-to-market and ease of maintenance are equally important as the last few ounces of performance (Note: I'm only talking about the last few ounces which you can get by knowing about the underlying electronics - the rest is just good programming and I would assume any decent software engineer can make obvious choices - obviously performance is important!).
Q.
But you'll be able to produce better code if you do know this stuff.
Define "better". Will it be more maintainable? Easier to read? Easier to explain to people? More re-useable? More flexible?
Q.
Surely this is just a case of flagging one of the undo states as a permanent version..? It's not exactly rocket science.
I agree with you that the user probably has a concept of a "finished version" - although I question how close this is to the different saved files people end up with at the moment. Some kind of document managing filesystem should be able to handle this - you just flag the particular undo states for each version.
Q.
I think that argument only works down to a certain level, no matter what the technology is. Obviously, as a software engineer, I have a fairly good understanding of how computers work. However, if pushed, my deep knowledge about the electronics which make up a CPU and the underlying technology is pretty weak. I don't need to know this stuff for the application development I do in Java or C++. If I did embedded systems programming the situation might be very different. Also, if I did know this stuff I might write better programs, perhaps, but I don't *need* to know in order to write adequate, functional code which performs half-decently, is easy to maintain and re-use.
:).
In the Microwave Oven example, I don't think it is at all obvious to joe user how it works. All they know is that they can set it for a specific length of time, and maybe different power levels, and that it heats stuff up. I go a few steps beyond that in that I have a chemical physics degree (from a long time ago!) so that (if I dig deeply!) I can remember stuff about molecular orbitals and energy absorption etc.. but I still don't know exactly how the microwaves are produced because I never asked anyone - nor do I need to in order to get my hot ready meal every evening (I work long hours, OK? don't hassle me over my eating habits!
(before you all start explaining microwave ovens to me I really don't want to know - if I did I could work it out for myself or look it up!)
So, I maintain that a user really only needs to go as deep as required for the job they are doing, or possibly a tiny bit deeper for that little extra understanding. In the case of someone using a computer for word processing they need to know how to turn the machine on, how to start the word processor and how to type - they don't need to know about disk caches, or saving in blocks rather than bytes, or CPU cycles.. Knowing about these things does nothing to help them do their job. There's no reason *why* they should have to know these things - computers are there to help people, after all, not to hinder them.
It's the job of the software engineer (and the product manager, and maybe the UI designer) to make life as easy as possible for the user, based on the known knowledge that user has.
Q.
Which millions of people already are. It's automatic for me to press Ctrl+S every few minutes.
:)
Yeah, I didn't say it was a good assumption
Q.
For example, the need to save a document. This is not a bad thing if done properly, in fact, it helps (forces) the users to understand how the actual machine works (it writes periodically to the disk, and not one character at a time).
.. and why should the modern user understand how the machine works anyhow? I don't know how my microwave oven generates microwaves (although I could find out easily enough if I needed to) but it doesn't prevent me from heating up ready-meals..
With modern technology, why shouldn't it write one character at a time to the disk? Or at least write it into the disk cache.. I know it's less than optimal but your word processor isn't going to stress the system out by doing this on a modern PC, and it would be much more intuitive to the user (assuming that the user wasn't already familiar with having to press the "save" button.)
Q.
On the contrary, my dear Watson. What if I change something in my Word document, but later on decides it was no good and wish to discard it? Nope, sorry. My old document is already rewritten with no turning back. Or is he suggesting that everyone should always make a copy of a document before editing it, just in case? Wouldn't THAT seem terrible unintuitive?
Like an eraser, or a bottle of tippex, that's what the "undo" button is there for. All this means is that the save process has to be a bit more sophisticated and store the last n changes.
Q.
For instance, you might have 're-discovered' the visitor pattern yourself and used it several times, but without the nomenclature of this book it was very hard to actually talk about that design with other developers.
The flip side of this is that the code you wrote to access your database used to log web site vistors confuses the hell out of the same developers when they see your "Visitor" object..
Seriously, the number of times I've chosen a class name for perfectly good reasons only to find out it conflicts with a design pattern name is frustratingly large.
It gets to the stage where whole swathes of the English language have been removed from the programming namespace by the people who write pattern books.
Patterns are great in their place, but we are in danger of having too many and they can't solve all the world's problems. Stop creating more patterns and using up more valuable English words before all my variables and classes become "flirble", "glarble" and "dooberry"..!!
Q.
Unfortunately there are way too many examples of prior art..
Q.
"...accidentally started vi..."
- you mean there are some people who start it deliberately?!!
Q.
... and there was me thinking that my presentation skills and general understanding of the industry were the key points in communicating with my less technical colleagues.
Obviously I'm wrong, and as soon as I start wearing a suit and tie everyone will understand me much more easily.
Q.
Didn't they force her to switch to Windows? Surely that's punishment enough??!
Q.
So you can't see the difference in meaning between "I am coming to the opinion that" and "I think that"..? The difference is subtle, I'll grant you, but there is a significant difference. If I had said "I think that" it would be false - I *don't* think that, but I'm getting to the stage where I might do soon...
I'm not defending my grammar, by the way - I'm sure it's terrible. After all MS Word is forever telling me everything I type is wrong..
Q.
You don't mean to say that Slashdotters are actually reading the article before posting, do you..?
Q.