SVN has all kinds of issues. It really needs a therapist at this point. Git is the best of the open-source systems. Of the closed systems, Perforce and Plastic are the only serious contenders, but I've had a hell of a time with Plastic due to the way it identifies individuals, problems with unmerging and database organization that's kludgy at best. Perforce is ancient, has some amazingly bad quirks, and is more expensive than hell above a couple of users.
I've burned many brain cycles trying to decide what to do, since Git just doesn't have the kind of front-end I'd like but does have a nicely-designed engine. At present, it's like driving a Volkswagon Beetle with a Formula 1 engine - the power is amazing, the capacity is staggering, the risk of ploughing off the road and over a cliff unrivalled. Everything else is like driving a Fornula 1 car with a Volkswagon Beetle engine - safe in the same way other statues are.
Ok, but first you have to show me a rail line in the US where trains routinely travel at 220mph. If you're ok with overseas, how long would you say it would take to drive from London to Paris, door-to-door, if the channel tunnel had been designed for cars and not trains? Now tell me how long it actually takes by driving onto a train. And that doesn't even do 220mph.
Both Britain and America are largely built on Irish "navvies" (barely-paid, untrained, under-educated borderline slave labor) and both ended up with infrastructure that has lasted a good hundred years under conditions far, far, far in excess of the original designs.
The worst of today's unemployed is certainly in no worse shape than the navvies ever were in terms of skills and experience. However, today it is certainly possible to give those people intensive training in large numbers. Bear in mind that doing the job serially won't work (the track initially replaced will be too badly damaged by inferior rolling stock by the time the job is done) and would take years if not decades to complete. If you're looking at a multi-year project done serially, then multi-year training en-masse and a single massive parallel upgrade won't take any longer but WILL ensure that all the track is in top condition for the high-speed trains and won't be damaged by old rolling stock.
Sure, it requires the roadbeds to be upgraded. And what of it? It can still be done in parallel and I see nothing in a Telford*-inspired rail bed that couldn't be done even if you were relying on unskilled labour. Further, a Telford-style design would likely be massive overkill. If "better than you need" can be done without PhDs in rail science, then I'm fairly sure the construction that would be sensible could be done just fine without experts.
*Thomas Telford and Isambard Kingdom Brunel were perhaps the two greatest engineer/architects of their time. Their designs had all the simplicity of the Great Pyramid, all the magnificence and all the capacity to be built with minimal individual skills provided the overseers were skilled. Absolutely anything they could design, we can design better (we can test before building, so can fix flaws in advance). Absolutely anything they required, we can get away with less (computers, mechanical excavators, laser range-finders, GPS, GPR, magnetic field sensors - not exactly in Brunel's storage locker, but quite capable of letting people of skill equal to any he had access to be able to measure, align and smooth off infinitely better than they could with a plumb line, spirit level and surveyors with ten meter rules).
What you can do with an incompetent person in charge isn't important. It's what you could do with a modern-day Telford or Brunel in charge that matters. Hell, like I said, you could probably just use their designs and use a computer to iron out any minor defects. Not bother with finding a modern engineer of that calibre.
You can replace the entire length of one set of tracks in one go, without any segment of track depending on any other segment of track being replaced first. Thus, the time it takes to replace the entire length is EXACTLY the same as the time it takes to replace one segment. That makes it "embarassingly parallel".
Why can't you run container trains on high-speed rail? The Europeans do. Hell, British Rail (which is one of the worst networks in Europe) runs goods trains FASTER than most passenger trains.
It hasn't "been tried", at least not in the US, because the US has never had anything that could be remotely worthy of being considered a real rail network. When it started, it was a bunch of isolated companies that had no real reach, and now it's one single network with no real reach AND an absurd speed limit AND 19th century infrastructure.
The Eurostar carries trucks and cars routinely between Britain and France and it is a highly successful project - far more so than I ever thought it would be, given that it was originally implemented by morons. THAT is what you should be looking at as an example. Amtrak isn't capable of that kind of operation. Amtrak is barely capable of operating. (Hell, Amtrak couldn't even get its next-gen trains to work.) Look at what has worked and why, look at what hasn't worked and why, but don't look at what hasn't worked and assume that this is a universal constant.
Yes they do. Specially-modified 747s can carry a single car in the storage section in the nose, and Hercules transport planes can carry a few jeeps or other small cars. That limits you to 1-8 passengers per aircraft, given normal car occupancy levels, which may reduce the effectiveness a bit.
Regularly employed, yes, but the Germans were very successful at getting past such obstacles during the first few years of the war. In part because they moved very very fast and resistance folk couldn't transport large bombs easily. Later, especially once the RAF had the Mosquito, it was a different story. Being able to do pinpoint bombing runs with 1000lb of ordinance tends to do a bit more damage to a bridge than a handful of torpex or more likely TNT could do.
Moving troops by truck is less safe - convoys can also be taken out by blowing up bridges or by using IEDs, and convoys are much, much slower (and therefore much more vulnerable) targets. Fixed-wing aircraft are no better, and arguably worse, since a train can release passengers anywhere along the track but an aircraft HAS to land at an airport. Of course, you could try using Ospreys or helicopters. Someone noted that you need the capacity to move 40,000 men. How many Ospreys would that take?
Yes, it's obvious that the primary benefit will be economic, but don't imagine for a moment that the Chinese - of all people - aren't viewing the tactical and strategic implications of high-speed rail on holding together and expanding their empire at a time when countries with inferior transport are incapable of staying intact.
Good point. And whereas a train can deliver maintenance crews and materials to the damaged area of track, an aircraft that cannot land cannot deliver either.
The Romans devastated their enemies more through superior mobility than superior tactics. Their enemies had dirt tracks, they had paved roads. Their enemies relied on fords, they could construct a bridge across vicious sections of river in a day and have multiple legions surrounding their foes by the next.
This is the difference between "good enough" and "the best". Those with the best are likely to win. 4x the speed means being able to move 4x the troops. Standard military wisdom is that when facing enemies of comparable technology, you need 3:1 in your favour to win. 4:1 gives you room to spare.
Different guagues is Bad Juju. Complexity is ALWAYS a weakness. If you want something reliable, you HAVE to have it simple. Trains that can do 65mph (which, incidentally, US trains can't - 55mph is too fast for quite a few regions, due to track damage) across multiple guagues have added complexity, particularly if they want to keep at the 65mph at all times. (Remember, uniform motion is cheap. Acceleration is expensive.)
220mph rail isn't significantly more expensive than 65mph rail in totality. Air resistance goes up with the square of the velocity, yes, but trains designed for 220mph speeds are built with air resistance in mind. 65mph rolling stock tends to be designed as cheaply as possible, which means you end up with drag far worse than the numbers alone would suggest.
Last, but not least, the rail in most nations is crap. The tracks are badly laid, poorly maintained and sub-optimal in location. In the same way that patching Windows will never produce a good OS, patching a crappy rail network will never produce a quality rail network. You HAVE to replace it wholesale. What's more, the cost of that replacement will actually be cheaper than continuing to repair the old crud in the long term. (The long term is something wannabe economists keep realizing they forget.)
Ok, not quite last. This point really is last. If you're competing against a rival system, you DON'T want to have said rival system dictate what you can and cannot do. Giving a competitor a say in how you compete is folly at best. Again, using software as an example, Linux does NOT use the bits and pieces of the Win32 API that Microsoft let others know about. It doesn't conform to POSIX where POSIX is broken. It doesn't limit itself to ANY competitor's ideas about what an OS should do and certainly does NOT limit itself to what ANY competitor thinks Linux should be limited to. Guess what? This approach has produced a viable solution. Approaches based on letting competitors dictate terms (eg: OS/2 needed Microsoft's cooperation, BeOS tried not to stir Microsoft's wrath) have invariably ended in disaster.
The cities around Charleston decided against building a light rail network between them because they all wanted total control and didn't want to pay anything. That attitude is common, I have found.
The US was great, some time in the 1950s, but frankly got eclipsed pretty quickly by other nations in just about every field. The US has remained a superpower on aggregate, because others specialized more, but this has been at the price of developing quickly at relatively little. Spread waaaay too thin.
Unemployment is high enough that you could replace the entire rail system of the US with the kind of tracks needed for high-speed rail within weeks, if not days, of the necessary track being produced because it's absurdly parallel. Replacing one piece of track has no dependencies on the state of any other piece of track, so there is no serialization and no blocking involved.
Rail too limited to get everywhere? Hmmm, seems to me there's plenty of trains that can carry cars. If you can travel between point A and point B faster than the cars could on their own, then drive the much shorter distances either end, everyone wins. You get total freedom AND get to sit back for most of the journey.
It won't happen because those antagonistic don't care about such stuff. If "freedom" was really a part of the equation, what could be freer than going anywhere you like in the country in a third the time, without the stress, at lower cost, with greatly reduced risk of accidents, far less wear-and-tear on your vehicle and no danger of a speeding ticket, all by having the middle bit of the journey done by someone else?
Some things aren't economic on a small scale but only become so on a large scale. Rail is something you have to roll out on a large scale, the larger the better. The countries they plan to move into don't have the greatest road systems in the world, giving the Chinese an advantage. Plus, rail is much less polluting and requires less fossil fuel, meeting international obligations (this matters to the Chinese government only because it's PR they can use against other nations) and freeing them from oil dependencies in nations potentially hostile to them.
In the event of conflict in the region, the Chinese will have greater mobility and reduced troop movement times, which basically means that they'll be able to dominate the region in a way America is no longer capable of within the Americas.
From the Chinese perspective, it's cheaper to build rail than to build a fleet of giant troop transport planes and it has none of the PR damage involved in the latter.
LISP perhaps should be there, as it runs damn fast on any stack machine. Tcl/Tk, Perl, Python, Ruby and PHP are not designed to run fast and, by being script languages, can't be fairly compared to compiled languages.
I still think we should be working harder on getting fusion working, as that solves a lot of the actual technical issues of fission (such as what to do with waste that will outlast humanity even if it stays contained).
As for the scuttling of ships carrying nuke waste, those pose all kinds of threats. Not just the immediate ones of pollution, etc, but they also constitute a source of extremely deadly material that will kill either through radiation or toxicity, parked in fairly accessible locations right off the coast of a nation with no meaningful government and a lot of warring factions all looking for an edge. Ohhhhhkay. Not good.
I'm far more concerned with the fact that war is becoming ever-more depersonalized, with every soldier essentially treating what they do as a video game. It's an inevitable trend now, since wars are about winning, but it's bound to alter the psychology for the worse (not that it was good to start with). Atrocities have occurred throughout not only recorded history but into archaeologically-recorded prehistory as well, but I stand by my belief that this isn't a record to be proud of and that we don't need to be encouraging it by making such stuff easier.
In this war, NATO does not appear to be targeting the weapons systems but Gadhaffi. Since his sons run the military, killing him wouldn't change anything for the better but might make the army more fanatical instead. Worse, it is upsetting the rebels on a major scale. If they feel they can't trust NATO to follow through, there is a major risk they'll try looking for someone who will. There's no evidence of terrorists on the side of the rebels, yet, but every time NATO works on meeting the political agenda of their leaders to kill meaningless figureheads, there's a serious risk the rebels will go elsewhere. That is something we ABSOLUTELY do not want.
NATO (and, since NATO is led by the US, by extension the US) is doing an excellent job of radicalizing both sides, extending the war and destabilizing the European/African border, apparently for the sole purpose of giving the hawks in Washington another kill for their collection. Never mind the consequences.
Google has released a research paper that suggests C++ is the best-performing programming language in the market.
Seems pretty obvious that there was indeed a claim that C++ is the best-performing language in the market. I tried drawing a different conclusion from this but the pencil broke.
No, because they tested a very narrow range of OO that was likely selected to make C++ the clear winner. Ok, go ahead and test 12 significantly different types of OO - they're not all the same - and see what happens. The nonsense is because they picked too narrow a grouping to draw any conclusions. Was it the language that was better? That specific compiler? The level of experience of the developers in each? Would other OO languages have done much better than C++?
If I'd assigned someone a project like that, I'd have mandated a minimum of 12 languages (4 popular, 4 traditional, 4 experimental) with a further breakdown mixing various methodologies (you want some parallel languages, some functional, some procedural, some stack, some OO, and maybe some with more exotic forms of abstraction).
My suspicion is that C++ will rank good against some, not so good against others, but where the balance shifts according to what you're trying to do.
Now, if you're insisting on pure OO vs OO, then the same 4:4:4 breakdown applies (where traditional might include a Smalltalk variant or spinoff). OO hasn't followed a linear path from then to now, it has branched in many directions and is still branching today. You've got to have a sensible analysis of then, now and future, to know how a language truly rates at any given task.
I agree. The article is nonsense. Whilst one of the comments suggested comparing it to assembly, that's perhaps a bit unfair. However, to be a test of "languages on the market" I would have expected the following to be there for certain:
C99
D (Digital Mars' language)
Fortran 2008
Erlang
Forth
Now, if you want to consider "the best", then you'd also want to include a few of the more experimental languages:
Occam-Pi
Unified Parallel C
AspeCt-oriented C
NESL
The problem with selecting benchmarks is that it's easy to pick languages your favourite language will do better at. The challange is to use a wide enough range of methodologies that you cannot predict ahead of time which one will do best at what.
Memories are non-locally stored across the brain (I've no idea what kind of RAID controller it uses, but it's damn good), so replacing a damaged portion shouldn't cause a problem provided the damage isn't too excessive. However, not all functions are replicated and no replication will be infinite, so after a certain point the damage becomes irreversible. It has to.
The critical issue is the section of the brain that transfers short-term memory to long-term memory. This was discovered by accident in the 60s. If that becomes damaged, new memories will either be corrupt or non-existent.
I'm guessing they used the same security guys that wrote a similar front-door for Hotmail. (One of their earliest security holes was where you could swap your user ID for anyone else's. Including the system admin's.)
Legally, you are correct. However, I happen to know the truth is a bit more complex. When it comes to potentially life-saving treatments, researchers and doctors routinely ignore the approvals process. Provided the patient gives informed consent, real hospitals really do offer experimental, untested, unapproved therapies, in direct violation of the law. Again, I refer to my father's work on Alzheimer's which did indeed include the use of such treatments (with the full knowledge of staff and patients).
There's no way to repair dead brain cells and even juvenile brains can't repair that degree of damage even though their neurogenesis rates are the maximum that can be achieved by the body. That limits you to hot-swapping the dead bits with living bits.
Further, since the tau protein is encapsulating neurotoxins, any alternative will allow those neurotoxins to be reintroduced to living parts of the brain. That places very significant limits on your activity.
Slashdot Mirror
SVN has all kinds of issues. It really needs a therapist at this point. Git is the best of the open-source systems. Of the closed systems, Perforce and Plastic are the only serious contenders, but I've had a hell of a time with Plastic due to the way it identifies individuals, problems with unmerging and database organization that's kludgy at best. Perforce is ancient, has some amazingly bad quirks, and is more expensive than hell above a couple of users.
I've burned many brain cycles trying to decide what to do, since Git just doesn't have the kind of front-end I'd like but does have a nicely-designed engine. At present, it's like driving a Volkswagon Beetle with a Formula 1 engine - the power is amazing, the capacity is staggering, the risk of ploughing off the road and over a cliff unrivalled. Everything else is like driving a Fornula 1 car with a Volkswagon Beetle engine - safe in the same way other statues are.
Ok, but first you have to show me a rail line in the US where trains routinely travel at 220mph. If you're ok with overseas, how long would you say it would take to drive from London to Paris, door-to-door, if the channel tunnel had been designed for cars and not trains? Now tell me how long it actually takes by driving onto a train. And that doesn't even do 220mph.
Both Britain and America are largely built on Irish "navvies" (barely-paid, untrained, under-educated borderline slave labor) and both ended up with infrastructure that has lasted a good hundred years under conditions far, far, far in excess of the original designs.
The worst of today's unemployed is certainly in no worse shape than the navvies ever were in terms of skills and experience. However, today it is certainly possible to give those people intensive training in large numbers. Bear in mind that doing the job serially won't work (the track initially replaced will be too badly damaged by inferior rolling stock by the time the job is done) and would take years if not decades to complete. If you're looking at a multi-year project done serially, then multi-year training en-masse and a single massive parallel upgrade won't take any longer but WILL ensure that all the track is in top condition for the high-speed trains and won't be damaged by old rolling stock.
Sure, it requires the roadbeds to be upgraded. And what of it? It can still be done in parallel and I see nothing in a Telford*-inspired rail bed that couldn't be done even if you were relying on unskilled labour. Further, a Telford-style design would likely be massive overkill. If "better than you need" can be done without PhDs in rail science, then I'm fairly sure the construction that would be sensible could be done just fine without experts.
*Thomas Telford and Isambard Kingdom Brunel were perhaps the two greatest engineer/architects of their time. Their designs had all the simplicity of the Great Pyramid, all the magnificence and all the capacity to be built with minimal individual skills provided the overseers were skilled. Absolutely anything they could design, we can design better (we can test before building, so can fix flaws in advance). Absolutely anything they required, we can get away with less (computers, mechanical excavators, laser range-finders, GPS, GPR, magnetic field sensors - not exactly in Brunel's storage locker, but quite capable of letting people of skill equal to any he had access to be able to measure, align and smooth off infinitely better than they could with a plumb line, spirit level and surveyors with ten meter rules).
What you can do with an incompetent person in charge isn't important. It's what you could do with a modern-day Telford or Brunel in charge that matters. Hell, like I said, you could probably just use their designs and use a computer to iron out any minor defects. Not bother with finding a modern engineer of that calibre.
You can replace the entire length of one set of tracks in one go, without any segment of track depending on any other segment of track being replaced first. Thus, the time it takes to replace the entire length is EXACTLY the same as the time it takes to replace one segment. That makes it "embarassingly parallel".
Why can't you run container trains on high-speed rail? The Europeans do. Hell, British Rail (which is one of the worst networks in Europe) runs goods trains FASTER than most passenger trains.
It hasn't "been tried", at least not in the US, because the US has never had anything that could be remotely worthy of being considered a real rail network. When it started, it was a bunch of isolated companies that had no real reach, and now it's one single network with no real reach AND an absurd speed limit AND 19th century infrastructure.
The Eurostar carries trucks and cars routinely between Britain and France and it is a highly successful project - far more so than I ever thought it would be, given that it was originally implemented by morons. THAT is what you should be looking at as an example. Amtrak isn't capable of that kind of operation. Amtrak is barely capable of operating. (Hell, Amtrak couldn't even get its next-gen trains to work.) Look at what has worked and why, look at what hasn't worked and why, but don't look at what hasn't worked and assume that this is a universal constant.
Yes, and "more than the value of the car and everything in it".
Yes they do. Specially-modified 747s can carry a single car in the storage section in the nose, and Hercules transport planes can carry a few jeeps or other small cars. That limits you to 1-8 passengers per aircraft, given normal car occupancy levels, which may reduce the effectiveness a bit.
Regularly employed, yes, but the Germans were very successful at getting past such obstacles during the first few years of the war. In part because they moved very very fast and resistance folk couldn't transport large bombs easily. Later, especially once the RAF had the Mosquito, it was a different story. Being able to do pinpoint bombing runs with 1000lb of ordinance tends to do a bit more damage to a bridge than a handful of torpex or more likely TNT could do.
Moving troops by truck is less safe - convoys can also be taken out by blowing up bridges or by using IEDs, and convoys are much, much slower (and therefore much more vulnerable) targets. Fixed-wing aircraft are no better, and arguably worse, since a train can release passengers anywhere along the track but an aircraft HAS to land at an airport. Of course, you could try using Ospreys or helicopters. Someone noted that you need the capacity to move 40,000 men. How many Ospreys would that take?
Yes, it's obvious that the primary benefit will be economic, but don't imagine for a moment that the Chinese - of all people - aren't viewing the tactical and strategic implications of high-speed rail on holding together and expanding their empire at a time when countries with inferior transport are incapable of staying intact.
Good point. And whereas a train can deliver maintenance crews and materials to the damaged area of track, an aircraft that cannot land cannot deliver either.
The Romans devastated their enemies more through superior mobility than superior tactics. Their enemies had dirt tracks, they had paved roads. Their enemies relied on fords, they could construct a bridge across vicious sections of river in a day and have multiple legions surrounding their foes by the next.
This is the difference between "good enough" and "the best". Those with the best are likely to win. 4x the speed means being able to move 4x the troops. Standard military wisdom is that when facing enemies of comparable technology, you need 3:1 in your favour to win. 4:1 gives you room to spare.
Different guagues is Bad Juju. Complexity is ALWAYS a weakness. If you want something reliable, you HAVE to have it simple. Trains that can do 65mph (which, incidentally, US trains can't - 55mph is too fast for quite a few regions, due to track damage) across multiple guagues have added complexity, particularly if they want to keep at the 65mph at all times. (Remember, uniform motion is cheap. Acceleration is expensive.)
220mph rail isn't significantly more expensive than 65mph rail in totality. Air resistance goes up with the square of the velocity, yes, but trains designed for 220mph speeds are built with air resistance in mind. 65mph rolling stock tends to be designed as cheaply as possible, which means you end up with drag far worse than the numbers alone would suggest.
Last, but not least, the rail in most nations is crap. The tracks are badly laid, poorly maintained and sub-optimal in location. In the same way that patching Windows will never produce a good OS, patching a crappy rail network will never produce a quality rail network. You HAVE to replace it wholesale. What's more, the cost of that replacement will actually be cheaper than continuing to repair the old crud in the long term. (The long term is something wannabe economists keep realizing they forget.)
Ok, not quite last. This point really is last. If you're competing against a rival system, you DON'T want to have said rival system dictate what you can and cannot do. Giving a competitor a say in how you compete is folly at best. Again, using software as an example, Linux does NOT use the bits and pieces of the Win32 API that Microsoft let others know about. It doesn't conform to POSIX where POSIX is broken. It doesn't limit itself to ANY competitor's ideas about what an OS should do and certainly does NOT limit itself to what ANY competitor thinks Linux should be limited to. Guess what? This approach has produced a viable solution. Approaches based on letting competitors dictate terms (eg: OS/2 needed Microsoft's cooperation, BeOS tried not to stir Microsoft's wrath) have invariably ended in disaster.
The cities around Charleston decided against building a light rail network between them because they all wanted total control and didn't want to pay anything. That attitude is common, I have found.
The US was great, some time in the 1950s, but frankly got eclipsed pretty quickly by other nations in just about every field. The US has remained a superpower on aggregate, because others specialized more, but this has been at the price of developing quickly at relatively little. Spread waaaay too thin.
Unemployment is high enough that you could replace the entire rail system of the US with the kind of tracks needed for high-speed rail within weeks, if not days, of the necessary track being produced because it's absurdly parallel. Replacing one piece of track has no dependencies on the state of any other piece of track, so there is no serialization and no blocking involved.
Rail too limited to get everywhere? Hmmm, seems to me there's plenty of trains that can carry cars. If you can travel between point A and point B faster than the cars could on their own, then drive the much shorter distances either end, everyone wins. You get total freedom AND get to sit back for most of the journey.
It won't happen because those antagonistic don't care about such stuff. If "freedom" was really a part of the equation, what could be freer than going anywhere you like in the country in a third the time, without the stress, at lower cost, with greatly reduced risk of accidents, far less wear-and-tear on your vehicle and no danger of a speeding ticket, all by having the middle bit of the journey done by someone else?
Some things aren't economic on a small scale but only become so on a large scale. Rail is something you have to roll out on a large scale, the larger the better. The countries they plan to move into don't have the greatest road systems in the world, giving the Chinese an advantage. Plus, rail is much less polluting and requires less fossil fuel, meeting international obligations (this matters to the Chinese government only because it's PR they can use against other nations) and freeing them from oil dependencies in nations potentially hostile to them.
In the event of conflict in the region, the Chinese will have greater mobility and reduced troop movement times, which basically means that they'll be able to dominate the region in a way America is no longer capable of within the Americas.
From the Chinese perspective, it's cheaper to build rail than to build a fleet of giant troop transport planes and it has none of the PR damage involved in the latter.
LISP perhaps should be there, as it runs damn fast on any stack machine. Tcl/Tk, Perl, Python, Ruby and PHP are not designed to run fast and, by being script languages, can't be fairly compared to compiled languages.
I still think we should be working harder on getting fusion working, as that solves a lot of the actual technical issues of fission (such as what to do with waste that will outlast humanity even if it stays contained).
As for the scuttling of ships carrying nuke waste, those pose all kinds of threats. Not just the immediate ones of pollution, etc, but they also constitute a source of extremely deadly material that will kill either through radiation or toxicity, parked in fairly accessible locations right off the coast of a nation with no meaningful government and a lot of warring factions all looking for an edge. Ohhhhhkay. Not good.
Bribable politicians.... priceless.
I'm far more concerned with the fact that war is becoming ever-more depersonalized, with every soldier essentially treating what they do as a video game. It's an inevitable trend now, since wars are about winning, but it's bound to alter the psychology for the worse (not that it was good to start with). Atrocities have occurred throughout not only recorded history but into archaeologically-recorded prehistory as well, but I stand by my belief that this isn't a record to be proud of and that we don't need to be encouraging it by making such stuff easier.
In this war, NATO does not appear to be targeting the weapons systems but Gadhaffi. Since his sons run the military, killing him wouldn't change anything for the better but might make the army more fanatical instead. Worse, it is upsetting the rebels on a major scale. If they feel they can't trust NATO to follow through, there is a major risk they'll try looking for someone who will. There's no evidence of terrorists on the side of the rebels, yet, but every time NATO works on meeting the political agenda of their leaders to kill meaningless figureheads, there's a serious risk the rebels will go elsewhere. That is something we ABSOLUTELY do not want.
NATO (and, since NATO is led by the US, by extension the US) is doing an excellent job of radicalizing both sides, extending the war and destabilizing the European/African border, apparently for the sole purpose of giving the hawks in Washington another kill for their collection. Never mind the consequences.
Looks like those two are very good starting points, though, unless you've a Cray handy.
From TFA:
Seems pretty obvious that there was indeed a claim that C++ is the best-performing language in the market. I tried drawing a different conclusion from this but the pencil broke.
No, because they tested a very narrow range of OO that was likely selected to make C++ the clear winner. Ok, go ahead and test 12 significantly different types of OO - they're not all the same - and see what happens. The nonsense is because they picked too narrow a grouping to draw any conclusions. Was it the language that was better? That specific compiler? The level of experience of the developers in each? Would other OO languages have done much better than C++?
If I'd assigned someone a project like that, I'd have mandated a minimum of 12 languages (4 popular, 4 traditional, 4 experimental) with a further breakdown mixing various methodologies (you want some parallel languages, some functional, some procedural, some stack, some OO, and maybe some with more exotic forms of abstraction).
My suspicion is that C++ will rank good against some, not so good against others, but where the balance shifts according to what you're trying to do.
Now, if you're insisting on pure OO vs OO, then the same 4:4:4 breakdown applies (where traditional might include a Smalltalk variant or spinoff). OO hasn't followed a linear path from then to now, it has branched in many directions and is still branching today. You've got to have a sensible analysis of then, now and future, to know how a language truly rates at any given task.
I'm sure there's a malloc replacement library out there that does GC. :)
I agree. The article is nonsense. Whilst one of the comments suggested comparing it to assembly, that's perhaps a bit unfair. However, to be a test of "languages on the market" I would have expected the following to be there for certain:
Now, if you want to consider "the best", then you'd also want to include a few of the more experimental languages:
The problem with selecting benchmarks is that it's easy to pick languages your favourite language will do better at. The challange is to use a wide enough range of methodologies that you cannot predict ahead of time which one will do best at what.
Memories are non-locally stored across the brain (I've no idea what kind of RAID controller it uses, but it's damn good), so replacing a damaged portion shouldn't cause a problem provided the damage isn't too excessive. However, not all functions are replicated and no replication will be infinite, so after a certain point the damage becomes irreversible. It has to.
The critical issue is the section of the brain that transfers short-term memory to long-term memory. This was discovered by accident in the 60s. If that becomes damaged, new memories will either be corrupt or non-existent.
I disagree. There's got to be a cutoff point below which it ceases to be fail and emerges into some sort of parallel universe.
I'm guessing they used the same security guys that wrote a similar front-door for Hotmail. (One of their earliest security holes was where you could swap your user ID for anyone else's. Including the system admin's.)
Legally, you are correct. However, I happen to know the truth is a bit more complex. When it comes to potentially life-saving treatments, researchers and doctors routinely ignore the approvals process. Provided the patient gives informed consent, real hospitals really do offer experimental, untested, unapproved therapies, in direct violation of the law. Again, I refer to my father's work on Alzheimer's which did indeed include the use of such treatments (with the full knowledge of staff and patients).
There's no way to repair dead brain cells and even juvenile brains can't repair that degree of damage even though their neurogenesis rates are the maximum that can be achieved by the body. That limits you to hot-swapping the dead bits with living bits.
Further, since the tau protein is encapsulating neurotoxins, any alternative will allow those neurotoxins to be reintroduced to living parts of the brain. That places very significant limits on your activity.