Exactly. Yes it is nice to dream of a perfect world (especially if one is young),
Actually, young folk do tend to see hacking as a perfect good coding style. It's the grey heads in the universities that keep beating the drum for better practices, and they're occasionally joined by seasoned devs who just get sick of the utter slackness of current coding practice.
It's easy for a programmer to say "We should stop worrying so much about compatibility and interoperability" when they don't have to deal with customers, support, or actually selling the end product. When a customer calls up and says, "Hey, how come this new version of Windows doesn't work with any of my old Windows software?" you can't just tell them "Because our programmers thought it was better to get a fresh start."
But he isn't talking about user software -- he's talking about programming languages. He's pointing out what every university computer science department has been saying for decades: there are vastly better ways of programming that have been researched and developed, and no-one's using them because they're unwilling to leave decades-old programming design behind. Design decisions that were a practical compromise made when memory was measured in kilobytes and compilers didn't have the grunt to optimise. Right now, programmers are going through a painstaking process of telling the computer each and every step to take and in what order, and the compiler is increasingly ignoring them, because it can easily refactor the code to be more efficient. We spend half our lives working out how to code up trivial little bits of code that are required for the "big idea" to work.
Now while this is not about incompatibility in the user space, in the end it does indeed have a knock-on effect. Userspace incompatibility arises when the source of the previous version is so hacked-up, patched and kludged that the coder of the new version can't see how it works. Not understanding the source code means he can't replicate the behaviour. The sort of good practice my uni lecturers always went on about would eliminate the problem. In current architectures, though, it would take too long and be too expensive... which is why we need architectures based around those good practices, actively promoting them.
Backward compatibility isn't just important, it's paramount. It's not 1957.
Nobody wants to upgrade their build system to a newer version of the language and find out it breaks the code all over the place. Nobody has time for that.
This premise is correct.
But...
New versions of the same language need to ONLY
(1) fix errors
(2) add new features that you invoke with new code that would be rejected by the old version's parser.
If you change how old code will behave, that's not a new version. It's a new language.
Likewise other systems, such as operating systems and even user-exposed interfaces, because ultimately programs depend on them working a certain way.
...your conclusion is wrong. With massive hard drives, we can in fact have our cake and eat it. Any modern compiler is a tiny piece of code compared to the average project built with the same compiler, so there is no reason we can't have a compatibility mode. Have a look at the first line of any shell script -- it tells you what shell it needs. A Bash script can call a Korn shell script, which can call a C shell script, which can in turn call a Bash shell script, and all without any knowing what goes on inside the others. They can do this because they are all built on the same typing system and function call system.
We could apply this principle to programming languages: when a new version will not compile the previous version's code, you don't want a whole new compiler -- instead you keep the old one alongside a modified version of it. If a file header identifies it as v 1.53, compile it with the latest compiler for version 1. If another file in the same project is v 2.04, compile it with the latest compiler for version 2. All you need to do is keep the type system and function calling backwards compatible, and the two will happily communicate. No code is broken. Old code stays as old code until and unless the update is needed, and new code can be written in the new way.
Of course, the change to the object model between Python 2.x and 3.x means that this wouldn't work with Python, but that's only because Guido chose not to develop it that way.
True, but the AC was conflating "C++isms" with "OOP". That's like looking at one country with a malfunctioning parliament and declaring democracy a bad idea.
There is a huge difference between "crash landing" and "being hit by an anti-aircraft missile". You might as well complain that being forced to wear a seatbelt is a waste of time because it doesn't protect against IEDs in Fallujah.
Generally speaking, being relaxed greatly reduces your chance and severity of injury. If you can, let your body go rag-doll if you know you're going to crash (easier said than done of course...).
"Bracing for impact" is the exact opposite of being relaxed.
There are more factors to it than that. If going rag-doll means having your head battered off two seats, that's a problem. Going limp presumably only reduces damage to muscles and tendons.....
Most crashes occur during landing and takeoff, and there are good odds of at least some survivors. Crashes that occur mid-flight are far less likely to have survivors, but that's not the type of crash this article is interested in.
However, your book does not have a sheet of glass on it. In the event of a crash, it isn't likely to pose a great threat. The bulk of the book isn't much of a problem either, in that it will probably fly around with the pages spread open as it is launched across the cabin (well, you were reading it, weren't you?) An iPhone, on the other hand, is a very dense piece of kit, and even if the glass doesn't break in such a way as to pose a threat, it will be like being hit by a rock.
If they want to talk about this as an exoskeleton, they need to show someone walking with a load. Otherwise, this is just a mobile platform for the Equipois ZeroG arm which is basically a steadycam mount for industrial equipment.
Well... yes, that's basically what it is. But it is still an exoskeleton, as it has solid load-bearing elements outside of the body. I'd love to see a video myself, but I also trust a company like Lockheed Martin when they say it is designed for mobility. The tech has existed to create semi-mobile ones for a looong time now, but it's never been an attractive proposition. People have been working on this stuff for decades, so I'd say that they've probably done most of what they claim.
A spring loaded linkage connects the load to a body harness, but with added linkages that can transfer the weight of the harness to the ground.
Nothing in the article says that the arm is innovative. The arm is a product that has been available for some time. The "added linkages that can transfer the weight of the harness to the ground" is the product. It's an idea that people have been trying for for decades, and now finally they can make the structure stable and usable. That's the news. Saying this is nothing new is like saying the moon landings were nothing new because people had already been up in space, and landing on the moon was just "adding a few maneouvers" to a normal spaceflight.
The arm you see is already in use, and yes, it operates on the same principle as the steady-cam rig. Steadicam transfers all the weight to the hips which protects the operator's spine and to aid dexterity by reducing the load on the arm muscles, but the legs still have to carry the weight (most steadicam operators are shadowed by a colleague and as soon as the director shouts "cut", the colleague takes the camera off them and puts it down for them). The logical next step was to built a structure that transfers the weight to the ground without using the operators' legs. This has been an active field of research for as long as exoskeletons have been under research. The problem used to be resistance in the joints being too high (unless the joint was too weak to take the load), so they tried looking at low-power models rather than zero power, but they weren't happy with the results. Essentially, the idea was just waiting for manufacturing technology to reach the point where the required joints and bearings could be produced.
I'm curious as to whether this is a noisy or silent solution -- if it's quiet enough, expect to hear of Hollywood picking them up to keep their steadicam operators running longer between breaks....
And here I bring up this point again... Please quit turning "easy to learn" languages into clusterf**k's by introducing C++'isms
I can not even think of a single person who actually likes C++ or Java, let alone any Object programming that was bolted onto Perl, PHP, or other scripting languages.
OOP programming is the death kick-in-the-nuts to projects that switch. Fullstop.
...
My one wish for developers, programmers and would-be game designers would be to take a step back and design your game engines completely black-boxed from the server environment. The game engine should only receive data, and only transmit commands, it should not transmit commands that it shouldn't know about, and the server should not send data the game client shouldn't know about.
So many games OOP development rely on interfacing with objects the server is keeping track of, but letting the game client keep track of too many things in parallel, resulting in hacking, cheating and rampant botting (primarily to destroy the game or the game's economy.)
It sounds like what you're looking for is... object oriented programming!
Seriously, the problem with OOP is bad teaching, which leads to bad implementation. I never understood OOP until I found a task that was best modelled in it (and none of the tasks I was presented at uni were). But more to the point, everyone forgets the principle of Smalltalk -- OOP as "message passing". You weren't supposed to be thinking of calling code (which can arbitrary) but of sending messages to other "agents". Does it make sense for me to change someone's clothes? Not really -- I should be asking them to do it. When you're thinking in terms of what is a reasonable message to send, you naturally restrict the interface. When you think in terms of "calling code", you tend to favour flexibility without considering what purpose it serves.
But what about having compatible sub-systems? Why can't I write a new piece of software in Foo#++ v2.0 and have it call code written in Foo#++ v1.53? Why can't the compiler or interpreter be left to deal with calling the correct language subsystem? In that case, the only part of the code that needs to be backwards compatible is the semantics of function calls.
So I have a few dozen Access apps when they "upgraded" to Office '03, and not a single one would run. Access had become a completely different program
[my emphasis: program]
We have the dichotomy here of user-space vs dev-space. But unfortunately a lot of things aren't one or the other. Access is a development tool, but it still qualifies as an office application. Certainly, maintaining backwards compatibility for users is great, but maintaining backwards compatibility indefinitely for devs is questionable.
Unfortunately, the problem in languages clearly isn't backwards compatibility per se, as the proliferation of new languages recently has given plenty of opportunities to start over without expecting codebase compatibility, but the new languages always seem to inherit far too much of the features in existing languages that hold them back.
How many languages have "functional programming features" without including the most important feature of functional programming: true determinism with immutable variables, hence easier testing and less debugging?
There is the issue of "learner mind": it's easier to imagine unorthodox situations and strategies before you're accustomed to the orthodoxy. Sadly, he seems a little over-coached, so seems to be trained in the orthodoxy.
By "residential routers", what they mean is that the coffee shops are skimping and using hardware aimed at the home user rather than designed specifically as a public access point.
A better tool would be a properly configured router. This software is a hack for misconfigured networks that treats a symptom (badly) rather than killing the disease.
Trolls love to bully anyone who isn't them. If there's an easy target then it doesn't matter if it's a woman, a homosexual, a jew, etc.
OK, so internet bullies make up stories based on a fictitious sexual history of their female targets. What common analogue is there for Jews targeted by trolls due to their race/religion?
Slashdot Mirror
Exactly. Yes it is nice to dream of a perfect world (especially if one is young),
Actually, young folk do tend to see hacking as a perfect good coding style. It's the grey heads in the universities that keep beating the drum for better practices, and they're occasionally joined by seasoned devs who just get sick of the utter slackness of current coding practice.
It's easy for a programmer to say "We should stop worrying so much about compatibility and interoperability" when they don't have to deal with customers, support, or actually selling the end product. When a customer calls up and says, "Hey, how come this new version of Windows doesn't work with any of my old Windows software?" you can't just tell them "Because our programmers thought it was better to get a fresh start."
But he isn't talking about user software -- he's talking about programming languages. He's pointing out what every university computer science department has been saying for decades: there are vastly better ways of programming that have been researched and developed, and no-one's using them because they're unwilling to leave decades-old programming design behind. Design decisions that were a practical compromise made when memory was measured in kilobytes and compilers didn't have the grunt to optimise. Right now, programmers are going through a painstaking process of telling the computer each and every step to take and in what order, and the compiler is increasingly ignoring them, because it can easily refactor the code to be more efficient. We spend half our lives working out how to code up trivial little bits of code that are required for the "big idea" to work.
Now while this is not about incompatibility in the user space, in the end it does indeed have a knock-on effect. Userspace incompatibility arises when the source of the previous version is so hacked-up, patched and kludged that the coder of the new version can't see how it works. Not understanding the source code means he can't replicate the behaviour. The sort of good practice my uni lecturers always went on about would eliminate the problem. In current architectures, though, it would take too long and be too expensive... which is why we need architectures based around those good practices, actively promoting them.
Backward compatibility isn't just important, it's paramount. It's not 1957.
Nobody wants to upgrade their build system to a newer version of the language and find out it breaks the code all over the place. Nobody has time for that.
This premise is correct.
But...
New versions of the same language need to ONLY
(1) fix errors
(2) add new features that you invoke with new code that would be rejected by the old version's parser. If you change how old code will behave, that's not a new version. It's a new language.
Likewise other systems, such as operating systems and even user-exposed interfaces, because ultimately programs depend on them working a certain way.
...your conclusion is wrong. With massive hard drives, we can in fact have our cake and eat it. Any modern compiler is a tiny piece of code compared to the average project built with the same compiler, so there is no reason we can't have a compatibility mode. Have a look at the first line of any shell script -- it tells you what shell it needs. A Bash script can call a Korn shell script, which can call a C shell script, which can in turn call a Bash shell script, and all without any knowing what goes on inside the others. They can do this because they are all built on the same typing system and function call system.
We could apply this principle to programming languages: when a new version will not compile the previous version's code, you don't want a whole new compiler -- instead you keep the old one alongside a modified version of it. If a file header identifies it as v 1.53, compile it with the latest compiler for version 1. If another file in the same project is v 2.04, compile it with the latest compiler for version 2. All you need to do is keep the type system and function calling backwards compatible, and the two will happily communicate. No code is broken. Old code stays as old code until and unless the update is needed, and new code can be written in the new way.
Of course, the change to the object model between Python 2.x and 3.x means that this wouldn't work with Python, but that's only because Guido chose not to develop it that way.
True, but the AC was conflating "C++isms" with "OOP". That's like looking at one country with a malfunctioning parliament and declaring democracy a bad idea.
I remember in 2012 when there was a Congressional hearing to decide if Muslims should be illegal.
Citation please.
It's in the deleted scenes on the special edition Bluray.
There is a huge difference between "crash landing" and "being hit by an anti-aircraft missile". You might as well complain that being forced to wear a seatbelt is a waste of time because it doesn't protect against IEDs in Fallujah.
Got a link?
Generally speaking, being relaxed greatly reduces your chance and severity of injury. If you can, let your body go rag-doll if you know you're going to crash (easier said than done of course...).
"Bracing for impact" is the exact opposite of being relaxed.
There are more factors to it than that. If going rag-doll means having your head battered off two seats, that's a problem. Going limp presumably only reduces damage to muscles and tendons.....
Most crashes occur during landing and takeoff, and there are good odds of at least some survivors. Crashes that occur mid-flight are far less likely to have survivors, but that's not the type of crash this article is interested in.
Landing and takeoff are the most dangerous times of the flight.
If there is a problem, they want you to hear. If you don't know you're about to crash, you might not brace. Ouch.
However, your book does not have a sheet of glass on it. In the event of a crash, it isn't likely to pose a great threat. The bulk of the book isn't much of a problem either, in that it will probably fly around with the pages spread open as it is launched across the cabin (well, you were reading it, weren't you?) An iPhone, on the other hand, is a very dense piece of kit, and even if the glass doesn't break in such a way as to pose a threat, it will be like being hit by a rock.
But can they hold it above their heads for a while, making relatively finely controlled movements?
If they want to talk about this as an exoskeleton, they need to show someone walking with a load. Otherwise, this is just a mobile platform for the Equipois ZeroG arm which is basically a steadycam mount for industrial equipment.
Well... yes, that's basically what it is. But it is still an exoskeleton, as it has solid load-bearing elements outside of the body. I'd love to see a video myself, but I also trust a company like Lockheed Martin when they say it is designed for mobility. The tech has existed to create semi-mobile ones for a looong time now, but it's never been an attractive proposition. People have been working on this stuff for decades, so I'd say that they've probably done most of what they claim.
A spring loaded linkage connects the load to a body harness, but with added linkages that can transfer the weight of the harness to the ground.
Nothing in the article says that the arm is innovative. The arm is a product that has been available for some time. The "added linkages that can transfer the weight of the harness to the ground" is the product. It's an idea that people have been trying for for decades, and now finally they can make the structure stable and usable. That's the news. Saying this is nothing new is like saying the moon landings were nothing new because people had already been up in space, and landing on the moon was just "adding a few maneouvers" to a normal spaceflight.
The arm you see is already in use, and yes, it operates on the same principle as the steady-cam rig. Steadicam transfers all the weight to the hips which protects the operator's spine and to aid dexterity by reducing the load on the arm muscles, but the legs still have to carry the weight (most steadicam operators are shadowed by a colleague and as soon as the director shouts "cut", the colleague takes the camera off them and puts it down for them). The logical next step was to built a structure that transfers the weight to the ground without using the operators' legs. This has been an active field of research for as long as exoskeletons have been under research. The problem used to be resistance in the joints being too high (unless the joint was too weak to take the load), so they tried looking at low-power models rather than zero power, but they weren't happy with the results. Essentially, the idea was just waiting for manufacturing technology to reach the point where the required joints and bearings could be produced.
I'm curious as to whether this is a noisy or silent solution -- if it's quiet enough, expect to hear of Hollywood picking them up to keep their steadicam operators running longer between breaks....
And here I bring up this point again... Please quit turning "easy to learn" languages into clusterf**k's by introducing C++'isms
I can not even think of a single person who actually likes C++ or Java, let alone any Object programming that was bolted onto Perl, PHP, or other scripting languages.
OOP programming is the death kick-in-the-nuts to projects that switch. Fullstop.
My one wish for developers, programmers and would-be game designers would be to take a step back and design your game engines completely black-boxed from the server environment. The game engine should only receive data, and only transmit commands, it should not transmit commands that it shouldn't know about, and the server should not send data the game client shouldn't know about.
So many games OOP development rely on interfacing with objects the server is keeping track of, but letting the game client keep track of too many things in parallel, resulting in hacking, cheating and rampant botting (primarily to destroy the game or the game's economy.)
It sounds like what you're looking for is... object oriented programming!
Seriously, the problem with OOP is bad teaching, which leads to bad implementation. I never understood OOP until I found a task that was best modelled in it (and none of the tasks I was presented at uni were). But more to the point, everyone forgets the principle of Smalltalk -- OOP as "message passing". You weren't supposed to be thinking of calling code (which can arbitrary) but of sending messages to other "agents". Does it make sense for me to change someone's clothes? Not really -- I should be asking them to do it. When you're thinking in terms of what is a reasonable message to send, you naturally restrict the interface. When you think in terms of "calling code", you tend to favour flexibility without considering what purpose it serves.
But what about having compatible sub-systems? Why can't I write a new piece of software in Foo#++ v2.0 and have it call code written in Foo#++ v1.53? Why can't the compiler or interpreter be left to deal with calling the correct language subsystem? In that case, the only part of the code that needs to be backwards compatible is the semantics of function calls.
So I have a few dozen Access apps when they "upgraded" to Office '03, and not a single one would run. Access had become a completely different program
[my emphasis: program]
We have the dichotomy here of user-space vs dev-space. But unfortunately a lot of things aren't one or the other. Access is a development tool, but it still qualifies as an office application. Certainly, maintaining backwards compatibility for users is great, but maintaining backwards compatibility indefinitely for devs is questionable.
Unfortunately, the problem in languages clearly isn't backwards compatibility per se, as the proliferation of new languages recently has given plenty of opportunities to start over without expecting codebase compatibility, but the new languages always seem to inherit far too much of the features in existing languages that hold them back.
How many languages have "functional programming features" without including the most important feature of functional programming: true determinism with immutable variables, hence easier testing and less debugging?
There is the issue of "learner mind": it's easier to imagine unorthodox situations and strategies before you're accustomed to the orthodoxy. Sadly, he seems a little over-coached, so seems to be trained in the orthodoxy.
Probably true. Weaker sex[*], easier to scare.
[* If women weren't weaker than men, there would be no "women's" category in sports.]
By "residential routers", what they mean is that the coffee shops are skimping and using hardware aimed at the home user rather than designed specifically as a public access point.
It is the equivalent of using duct tape and plastic wrap to replace a broken car window.
Or the equivalent of using duct tape and plastic wrap to shut up the guy next to you talking too loudly on his phone.
A better tool would be a properly configured router. This software is a hack for misconfigured networks that treats a symptom (badly) rather than killing the disease.
Trolls love to bully anyone who isn't them. If there's an easy target then it doesn't matter if it's a woman, a homosexual, a jew, etc.
OK, so internet bullies make up stories based on a fictitious sexual history of their female targets. What common analogue is there for Jews targeted by trolls due to their race/religion?
That should have been "Self proclaimed vigilante"
Erm... vigilantes are kind of self-proclaimed by definition, aren't they...?
Note that I'm NOT talking about using public wi-fi here, just the idea that bittorrent has no place.
Then you are discussing on the wrong article.