Yeah, I see things on that order of complexity in Ruby, too. But to me, that's pretty much the same level as a swap; each of those cases is destructuring a simple, non-nested sequence (either an express sequence or one generated by a function call that returns a sequence) on the rhs into multiple variables on the lhs. Its not the kind of nested nightmare that the (deliberately unusually involved) example the The Ruby Programming Language used.
What I was saying is that beyond the simple, non-nested cases, it doesn't seem to be common in Ruby, not that no one uses multiple assignment.
Ruby performance sucks. It is impossibly slow, even compared to languages like Perl or Python. I make no excuses for that. Look at the performance improvements of rails 1.9, and you'll get an idea of just how bad 1.8 is.
Clearly, you mean Ruby 1.9 vs. Ruby 1.8. Rails went from 1.2 to 2.0. Ruby went from 1.8 to 1.9, and in that step also switched to a bytecode compiler/VM (YARV) for a big performance improvement.
Much of the criticism I've read in the past few months about Rails is related to problems with how the public Rails API is designed and how too many developers are using runtime hacks to extend objects instead of having sane, language-specific inheritance/override methods for extension purposes. Again, nothing to do with Ruby the language
Actually, the absence of features for explict overriding (vs. implict overrides as the default) is something to do with Ruby the language (just like dynamic rather than static typing, etc. are inherent to Ruby as a language.)
OTOH, the complaints about "monkeypatching" are pretty much just a variation on the complaints about dynamic typing: "the language doesn't bind your hands enough, and someone else might do (or has done) something I don't like that was enabled by that."
Fine, look, everyone knows where to find Java and C if they need them. Beyond that, if you don't like the way the Rails team (or certain third-party plug-in writers) have used the power to reopen classes and objects, its not like there aren't plenty of other Ruby web application frameworks, ORM solutions aside from ActiveRecord, and libraries available for most uses in Ruby. Maybe the one library you really want was programmed by someone whose ideas about how best to use the language don't match yours, but that's possible with any language no matter what features it has. If you want code written to your specs, you've either got to write it yourself or pay someone else to do it for you, and complaining about a language because someone has used it to write a library using techniques you don't like isn't going to solve anything.
but you can't reall discuss Ruby without Rails because in the real world it's what currently drives its adoption.
I dunno, I find it pretty easy to discuss Ruby without Rails. Rails is certainly the framework that made Ruby really visible in the US (though I gather it was fairly popular in Japan even before Rails), but I think that as it is getting exposed, the size of the non-Rails Ruby community compared to the Rails segment is probably growing.
I doubt many people are writing desktop apps with it.
I would imagine that if there weren't quite a few people doing that, you would have fewer GUI toolkits for it. And, of course, its also useful for system scripting; not every programming task is about a big app, whether web or desktop.
Once you learn python you ain't gonna get past hello world in ruby. You will sit there, look at the syntax and say what the hell do I want to learn this for.
I learned Python pretty much immediately before learning Ruby, and I personally find Ruby more attractive, from a syntactic perspective, even before considering Python's interesting use of whitespace, which doesn't bother me as much as it does some people, but still isn't as attractive to me as it appears to be to Python fans.
I was reading along today when I came to this: "Assignment to a constant that already exists causes Ruby to issue a warning. Ruby does execute the assignment, however, which means that constants are nor really constant." Now this is a bit of a surprising statement. Isn't this an elephant in the room?
In the context of Ruby, where "private" methods and instance variables are just a wee bit harder to get at rather than actually private, not enormously, though it would probably be cleaner (and consistent with how private methods, etc., are handled) if a "normal" assigment to an assigned constant raised an error, but there was a special method call that could be used to get around it.
Shouldn't it get more of an explanation?
What else is there to say to explain it? I mean, I could see providing an example where taking advantage of the fact that it only produces a warning rather than blowing up might be useful (if you can construct one), but as far as explaining, what more is there to say?
A few pages further on, while discussing parallel assignment, we get this: "a,(b,(c,d)) = [1,[2,[3,4]]] # Parens: a=1; b=2;c=3;d=4". Now I can figure out what is happening and what the book is trying to explain. But at the same time the book seems to ignore a second elephant in the room. Why in the world would someone ever write just a difficult to comprehend statement?
I would guess the only reason for anything that complicated in a multiple assignment would be because the author was writing a book using a needlessly complicated case to illustrate how the feature functioned so that people could understand the feature, even though they would never, ever, use it that way in practice.
At least, I hope so.
Is is a common Ruby idiom?
I've rarely seen a multiple assignment much more complex than the simple swap case ("a, b = b, a") in Ruby; I don't think anything remotely like that example is common.
As I think back on what I've read by David, and I realize I'm sort of leaving Matz out right here and don't know how much of the writing is his, I think I see a sort of matter of factness to it. My recollection of Ruby for Rails is that it is much more interested in explaining some of the odder parts of Ruby and Rails. Perhaps the authors just prefer a matter of fact style and figure that readers can go elsewhere for a explanation of what seem to me to be rather odd elements of Ruby?
As I recall, K&R is pretty matter-of-fact, too, and that's what the authors held out as their model. Really, I'm glad that The Ruby Programming Language is different in its tone and approach from The Ruby Way, Programming Ruby, and Ruby for Rails, because we already have those books, and they do what they do pretty well.
It would be faster until some guy arrives 5 minutes later then everyone else and has to go through security and get on the plane, because of the order everyone would have to stop, let him through, reorganize and then go through.
That depends on implementation; any workable implementation, I would think, would be to have a cutoff at which you begin organizing people to board, anyone who arrives once that process begins risks not being able to get on the plane. Sure, some people would miss flights that otherwise wouldn't, but any boarding system leaves you with an ultimate cutoff at which you are too late and can't board.
(If it were adopted universally, and you actually scanned boarding passes in the security line, you could divert people that were too late at that point, and also track who had arrived so that a place could be held for people who hadn't arrived at the gate, but had crossed security, when pre-boarding organization started, since if they didn't arrive in time to join the queue and board, the queue could just be collapsed around their spot harmlessly.)
Of course, another alternative is to combine this method with not having reserved seating, in which case where you sit is determined by arrival order. You've got some issues with, e.g., the emergency exit rows, but you could deal with that, for instance, by having people ineligible or unwilling to sit in those rows not join the boarding queue until those seats have been filled, and then take the next available spots in the queue. Then late arrivals (as long as the plane is still boarding) aren't a problem, they just get the next seat in line.
The Ruby Programming Language is a great book, from what I've seen of it (I've read a bit on Safari), but I still like Programming Ruby (and The Ruby Way and Ruby for Rails -- a great general Ruby book that doesn't have as strong a Rails focus as the name might suggest -- even though neither of those two has yet been updated for 1.9), too. I wouldn't particularly want to do without any of them, though if I had to choose only one right now, I might lean toward The Ruby Programming Language. But, fortunately, I don't have to choose only one.
The Ruby Programming Language is a slim, more manageable 444 pages and, in contrast, is the only one to cover Ruby version 1.9.
This is true of the dead-tree editions of the three major books you list, though it may be worth noting that the 3rd Edition of the Pickaxe (Programming Ruby) is currently available (in PDF) as a beta book and covers Ruby 1.9.
Ruby isn't lightning fast, but its fast enough for lots of things, and its easy enough to interface with C (if you're using the main implementation) or Java (if you are using JRuby) if you need to refactor identified bottlenecks in a lower-level, higher-speed language.
As to scalability, I don't know of any particular problems with Ruby there. Green threads pre-1.9 and a Python-style GIL in 1.9 limit the ability to benefit from SMP architecture in one process on the one side, but the standard library comes with some fairly useful distribution tools. Is not, say, Erlang or Oz, but then neither is Java.
What, it's good for RAD you say? Use something like http://wavemaker.net/ and get RAD with Java.
WaveMaker seems to offer a Web application framework and a visual builder for web apps that is tightly tied to that framework. This might be a viable Java alternative to Rails for some web applications, but its certainly not a general alternative to Ruby. And its suggests that your scalability complaint is probably similarly a misplaced reference to the various complaints (the main and most frequently cited one of which was retracted by the people making it) about the scalability of Rails, for which there are many alternatives even within the Ruby universe (Waves, Camping, Nitro, Sinatra, Wuby, etc.)
There are stories aplenty about how Sony paid hundreds of millions of dollars to the movie studios to get them to switch.
AFAIK, what all those stories share is that they lack any evidence or named sources, and in many cases overtly cite the speculation of unnamed "analysts" both on the existence and amount of the payoffs.
Not really, they used to be reasonably, though not outstandingly, popular. That stopped not because US consumers stopped liking "diesel cars", per se, but because the US has been slow to mandate low-sulfur diesel fuels, and many states' emission standards for passenger cars made it illegal to sell diesel cars because of the sulfur emissions that were a consequence of the fuel used. So, most automakers (US and import) don't sell diesel cars anywhere in the US, because they have a strong preference for selling 50-state cars.
You want a good looking computer that peforms well and you can delegate the fixes to the manufacturer?
Given the level of support provided on most consumer computers (business support may be better), I'm not sure "delegate the fixes to the manufacturer" is a substantial practical benefit available to most purchasers in any case.
HD BlueRay on a 19" screen?!? I cant see the difference on my 32" screen... talk about overkill
This comment only makes sense if you sit as far away from your laptop as you would from the 32" screen, or at least far enough away that the 19" screen occupies less of your visual field than the 32" screen would at the distance you typically view it.
That seems rather unlikely, unless you typically sit unusually close to your 32" screen or use your laptop from an unusually great distance.
Why on earth would you need to watch a High Def movie on your laptop? Laptop screens are so tiny.
Laptop screens are also much closer to your eyeballs in normal use than typical living-room TV distance. The useful resolution (that is, the resolution that isn't wasted because you can't make out the detail) of a laptop screen is probably at least as great as the typical living room HDTV.
Even if you are using your laptop to play a movie on a bigger screen, like your 1080p 52 inch TV, I would assume there would be a power outlet near by.
That, OTOH, is a good point. Conversely, presumably having a Blu-ray drive won't shorten your battery life when not playing Blu-ray movies, so there doesn't seem to be a real downside here. You are adding a feature (playing back Blu-ray movies) that, when used, limits the use of a laptop from battery power. But laptops, IME, are frequently used running off wall power in the role that used to be taken, years ago, by "lunchbox" portables, as well as on battery power for complete freedom. So even if it just gives you a new feature that can only be used on wall power, its a useful new feature for some segment of the market. And, you know, for people who aren't willing to pay for that, there will probably continue to be laptops with regular DVD drives and without optical drives at all.
Category three users are much more likely to report n00b questions than actual bugs/missing features.
Places where novice users fail to understand the OS (including the relation of the OS to non-OS components) given the existing presentation are actual bugs and missing features, presuming those users are in the group Ubuntu is trying to reach.
The Bible says that God created the world in 7 days (rested on the 7th), but does not define what a day is.
Look, one can choose to view Genesis figuratively rather than literally, but its pretty clear that each of the days of creation consisted ofan evening and a morning. I suppose you could say, well, the Bible doesn't say what an evening and a morning are, but then you are getting to the point where any finite set of words can literally mean anything because at some point you are going to run into something that isn't defined except perhaps in terms of itself.
If you want to say that, as a Christian, you have no trouble taking Genesis figuratively rather than literally, say that, but trying to argue that there is wiggle room because it doesn't define what the "day" it is referring to in each day of creation means is hard to defend, since it does. And, anyhow, its hard to take Genesis literally, since it offers two different sequences of creation.
Five years ago, we were talking about using Terabit Ethernet in 2008. Those plans have been pushed back a bit, but Ethernet inventor Bob Metcalfe this week is starting to throw around a new date for Terabit Ethernet: 2015.
So, 5 years ago, Tb-E was 5 years away, and now its 7 years away. So by 2015, it should be about 10 years away, and by 2025 it should be about 14 years away, etc.
But a shotgun buy/sell system as you are proposing dramatically favors those with larger revenue streams and ready cash reserves.
I think that's easily mitigated by not allowing purchase, but allowing any person to tender the declared value (perhaps putting the funds in escrow with the Copyright Office) to force an involuntary transfer to the public domain (perhaps keeping the option to "outbid" the tender by raising the declared price above the tender and paying back taxes on the new declared price, but if you do that, you may want the to allow the tender to be for any value greater than or equal to the declared value, so that someone making a public domain buyout offer can insulate themselves against the copyright holder "outbidding" by raising their declared value by a minimal increment over the previous value.) One variation that might be interesting is to require copyright notice on registered works to include a registration number, and allowing people to make pledges that could be individually less than the declared value through the copyright office to acquire the work for the public domain; once the total of pledges exceeded the declared value, all current pledges would be given a fixed time (say, 30 days) to actually tender funds or have their pledges cancelled.
Nor does your claim of knowledge about 'most US jurisdictions' have any merit whatsoever without at least some evidence.
Look, I'm not trying to convince you of anything. If you choose to believe the contrary, that's fine. I don't really care. What do you expect me to present, citations to all the laws taxing tangible personal property as a class that do not exist? That would be difficult. Of course, if you'd like to point to the laws in US jurisdictions that tax tangible personal property generally, rather than narrow taxes on a specific subset like vehicles, I'd love to hear about them.
I at least went to the effort of posting something more than unsubstantiated opinion.
What you pointed out wasn't even relevant to the issue being discussed, independent of its accuracy, much less the degree of support. A point failing to be relevant is a rather more critical failure than a relevant point failing to be supported.
Cool idea, but you need way to keep in account the inflation.
If the rate of inflation takes a significant bite out of the increase in a fee that doubles every year, you've got enormous fundamental economic problems to deal with and details of copyright management scheme are the least of your concerns. You might want to adjust the base $0.01 rate for new works for inflation (or just double it every 15-20 years, which keeps the progression the same and just changes the starting point), but you don't really need to do anything else.
I'm not saying its necessarily a great plan, but inflation doesn't really do much to it.
Might want to talk to various state and local governments and their DMV departments.
I might not. As I pointed out in an earlier post in this thread, vehicle taxes are the one kind of tangible personal property that, in the US, is frequently subject to property taxes. That doesn't change the fact that tangible personal property as a whole is not subject to property taxes (or anything structurally similar) in most US jurisdictions. Nor does it change that merely waving one's hand at a wikipedia article on "ad valorem" taxes fails to rebut the preceding fact.
Slashdot Mirror
Its more succinct (and, to me at least, somewhat more intuitive) to replace this: with this:
Yeah, I see things on that order of complexity in Ruby, too. But to me, that's pretty much the same level as a swap; each of those cases is destructuring a simple, non-nested sequence (either an express sequence or one generated by a function call that returns a sequence) on the rhs into multiple variables on the lhs. Its not the kind of nested nightmare that the (deliberately unusually involved) example the The Ruby Programming Language used.
What I was saying is that beyond the simple, non-nested cases, it doesn't seem to be common in Ruby, not that no one uses multiple assignment.
To bring it back on topic, there is a Ruby continuation-based web application framework (Borges) that is (or began as) a port of Seaside 2 to Ruby.
Clearly, you mean Ruby 1.9 vs. Ruby 1.8. Rails went from 1.2 to 2.0. Ruby went from 1.8 to 1.9, and in that step also switched to a bytecode compiler/VM (YARV) for a big performance improvement.
Actually, the absence of features for explict overriding (vs. implict overrides as the default) is something to do with Ruby the language (just like dynamic rather than static typing, etc. are inherent to Ruby as a language.)
OTOH, the complaints about "monkeypatching" are pretty much just a variation on the complaints about dynamic typing: "the language doesn't bind your hands enough, and someone else might do (or has done) something I don't like that was enabled by that."
Fine, look, everyone knows where to find Java and C if they need them. Beyond that, if you don't like the way the Rails team (or certain third-party plug-in writers) have used the power to reopen classes and objects, its not like there aren't plenty of other Ruby web application frameworks, ORM solutions aside from ActiveRecord, and libraries available for most uses in Ruby. Maybe the one library you really want was programmed by someone whose ideas about how best to use the language don't match yours, but that's possible with any language no matter what features it has. If you want code written to your specs, you've either got to write it yourself or pay someone else to do it for you, and complaining about a language because someone has used it to write a library using techniques you don't like isn't going to solve anything.
I dunno, I find it pretty easy to discuss Ruby without Rails. Rails is certainly the framework that made Ruby really visible in the US (though I gather it was fairly popular in Japan even before Rails), but I think that as it is getting exposed, the size of the non-Rails Ruby community compared to the Rails segment is probably growing.
I would imagine that if there weren't quite a few people doing that, you would have fewer GUI toolkits for it. And, of course, its also useful for system scripting; not every programming task is about a big app, whether web or desktop.
I learned Python pretty much immediately before learning Ruby, and I personally find Ruby more attractive, from a syntactic perspective, even before considering Python's interesting use of whitespace, which doesn't bother me as much as it does some people, but still isn't as attractive to me as it appears to be to Python fans.
In the context of Ruby, where "private" methods and instance variables are just a wee bit harder to get at rather than actually private, not enormously, though it would probably be cleaner (and consistent with how private methods, etc., are handled) if a "normal" assigment to an assigned constant raised an error, but there was a special method call that could be used to get around it.
What else is there to say to explain it? I mean, I could see providing an example where taking advantage of the fact that it only produces a warning rather than blowing up might be useful (if you can construct one), but as far as explaining, what more is there to say?
I would guess the only reason for anything that complicated in a multiple assignment would be because the author was writing a book using a needlessly complicated case to illustrate how the feature functioned so that people could understand the feature, even though they would never, ever, use it that way in practice.
At least, I hope so.
I've rarely seen a multiple assignment much more complex than the simple swap case ("a, b = b, a") in Ruby; I don't think anything remotely like that example is common.
As I recall, K&R is pretty matter-of-fact, too, and that's what the authors held out as their model. Really, I'm glad that The Ruby Programming Language is different in its tone and approach from The Ruby Way, Programming Ruby, and Ruby for Rails, because we already have those books, and they do what they do pretty well.
That depends on implementation; any workable implementation, I would think, would be to have a cutoff at which you begin organizing people to board, anyone who arrives once that process begins risks not being able to get on the plane. Sure, some people would miss flights that otherwise wouldn't, but any boarding system leaves you with an ultimate cutoff at which you are too late and can't board.
(If it were adopted universally, and you actually scanned boarding passes in the security line, you could divert people that were too late at that point, and also track who had arrived so that a place could be held for people who hadn't arrived at the gate, but had crossed security, when pre-boarding organization started, since if they didn't arrive in time to join the queue and board, the queue could just be collapsed around their spot harmlessly.)
Of course, another alternative is to combine this method with not having reserved seating, in which case where you sit is determined by arrival order. You've got some issues with, e.g., the emergency exit rows, but you could deal with that, for instance, by having people ineligible or unwilling to sit in those rows not join the boarding queue until those seats have been filled, and then take the next available spots in the queue. Then late arrivals (as long as the plane is still boarding) aren't a problem, they just get the next seat in line.
The Ruby Programming Language is a great book, from what I've seen of it (I've read a bit on Safari), but I still like Programming Ruby (and The Ruby Way and Ruby for Rails -- a great general Ruby book that doesn't have as strong a Rails focus as the name might suggest -- even though neither of those two has yet been updated for 1.9), too. I wouldn't particularly want to do without any of them, though if I had to choose only one right now, I might lean toward The Ruby Programming Language. But, fortunately, I don't have to choose only one.
It can also be "free" (of marginal financial cost) if you subscribe to Safari.
This is true of the dead-tree editions of the three major books you list, though it may be worth noting that the 3rd Edition of the Pickaxe (Programming Ruby) is currently available (in PDF) as a beta book and covers Ruby 1.9.
Ruby isn't lightning fast, but its fast enough for lots of things, and its easy enough to interface with C (if you're using the main implementation) or Java (if you are using JRuby) if you need to refactor identified bottlenecks in a lower-level, higher-speed language.
As to scalability, I don't know of any particular problems with Ruby there. Green threads pre-1.9 and a Python-style GIL in 1.9 limit the ability to benefit from SMP architecture in one process on the one side, but the standard library comes with some fairly useful distribution tools. Is not, say, Erlang or Oz, but then neither is Java.
WaveMaker seems to offer a Web application framework and a visual builder for web apps that is tightly tied to that framework. This might be a viable Java alternative to Rails for some web applications, but its certainly not a general alternative to Ruby. And its suggests that your scalability complaint is probably similarly a misplaced reference to the various complaints (the main and most frequently cited one of which was retracted by the people making it) about the scalability of Rails, for which there are many alternatives even within the Ruby universe (Waves, Camping, Nitro, Sinatra, Wuby, etc.)
AFAIK, what all those stories share is that they lack any evidence or named sources, and in many cases overtly cite the speculation of unnamed "analysts" both on the existence and amount of the payoffs.
Not really, they used to be reasonably, though not outstandingly, popular. That stopped not because US consumers stopped liking "diesel cars", per se, but because the US has been slow to mandate low-sulfur diesel fuels, and many states' emission standards for passenger cars made it illegal to sell diesel cars because of the sulfur emissions that were a consequence of the fuel used. So, most automakers (US and import) don't sell diesel cars anywhere in the US, because they have a strong preference for selling 50-state cars.
Given the level of support provided on most consumer computers (business support may be better), I'm not sure "delegate the fixes to the manufacturer" is a substantial practical benefit available to most purchasers in any case.
This comment only makes sense if you sit as far away from your laptop as you would from the 32" screen, or at least far enough away that the 19" screen occupies less of your visual field than the 32" screen would at the distance you typically view it.
That seems rather unlikely, unless you typically sit unusually close to your 32" screen or use your laptop from an unusually great distance.
Laptop screens are also much closer to your eyeballs in normal use than typical living-room TV distance. The useful resolution (that is, the resolution that isn't wasted because you can't make out the detail) of a laptop screen is probably at least as great as the typical living room HDTV.
That, OTOH, is a good point. Conversely, presumably having a Blu-ray drive won't shorten your battery life when not playing Blu-ray movies, so there doesn't seem to be a real downside here. You are adding a feature (playing back Blu-ray movies) that, when used, limits the use of a laptop from battery power. But laptops, IME, are frequently used running off wall power in the role that used to be taken, years ago, by "lunchbox" portables, as well as on battery power for complete freedom. So even if it just gives you a new feature that can only be used on wall power, its a useful new feature for some segment of the market. And, you know, for people who aren't willing to pay for that, there will probably continue to be laptops with regular DVD drives and without optical drives at all.
Places where novice users fail to understand the OS (including the relation of the OS to non-OS components) given the existing presentation are actual bugs and missing features, presuming those users are in the group Ubuntu is trying to reach.
Look, one can choose to view Genesis figuratively rather than literally, but its pretty clear that each of the days of creation consisted ofan evening and a morning. I suppose you could say, well, the Bible doesn't say what an evening and a morning are, but then you are getting to the point where any finite set of words can literally mean anything because at some point you are going to run into something that isn't defined except perhaps in terms of itself.
If you want to say that, as a Christian, you have no trouble taking Genesis figuratively rather than literally, say that, but trying to argue that there is wiggle room because it doesn't define what the "day" it is referring to in each day of creation means is hard to defend, since it does. And, anyhow, its hard to take Genesis literally, since it offers two different sequences of creation.
So, 5 years ago, Tb-E was 5 years away, and now its 7 years away. So by 2015, it should be about 10 years away, and by 2025 it should be about 14 years away, etc.
I disagree. The only thing equivalent to the public domain is the public domain.
I think that's easily mitigated by not allowing purchase, but allowing any person to tender the declared value (perhaps putting the funds in escrow with the Copyright Office) to force an involuntary transfer to the public domain (perhaps keeping the option to "outbid" the tender by raising the declared price above the tender and paying back taxes on the new declared price, but if you do that, you may want the to allow the tender to be for any value greater than or equal to the declared value, so that someone making a public domain buyout offer can insulate themselves against the copyright holder "outbidding" by raising their declared value by a minimal increment over the previous value.) One variation that might be interesting is to require copyright notice on registered works to include a registration number, and allowing people to make pledges that could be individually less than the declared value through the copyright office to acquire the work for the public domain; once the total of pledges exceeded the declared value, all current pledges would be given a fixed time (say, 30 days) to actually tender funds or have their pledges cancelled.
Look, I'm not trying to convince you of anything. If you choose to believe the contrary, that's fine. I don't really care. What do you expect me to present, citations to all the laws taxing tangible personal property as a class that do not exist? That would be difficult. Of course, if you'd like to point to the laws in US jurisdictions that tax tangible personal property generally, rather than narrow taxes on a specific subset like vehicles, I'd love to hear about them.
What you pointed out wasn't even relevant to the issue being discussed, independent of its accuracy, much less the degree of support. A point failing to be relevant is a rather more critical failure than a relevant point failing to be supported.
If the rate of inflation takes a significant bite out of the increase in a fee that doubles every year, you've got enormous fundamental economic problems to deal with and details of copyright management scheme are the least of your concerns. You might want to adjust the base $0.01 rate for new works for inflation (or just double it every 15-20 years, which keeps the progression the same and just changes the starting point), but you don't really need to do anything else.
I'm not saying its necessarily a great plan, but inflation doesn't really do much to it.
I might not. As I pointed out in an earlier post in this thread, vehicle taxes are the one kind of tangible personal property that, in the US, is frequently subject to property taxes. That doesn't change the fact that tangible personal property as a whole is not subject to property taxes (or anything structurally similar) in most US jurisdictions. Nor does it change that merely waving one's hand at a wikipedia article on "ad valorem" taxes fails to rebut the preceding fact.