There was a need for a PHP-like language to write web back-ends. It could have been Perl, or Python, or PHP, or Ruby, or probably any of a hundred others.
Clearly you weren't there.
Ruby didn't exist. Python may as well not have existed. Unless you had a lot of money to spend, your choices in the web app space were, at the start, SSI or CGI (the back end for which was often Perl). CGI was notoriously slow, and Perl was quite slow to start a script (it was quite speedy once it was running). Yes, mod_perl existed, but it was at its core a mechanism for extending Apache's functionality, not really a system for building web apps/sites in. JSF existed, if you had the computrons to run it and the patience to learn it.
PHP was really the only thing which just worked in anything resembling an efficient manner, and it worked pretty well for those jobs where SSI wasn't quite good enough. Hosting services installed it by default, and if you wanted anything else, you had to work for it.
Followed by "Perl is objectively a broken language"...
There is a saying in the C++ community, that many language features are intended to protect against Murphy, not Machiavelli.
Unlike Java, Perl does not even try to protect you from malicious programmers. Being a scripting language, Perl also doesn't try hard to protect you from careless programmers. Nonetheless, these particular examples of brokenness would be hard to encounter by accident. You can't say that of PHP.
Sure, I'm not saying that non-physical shots shouldn't be done, merely that CGI enables them to be overdone. The Matrix is a case in point: the Wachowskis were careful to use impossible shots sparingly, and only use them inside the Matrix; scenes set in the "real world" were much more conservative.
There is a story that Richard Donner put up a banner in the production office for Superman which had one word on it: "verisimilitude". That's what's missing from a lot of modern effects-heavy films.
That was a great shot from Soy Cuba. I'm also reminded of the opening of A Touch of Evil.
First, there was the post-war boom, then women entered the workforce, then there was globalisation, the dot-com bubble, and easy credit. Millennials are getting less because we've run out of things to exploit to feed our demand for exponential growth. It was inherently unsustainable and had to stop some time. Now is that time.
I was just thinking that. The entitlement generation getting LESS than anyone else!
The entitlement generation got MORE than anyone else, but thankfully they're retiring about now. Hopefully they'll be freeing up the property market soon as they die off.
As a side note, really wish they had made areal Halo movie.
I think they should make fewer movies of video games (or, if you must, do something like the upcoming Assassin's Creed and set a new story in the same universe). Movies are too short to get across the amount of story that you can fit into a video game.
A better alternative would be the epic TV genre which is all the rage at the moment. Imagine the Halo trilogy told over three seasons, 13 episodes each.
Oh, yes the Portal colour scheme. That annoyed the crap out of me, too.
Having said that, to be fair, there are only so many ways you can adjust Namibia to look like country Australia minus all the plants. Do an image search for "Coober Pedy" or "Mallee" some time and you'll see what I mean.
But it is true that using actual physical special effects can create some unique film events. My favorite is the scene in ET where Elliot reveals ET to his older brother. The actor playing the brother was not actually informed of how ET was going to be revealed, so the shock you see on his face is very real. If ET was just a digitally-created image edited into the footage in post-production, it's probable you wouldn't get quite the same response, particularly from child actors.
Further to that topic, CGI lets you create camera moves which are not possible in real life, in the sense that even if there was a fantasy/sci-fi/action/whatever thing going on, there's nowhere that you could physically place a camera which would get that shot. It violates the logic of the universe, which breaks the illusion for many people. In a film like Inception it can work but only because it's set in a surreal dreamscape, so you buy that it could work in that universe. But in a film like The A-Team it just looks ridiculous.
I loved the shakycam space battle scenes from the remake of Battlestar Galactica.
I would expect someone claiming to be fluent in a programming language to be able to sit down, cold, and write code in that language which would compile (or interpret) without syntax error and solve the problem at hand.
Hmmm... I'm not sure I buy that. Someone who has used a language a lot naturally writes more conformant code, but this isn't actually a useful skill. In almost all programming languages, it's a better use of your time to manually check the intent of the program before feeding it to the compiler, rather than the syntax. Detecting and diagnosing syntax are one of those things that compilers are extremely good at to the point where it's not worth wasting a programmer's time doing it.
Requiring that someone's whiteboard code is 100% syntax-correct would eliminate many "assertive programmers" (in the Gerard Weinberg sense). Having said that, I think we could all tell the difference between a trivial error that the compiler would catch and someone who really doesn't know what they're doing.
You'll notice something interesting: My offhand calculation of "300 years" was in response to someone claiming fluency in 60 languages - which derived from my estimate of about 5 years per language to acquire true fluency.
My exact words were "varying levels of fluency". You may have missed that carefully-chosen wording. If so, then your response makes sense to me now.
Being able to regurgitate 3 pages of grammar rules doesn't make you fluent in a human language.
Indeed it does not. The vast majority of human language acquisition is vocabulary, which is what enables you to communicate with other people. Programming languages don't have an equivalent of this.
I maintain (and I know this from experience) that if you can already program in a modern functional language (say, Scheme or Haskell), Prolog, and are already familiar with the pi calculus model, then you can pick up the Erlang language in an afternoon, and most of the main idioms and gotchas in a week. Admittedly it helps that Erlang is an extremely well-designed language, of course, but it really is that easy. However, to call yourself an "Erlang programmer" with a clear conscience, to be productive in the areas where Erlang shines, you need to know OTP inside and out. That takes months to learn and years to master.
Like any skill, achieving fluency in a programming language requires a lot of practice - hands on application of the language to your chosen (or assigned) problems, [...]
Ah, now here's one thing where I think I had an advantage: Compiler writing (which was my "problem" about 20 years ago), as well as fostering an interest in collecting different programming languages just to see what makes them tick, has a special property in that it's almost all algorithms and data structures with a bit of I/O. You are working with the core language and standard library (i.e. not third-party libraries or frameworks) almost all of the time. If your problem space resembles that, it's very possible to know enough about programming languages of all types to be up to speed in a a new language in a surprisingly short amount of time.
Nowadays, of course, you'd want to use something like LLVM if you're compiling to real CPUs. But even then, it's a matter of learning the native LLVM binding given that you already know half a dozen LLVM bindings.
If you care about GUIs, networking, databases, mobile, or what have you, then yes, that takes work. However, you would have to do that same work if you were moving to a different problem space anyway. Someone who rightly calls themselves a "C# developer" with 10 years experience might not be as productive as you might hope if you sat them down in front of Unity 3D for the first time.
100% correct. I only claimed to speak 60 programming languages, not to know the idiosyncrasies of their standard (and not-so-standard but still required) libraries. That makes the exercise a bit easier.
Disconnect your computer from the internet, and write a fully conforming Ada 2012 compiler in Common Lisp.
Interestingly, Ada isn't one of them. Nor is Python, interestingly.
If you're curious how I got to 60, there are a lot of languages in there which are distinct languages with distinct specs, but are essentially dialects.
Consider the Turner family of languages, for example. I've used KRC, Miranda, Orwell, Miracula, and Haskell. All of them are distinct languages with their own specs. I can remember writing a Prolog interpreter in at least three of them. I can still explain to you some of the key differences between them. if you know two of them you know them all, and besides, one of them is still around.
Other examples of distinct-but-close-enough languages which I have used in a nontrivial manner are Eiffel and Sather, SML and O'Caml (never used Alice), Smalltalk and Newspeak, Object Pascal and Delphi, Agda and Coq (never used Epigram), PostScript and Forth, Java and Modula-3.
And then there's logic languages. I've used (again, seriously used) Prolog, Datalog, Mercury, Oz, Gödel, and KL1. All of them are distinct languages with crucial differences, but so closely related that once you know two of them well (say, one dynamically typed and one statically typed variant), you can get quite productive in most of them within an afternoon.
Unless you have been programming for about 300 years, there is zero chance you have achieved fluency in more than 2 or 3 of these programming languages. Being able to print "Hello world," does not count as fluency, any more than being able to say, "Hello, my name is Robert," counts as fluency in a human language.
Once you get past the first 6 or so, assuming you chose them carefully, the similarities are apparent. But if it helps, merely being able to write a nontrivial program in a given language doesn't mean that you can call yourself a "X programmer".
Consider what it means to be a Java programmer. I know Java, the language, extremely well. Well enough to write a conforming Java 1.7 to bytecode compiler, I would think. Now here's what I don't know: JSF, Spring, Swing, Maven, Ant, Struts, Android SDK, Eclipse RCP, etc. It's knowing a decent amount of that stuff that which lets you call yourself a "Java programmer" in good conscience. I can write programs in Java, but I'm not a Java programmer.
Having said that, I speak over 60 programming languages (to varying levels of fluency) at last count, and I do the Pragmatic Programmers thing of doing another one every year. I may not be the best person to ask.
ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.
Incidentally, the C standard contains a lot of undefined behaviour which isn't there to ease porting to obscure platforms, but to enable optimisations that only seem to give a measurable performance improvement in highly artificial benchmarks.
Playing while driving, injuries, dead bodies, people blocking emergency services buildings... yup, that's how I remember Ingress. The only difference I can see is that the Pokemon game lore is comprehensible.
The problem with that is that it makes an assumption about the processors stack and how it works.
Not exactly. If your language needs to support cactus-stack-structured lexical closures anyway, it can be worth not implementing your activation stack in terms of the CPU's stack. Notably, Appel's original ML implementation didn't bother with a traditional stack and just allocated fragments on the heap.
ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.
I see you haven't been bitten by this yet. Trust me, when your old code compiles on every architecture you can think of EXCEPT for x86-64, you'll get just a little bit upset too.
I've been involved in firmware development for implantable medical devices as well as other devices and it's simply not true that assembly has much use this day in age.
I've been involved in firmware development for small devices. In my (probably limited compared to you) experience, the ability to read and understand assembly is just as important as it's always been in that space, even if not a single line of deployed code is written in assembly. If I was hiring someone, I would put that in the job requirements. For TIOBE's statistics-gathering purposes, that may well translate to "assembly programmer wanted".
I write compilers for a living, and I came in to say something much like the above.
I apologise in advance for the following rant. It may not be fair to direct it at you personally, but I'm going to do it anyway.
There is a trend happening in modern C-family compilers where they have decided to go full language-lawyer on aliasing rules. It's getting much, much easier to write code which looks sane and has worked for 20 years, but compiles to code which subtly does what you don't expect on the most recent compilers.
Now this isn't entirely your fault, because C-family language standards are severely obsolete and kind of stupid in this respect. The aliasing rules date from an era when CPUs were much slower than they are today. I do a lot of scientific-type high performance code, and I don't think I've seen a performance issue in the last decade that can be blamed on pointer aliasing, despite the C-family committees still act as if this is the most insidious performance problem in the world. But I have been bitten several times by compilers generating code that may be technically correct (the best kind of correct!) but clearly not what the programmer intended.
The standards are full of these nasal demons, where you shouldn't go there just in case the compiler decides in its wisdom to optimise that code in a certain way. Is it so much to ask that once in a while we might get a performance guarantee? Something which says "If you write the code this way, this will definitely happen". Hell, Scheme programmers get a guarantee that tail call optimisation always happens. We don't even get a guarantee on the empty base optimisation!
We may see more assembly in the years to come, not because it's faster, but because assembly has "do what I say" semantics in a way that C and C++ do not.
There was a very good op-ed from the Usenet days which pointed out that an assembly programmer will always beat a high-level-language programmer on most performance metrics because a typical assembly programmer can use a compiler but a typical high-level-language programmer can't use an assembler.
An assembly programmer can use a profiler to work out where the problems are, inspect the output of the compiler, see what's wrong with it, and fix it using assembly. (Today we might include intrinsics as a potential fix, of course.) Assembly programmers write faster code because they can also use a compiler.
The good thing is that this is about Australia and not about some place where innovation is actually taking place. So in the end, it's a storm in a teacup.
What, you didn't like Cleverman?
Actually, the lack of an open-ended fair use system is probably partly to blame.
Slashdot Mirror
There was a need for a PHP-like language to write web back-ends. It could have been Perl, or Python, or PHP, or Ruby, or probably any of a hundred others.
Clearly you weren't there.
Ruby didn't exist. Python may as well not have existed. Unless you had a lot of money to spend, your choices in the web app space were, at the start, SSI or CGI (the back end for which was often Perl). CGI was notoriously slow, and Perl was quite slow to start a script (it was quite speedy once it was running). Yes, mod_perl existed, but it was at its core a mechanism for extending Apache's functionality, not really a system for building web apps/sites in. JSF existed, if you had the computrons to run it and the patience to learn it.
PHP was really the only thing which just worked in anything resembling an efficient manner, and it worked pretty well for those jobs where SSI wasn't quite good enough. Hosting services installed it by default, and if you wanted anything else, you had to work for it.
Followed by "Perl is objectively a broken language"...
There is a saying in the C++ community, that many language features are intended to protect against Murphy, not Machiavelli.
Unlike Java, Perl does not even try to protect you from malicious programmers. Being a scripting language, Perl also doesn't try hard to protect you from careless programmers. Nonetheless, these particular examples of brokenness would be hard to encounter by accident. You can't say that of PHP.
Sure, I'm not saying that non-physical shots shouldn't be done, merely that CGI enables them to be overdone. The Matrix is a case in point: the Wachowskis were careful to use impossible shots sparingly, and only use them inside the Matrix; scenes set in the "real world" were much more conservative.
There is a story that Richard Donner put up a banner in the production office for Superman which had one word on it: "verisimilitude". That's what's missing from a lot of modern effects-heavy films.
That was a great shot from Soy Cuba. I'm also reminded of the opening of A Touch of Evil.
Seth Rogen does cartoons?
Having said that, I disagree. Stoner comedy has not changed in quality since Cheech & Chong.
But why are you getting less?
Because previous generations got too much.
First, there was the post-war boom, then women entered the workforce, then there was globalisation, the dot-com bubble, and easy credit. Millennials are getting less because we've run out of things to exploit to feed our demand for exponential growth. It was inherently unsustainable and had to stop some time. Now is that time.
I was just thinking that. The entitlement generation getting LESS than anyone else!
The entitlement generation got MORE than anyone else, but thankfully they're retiring about now. Hopefully they'll be freeing up the property market soon as they die off.
As a side note, really wish they had made areal Halo movie.
I think they should make fewer movies of video games (or, if you must, do something like the upcoming Assassin's Creed and set a new story in the same universe). Movies are too short to get across the amount of story that you can fit into a video game.
A better alternative would be the epic TV genre which is all the rage at the moment. Imagine the Halo trilogy told over three seasons, 13 episodes each.
Oh, yes the Portal colour scheme. That annoyed the crap out of me, too.
Having said that, to be fair, there are only so many ways you can adjust Namibia to look like country Australia minus all the plants. Do an image search for "Coober Pedy" or "Mallee" some time and you'll see what I mean.
But it is true that using actual physical special effects can create some unique film events. My favorite is the scene in ET where Elliot reveals ET to his older brother. The actor playing the brother was not actually informed of how ET was going to be revealed, so the shock you see on his face is very real. If ET was just a digitally-created image edited into the footage in post-production, it's probable you wouldn't get quite the same response, particularly from child actors.
Further to that topic, CGI lets you create camera moves which are not possible in real life, in the sense that even if there was a fantasy/sci-fi/action/whatever thing going on, there's nowhere that you could physically place a camera which would get that shot. It violates the logic of the universe, which breaks the illusion for many people. In a film like Inception it can work but only because it's set in a surreal dreamscape, so you buy that it could work in that universe. But in a film like The A-Team it just looks ridiculous.
I loved the shakycam space battle scenes from the remake of Battlestar Galactica.
I stopped feeling things when I was four. Thanks to Mickey Mouse and Bugs Bunny, my perceptions were all made of ink.
There's a good analogy here. Warner Brothers, Hanna-Barbera, and even John K cartoons were funny in a way that Seth MacFarlane is not.
I would expect someone claiming to be fluent in a programming language to be able to sit down, cold, and write code in that language which would compile (or interpret) without syntax error and solve the problem at hand.
Hmmm... I'm not sure I buy that. Someone who has used a language a lot naturally writes more conformant code, but this isn't actually a useful skill. In almost all programming languages, it's a better use of your time to manually check the intent of the program before feeding it to the compiler, rather than the syntax. Detecting and diagnosing syntax are one of those things that compilers are extremely good at to the point where it's not worth wasting a programmer's time doing it.
Requiring that someone's whiteboard code is 100% syntax-correct would eliminate many "assertive programmers" (in the Gerard Weinberg sense). Having said that, I think we could all tell the difference between a trivial error that the compiler would catch and someone who really doesn't know what they're doing.
Somebody who works with C# could probably be very productive un VB.Net within a day or two, even though the languages appear quite different.
And on the other hand, someone who has worked for years in C#.Net might take months to get up to speed with Unity 3D.
You'll notice something interesting: My offhand calculation of "300 years" was in response to someone claiming fluency in 60 languages - which derived from my estimate of about 5 years per language to acquire true fluency.
My exact words were "varying levels of fluency". You may have missed that carefully-chosen wording. If so, then your response makes sense to me now.
Being able to regurgitate 3 pages of grammar rules doesn't make you fluent in a human language.
Indeed it does not. The vast majority of human language acquisition is vocabulary, which is what enables you to communicate with other people. Programming languages don't have an equivalent of this.
I maintain (and I know this from experience) that if you can already program in a modern functional language (say, Scheme or Haskell), Prolog, and are already familiar with the pi calculus model, then you can pick up the Erlang language in an afternoon, and most of the main idioms and gotchas in a week. Admittedly it helps that Erlang is an extremely well-designed language, of course, but it really is that easy. However, to call yourself an "Erlang programmer" with a clear conscience, to be productive in the areas where Erlang shines, you need to know OTP inside and out. That takes months to learn and years to master.
Like any skill, achieving fluency in a programming language requires a lot of practice - hands on application of the language to your chosen (or assigned) problems, [...]
Ah, now here's one thing where I think I had an advantage: Compiler writing (which was my "problem" about 20 years ago), as well as fostering an interest in collecting different programming languages just to see what makes them tick, has a special property in that it's almost all algorithms and data structures with a bit of I/O. You are working with the core language and standard library (i.e. not third-party libraries or frameworks) almost all of the time. If your problem space resembles that, it's very possible to know enough about programming languages of all types to be up to speed in a a new language in a surprisingly short amount of time.
Nowadays, of course, you'd want to use something like LLVM if you're compiling to real CPUs. But even then, it's a matter of learning the native LLVM binding given that you already know half a dozen LLVM bindings.
If you care about GUIs, networking, databases, mobile, or what have you, then yes, that takes work. However, you would have to do that same work if you were moving to a different problem space anyway. Someone who rightly calls themselves a "C# developer" with 10 years experience might not be as productive as you might hope if you sat them down in front of Unity 3D for the first time.
100% correct. I only claimed to speak 60 programming languages, not to know the idiosyncrasies of their standard (and not-so-standard but still required) libraries. That makes the exercise a bit easier.
Disconnect your computer from the internet, and write a fully conforming Ada 2012 compiler in Common Lisp.
Interestingly, Ada isn't one of them. Nor is Python, interestingly.
If you're curious how I got to 60, there are a lot of languages in there which are distinct languages with distinct specs, but are essentially dialects.
Consider the Turner family of languages, for example. I've used KRC, Miranda, Orwell, Miracula, and Haskell. All of them are distinct languages with their own specs. I can remember writing a Prolog interpreter in at least three of them. I can still explain to you some of the key differences between them. if you know two of them you know them all, and besides, one of them is still around.
Other examples of distinct-but-close-enough languages which I have used in a nontrivial manner are Eiffel and Sather, SML and O'Caml (never used Alice), Smalltalk and Newspeak, Object Pascal and Delphi, Agda and Coq (never used Epigram), PostScript and Forth, Java and Modula-3.
And then there's logic languages. I've used (again, seriously used) Prolog, Datalog, Mercury, Oz, Gödel, and KL1. All of them are distinct languages with crucial differences, but so closely related that once you know two of them well (say, one dynamically typed and one statically typed variant), you can get quite productive in most of them within an afternoon.
Oh, and four different assembly languages.
Unless you have been programming for about 300 years, there is zero chance you have achieved fluency in more than 2 or 3 of these programming languages. Being able to print "Hello world," does not count as fluency, any more than being able to say, "Hello, my name is Robert," counts as fluency in a human language.
Once you get past the first 6 or so, assuming you chose them carefully, the similarities are apparent. But if it helps, merely being able to write a nontrivial program in a given language doesn't mean that you can call yourself a "X programmer".
Consider what it means to be a Java programmer. I know Java, the language, extremely well. Well enough to write a conforming Java 1.7 to bytecode compiler, I would think. Now here's what I don't know: JSF, Spring, Swing, Maven, Ant, Struts, Android SDK, Eclipse RCP, etc. It's knowing a decent amount of that stuff that which lets you call yourself a "Java programmer" in good conscience. I can write programs in Java, but I'm not a Java programmer.
...about every 2 hours, on the current job.
Having said that, I speak over 60 programming languages (to varying levels of fluency) at last count, and I do the Pragmatic Programmers thing of doing another one every year. I may not be the best person to ask.
ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.
Incidentally, the C standard contains a lot of undefined behaviour which isn't there to ease porting to obscure platforms, but to enable optimisations that only seem to give a measurable performance improvement in highly artificial benchmarks.
Playing while driving, injuries, dead bodies, people blocking emergency services buildings... yup, that's how I remember Ingress. The only difference I can see is that the Pokemon game lore is comprehensible.
The problem with that is that it makes an assumption about the processors stack and how it works.
Not exactly. If your language needs to support cactus-stack-structured lexical closures anyway, it can be worth not implementing your activation stack in terms of the CPU's stack. Notably, Appel's original ML implementation didn't bother with a traditional stack and just allocated fragments on the heap.
ISO-C has a lot of behavior that is specified as being undefined or compiler-defined that you have to be aware of, but if you are your code will compile for more architectures than any other language out there, no matter how portable they claim that it is.
I see you haven't been bitten by this yet. Trust me, when your old code compiles on every architecture you can think of EXCEPT for x86-64, you'll get just a little bit upset too.
I've been involved in firmware development for implantable medical devices as well as other devices and it's simply not true that assembly has much use this day in age.
I've been involved in firmware development for small devices. In my (probably limited compared to you) experience, the ability to read and understand assembly is just as important as it's always been in that space, even if not a single line of deployed code is written in assembly. If I was hiring someone, I would put that in the job requirements. For TIOBE's statistics-gathering purposes, that may well translate to "assembly programmer wanted".
I write compilers for a living, and I came in to say something much like the above.
I apologise in advance for the following rant. It may not be fair to direct it at you personally, but I'm going to do it anyway.
There is a trend happening in modern C-family compilers where they have decided to go full language-lawyer on aliasing rules. It's getting much, much easier to write code which looks sane and has worked for 20 years, but compiles to code which subtly does what you don't expect on the most recent compilers.
Now this isn't entirely your fault, because C-family language standards are severely obsolete and kind of stupid in this respect. The aliasing rules date from an era when CPUs were much slower than they are today. I do a lot of scientific-type high performance code, and I don't think I've seen a performance issue in the last decade that can be blamed on pointer aliasing, despite the C-family committees still act as if this is the most insidious performance problem in the world. But I have been bitten several times by compilers generating code that may be technically correct (the best kind of correct!) but clearly not what the programmer intended.
The standards are full of these nasal demons, where you shouldn't go there just in case the compiler decides in its wisdom to optimise that code in a certain way. Is it so much to ask that once in a while we might get a performance guarantee? Something which says "If you write the code this way, this will definitely happen". Hell, Scheme programmers get a guarantee that tail call optimisation always happens. We don't even get a guarantee on the empty base optimisation!
We may see more assembly in the years to come, not because it's faster, but because assembly has "do what I say" semantics in a way that C and C++ do not.
There was a very good op-ed from the Usenet days which pointed out that an assembly programmer will always beat a high-level-language programmer on most performance metrics because a typical assembly programmer can use a compiler but a typical high-level-language programmer can't use an assembler.
An assembly programmer can use a profiler to work out where the problems are, inspect the output of the compiler, see what's wrong with it, and fix it using assembly. (Today we might include intrinsics as a potential fix, of course.) Assembly programmers write faster code because they can also use a compiler.
UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS.
The good thing is that this is about Australia and not about some place where innovation is actually taking place. So in the end, it's a storm in a teacup.
What, you didn't like Cleverman?
Actually, the lack of an open-ended fair use system is probably partly to blame.