I don't know the details of the story of the IEEE Scheme standards, but the RnRS document series are the traditional community definition of the language. One of these (R3RS?) served as the basis for the submitted and approved IEEE standard, but there's been a few RnRS documents since, and those are the ones that people in the scheme community actually care about.
Note that I didn't say that stanrdard threading and exception handling facilities should be implemented in terms of call/cc. I said they should be implementable in terms of it. The let forms are implementable in terms of lambda, but they typically aren't implemented in terms of it. Threading and exception handling can be implementation primitives without being language primitives.
The point is that such a design makes the language simpler.
Those are good things to have some standard way of doing, yes, but they don't actually support the point you made: "reducing the number of primitives by creating a can of worms like CALL-CC is not good design."
Why so? Because you can have it both ways: you can have call/cc as a language primitive, plus standard threading and exception facilities implementable with macros on top of call/cc. (And if you look at R5RS, you'll see that this approach is already taken for large parts of the language; the standard demonstrates how to define, for example, let, in terms of lambda and macros.)
;;; ;;; Macro to increment a variable by one. ;;; ;;; Usage: ;;; ;;; (define a 5) ;;; (inc! a) ; a is now 6 ;;; (define-syntax inc! (syntax-rules () ((inc! x) (set! x (+ x 1)))))
Not that idiomatic Scheme code will do this very often. Langauges like Java or C use "++a" most often for loop indexes. Looping in Scheme is typically driven off data structures.
But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.
Lisp syntax certainly does not attempt to look like the combination of English text and mathematical formulas that most languages shoot for, but this in fact has many advantages. The idea of making a language look like that doesn't change the fact that the language will work in a way very different from English or mathematical notation; your previous knowledge of those things will not necessarily help you reason about your code, and at worst, may confuse newcomers by tempting them to apply analogies that don't hold. And to achieve that "look" for your language, you always end up giving it a really complex and inflexible syntax, whose users are not going to have any systematic knowledge of. (Do you know many people who can give you a BNF grammar for Java, or tell you the exact precedence rules for it?)
Lisp makes no pretence at looking like English or mathematics. You're certainly expected to understand the syntax rules of the language more than in "friendlier" ones, but these rules are far, far simpler, and you can actually reason them through. Remember, Scheme oooks regularly include a section that shows you how to write a Scheme interpreter in one page of Scheme code; basic knowledge of how Scheme itself works is considered to be elementary Scheme knowledge.
That is, what I'm saying is that compared to other languages, Lisp dialects demand that you understand the language itself far more, but this is a good thing, which will make you program way better. Why? Because you're going to be able to reason about the execution of your program far better than your average Java programmer.
If you are too embarrassed to have others know you do something, do not do it. If you will do it anyway, stop being embarrassed about it.
That's a really uninsightful thing to say. The power to selectively disclose or withhold information about yourself from others is crucial to your ability to play various social roles, because you have no control over which information about yourself may wrongly discredit you in the eyes of which other people. Being unembarrassed about doing something that most people object to can be good for your personal psychological state, but that will not protect you when somebody, because of it, say, denies you a job you are perfectly qualified to do.
And please don't start with some individualistic bullshit about how none of this matters as long as you feel good about yourself, because being denied major oportunities for reasons that should be irrelevant can be a pretty crushing experience, and you should never overestimate your ability to come emotionally unscathed out of such situations.
Consider the way every object can implement a fallback method that is called if somebody invokes "foo.bar" and bar does not exist in foo. It implies that every single method invocation must be identified by string not a number, and matched by string comparison.
A few people have told you this already in this thread, but I'll put it in a slightly different way.
No, what you said is not true at all. There is a simple technique to avoid that, and that technique is widely used. When you compile the code, whenever you run into a method name, you intern it into a symbol table, and you just emit a pointer to the symbol table entry to your code. Determining whether a class has a method then becomes just a pointer comparison.
In general, to the extent that the method names that may be called at any one time are known at compile time, a compiler can optimize that to use nothing more than a cheap numeric comparison. And at least in the case of Ruby, I do know for a fact that this is done (check out the Symbol class).
The only case in Ruby where you'd need to munch on a string to figure out which method to call is if you're sending the method name as a string to an object, instead of as a symbol. What the language does in that case is convert your string to a symbol, and then use that. If the string is static (and thus known at compile-time), you should have used a symbol literal. If the string is not static, and computed at runtime (and is not otherwise a dumb thing to do security-wise, of course), then if you send the same message repeatedly, you can do the symbol conversion by hand yourself and reuse the result for a performance boost.
Will someone PLEASE explain why a *software* company feels its necessary to enter markets in which it has a competitive disadvantage years after the competition?
Because they judge that they don't have much more room for growth in the software market?
I thought that that was the joke. I hope that we're bright enough to realise it.
You're missing a very important point: if the prevalence of jokes like that contributes to keeping women away from certain opportunities, the intent behind them plays no role in this.
Sure, perhaps the OP was making a very sophisticated joke about sexism. That doesn't mean that its overall effect won't be propping up sexism.
Are you aware that dictionaries are not meant to be philosophically sophisticated authorities, and that citing a dictionary definition does not establish anything at all?
You're forgetting the massive amounts of damage that nice, well-meaning people in all walks of life, who, in the name of "contributing" and/or "helping," inflict upon the world for a variety of reasons, like: (a) they think they know a lot more than they really do; (b) they are really seeking to stroke their own ego, but rationalize it away by telling themselves how selfless they are for offering their awesome help to the whole world for free.
People go on and on about Wikipedia vandals of the crudest sort and how quickly they're caught, but your real murderer of content isn't them; it's the masses of well-meaning, bumbling fools who call themselves "nerds," who "help" by taking carefully-written and well organized articles, and making small "improvements" to them--you know, the article is missing each one of these little irrelevant facts that each one of them just happens to think they know. So each of them opens up the article for edits, and in any old random place, with no regard for organization or narrative flow, they insert the "fact" that they saw was missing. And yay! Now Wikipedia has become a little bit better, all thanks to them! Aren't they such awesome, knowledgeable, generous people!
Take any good article and allow this to happen to it a few times, and it'll become illegible mush, a laundry list of "facts" that just happen to be thrown together.
Rebates are like coupons and generic brands in that they enable retailers to sell the same product at two different prices-- a higher one that you can choose to pay if you want the convenience of not mailing in anything and/or the cache of a name brand, and a much lower one if price matters enough to you to make you clip coupons, mail in receipts or put up with ugly packaging. This is a good thing for everyone involved, because it gives people more options; people choose how much they want to trade convenience for $$, and the company can afford to offer much lower rebate prices because they know everyone won't pay them.
Um, this makes no sense. First of all, IIRC, the point of coupons is to offer an incentive for repeat purchases. If you buy a box of cat food, you get along with it, inside the box, a coupon that gets you a discount on your next box of cat food (applied at the register next time you buy), as long as you buy the same brand. This makes perfect sense; the customer is compensated with a lower price, the company with a stabler cash stream. Or to put it more strongly: even if a seller is offering its product at the lowest rational price for random buyers, it still makes sense for it to offer a better price for repeat buyers, because they provide a definite benefit to the seller.
However, in the bizarre picture you paint above, sellers create artificial barriers to obtaining the lowest rational price they can offer to random buyers. These barriers require you do do things that are irrelevant to the transaction. In exchange for this, the buyer gets the "benefit" of paying the lowest rational price the seller can offer to random buyers. By performing menial crap tasks irrelevant to the transaction at hand, the buyer bypasses the artificial barriers to obtaining the price they should get. In other words, the "problem" the rebates solve is none other than the one they create in the first place.
Also, there's the deceptive practice of the seller's advertising the lowest rational price for a product that they intend to obtain per-unit sales revenues greater than the advertised price. At the very least, by holding on to your money while they "process your application" (i.e., "solve" the "problem" they created for you in the first place), they're getting a 0% interest loan from you, on which they can easily obtain interest (the highest-yielding money market funds are offering about 5% currently).
At its worst, well, if they don't actually intend to give out the rebate to everybody who claims it, then they're even more obviously advertising a lower unit price than the per-unit revenues they have projected. To the buyer, this is a market inefficiency that makes it difficult to obtain the best price, because advertised prices are then not actually true.
The core problem of spelling reform is that English spelling is not random. It's a code that has a dual purpose - as a phonetic reminder (not a purely phonetic encoding) and as an etymological hint.
You went wrong when you assumed that English spelling is guided by a purpose at all. (Nobody sat down and designed it, you know.)
I believe that the richness of multi-contextual information in English spelling brings it closer to the way the words are conceived and stored mentally than any pure phonetic rendering.
And you're a crackpot if you think that the way words are "stored mentally" involves etymology.
Have you ever read prose presented in a dense, spelled out accent? You have to "sound it out" to understand it, and some words may evade parsing until you finally guess them some minutes later. You can't anymore just scan with the eye, and read as fast as you can see.
That means nothing more than that you are familiar with English spelling, and not with whatever idiosyncratic improvised rendering of dialect that you're reading. Which is not surprising, giving that you read English spelling all the time, and only read idiosyncratic dialectal orthographies very infrequently. The idea that you find it easier to read the normal English spelling because it encodes etymology (oh, sorry, I mean, "richness of multi-contextual information"), and not because you're just familiar with it, is, to put it mildly, recherché.
The second one ends in a preposition. A preposition must always have an object.
Either the second statement is false, or many things that you label as "prepositions" in English are mislabeled, because in English sentences may certainly end in words that are customarily called prepositions, as you yourself provide examples of.
Also, contemporary linguists ordinarily label the in in sentences like I went in as an intransitive prepositions--i.e., a preposition without an object. Non-linguists who deceive themselves into believing they know squat about grammar typically complain about this practice, and say that in is an adverb in that sentence. In the end, (a) linguists tend to know what they're doing, while the complainers don't, and (b) whether you call it an "adverb" or an "intransitive preposition" or "word class #237" doesn't make a grammatical difference; what matters is how you group the words together, and that the grouping must respond to classes of words that the grammar of English treats equivalently in some way.
And for reasons I won't explain (though I'll refer people Sag, Wasow and Bender's syntax textbook), because of the rules on how to form English verb phrases, the grouping implied by labeling in an "intransitive preposition" in that sentence is right, and the one implied by labeling it an "adverb" is wrong.
PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0; PDO requires the new OO features in the core of PHP 5, and so will not run with earlier versions of PHP.
Many of PHP's inconsistencies stem from the fact that it is an open source language. While it has likely changed now, many functions were accepted into the source without anyone ensuring a consistent naming scheme, parameter order or behavior. To maintain backward compatibility for what is now a very large user base, this cannot be easily changed at this point.
Even if we granted that the functions can't be easily changed, that's got nothing to do with whether it's open source or not. But of course, I'm not willing to grant that it can't be easily changed. Make the next major version include all the functions as modules you need to load, and perhaps provide an utility to tell upgraders which files require which modules.
Several of the examples of redundant functions are not redundant at all. The escaping functions relate to the specific database they are escaping the data for. Oracle requires that things be escaped differently than MySQL, a single function wouldn't work.
That's a terrible example. What this means is simply that the language doesn't have decent database abstraction facilities (and in fact, PHP is infamous for precisely this). In a well designed database access framework, you specify which kind of database you're connecting to, and the framework picks the appropriate methods for doing all the database flavor-specific stuff. Or in other words, you tell the system "connect to this database" and "escape this string for this connection," and the system figures out, based on the kind of database, what to do.
Where for example is the phone number where a US Citizen may call and have an illegal or undesirable alien (One who is acting badly for those who don't understand) promptly and properly dealt with under law. Where I live, if I call the Sheriff I may see an officer in 1 hour or so depending on the time of day.
Hah, that's a good one: the idea that if your neighbor is playing the stereo too loudly, the government should respond quicker to it if he's Mexican. (And of course, Mexicans are illegal aliens--just look at them!)
Have a good look at many programming languages, which should be very different from each other. Most people who've made lists of languages for you above have failed to do so. Here's what I take is a reasonable one: C, Java, Scheme and Common Lisp, Smalltalk or Ruby, Prolog, ML (either Standard ML or O'Caml), Haskell. You don't need to actually become proficient at writing programs in all of these, but you will benefit enormously from learning the basic ideas of each of them, and what kind of problem they tend to excel on.
There's a few topics in computer science that demand an understanding of many, many different things. My favorite example is database systems; an in-depth understanding of databases requires you to understand hardware, data structures, algorithms, time and space complexity, compilers (for the design and implementation of query languages), facility with higher mathematics and logic (in order to understand things like the relational algebra and calculus), software system architecture and design (to understand why we use dedicated database systems), and many, many more things. Another such topic is compilers; another is AI.
You want to have an understanding of topics like these, and the degree of your understanding thereof is a good measure you can use to gauge your progress. This means that it's good to pick up a couple of textbooks on databases and compilers, to read them through, and to revisit them. Chris Date's database textbook is a good one, and there's others.
Switching to Unicode doesn't help the problem of character encodings.
But what the GP has in mind is not just switching to Unicode, it's using a language implementation that has good Unicode support. This means that strings are internally represented as Unicode, and the language's character I/O libraries handle all conversion between external encodings and the internal representation. This means that program code doesn't do any conversions; all it does is specify a desired encoding when opening a character I/O stream.
This is one of the things that, e.g., Java, does almost perfectly right. (The one dumb flaw is the primitive 16-bit char type.)
Wait a moment - wasn't Ruby authored by a Japanese person? I'd be absolutely stupefied if the language itself doesn't have good built-in multibyte character support.
There's a difference between having "multibyte character support" and what the GP wants, which is clean Unicode support in the language. Ruby does have support for at least Japanese multibyte encodings, but that's different.
The model in question is one that Java comes pretty close to: all of your strings in your language are represented internally as Unicode, with the details of the representation hidden from you. Whenever you do character I/O, then, you specify what external encoding to use, and the language's libraries handle all the conversions for you. You never need to do any explicit character set conversions.
Ruby doesn't do any of this for you. IIRC, there's a command-line switch for making it internally represent strings in multibyte for using Japanese-specific encodings, and if you want to try Unicode, you've got to use UTF-8 internally, and jump some strange hoops...
Finally, the fact that Ruby's author is Japanese should actually make you unsurprised that it doesn't have good Unicode support. A lot of Japanese people are allergic to Unicode, and in particular, to the Han Unification in Unicode.
This is for a freshman English composition class, isn't it? Strunk & White is on the order of 100 pages, and very readable. The book you've pointed to (Cambridge Grammar of the English Language) is over 1700 pages of obtuse, boring jargon (based on the sample pages on the website).
Slashdot Mirror
I don't know the details of the story of the IEEE Scheme standards, but the RnRS document series are the traditional community definition of the language. One of these (R3RS?) served as the basis for the submitted and approved IEEE standard, but there's been a few RnRS documents since, and those are the ones that people in the scheme community actually care about.
Note that I didn't say that stanrdard threading and exception handling facilities should be implemented in terms of call/cc. I said they should be implementable in terms of it. The let forms are implementable in terms of lambda, but they typically aren't implemented in terms of it. Threading and exception handling can be implementation primitives without being language primitives.
The point is that such a design makes the language simpler.
Those are good things to have some standard way of doing, yes, but they don't actually support the point you made: "reducing the number of primitives by creating a can of worms like CALL-CC is not good design."
Why so? Because you can have it both ways: you can have call/cc as a language primitive, plus standard threading and exception facilities implementable with macros on top of call/cc. (And if you look at R5RS, you'll see that this approach is already taken for large parts of the language; the standard demonstrates how to define, for example, let, in terms of lambda and macros.)
;;;
;;; Macro to increment a variable by one.
;;;
;;; Usage:
;;;
;;; (define a 5)
;;; (inc! a) ; a is now 6
;;;
(define-syntax inc!
(syntax-rules ()
((inc! x)
(set! x (+ x 1)))))
Not that idiomatic Scheme code will do this very often. Langauges like Java or C use "++a" most often for loop indexes. Looping in Scheme is typically driven off data structures.
But Scheme looks like one of the many programming languages developed for parsers and compilers, instead of for the people. Programming languages should be easy to read for humans too.
Lisp syntax certainly does not attempt to look like the combination of English text and mathematical formulas that most languages shoot for, but this in fact has many advantages. The idea of making a language look like that doesn't change the fact that the language will work in a way very different from English or mathematical notation; your previous knowledge of those things will not necessarily help you reason about your code, and at worst, may confuse newcomers by tempting them to apply analogies that don't hold. And to achieve that "look" for your language, you always end up giving it a really complex and inflexible syntax, whose users are not going to have any systematic knowledge of. (Do you know many people who can give you a BNF grammar for Java, or tell you the exact precedence rules for it?)
Lisp makes no pretence at looking like English or mathematics. You're certainly expected to understand the syntax rules of the language more than in "friendlier" ones, but these rules are far, far simpler, and you can actually reason them through. Remember, Scheme oooks regularly include a section that shows you how to write a Scheme interpreter in one page of Scheme code; basic knowledge of how Scheme itself works is considered to be elementary Scheme knowledge.
That is, what I'm saying is that compared to other languages, Lisp dialects demand that you understand the language itself far more, but this is a good thing, which will make you program way better. Why? Because you're going to be able to reason about the execution of your program far better than your average Java programmer.
Plus, you can do macros.
[...] reducing the number of primitives by creating a can of worms like CALL-CC is not good design.
Please argue for this point.
Or 2007. Or 2008.
That's a really uninsightful thing to say. The power to selectively disclose or withhold information about yourself from others is crucial to your ability to play various social roles, because you have no control over which information about yourself may wrongly discredit you in the eyes of which other people. Being unembarrassed about doing something that most people object to can be good for your personal psychological state, but that will not protect you when somebody, because of it, say, denies you a job you are perfectly qualified to do.
And please don't start with some individualistic bullshit about how none of this matters as long as you feel good about yourself, because being denied major oportunities for reasons that should be irrelevant can be a pretty crushing experience, and you should never overestimate your ability to come emotionally unscathed out of such situations.
A few people have told you this already in this thread, but I'll put it in a slightly different way.
No, what you said is not true at all. There is a simple technique to avoid that, and that technique is widely used. When you compile the code, whenever you run into a method name, you intern it into a symbol table, and you just emit a pointer to the symbol table entry to your code. Determining whether a class has a method then becomes just a pointer comparison.
In general, to the extent that the method names that may be called at any one time are known at compile time, a compiler can optimize that to use nothing more than a cheap numeric comparison. And at least in the case of Ruby, I do know for a fact that this is done (check out the Symbol class).
The only case in Ruby where you'd need to munch on a string to figure out which method to call is if you're sending the method name as a string to an object, instead of as a symbol. What the language does in that case is convert your string to a symbol, and then use that. If the string is static (and thus known at compile-time), you should have used a symbol literal. If the string is not static, and computed at runtime (and is not otherwise a dumb thing to do security-wise, of course), then if you send the same message repeatedly, you can do the symbol conversion by hand yourself and reuse the result for a performance boost.
What superstition leads you to think that the phrase genuinely funny is "incorrect"?
Because they judge that they don't have much more room for growth in the software market?
You're missing a very important point: if the prevalence of jokes like that contributes to keeping women away from certain opportunities, the intent behind them plays no role in this.
Sure, perhaps the OP was making a very sophisticated joke about sexism. That doesn't mean that its overall effect won't be propping up sexism.
Sure. That says more about you than it does about genetics or gender differences.
Are you aware that dictionaries are not meant to be philosophically sophisticated authorities, and that citing a dictionary definition does not establish anything at all?
People go on and on about Wikipedia vandals of the crudest sort and how quickly they're caught, but your real murderer of content isn't them; it's the masses of well-meaning, bumbling fools who call themselves "nerds," who "help" by taking carefully-written and well organized articles, and making small "improvements" to them--you know, the article is missing each one of these little irrelevant facts that each one of them just happens to think they know. So each of them opens up the article for edits, and in any old random place, with no regard for organization or narrative flow, they insert the "fact" that they saw was missing. And yay! Now Wikipedia has become a little bit better, all thanks to them! Aren't they such awesome, knowledgeable, generous people!
Take any good article and allow this to happen to it a few times, and it'll become illegible mush, a laundry list of "facts" that just happen to be thrown together.
Rebates are like coupons and generic brands in that they enable retailers to sell the same product at two different prices-- a higher one that you can choose to pay if you want the convenience of not mailing in anything and/or the cache of a name brand, and a much lower one if price matters enough to you to make you clip coupons, mail in receipts or put up with ugly packaging. This is a good thing for everyone involved, because it gives people more options; people choose how much they want to trade convenience for $$, and the company can afford to offer much lower rebate prices because they know everyone won't pay them.
Um, this makes no sense. First of all, IIRC, the point of coupons is to offer an incentive for repeat purchases. If you buy a box of cat food, you get along with it, inside the box, a coupon that gets you a discount on your next box of cat food (applied at the register next time you buy), as long as you buy the same brand. This makes perfect sense; the customer is compensated with a lower price, the company with a stabler cash stream. Or to put it more strongly: even if a seller is offering its product at the lowest rational price for random buyers, it still makes sense for it to offer a better price for repeat buyers, because they provide a definite benefit to the seller.
However, in the bizarre picture you paint above, sellers create artificial barriers to obtaining the lowest rational price they can offer to random buyers. These barriers require you do do things that are irrelevant to the transaction. In exchange for this, the buyer gets the "benefit" of paying the lowest rational price the seller can offer to random buyers. By performing menial crap tasks irrelevant to the transaction at hand, the buyer bypasses the artificial barriers to obtaining the price they should get. In other words, the "problem" the rebates solve is none other than the one they create in the first place.
Also, there's the deceptive practice of the seller's advertising the lowest rational price for a product that they intend to obtain per-unit sales revenues greater than the advertised price. At the very least, by holding on to your money while they "process your application" (i.e., "solve" the "problem" they created for you in the first place), they're getting a 0% interest loan from you, on which they can easily obtain interest (the highest-yielding money market funds are offering about 5% currently).
At its worst, well, if they don't actually intend to give out the rebate to everybody who claims it, then they're even more obviously advertising a lower unit price than the per-unit revenues they have projected. To the buyer, this is a market inefficiency that makes it difficult to obtain the best price, because advertised prices are then not actually true.
The core problem of spelling reform is that English spelling is not random. It's a code that has a dual purpose - as a phonetic reminder (not a purely phonetic encoding) and as an etymological hint.
You went wrong when you assumed that English spelling is guided by a purpose at all. (Nobody sat down and designed it, you know.)
I believe that the richness of multi-contextual information in English spelling brings it closer to the way the words are conceived and stored mentally than any pure phonetic rendering.
And you're a crackpot if you think that the way words are "stored mentally" involves etymology.
Have you ever read prose presented in a dense, spelled out accent? You have to "sound it out" to understand it, and some words may evade parsing until you finally guess them some minutes later. You can't anymore just scan with the eye, and read as fast as you can see.
That means nothing more than that you are familiar with English spelling, and not with whatever idiosyncratic improvised rendering of dialect that you're reading. Which is not surprising, giving that you read English spelling all the time, and only read idiosyncratic dialectal orthographies very infrequently. The idea that you find it easier to read the normal English spelling because it encodes etymology (oh, sorry, I mean, "richness of multi-contextual information"), and not because you're just familiar with it, is, to put it mildly, recherché.
Either the second statement is false, or many things that you label as "prepositions" in English are mislabeled, because in English sentences may certainly end in words that are customarily called prepositions, as you yourself provide examples of.
Also, contemporary linguists ordinarily label the in in sentences like I went in as an intransitive prepositions--i.e., a preposition without an object. Non-linguists who deceive themselves into believing they know squat about grammar typically complain about this practice, and say that in is an adverb in that sentence. In the end, (a) linguists tend to know what they're doing, while the complainers don't, and (b) whether you call it an "adverb" or an "intransitive preposition" or "word class #237" doesn't make a grammatical difference; what matters is how you group the words together, and that the grouping must respond to classes of words that the grammar of English treats equivalently in some way.
And for reasons I won't explain (though I'll refer people Sag, Wasow and Bender's syntax textbook), because of the rules on how to form English verb phrases, the grouping implied by labeling in an "intransitive preposition" in that sentence is right, and the one implied by labeling it an "adverb" is wrong.
PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0; PDO requires the new OO features in the core of PHP 5, and so will not run with earlier versions of PHP.
...
Even if we granted that the functions can't be easily changed, that's got nothing to do with whether it's open source or not. But of course, I'm not willing to grant that it can't be easily changed. Make the next major version include all the functions as modules you need to load, and perhaps provide an utility to tell upgraders which files require which modules.
Several of the examples of redundant functions are not redundant at all. The escaping functions relate to the specific database they are escaping the data for. Oracle requires that things be escaped differently than MySQL, a single function wouldn't work.
That's a terrible example. What this means is simply that the language doesn't have decent database abstraction facilities (and in fact, PHP is infamous for precisely this). In a well designed database access framework, you specify which kind of database you're connecting to, and the framework picks the appropriate methods for doing all the database flavor-specific stuff. Or in other words, you tell the system "connect to this database" and "escape this string for this connection," and the system figures out, based on the kind of database, what to do.
Hah, that's a good one: the idea that if your neighbor is playing the stereo too loudly, the government should respond quicker to it if he's Mexican. (And of course, Mexicans are illegal aliens--just look at them!)
You want to have an understanding of topics like these, and the degree of your understanding thereof is a good measure you can use to gauge your progress. This means that it's good to pick up a couple of textbooks on databases and compilers, to read them through, and to revisit them. Chris Date's database textbook is a good one, and there's others.
But what the GP has in mind is not just switching to Unicode, it's using a language implementation that has good Unicode support. This means that strings are internally represented as Unicode, and the language's character I/O libraries handle all conversion between external encodings and the internal representation. This means that program code doesn't do any conversions; all it does is specify a desired encoding when opening a character I/O stream.
This is one of the things that, e.g., Java, does almost perfectly right. (The one dumb flaw is the primitive 16-bit char type.)
There's a difference between having "multibyte character support" and what the GP wants, which is clean Unicode support in the language. Ruby does have support for at least Japanese multibyte encodings, but that's different.
The model in question is one that Java comes pretty close to: all of your strings in your language are represented internally as Unicode, with the details of the representation hidden from you. Whenever you do character I/O, then, you specify what external encoding to use, and the language's libraries handle all the conversions for you. You never need to do any explicit character set conversions.
Ruby doesn't do any of this for you. IIRC, there's a command-line switch for making it internally represent strings in multibyte for using Japanese-specific encodings, and if you want to try Unicode, you've got to use UTF-8 internally, and jump some strange hoops...
Finally, the fact that Ruby's author is Japanese should actually make you unsurprised that it doesn't have good Unicode support. A lot of Japanese people are allergic to Unicode, and in particular, to the Han Unification in Unicode.
There's A Student's Introduction to English Grammar, by the same authors.