That provision would require universities to filter P2P and to offer legal alternatives.
Since P2P filesharing is legal (though sharing particular files may not be), and there are no other alternatives with the same features, this seems to be nonsense.
Re:Don't get blindsided by big stuff you can't see
on
The Future of XML
·
· Score: 1
but when you right down to it, do you really think the banking industry, the petroleum industry, and countless others are going to roll over tomorrow and start hacking JSON?
No, clearly, few technologies grow to maturity in industries like that. They are fire-tested and develop in industries that can take the risk of experimentation, and then they are adopted by those industries once they are proven. So, yeah, XML is going to be around for a while, even if JSON, YAML, or something like it may displace it for many uses (including highly-sensitive ones) in the long run.
That said, I don't see a lot of intrinsic advantages XML has over YAML (JSON's slightly bigger brother); most of its current advantages are in the domain of tool support (including auxiliary technologies that are also implemented in XML). But JSON/YAML, the longer and more widely they are used, are going to grow a lot of that support, too, and narrow the gap.
Oh! You mean that thing that lacks unicode character support, that lacks any easy way to define the character set, and has plenty of other problems, like for example its inability to fail fast?
S-expressions don't "lack unicode character support"; generic S-expressions are encoding neutral. What generic S-expressions lack is a specified mechanism for specifying encoding.
And these are -explicitly- shared hosting accounts, and there are some restrictions - including how quickly you can grow your disk usage, and if you are using too much bandwidth you'll be flagged.
Heh. "Unlimited bandwidth", but if you use "too much" you'll be "flagged". IOW, Yahoo! has just joined the long-tradition of "unlimited" hosting services where "unlimited" means "we won't tell you up front what the limits are, but they sure exist, and you'll sure be nailed for breaking them."
Better off getting an account where the limits are disclosed, and you can pay to get them raised.
Re:JSON is S-expressions done wrong
on
The Future of XML
·
· Score: 1
JSON is almost exactly equivalent to LISP S-expressions.
Not really, even in the relation between JSON and JavaScript and the relation between S-Expressions and Lisp. JSON is a subset of JavaScript, and S-Expressions are a superset of Lisp.
Unfortunately, JSON has major security problems due to a Javascript design error.
JSON doesn't rely on having JavaScript on either end. Particular applications or libraries that use JSON, either in JavaScript or otherwise, may have security errors due to design of those libraries or applications, but JSON itself does not have a security problem, and if it did, it could not be due to a JavaScript design error since JSON can be used without JavaScript ever touching it.
In LISP, there's the "reader", which takes in a string, parses it, and generates a tree structure (or graph; there's a way to express cross-links), and just returns the data structure. Then lISP has "eval", which takes a data structure created by the reader and runs it.
Javascript combines both functions into one, called "eval", which takes a string, parses it, and runs it. Giant security hole. There are attempts to patch around this, but it's ugly.
And it may be true that JavaScript doesn't have an accessible (to user code) "reader" for arbitrary JavaScript as part of the core language. However, there are JSON parsers (including one on the JSON website) for JavaScript that don't rely on eval (as well as the ugly hacks that try to detect "evil" in the JSON and then call eval if they think the JSON is "safe"). Using a JSON parser rather than eval addresses the security concerns; any security problems are not the fault of either the design of JSON or the design of the JavaScript language, tehy are the fault of the design of the application.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 2, Insightful
While I hate XML Schema, it's still better for many uses than just throwing random crap on the wire and hoping that the other end can make sense of it.
XML Schema may let the other end validate it, but it doesn't let the other end make sense of it. The other end can only make sense of it if they've got code written to handle the kind of data it contains: which is true, really, of any data format.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 2, Interesting
JSON is inflicting Javascript on everyone.
No, it really doesn't, but if "JavaScript" in the name bothers you, you might feel better with YAML.
No, it wouldn't because JSON is bare bones data. It's simply nested hash tables, arrays and strings.
"You might feel better..." -> "No, it wouldn't..."? WTF is that supposed to mean? How is taht even a response to what precedes it?
XML does much more than that.
"JSON is..." -> "XML does much more than that." Again, this is incoherent. XML is simply tree-structured markup. It has less inherent semantic content than JSON/YAML. OTOH, JSON/YAML can do a lot more than what it is, just as XML can. Both JSON/YAML and XML can present pretty arbitrary data in manner which is fairly easy to parse automatically and fairly readable. XML strengths, IMO, is that its a more natural format for text-centric markup, and that it has a lot more maturity in the available tools and applications.
The point is, though, JSON doesn't force JavaScript on anyone.
Which sort of gets into the point I did want to make but was too impatient to explain: JSON is good where JSON is best, and XML is good where XML is best.
That's kind of a dumb point to make without any discussion about which those areas are; as discussed above, the areas I see where XML is intrinsically superior are fairly narrow, though its currently probably better for lots of projects simply because its been established longer and has better tool support.
There are other programming languages out there.
And there are JSON and/or YAML libraries for quite a lot of them. So what?
Would you like to live in a world of S-expressions?
You missed the point again. Sure, there are other programming languages out there. The fact that there are JSON libraries for many of them underlines that the argument "JSON is forcing JavaScript on everyone" is false. JSON is an interchange format. It may be inspired by JavaScript, but it isn't forcing JavaScript on anyone.
But, yeah, S-expressions are great.
The LISP people would point out there are libraries to read/write S-expressions, so why use JSON?
Since I didn't say "there are libraries to use JSON, so why use XML", but "there are libraries to use JSON from other languages, so JSON isn't forcing JavaScript on anyone", I think you miss the point. Anyone, real Lispers are more likely to say that "there are libraries to read/write S-expressions, so why use XML, which is essentially a more verbose but no more expressive or clear variant of S-expressions?*"
The answer of course is that we want more than simply nesting lists of strings. We want our markup languages to fit our requirements, not the other way around.
S-expressions are not "nesting lists of strings".
We want our markup languages to fit our requirements, not the other way around.
And, very often, a markup language inherently isn't a natural fit to data interchange requirements. JSON/YAML are both motivated by that specific fact. In fact, but for XHTML and office document formats, I've rarely seen an application where XML was used where a markup language was a really natural tool to start with. XML is popular because its a hammer that everyone's gotten really comfortable using, so every data interchange need is treated as if it were a nail, whether or not its actually a nail, a screw, or glue-on wallpaper.
My problems with JSON are:
This is certainly a limitation in JSON/YAML tool support. I don't think its an inherent limitation in the formats: either has
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 1
Comparing XML to JSON or plists isn't exactly fair though, since they XML does not define any semantics.
Its perfectly fair, since they are often alternatives for the same use.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 4, Informative
JSON is inflicting Javascript on everyone.
No, it really doesn't, but if "JavaScript" in the name bothers you, you might feel better with YAML.
There are other programming languages out there.
And there are JSON and/or YAML libraries for quite a lot of them. So what?
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 4, Interesting
Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.
JSON/YAML is/are better (not considering, of course, the variety and maturity of available tools; but then, perhaps, you don't always need most of what is out there in XML tools, either) for lots of things (mostly, the kinds of things TFA notes XML wasn't designed for and often isn't the best choice for),things that aren't marked-up text. Where you actually want an extensible language for text-centric markup, rather than a structured format for interchange of something that isn't marked-up text, XML seems to be a pretty good choice. Of course, for some reason, that seems to be a minority of the uses of XML.
Heat is a problem with Li-ion batteries. If they get too hot they explode. Leaving a phone in a car with direct sunlight is enough.
The cabin of a car with direct sunlight with the windows closed can reach air temperatures upward of 130F with surfaces exposed to sunlight temperatures close to 200F.
Its highly unlikely that the battery of any electric vehicle will be located in the passenger cabin, or exposed to the kind of temperature extremes one would find in the cabin when the car is left in direct sunlight with the windows closed.
Also, Li-Ion batteries designed for electric cars and other large-scale applications use an different cathode materials that reduce temperature sensitivity and increase lifespan, at the cost (compared to the kind of batteries you'd find in, say, a laptop) of decreased energy density.
The US is very rapidly turning into a developing country.
See, this is one of many places the use of "developing" as a euphemism for "less-developed" falls apart. Even if, in the general case, it were reasonable to describe most less-developed countries as "developing" (that is, approaching the level of development in the more advanced countries), it clearly isn't a good way to describe the regress of the most developed country of the world.
(And, really, "developing" isn't a good description for LDCs in the general case, either; while some are narrowing the gap the the most advanced countries, very many are developing, if at all, more slowly than the most advanced countries and falling farther behind; calling them "developing" countries is a misleading euphemism that obscures the real conditions.)
I guess the only time you could benefit from a query being serviced by multiple processors is if your database is handling fewer concurrent requests than you have processors, and yet you need to shave milliseconds off the small number of queries that are running.
I might be missing something, but that sounds like a pretty specialised use case.
Seems like it could be fairly common (and potentially shaving a lot more than "milliseconds" off individual queries) in an OLAP environment. Not as common or useful, I would presume, in most OLTP environments.
Sorry, I should've been more clear on this. I meant automatically indenting as you type, not automatically indenting an existing file.
But Python doesn't allow an editor to automatically correctly indent as you type, either; all an editor can give you is the most-likely indentation point (the last line's indentation normally, one indent level in if you use an "if [...]:" or some similar statement that introduces a block.) With a language that has an unambiguous block structure defined by delimiters, the editor can correctly indent as you type, not merely give you the most likely indentation. The effects are superficially similar, but not the same.
It's no more burdensome than the automatic indentation you'd have to apply in a language that uses braces (at least, assuming you're using a decent editor). In vim, all I need to do to indent pasted code is use ]p instead of p or [p instead of P when I paste it, and it automatically gets adjusted to the current indentation level. That's a single extra key stroke, which you'd at least need to tell it to indent the code appropriately for you with other languages.
Yes, if you happen to want to insert the pasted text at the current indentation level. Which you may or may not. Because the same text could be pasted at different indentation levels and still be legitimate code (with different meanings), the general case is that you have to do that, and then sometimes adjust by one indentation level in one direction or the other (most likely, if an adjustment is needed, it will be one level out.)
With a language whose block structure is carried by delimiters, as long as you copy the right source code (including the beginning and/or ending delimiters, as appropriate), its always simply an "autoindent" on the region and you are in the right place. With Python, the source code copied doesn't carry enough information to unambiguously determine the correct indentation level, so its not possible to have a one-step, always-correct mechanism to correct the indentation.
Perhaps that's because neither you nor the post you replied to understand what's going on? Python has block delimiters just like any other language. It's a tab character. The only difference is that most editors make it an option to display it.
The tab (or spaces) in Python are not block delimiters. They are per-line block-level markers, which are not, at all, the same thing, though of course there is a direct conversion between code in which blocks are indicated with block-level-markers and otherwise-syntactically-identical code in which blocks are indicated with delimiters (which is why languages with regular, unambiguous delimiters can be automatically indented by editors.)
I'm glad that you brought up the "Cut and Paste" idea. If you are duplicating code, you should be refactoring it out into a function, not creating more lines to maintain.
Perhaps you should reconsider that criticism after thinking about the difference between "Cut" and "Copy", and thinking about what the most natural way is to move a large block of already-written code that would otherwise need to be repeated from the inside of one function out into into its own function without creating more lines to maintain.
No, sadly, they aren't fixing any of the key problems with the language, they're just not maintaining compatibility. Should be pretty much the death knell for python. I guess ruby wins.
If not maintaining compatibility is the "death knell", then Ruby is eliminated (1.9 isn't backward compatible with 1.8.x), too.
strawman. you ignored that such an update didn't break existing code.
If I did, that wouldn't be a strawman, it would be a bad analogy. I wasn't saying you argued that C90 -> C99 said something about C, I was saying your argument suggested that by analogy.
OTOH, I didn't "ignore" that since it is not true. C99 makes illegal constructs that were legal in C90. Since the Perl6 primary implementation can also run Perl5 code even though Perl5 code is not valid Perl6, I don't see how that is substantially different from the fact that most practical C99 implementations are likely to have options to allow the illegal C90 constructs (and, conversely, most C90 implementations probably warned on them in the first place), though they are strictly-speaking not valid C99. Both language updates break existing code. Both have workarounds in the implementations people are likely to use which make the fact that the language update breaks existing code almost completely irrelevant.
When important languages like Python or Perl announce they are going to improve the language such that it breaks older scripts, it just shows that the language was never that mature to begin with.
So, C90 -> C99 provided that C was never that mature to begin with? Sure, most implementations probably work around the compatibility issues in most cases, with appropriate options; then again, Perl and Python both have automatic conversion tools, and the former at least as a compatibility mode. So whether you focus on languages changes or how those language changes are implemented, I don't see an enormous difference in kind here. There is something of a difference in degree, but then again, I don't see anyone, especially not GvR, Perl, or Matz, claiming that Python, Perl, or Ruby are as "mature" as C.
Or that it's more fun for the (unpaid) authors to design and innovate than to be maintenance engineers.
I don't know off the head about Wall (or Matz), but last I checked Guido van Rossum was paid by Google, and half of that (by time) is to develop Python. I believe that it was something for which he was paid when he first developed Python, as well.
Then again, whether or not they sell licenses or get a regular paycheck from an employer for work on the language, its certainly not at all the case that the developers of popular OSS languages lack a financial stake in the industrial success of their language. Not only does it have some effect on their own employability in traditional jobs, it is also a source of income for them in consulting, publishing books, etc.
Er, which D language? There appear to be at least six.
Languages like D, Haskell, Python, Perl, Lua, etc are all pretty interesting. but making them a core component of your business seems like a bad idea. The people who put them together are not getting paid by you and don't really care about your company's schedules. Generally you just have to force users of your scripts to install the right version of python/whatever until you can move all your software forward.
Since they are OSS, (except, maybe, D, depending on which "D" you are referring to) you don't have to "force" them to do much but install your software, which is free to include the language implementation it needs. And you can continue to do so, freely (including paying someone for maintenance of the language, its bundled libraries, etc., if you wish) even after whoever originally made the language has discontinued making or supporting the version you want to use, the platform it runs on, or the language entirely. Something you can't do with your average commercial language product.
Any decent editor can automatically indent code for you in any language,
Wrong. Any decent editor can automatically indent code for you in any langauge where the proper indentation can be unambiguously defined by applying a series of rules to some other set of constructs in the language. This works for any language that has an unambiguous block structure even in the absence of any significance given to different whitespace patterns, which is true of lots and lots of languages, but, notably, not Python.
Because the interpretation of the block structure of Python relies on indentation, a Python editor can't automatically indent properly. Sure, as you are typing, it can give you a guess at where you might want to indent the next line that you only have to shift-tab or tab to get to where you do want it (and it can automatically handle tab->space conversion, etc.), but it can't automatically indent code that isn't already indented properly.
and in this case Python is even easier because all it uses is the indentation, so you don't have to manually add additional delimiters in the appropriate places; just indent as usual.
In a language with structure that is unambiguous before considering the detail of whitespace patterns (e.g., Lisp) and a decent editor, there is no "indent as usual". You just enter delimiters. When you feel like breaking a line, you do so. Your editor indents exactly right every time with no intervention. The only time you need to do anything manually to indent is after a cut and past operations, or after manually doing something that destroys the existing indentation for some reason, and all you need to do then is to tell your editor to automatically indent the line or region of code, and your are back to okay.
So, no, Python doesn't take away the need for delimiters and keep the same burden on indentation, it trades the burden of putting in and preserving the right delimiters for the burden of putting in and preserving the right indentation.
Copying and pasting code in any language requires you to reindent it just as much as with Python, lest it become an unreadable mess,
Copying and pasting code in a language that is structurally unambiguous before considering indentation, using a decent editor, requires telling the editor to automatically indent the block of pasted-in code. Usually that's selecting the code and and then hitting one keyboard shortcut. (Conceptually, an editor could be configured to automatically indent on an paste operation, but I don't immediately recall any that are by default.)
Copying and pasting code in a language where block structure is indicated by indentation alone usually requires selecting the code and then manually adding or deleting the right number of indentation steps to match the intended meaning of the code. This isn't a lot more burdensome, but it is clearly at least slightly more burdensome.
Does anyone else here remember the Turbo Pascal 3.0 -> 4.0 upgrade fiasco? There were supposedly (3rd party, I think) applications that would look at your TP 3.0 code and upgrade it to 4.0. None of them worked, of course.
Um, Python 3.0 is already out in alpha, and the conversion tool is available. Rather than fearmongering based on something that happened with a different language, in the 1980s, when the tools were 3rd party rather than part of the release of the new version, why not look for some evidence that the conversion tool at issue doesn't actually work to criticize it?
Why would anyone consider even using python for the next few years... sounds like someone just killed python to me!
Uh, why?
Its not like the 2.x branch is stopped, or as if their isn't an automatic transition tool. And its not like Perl6 and Ruby 1.9 aren't also backward-incompatible releases, too. (Perl6 likewise has a conversion tool.) Progress sometimes means abandoning some backwards-compatibility.
Depending on who you talk to, this can be said to be backward compatible.
At least the first form of "backward compatibility" mentioned (a translator for most older code) is also available (or a planned feature) for Python 3.0.
Slashdot Mirror
Since P2P filesharing is legal (though sharing particular files may not be), and there are no other alternatives with the same features, this seems to be nonsense.
No, clearly, few technologies grow to maturity in industries like that. They are fire-tested and develop in industries that can take the risk of experimentation, and then they are adopted by those industries once they are proven. So, yeah, XML is going to be around for a while, even if JSON, YAML, or something like it may displace it for many uses (including highly-sensitive ones) in the long run.
That said, I don't see a lot of intrinsic advantages XML has over YAML (JSON's slightly bigger brother); most of its current advantages are in the domain of tool support (including auxiliary technologies that are also implemented in XML). But JSON/YAML, the longer and more widely they are used, are going to grow a lot of that support, too, and narrow the gap.
S-expressions don't "lack unicode character support"; generic S-expressions are encoding neutral. What generic S-expressions lack is a specified mechanism for specifying encoding.
Heh. "Unlimited bandwidth", but if you use "too much" you'll be "flagged". IOW, Yahoo! has just joined the long-tradition of "unlimited" hosting services where "unlimited" means "we won't tell you up front what the limits are, but they sure exist, and you'll sure be nailed for breaking them."
Better off getting an account where the limits are disclosed, and you can pay to get them raised.
Not really, even in the relation between JSON and JavaScript and the relation between S-Expressions and Lisp. JSON is a subset of JavaScript, and S-Expressions are a superset of Lisp.
JSON doesn't rely on having JavaScript on either end. Particular applications or libraries that use JSON, either in JavaScript or otherwise, may have security errors due to design of those libraries or applications, but JSON itself does not have a security problem, and if it did, it could not be due to a JavaScript design error since JSON can be used without JavaScript ever touching it.
And it may be true that JavaScript doesn't have an accessible (to user code) "reader" for arbitrary JavaScript as part of the core language. However, there are JSON parsers (including one on the JSON website) for JavaScript that don't rely on eval (as well as the ugly hacks that try to detect "evil" in the JSON and then call eval if they think the JSON is "safe"). Using a JSON parser rather than eval addresses the security concerns; any security problems are not the fault of either the design of JSON or the design of the JavaScript language, tehy are the fault of the design of the application.
XML Schema may let the other end validate it, but it doesn't let the other end make sense of it. The other end can only make sense of it if they've got code written to handle the kind of data it contains: which is true, really, of any data format.
"You might feel better..." -> "No, it wouldn't..."? WTF is that supposed to mean? How is taht even a response to what precedes it?
"JSON is..." -> "XML does much more than that." Again, this is incoherent. XML is simply tree-structured markup. It has less inherent semantic content than JSON/YAML. OTOH, JSON/YAML can do a lot more than what it is, just as XML can. Both JSON/YAML and XML can present pretty arbitrary data in manner which is fairly easy to parse automatically and fairly readable. XML strengths, IMO, is that its a more natural format for text-centric markup, and that it has a lot more maturity in the available tools and applications.
The point is, though, JSON doesn't force JavaScript on anyone.
That's kind of a dumb point to make without any discussion about which those areas are; as discussed above, the areas I see where XML is intrinsically superior are fairly narrow, though its currently probably better for lots of projects simply because its been established longer and has better tool support.
You missed the point again. Sure, there are other programming languages out there. The fact that there are JSON libraries for many of them underlines that the argument "JSON is forcing JavaScript on everyone" is false. JSON is an interchange format. It may be inspired by JavaScript, but it isn't forcing JavaScript on anyone.
But, yeah, S-expressions are great.
Since I didn't say "there are libraries to use JSON, so why use XML", but "there are libraries to use JSON from other languages, so JSON isn't forcing JavaScript on anyone", I think you miss the point. Anyone, real Lispers are more likely to say that "there are libraries to read/write S-expressions, so why use XML, which is essentially a more verbose but no more expressive or clear variant of S-expressions?*"
S-expressions are not "nesting lists of strings".
And, very often, a markup language inherently isn't a natural fit to data interchange requirements. JSON/YAML are both motivated by that specific fact. In fact, but for XHTML and office document formats, I've rarely seen an application where XML was used where a markup language was a really natural tool to start with. XML is popular because its a hammer that everyone's gotten really comfortable using, so every data interchange need is treated as if it were a nail, whether or not its actually a nail, a screw, or glue-on wallpaper.
This is certainly a limitation in JSON/YAML tool support. I don't think its an inherent limitation in the formats: either has
Its perfectly fair, since they are often alternatives for the same use.
No, it really doesn't, but if "JavaScript" in the name bothers you, you might feel better with YAML.
And there are JSON and/or YAML libraries for quite a lot of them. So what?
JSON/YAML is/are better (not considering, of course, the variety and maturity of available tools; but then, perhaps, you don't always need most of what is out there in XML tools, either) for lots of things (mostly, the kinds of things TFA notes XML wasn't designed for and often isn't the best choice for),things that aren't marked-up text. Where you actually want an extensible language for text-centric markup, rather than a structured format for interchange of something that isn't marked-up text, XML seems to be a pretty good choice. Of course, for some reason, that seems to be a minority of the uses of XML.
The cabin of a car with direct sunlight with the windows closed can reach air temperatures upward of 130F with surfaces exposed to sunlight temperatures close to 200F.
Its highly unlikely that the battery of any electric vehicle will be located in the passenger cabin, or exposed to the kind of temperature extremes one would find in the cabin when the car is left in direct sunlight with the windows closed.
Also, Li-Ion batteries designed for electric cars and other large-scale applications use an different cathode materials that reduce temperature sensitivity and increase lifespan, at the cost (compared to the kind of batteries you'd find in, say, a laptop) of decreased energy density.
See, this is one of many places the use of "developing" as a euphemism for "less-developed" falls apart. Even if, in the general case, it were reasonable to describe most less-developed countries as "developing" (that is, approaching the level of development in the more advanced countries), it clearly isn't a good way to describe the regress of the most developed country of the world.
(And, really, "developing" isn't a good description for LDCs in the general case, either; while some are narrowing the gap the the most advanced countries, very many are developing, if at all, more slowly than the most advanced countries and falling farther behind; calling them "developing" countries is a misleading euphemism that obscures the real conditions.)
Seems like it could be fairly common (and potentially shaving a lot more than "milliseconds" off individual queries) in an OLAP environment. Not as common or useful, I would presume, in most OLTP environments.
It seems to me a focus of Stallman's approval of the OLPC is freedom, particularly software but also hardware, throughout the system.
Now, it seems to me that that is pretty much Stallman's area of specialty.
But Python doesn't allow an editor to automatically correctly indent as you type, either; all an editor can give you is the most-likely indentation point (the last line's indentation normally, one indent level in if you use an "if [...]:" or some similar statement that introduces a block.) With a language that has an unambiguous block structure defined by delimiters, the editor can correctly indent as you type, not merely give you the most likely indentation. The effects are superficially similar, but not the same.
Yes, if you happen to want to insert the pasted text at the current indentation level. Which you may or may not. Because the same text could be pasted at different indentation levels and still be legitimate code (with different meanings), the general case is that you have to do that, and then sometimes adjust by one indentation level in one direction or the other (most likely, if an adjustment is needed, it will be one level out.)
With a language whose block structure is carried by delimiters, as long as you copy the right source code (including the beginning and/or ending delimiters, as appropriate), its always simply an "autoindent" on the region and you are in the right place. With Python, the source code copied doesn't carry enough information to unambiguously determine the correct indentation level, so its not possible to have a one-step, always-correct mechanism to correct the indentation.
The tab (or spaces) in Python are not block delimiters. They are per-line block-level markers, which are not, at all, the same thing, though of course there is a direct conversion between code in which blocks are indicated with block-level-markers and otherwise-syntactically-identical code in which blocks are indicated with delimiters (which is why languages with regular, unambiguous delimiters can be automatically indented by editors.)
Perhaps you should reconsider that criticism after thinking about the difference between "Cut" and "Copy", and thinking about what the most natural way is to move a large block of already-written code that would otherwise need to be repeated from the inside of one function out into into its own function without creating more lines to maintain.
If not maintaining compatibility is the "death knell", then Ruby is eliminated (1.9 isn't backward compatible with 1.8.x), too.
If I did, that wouldn't be a strawman, it would be a bad analogy. I wasn't saying you argued that C90 -> C99 said something about C, I was saying your argument suggested that by analogy.
OTOH, I didn't "ignore" that since it is not true. C99 makes illegal constructs that were legal in C90. Since the Perl6 primary implementation can also run Perl5 code even though Perl5 code is not valid Perl6, I don't see how that is substantially different from the fact that most practical C99 implementations are likely to have options to allow the illegal C90 constructs (and, conversely, most C90 implementations probably warned on them in the first place), though they are strictly-speaking not valid C99. Both language updates break existing code. Both have workarounds in the implementations people are likely to use which make the fact that the language update breaks existing code almost completely irrelevant.
So, C90 -> C99 provided that C was never that mature to begin with? Sure, most implementations probably work around the compatibility issues in most cases, with appropriate options; then again, Perl and Python both have automatic conversion tools, and the former at least as a compatibility mode. So whether you focus on languages changes or how those language changes are implemented, I don't see an enormous difference in kind here. There is something of a difference in degree, but then again, I don't see anyone, especially not GvR, Perl, or Matz, claiming that Python, Perl, or Ruby are as "mature" as C.
I don't know off the head about Wall (or Matz), but last I checked Guido van Rossum was paid by Google, and half of that (by time) is to develop Python. I believe that it was something for which he was paid when he first developed Python, as well.
Then again, whether or not they sell licenses or get a regular paycheck from an employer for work on the language, its certainly not at all the case that the developers of popular OSS languages lack a financial stake in the industrial success of their language. Not only does it have some effect on their own employability in traditional jobs, it is also a source of income for them in consulting, publishing books, etc.
Er, which D language? There appear to be at least six.
Since they are OSS, (except, maybe, D, depending on which "D" you are referring to) you don't have to "force" them to do much but install your software, which is free to include the language implementation it needs. And you can continue to do so, freely (including paying someone for maintenance of the language, its bundled libraries, etc., if you wish) even after whoever originally made the language has discontinued making or supporting the version you want to use, the platform it runs on, or the language entirely. Something you can't do with your average commercial language product.
Wrong. Any decent editor can automatically indent code for you in any langauge where the proper indentation can be unambiguously defined by applying a series of rules to some other set of constructs in the language. This works for any language that has an unambiguous block structure even in the absence of any significance given to different whitespace patterns, which is true of lots and lots of languages, but, notably, not Python.
Because the interpretation of the block structure of Python relies on indentation, a Python editor can't automatically indent properly. Sure, as you are typing, it can give you a guess at where you might want to indent the next line that you only have to shift-tab or tab to get to where you do want it (and it can automatically handle tab->space conversion, etc.), but it can't automatically indent code that isn't already indented properly.
In a language with structure that is unambiguous before considering the detail of whitespace patterns (e.g., Lisp) and a decent editor, there is no "indent as usual". You just enter delimiters. When you feel like breaking a line, you do so. Your editor indents exactly right every time with no intervention. The only time you need to do anything manually to indent is after a cut and past operations, or after manually doing something that destroys the existing indentation for some reason, and all you need to do then is to tell your editor to automatically indent the line or region of code, and your are back to okay.
So, no, Python doesn't take away the need for delimiters and keep the same burden on indentation, it trades the burden of putting in and preserving the right delimiters for the burden of putting in and preserving the right indentation.
Copying and pasting code in a language that is structurally unambiguous before considering indentation, using a decent editor, requires telling the editor to automatically indent the block of pasted-in code. Usually that's selecting the code and and then hitting one keyboard shortcut. (Conceptually, an editor could be configured to automatically indent on an paste operation, but I don't immediately recall any that are by default.)
Copying and pasting code in a language where block structure is indicated by indentation alone usually requires selecting the code and then manually adding or deleting the right number of indentation steps to match the intended meaning of the code. This isn't a lot more burdensome, but it is clearly at least slightly more burdensome.
Um, Python 3.0 is already out in alpha, and the conversion tool is available. Rather than fearmongering based on something that happened with a different language, in the 1980s, when the tools were 3rd party rather than part of the release of the new version, why not look for some evidence that the conversion tool at issue doesn't actually work to criticize it?
Uh, why?
Its not like the 2.x branch is stopped, or as if their isn't an automatic transition tool. And its not like Perl6 and Ruby 1.9 aren't also backward-incompatible releases, too. (Perl6 likewise has a conversion tool.) Progress sometimes means abandoning some backwards-compatibility.
At least the first form of "backward compatibility" mentioned (a translator for most older code) is also available (or a planned feature) for Python 3.0.