My only quibble with Picasa is that it the Mac version doesn't have proper retina support yet (which you REALLY want in a photo app). I'm sure it will be fixed eventually.
But otherwise Picasa is fantastic. Very good at using the actual files and filesystem rather than a proprietary database.
Whatever you chose, make sure it encodes metadata IN the actual file or filename, so you can shove a subset to whatever other app or platform you like and it will tag along with no process required. Given the choice, in-file is better than filname, so that sync tools can match up different revisions of the same image.
Nope, the EU 'government' created the damn thing in the first place. The EU *court* struck it down.
OTOH, at least the whole scheme was out in the open, as opposed to the plain illegal surveillance in the US.
OTTH, who knows how many of the national goverrments are doing that as well. There is also the neat trick (used by the UK among others) of turning a blind eye to, say, US surveillance of european citizens in return for access to the data. That way noone is offiically spying on their own citizens, but the net result is the same.
For various reasons, functional langugaes are not always a realistic option in you project (especially if you're not starting from scratrch, but yes: there is a lot more to learn from functional programming than lambda-envy.
No, I love objects. But language features should be used where they bring value, not randomly because they're there.
First of all, I have no problem with immutable stuff, I don't even consider that state.
Mutable object state is fine too, as long as it in fact reflects the behaviour you're modelling. But it should be pared down to that. Not absolutely religiously, but it is a good ideal to strive towards, right up there with high cohesion and low coupling.
Many litter their objects with instance variables that do *not* model the core state of the object at all, but rather serve as a 'nifty' way to pass data to functions with less typing. This makes the object more stateful, which just makes life more difficult all around: you need to know what has happened before to predict what a function will do, and so you depend on many more places in the code to be certain that any one piece does what it should. The logic becomes less readable, more bug prone, harder to alter without introducing bugs, and harder to verify with tests. And that's not even going into thread safety and parallelization.
Fighting all this is not fighting object orientation. If anything, some solution approaches can be considered *more* object oriented: if that param-list starts getting too long, rather than abuse instance fields as lazy params, group the params into sensible value objects, and you may find the new abstraction yields additional benefits: an avenue for better expressing function and intent, implementing validation and constraints, encasulating calculations and query logic from the client code where it only constitutes noise, into self-explanatory functions on the data object.
Caching is an optimisation that does indeed introduce state, and all the problems that comes with it in full.
Like all optimisation, it constitutes buying performance in exchange for increased complexity (of some sort). The cost of complexity is high, and the tradeoff should be qualified by a solid cost-benefit anaylis, and by extension pertain to a demonstrably real performance problem.
That said, I certainly accept that 'true' changing state can be part of a good model, and I don't consider that caching. Just keep it under control, make sure it actually delivers value, and don't sprinkle it around lightly.
There are of course cases where comments are warranted, and properly justified optimizations may be just such a case. The others also usually fall under the broader umbrella of "exceptions" to how things might normaly be done. Just don't use it as an excuse to make the code less clear than it could be given the perfomance constraints, and beware of premature optimisation, which is a prime cause of brittle and unreadable code, with frequently no real benefit to offset the cost. And always consider if you could say some of it with code too.
As a general rule, though, I still think it is wise to keep in mind that since the comment is not executed, there is no guarantee that it reamains correct, if ever it was. I sometimes make a hobby out of trying to find at least one error in every comment I see. It doesn't always pan out, but tre percentagewhere it does is both staggering and frightening - I warmly reccommend the practice to everyone.
You always have to keep in mind that code will be changed by serveal peopale, and your 'elegant' intention may not be understood or followed through by the next guy. So go for simple rules of thumb that not only keep your code readable and clear, but can accommodate future change while ramaining so.
My number one rule for keeping code both readable and robust is this: Reduce state.
I don't mean everything needs to be purely functional, but consider state a general liability to both correctness, readability, testability and maintainability. Less is more.. * Whatever state you have should be focused and serve to explain/model the actual problem domain, not just 'keep stuff for later'. * Keep state as local as possible - most code is litered with instance variables that should have been locals and params. * Just because an object _can_ bundle state with its functions doesn't mean it _should_. * If it can be done in a static method and still make sense, do so.
Who said anything about GPS? There there is plenty of stuff in geosynchronous orbit that need a clock accuracy that requires taking relativity into account, and has been from way before GPS, regardless of where the first experiments to demonstrate the effect took place.
In any case, proof at NEO invalidates the newtonian prediction, and I know of no model that predicts that the problem would exist at NEO but go away at higher altitudes.
You're pretty sure. Oh, that's settled then. Don't bother googling it or anything, it's not like anyone actullay knows this stuff or publishes anything about it.
FYI: Merely the altitude of, say, geostationary orbit implies a potential energy that means you have to account for time dilation if you want to stay in sync with clocks on the ground. This was proven experimentally decades ago, and predicted way before that.
This type of catch in itself is not that uncommon or interesting.
The interesting questions are "why so harsh" and mor importantly: "why now?" and?
The answer is that educated russians with marketable degrees are fleeing the country by the boatload to escape what Putin is doing to Russia. Eroding freedoms, isolationalist policies, state-sponsored nationalism, rampant corruption, tolerance of violent crime, and these things in turn scaring away foreign investors - to an intelligent, educated young adult this easily adds up to "not the place to build a future".
If immersive efefct i what you'tre going for, the potential for this technique is in fact severly limited. First let's strip away some marketing mumbo jumbo:
The "projecting directly onto the retina" pitch is bull. Unless you want to venture into eye surgery, you can't bypass the optics of the cornea etc ("lazers" or no "lazers"), so any light looking like it comes from a particular direction has to actually arrive from roughly that direction. It follows that and some part of the chain has to physically cover at least as much of the field of view as it looks like to the viewer. If you're close enough to the cornea that doesn't have to be very big, but unless you're willing to fix your gaze in a single direction and shave your eyelashes, there are practical limits to how far this goes.
The "no screen" pitch is also bull: The DLP-chip is a screen just fine, just a really small, really bright, reflective one. Optics can make it look bigger, but this approach doesn't really scale to anything beyond a binocular-like FOV as long as the screen/chip remains stationary.
Either you need a bigger screen, or you need the small screen to follow your pupil around as your eyes move (really fast). The latter is likely to take longer to become practical than the surgical option, so for the next few decades, it's going to be external screens of some sort for most of us.
That said, doubly curved displays, more advanced optics and futher miniaturisation can greatly improve FOV, size and quality compared to the cluncky rigs we see todaty, but don't expect anything beyond "really clunky ski goggles", even in the long term.
Nope, survival is just one means among several. What evolution is really all about is propagation of DNA.
Traits can rise to prominence or dwindle into nothingness without affecting survival at all, if they affect reproductive success in some other way.
A gene doesn't even have to be reproduced via the same individual to support its own propagation: In multicellular organisms like ourselves, millions of cells self-sacrifice every day, having offloaded the task of propagating their genes to the other clones in in the same colony (i.e. body). Insect colonies display similar constructs at the level of complex individuals, to the point of the majority of individuals being intrinsically sterile.
Humans and other social animals display social contracts that are much weaker, but which still strongly affect behaviour, and probably for much the same reasons. If humans were truly as asocial as lone-hunter-type animals, you and I would be out feeding or sleeping, not hanging out here on slashdot trying to impress each other with our insights.
Granted, repvik goes a bit too far. The claim of controlling for all factors remains irrevocably bunk, but that does not in itself mean the study is not good enough - it merely reflects poorly on the source of that claim. Which brings us to the crux: who is that source? Does the actual publication make this extraordinary claim, or is it merely a perversion introduced by someone else along the chain from there and to this comment?
There are not millions of muslim terrorists. The terrorists I mentioned all pretend (and probably claim in honesty) to be on the side of the greater good, like they all do.
As for small and unimportant, how are you counting? If you include all use of guerilla tactics ion hot conflicts, you have to do som on the other sides too. All of them, all over the world. If you don't, there is not a clear difference in numbers, although one specific attack had an admittedly spectalular bodycount.
This moves in waves. Let's not forget about IRA, ETA, RAF, various other left-wing bombers in Europe, untold guerilla movements in Africa and South America. With some exceptions it mostly follows where there are active separatist movements at any given time Do your homework.
They don't build machines to do it. You could build stuff that way yourself too, manually using a hot glue gun or an icing bag or whatever (I won't get into the more literal or imaginative emulations) and it would probably not be patentable, and certainly not covered by current 3D printing patents.
Slashdot Mirror
How does exclusive programming compare to extreme programming and functional programming?
My only quibble with Picasa is that it the Mac version doesn't have proper retina support yet (which you REALLY want in a photo app). I'm sure it will be fixed eventually.
But otherwise Picasa is fantastic. Very good at using the actual files and filesystem rather than a proprietary database.
Whatever you chose, make sure it encodes metadata IN the actual file or filename, so you can shove a subset to whatever other app or platform you like and it will tag along with no process required. Given the choice, in-file is better than filname, so that sync tools can match up different revisions of the same image.
Oh, they make a profit all right. By taking the money and then not making any flying cars.
Nope, the EU 'government' created the damn thing in the first place. The EU *court* struck it down.
OTOH, at least the whole scheme was out in the open, as opposed to the plain illegal surveillance in the US.
OTTH, who knows how many of the national goverrments are doing that as well.
There is also the neat trick (used by the UK among others) of turning a blind eye to, say, US surveillance of european citizens in return for access to the data. That way noone is offiically spying on their own citizens, but the net result is the same.
For various reasons, functional langugaes are not always a realistic option in you project (especially if you're not starting from scratrch, but yes: there is a lot more to learn from functional programming than lambda-envy.
No, I love objects.
But language features should be used where they bring value, not randomly because they're there.
First of all, I have no problem with immutable stuff, I don't even consider that state.
Mutable object state is fine too, as long as it in fact reflects the behaviour you're modelling. But it should be pared down to that. Not absolutely religiously, but it is a good ideal to strive towards, right up there with high cohesion and low coupling.
Many litter their objects with instance variables that do *not* model the core state of the object at all, but rather serve as a 'nifty' way to pass data to functions with less typing. This makes the object more stateful, which just makes life more difficult all around: you need to know what has happened before to predict what a function will do, and so you depend on many more places in the code to be certain that any one piece does what it should. The logic becomes less readable, more bug prone, harder to alter without introducing bugs, and harder to verify with tests. And that's not even going into thread safety and parallelization.
Fighting all this is not fighting object orientation. If anything, some solution approaches can be considered *more* object oriented: if that param-list starts getting too long, rather than abuse instance fields as lazy params, group the params into sensible value objects, and you may find the new abstraction yields additional benefits: an avenue for better expressing function and intent, implementing validation and constraints, encasulating calculations and query logic from the client code where it only constitutes noise, into self-explanatory functions on the data object.
Caching is an optimisation that does indeed introduce state, and all the problems that comes with it in full.
Like all optimisation, it constitutes buying performance in exchange for increased complexity (of some sort). The cost of complexity is high, and the tradeoff should be qualified by a solid cost-benefit anaylis, and by extension pertain to a demonstrably real performance problem.
That said, I certainly accept that 'true' changing state can be part of a good model, and I don't consider that caching. Just keep it under control, make sure it actually delivers value, and don't sprinkle it around lightly.
I was intentionally overstating it a bit.
There are of course cases where comments are warranted, and properly justified optimizations may be just such a case. The others also usually fall under the broader umbrella of "exceptions" to how things might normaly be done. Just don't use it as an excuse to make the code less clear than it could be given the perfomance constraints, and beware of premature optimisation, which is a prime cause of brittle and unreadable code, with frequently no real benefit to offset the cost.
And always consider if you could say some of it with code too.
As a general rule, though, I still think it is wise to keep in mind that since the comment is not executed, there is no guarantee that it reamains correct, if ever it was.
I sometimes make a hobby out of trying to find at least one error in every comment I see. It doesn't always pan out, but tre percentagewhere it does is both staggering and frightening - I warmly reccommend the practice to everyone.
You always have to keep in mind that code will be changed by serveal peopale, and your 'elegant' intention may not be understood or followed through by the next guy. So go for simple rules of thumb that not only keep your code readable and clear, but can accommodate future change while ramaining so.
My number one rule for keeping code both readable and robust is this: Reduce state.
I don't mean everything needs to be purely functional, but consider state a general liability to both correctness, readability, testability and maintainability. Less is more..
* Whatever state you have should be focused and serve to explain/model the actual problem domain, not just 'keep stuff for later'.
* Keep state as local as possible - most code is litered with instance variables that should have been locals and params.
* Just because an object _can_ bundle state with its functions doesn't mean it _should_.
* If it can be done in a static method and still make sense, do so.
All comments are lies.
Write readable *code*
It does neither. Which dimension reversed is left as an exercise to the reader. Hint: it's not time.
Who said anything about GPS? There there is plenty of stuff in geosynchronous orbit that need a clock accuracy that requires taking relativity into account, and has been from way before GPS, regardless of where the first experiments to demonstrate the effect took place.
In any case, proof at NEO invalidates the newtonian prediction, and I know of no model that predicts that the problem would exist at NEO but go away at higher altitudes.
You're pretty sure. Oh, that's settled then. Don't bother googling it or anything, it's not like anyone actullay knows this stuff or publishes anything about it.
FYI: Merely the altitude of, say, geostationary orbit implies a potential energy that means you have to account for time dilation if you want to stay in sync with clocks on the ground. This was proven experimentally decades ago, and predicted way before that.
This type of catch in itself is not that uncommon or interesting.
The interesting questions are "why so harsh" and mor importantly:
"why now?" and?
The answer is that educated russians with marketable degrees are fleeing the country by the boatload to escape what Putin is doing to Russia.
Eroding freedoms, isolationalist policies, state-sponsored nationalism, rampant corruption, tolerance of violent crime, and these things in turn scaring away foreign investors - to an intelligent, educated young adult this easily adds up to "not the place to build a future".
Same here. What I need is a sharp axe to split firewood with. Why would I use a console OS for that? This product is clearly worthless.
this has far more potential
If immersive efefct i what you'tre going for, the potential for this technique is in fact severly limited.
First let's strip away some marketing mumbo jumbo:
The "projecting directly onto the retina" pitch is bull.
Unless you want to venture into eye surgery, you can't bypass the optics of the cornea etc ("lazers" or no "lazers"), so any light looking like it comes from a particular direction has to actually arrive from roughly that direction. It follows that and some part of the chain has to physically cover at least as much of the field of view as it looks like to the viewer. If you're close enough to the cornea that doesn't have to be very big, but unless you're willing to fix your gaze in a single direction and shave your eyelashes, there are practical limits to how far this goes.
The "no screen" pitch is also bull:
The DLP-chip is a screen just fine, just a really small, really bright, reflective one. Optics can make it look bigger, but this approach doesn't really scale to anything beyond a binocular-like FOV as long as the screen/chip remains stationary.
Either you need a bigger screen, or you need the small screen to follow your pupil around as your eyes move (really fast).
The latter is likely to take longer to become practical than the surgical option, so for the next few decades, it's going to be external screens of some sort for most of us.
That said, doubly curved displays, more advanced optics and futher miniaturisation can greatly improve FOV, size and quality compared to the cluncky rigs we see todaty, but don't expect anything beyond "really clunky ski goggles", even in the long term.
Nope, survival is just one means among several.
What evolution is really all about is propagation of DNA.
Traits can rise to prominence or dwindle into nothingness without affecting survival at all, if they affect reproductive success in some other way.
A gene doesn't even have to be reproduced via the same individual to support its own propagation:
In multicellular organisms like ourselves, millions of cells self-sacrifice every day, having offloaded the task of propagating their genes to the other clones in in the same colony (i.e. body). Insect colonies display similar constructs at the level of complex individuals, to the point of the majority of individuals being intrinsically sterile.
Humans and other social animals display social contracts that are much weaker, but which still strongly affect behaviour, and probably for much the same reasons.
If humans were truly as asocial as lone-hunter-type animals, you and I would be out feeding or sleeping, not hanging out here on slashdot trying to impress each other with our insights.
That's what they want you to think.
Suomin still has to sweden the deal with some cash. How el-scandianavia-ford it?
Suomi the money!
Granted, repvik goes a bit too far. The claim of controlling for all factors remains irrevocably bunk, but that does not in itself mean the study is not good enough - it merely reflects poorly on the source of that claim. Which brings us to the crux: who is that source? Does the actual publication make this extraordinary claim, or is it merely a perversion introduced by someone else along the chain from there and to this comment?
Even a team of specially-trained machine learning experts makes only painfully slow progress due to the lack of tools to build these systems
Why not just teach a machine to do it?
Total deaths from all the groups in Europe you listed are quite possibly smaller than from the September 11 attacks alone.
You are quite possibly making this shit up as you go along.
There are not millions of muslim terrorists.
The terrorists I mentioned all pretend (and probably claim in honesty) to be on the side of the greater good, like they all do.
As for small and unimportant, how are you counting? If you include all use of guerilla tactics ion hot conflicts, you have to do som on the other sides too. All of them, all over the world.
If you don't, there is not a clear difference in numbers, although one specific attack had an admittedly spectalular bodycount.
most Terrorists are Muslims.
Troll.
This moves in waves.
Let's not forget about IRA, ETA, RAF, various other left-wing bombers in Europe, untold guerilla movements in Africa and South America.
With some exceptions it mostly follows where there are active separatist movements at any given time
Do your homework.
They don't build machines to do it.
You could build stuff that way yourself too, manually using a hot glue gun or an icing bag or whatever (I won't get into the more literal or imaginative emulations) and it would probably not be patentable, and certainly not covered by current 3D printing patents.