John Joyce
6/1/2007 10:59:00 PM
On Jun 1, 2007, at 9:23 AM, Richard Conroy wrote:
> On 6/1/07, Ivan Mashchenko <ivan.mashchenko@gmail.com> wrote:
>> Richard Conroy wrote:
>>
>> > It depends on your definition of 'convenient'.
>>
>> IMHO convinient is as in C#. There I don't have to bother how are
>> strings stored in memroy, they just do work and are international.
>
> It's not *that* convenient. By default Ruby strings are 8-byte. You
> can make
> them Unicode strings very easily through a library (kCODE IIRC),
> and they
> will behave as unicode in a way that you don't have to think about.
> You don't
> have to use a different string type.
>
> The problem occurs when you use code that you didn't write that
> expects
> strings to be single-byte. So every time you evaluate a Ruby
> library, Rails
> plugin or gem, you have to do more homework than you would in the
> unicode centric Java or C#.
>
>> > Well yes, but I would use UTF-8 instead.
>>
>> Won't there be a problem if the data is stored in UTF-16 (as far as I
>> know Orace, NVARCHAR uses 16-bit per symbol)
>
> Every database worth using lets you specify the encoding of your
> string
> and character types. Check your manuals or the Oracle forums. Anything
> that is any way associated with web development supports UTF-8.
>
>>
>> > Also Ruby 1.9 is going to break/deprecate stuff - I wouldn't
>> develop against it
>> > migrating from 1.8 -> 1.9 is going to be tricky
>>
>> So why should anyone develop a new project against 1.8 if it is
>> going to
>> be deprecated?
>
> Okay, you misunderstood me. There is a feature roadmap towards Ruby
> 2.0,
> where major changes are coming in; the two biggest that I recall
> are Unicode
> support and native/pre-emptive threads. The only reasonable way to
> implement
> them are by altering the behaviour of core classes and the standard
> library.
>
> This will mean that Ruby code of any sophistication written for Ruby
> 1.8, including
> many libraries is likely to break.
>
> Ruby 1.8 is not going away. Ruby is an open language, with a public
> source
> repository. Unlike with .Net say, where Microsoft distribute the
> runtime in
> binary only-form and can make older versions difficult to get. You
> have no
> obligation to migrate to the most recent version, and there is no
> technical
> reason that multiple runtimes (application specific) cannot co-
> exist on the
> same machine.
>
> Chasing the latest release is really something that you only do
> with commercial
> languages. It's not something that is generally done with open
> languages.
>
>>
>> > If you are moving to Ruby 1.9, do it with a complete working
>> > application.
>>
>> But isn't it going to be tricky, as you've said?
>
> It would be one hell of a lot easier than developing against a moving
> target, not knowing if the issues in your code are your issues or
> due to the latest release candidate.
>
> Bleeding edge software development is for people who can spare a
> lot of blood loss;
>
>> I dont have to be moving for now as I have no line of Ruby code (I
>> have
>> only an idea in my head) for today. And no Ruby experience (I am C++,
>> C#, Java and T-SQL developer). I've chosen Ruby as it seems almost
>> good
>> and free.
>
> Yeah, its a great language. Make a point of checking out the JRuby
> project.
> Its an exceptionally well developed Ruby runtime; it is
> considerably more
> than an interpreter or language bridge - the JRuby guys have basically
> doubled the size of the Java platform (or Ruby platform depending
> on POV).
> Ruby is strong where Java is weak, and vice versa.
>
>> Have I understood you correctly - you think I should make it Ruby 1.8
>> and then do a tricky move when it comes?
>
> Use Rails, where the most compelling features in Ruby 1.9/2.0 are
> already
> present: Unicode, native concurrency (via processes) and good
> performance
> (via all those <foo>caching mechanisms). When the Rails guys go
> Ruby 1.9
> you can.
>
>> > Or better still, develop against Rails versions, not Ruby versions.
>>
>> This advice can prove useful. I'll think about it.
>
> regards,
> Richard.
>
Objective-C (through the Cocoa framework) also handles Unicode
superbly. Problem is, it is not cross-platform and is in fact
strictly OS X stuff, but you could indeed use those libraries
(NSString, etc...) through RubyCocoa, but of course that is far from
convenient or optimal for most purposes.
Ideally, if major OS vendors got behind Ruby full force and put their
Unicode know-how into the codebase, things would be smoother. They're
the ones who really have already figured out pretty good ways to
handle that stuff, and all the major scripting languages could
benefit from it.