Why was this labeled flamebait? It's exactly what happened.
It is not what happened. What actually happened is a sequence of events that could have happened to any of us when we were kids.
A 14 year old kid took a clock apart and put it back together. The word "invention" was thrown around (he may or may not have used the word himself; this is unclear), but the kid was absolutely clear about his motives: he wanted to understand how it worked. Many, many Slashdotters can relate to this. This happened to me when I was a kid.
He was proud of himself and took it to school to show it off to a world which isn't very impressed by such things. He was told to put it away but couldn't help himself. Many, many Slashdotters can relate to this. This happened to me when I was a kid.
What most Slashdotters can't relate to is having the cops called on you and being the subject of a viral shitstorm for doing this. This did not happen to me when I was a kid. The kid is not an inventor. He might be a genius (his measured IQ may well be in the top 2%), or he might not be. The central point is that he is one of us, and we take care of our own. When normal geek childhood is criminalised, that's news for nerds and stuff that matters.
There has been a lot of talk (with no actual evidence, I might add) that the kid's father somehow engineered this, or wanted an incident, or to make a point. Even if that were true, the point was indeed made. So many social media commenters (and sadly Slashdot comments have devolved to the level of social media commenters) concentrate on what the kid did wrong, and don't stop to ponder just why it's so easy for incidents like this to happen if your skin has a bit of melanin in it.
The term troll is actually derived from a fishing troll, because it lures people in. It has nothing to do with the actual fictional monster that is a troll.
That's technically true, but the term also comes from the day when trolling was considered an artform. Your modern troll has more in common with the fictional monster than anything you used to see on alt.syntax.tactical.
I know you think you're being clever, but that's often the case.
My point (which I suspect that you agree with) is that a corporation who thinks they can get away with influencing the government will influence the government to improve their near-term bottom line, no more and no less.
The problem with the GP's conspiracy theory is that it's too broad and too grand to reflect reality. We know that some corporations are secretly backing the anti-evolution movement because casting doubt on science in those fields in the mind of the public helps cast doubt on (say) the link between smoking and cancer or the link between fossil fuels and climate change.
There is no grand conspiracy for the simple reason that different people and different organisations have different agendas. Remember the protests against SOPA and PIPA? Many interpreted it as Hollywood having a different corporate agenda from Silicon Valley. There was, actually, a grain of truth to this. Tech companies didn't get involved entirely out of the goodness of their hearts...
So now you'll have a box that analyzes and sends home (for "personalization" and "quality" purposes) everything you say, is always on ("just so you can activate it by voice") and is hooked to your telescreen. Yay!
My xbone didn't even come with a Kinect. The only way it has audio input is if I plug a headset in, which I won't be doing very often.
The people producing Python or C++ libraries abandon those libraries when they move to a new language - they don't have a choice.
That's certainly true of Python. Hell, you practically need to abandon your Python libraries when you move to the next version of Python.
But it's not true of C++. Binding well-written C++ libraries to other languages sometimes takes a little work (you do need to write a glue layer if there's a serious impedance mismatch, but then you need to do that with C too), but it does work and largely works quite well. Python, Java, Rust, Go, Haskell, O'Caml... you name it, you can The only languages which don't work well with C++ libraries are old languages like Tcl.
Look at LLVM as an instructive example. It's a large complex beast written in heavy C++, but there are bindings for every language you'd ever want to seriously write a compiler in.
I see you do not understand what a mobile app is. There is no real logic in the app, it's just UI for a web service.
That's true in many cases, but it's far from the whole story. Well-written mobile apps try to minimise network communication because that can drain battery life much faster than a modest amount of computation.
Even badly-written mobile apps, like the Facebook client, do DSP on the device for things like its spyware voice recognition feature.
(ok, C++ does too but C is where you get all the amazing well written, optimized libraries you'd want on most devices).
You have clearly never had to support on very many third-party C libraries. The standard open source ones that have been around for decades (e.g. zlib, Berkeley DB) are indeed well-written and high-quality, but they are not the common case.
I recall from my C class that the language only has 34 keywords and that one of its advantages is that it doesn't come with unnecessary baggage.
What that typically means in practice is that for anything beyond a certain scale, you need to write the unnecessary baggage yourself. And believe me, you will.
As an embedded engineer, I appreciate this and also have never had to use a string package, or library, in my professional career.
Some embedded devices do have complex UIs which might find it useful. I've never written the firmware for a modern digital TV or DVR might need to do some of that. But yes, most firmware (and I have worked on some) doesn't need to manipulate strings.
Google it, you'll get that it has to do with number of transistors, not complexity.
Read Moore's papers.
The AC is strictly incorrect in stating that it has "nothing to do with the number of transistors on a chip". It has something to do with that. However, they did state what Moore said accurately, unlike whatever source Google took you to.
In any case, everyone has known Moore's law has been failing to keep up for a few years.
Transistor counts technically "failed to keep up" around the 1992-1997 era, but increased at a higher rate than predicted by Moore's Law (1975 version) between 2005 and 2012. Moore's Law is an observation about long-term trends. You can't tell anything from "a few years".
A far more likely reason is that sometimes it's possible to recover a deleted email and sometimes it is not. By analogy, think of the circumstances under which it is possible to recover a deleted file on disk.
Yahoo's policy says it can't recover deleted emails because if it said anything else, someone with an expensive lawyer would interpret that as a guarantee.
Something tells me you have no idea what kinds of things perl is vulnerable to.
I think you might be missing the context of Larry Wall's remarks, and the attack vector that is being described. We are not talking about ways that a programming language can help protect the system that the program is running on from a malicious program, or from a carelessly written program. We are talking about ways that a programming language can protect its own virtual machine from having its own invariants broken.
Java bytecode cannot crash a Java virtual machine no matter how hard the programmer tries. In all of the years of security holes in Java, not one of those holes was in the VM or classloader itself; they were all bugs in the standard library, and the security manager was one particular weak point. These bugs allowed remote attackers to get whatever privileges the VM has, but they still couldn't crash the VM using only Java code.
By contrast, Perl code can crash a Perl virtual machine, however, it is so hard to do on purpose that Larry Wall's advice to "don't do that" really is a good way to guard against it. The Perl virtual machine protects itself from badly-written code, but not maliciously-written code because if (as Raymond Chen would put it) you're already on the other side of the airtight hatchway, there are easier ways to do it.
You may have missed this, but I was actually defending millennials. I'm one of those rare gen xers who, due to circumstances (child with a disability, which has a bunch of consequential problems such as being a single-income family and being unable to relocate for work) missed out on all the alleged wealth.
Programs which accidentally allow remote execution in any non-managed language are easy to find. It's much harder to encounter a Perl script which breaks the security of the Perl language/VM itself.
And yet as C++ progresses, it becomes easier and easier to write simple and performant code that can't be exploited.
True, but that's not what is meant by the phrase. "Machiavelli", in this case, refers to the programmer.
In Java, "private" means "private". It is an abstraction which cannot be broken by the programmer. In C++, you can get at a private member of a class if you are sufficiently determined thanks to pointer shenanigans. But you can't do it by accident.
Slashdot Mirror
Why was this labeled flamebait? It's exactly what happened.
It is not what happened. What actually happened is a sequence of events that could have happened to any of us when we were kids.
A 14 year old kid took a clock apart and put it back together. The word "invention" was thrown around (he may or may not have used the word himself; this is unclear), but the kid was absolutely clear about his motives: he wanted to understand how it worked. Many, many Slashdotters can relate to this. This happened to me when I was a kid.
He was proud of himself and took it to school to show it off to a world which isn't very impressed by such things. He was told to put it away but couldn't help himself. Many, many Slashdotters can relate to this. This happened to me when I was a kid.
What most Slashdotters can't relate to is having the cops called on you and being the subject of a viral shitstorm for doing this. This did not happen to me when I was a kid. The kid is not an inventor. He might be a genius (his measured IQ may well be in the top 2%), or he might not be. The central point is that he is one of us, and we take care of our own. When normal geek childhood is criminalised, that's news for nerds and stuff that matters.
There has been a lot of talk (with no actual evidence, I might add) that the kid's father somehow engineered this, or wanted an incident, or to make a point. Even if that were true, the point was indeed made. So many social media commenters (and sadly Slashdot comments have devolved to the level of social media commenters) concentrate on what the kid did wrong, and don't stop to ponder just why it's so easy for incidents like this to happen if your skin has a bit of melanin in it.
The term troll is actually derived from a fishing troll, because it lures people in. It has nothing to do with the actual fictional monster that is a troll.
That's technically true, but the term also comes from the day when trolling was considered an artform. Your modern troll has more in common with the fictional monster than anything you used to see on alt.syntax.tactical.
I know you think you're being clever, but that's often the case.
My point (which I suspect that you agree with) is that a corporation who thinks they can get away with influencing the government will influence the government to improve their near-term bottom line, no more and no less.
The problem with the GP's conspiracy theory is that it's too broad and too grand to reflect reality. We know that some corporations are secretly backing the anti-evolution movement because casting doubt on science in those fields in the mind of the public helps cast doubt on (say) the link between smoking and cancer or the link between fossil fuels and climate change.
There is no grand conspiracy for the simple reason that different people and different organisations have different agendas. Remember the protests against SOPA and PIPA? Many interpreted it as Hollywood having a different corporate agenda from Silicon Valley. There was, actually, a grain of truth to this. Tech companies didn't get involved entirely out of the goodness of their hearts...
What do you get? To be a slaves to the corporations who get permission to buy some of what those same corporations sell.
Corporations are part of a conspiracy to impose more regulation. You heard it here first, folks.
So now you'll have a box that analyzes and sends home (for "personalization" and "quality" purposes) everything you say, is always on ("just so you can activate it by voice") and is hooked to your telescreen. Yay!
My xbone didn't even come with a Kinect. The only way it has audio input is if I plug a headset in, which I won't be doing very often.
I think last time it was called "Plays for Sure", wasn't it?
The people producing Python or C++ libraries abandon those libraries when they move to a new language - they don't have a choice.
That's certainly true of Python. Hell, you practically need to abandon your Python libraries when you move to the next version of Python.
But it's not true of C++. Binding well-written C++ libraries to other languages sometimes takes a little work (you do need to write a glue layer if there's a serious impedance mismatch, but then you need to do that with C too), but it does work and largely works quite well. Python, Java, Rust, Go, Haskell, O'Caml... you name it, you can The only languages which don't work well with C++ libraries are old languages like Tcl.
Look at LLVM as an instructive example. It's a large complex beast written in heavy C++, but there are bindings for every language you'd ever want to seriously write a compiler in.
I see you do not understand what a mobile app is. There is no real logic in the app, it's just UI for a web service.
That's true in many cases, but it's far from the whole story. Well-written mobile apps try to minimise network communication because that can drain battery life much faster than a modest amount of computation.
Even badly-written mobile apps, like the Facebook client, do DSP on the device for things like its spyware voice recognition feature.
Have they rewritten the Java runtime in Java yet?
Yes.
Last time I looked, it was written in C.
Not all of it. The original Sun class loader has been written in Java since 1.0.
(ok, C++ does too but C is where you get all the amazing well written, optimized libraries you'd want on most devices).
You have clearly never had to support on very many third-party C libraries. The standard open source ones that have been around for decades (e.g. zlib, Berkeley DB) are indeed well-written and high-quality, but they are not the common case.
I recall from my C class that the language only has 34 keywords and that one of its advantages is that it doesn't come with unnecessary baggage.
What that typically means in practice is that for anything beyond a certain scale, you need to write the unnecessary baggage yourself. And believe me, you will.
As an embedded engineer, I appreciate this and also have never had to use a string package, or library, in my professional career.
Some embedded devices do have complex UIs which might find it useful. I've never written the firmware for a modern digital TV or DVR might need to do some of that. But yes, most firmware (and I have worked on some) doesn't need to manipulate strings.
I was talking about space overhead, but okay, sure.
You can avoid fourth amendment violations by leaving your persons, papers, and effects in your houses.
Google it, you'll get that it has to do with number of transistors, not complexity.
Read Moore's papers.
The AC is strictly incorrect in stating that it has "nothing to do with the number of transistors on a chip". It has something to do with that. However, they did state what Moore said accurately, unlike whatever source Google took you to.
Yes, let's redefine Moore's law all day just like the media does, just like everybody does.
Just like Gordon Moore did 10 years after he originally stated it...
In any case, everyone has known Moore's law has been failing to keep up for a few years.
Transistor counts technically "failed to keep up" around the 1992-1997 era, but increased at a higher rate than predicted by Moore's Law (1975 version) between 2005 and 2012. Moore's Law is an observation about long-term trends. You can't tell anything from "a few years".
Having said that, you're right about Kurzweil.
OK, we have been talking cross-purposes it appears. I went back to the question and I did indeed miss one crucial detail in it.
My fault. Sorry about that.
there is nothing done in new languages that can't be done in others
Not only that, it can be done with worst-case constant overhead simply by implementing the new language using an old language first.
See, I know my algorithmic complexity theory too.
A far more likely reason is that sometimes it's possible to recover a deleted email and sometimes it is not. By analogy, think of the circumstances under which it is possible to recover a deleted file on disk.
Yahoo's policy says it can't recover deleted emails because if it said anything else, someone with an expensive lawyer would interpret that as a guarantee.
No, I'm not talking about the VM crashing because of badly-written code; I'm talking about the VM allowing you to make it do things.
And that's correct. However, you are not talking about what Larry Wall was talking about when he said "don't do that".
Something tells me you have no idea what kinds of things perl is vulnerable to.
I think you might be missing the context of Larry Wall's remarks, and the attack vector that is being described. We are not talking about ways that a programming language can help protect the system that the program is running on from a malicious program, or from a carelessly written program. We are talking about ways that a programming language can protect its own virtual machine from having its own invariants broken.
Java bytecode cannot crash a Java virtual machine no matter how hard the programmer tries. In all of the years of security holes in Java, not one of those holes was in the VM or classloader itself; they were all bugs in the standard library, and the security manager was one particular weak point. These bugs allowed remote attackers to get whatever privileges the VM has, but they still couldn't crash the VM using only Java code.
By contrast, Perl code can crash a Perl virtual machine, however, it is so hard to do on purpose that Larry Wall's advice to "don't do that" really is a good way to guard against it. The Perl virtual machine protects itself from badly-written code, but not maliciously-written code because if (as Raymond Chen would put it) you're already on the other side of the airtight hatchway, there are easier ways to do it.
You may have missed this, but I was actually defending millennials. I'm one of those rare gen xers who, due to circumstances (child with a disability, which has a bunch of consequential problems such as being a single-income family and being unable to relocate for work) missed out on all the alleged wealth.
Programs which accidentally allow remote execution in any non-managed language are easy to find. It's much harder to encounter a Perl script which breaks the security of the Perl language/VM itself.
...just like a real FPS?
And yet as C++ progresses, it becomes easier and easier to write simple and performant code that can't be exploited.
True, but that's not what is meant by the phrase. "Machiavelli", in this case, refers to the programmer.
In Java, "private" means "private". It is an abstraction which cannot be broken by the programmer. In C++, you can get at a private member of a class if you are sufficiently determined thanks to pointer shenanigans. But you can't do it by accident.