On 11/8/05, mortench <mortench / gmail.com> wrote:
> Re: comments by  Austin Ziegler
>
> 1. You confuses what I said about the VM for the job of the compiler.
> The VM executes compiled java code. Early Java VM's was based on a
> simple interpreter of bytecode. Hence the comparison is in perfect
> order. And hotspot works fine on everything that can be compiled to
> bytecode, like Jython or any of the several scripting languges for the
> java vm. The next verison of java after mustang will even have special
> optimized bytecode instructions for (scripting) languages.

Um. (1) Early Java VMs were still bytecode based. Even "interpreted",
bytecodes are more optimizable -- in general -- than ASTs. The full
HotSpot VMs weren't around for a few more years, but early Java VMs were
still more than simple interpreters. (2) It is unlikely that the
bytecode instructions will actively help Ruby -- and if it's The Next
Version After, that's completely useless in terms of reality.

> 3. "First class" is not marketing nonsense but means integrated,
> build-in language support (for unicode) at a level comparable to other
> features. From what I have read ruby does not have that. Maybe I am
> wrong because I don't know Ruby that well?

Okay, you're still not listening. I've done Unicode work. "First-class
Unicode Support" is marketing bullshit if you're not willing to call it
nonsense. What do *you* mean by "First-class Unicode Support"? That
description will be the basis of the feature.

Do you want UTF-8 strings? Ruby supports them. Do you want to
*manipulate* UTF-8 strings on a character level? Ruby *will* support
that. Even now, with Oniguruma (at least; the other regex engine may
support it), you can split by character using regex. Do you want to
convert between ISO-8859-1 and UTF-8? Ruby supports that, too.

Just saying you want "First-class Unicode Support" is nonsense. Ruby's
strings *are not* any Unicode encoding. At the same time, they're not
ISO-8859-1 encoding, either. Ruby's strings are -- in many ways -- what
other languages might call a ByteVector. In Ruby 2.0, Matz has indicated
that Ruby's strings will carry around an encoding flag that explicitly
indicates how they should be interpreted. This is, in fact, far
*superior* to what Java and Python do -- which are limited to UTF-8
string representations (AFAIK). Nothing will prevent Ruby from carrying
around full UTF-16 if that's appropriate -- and converting between
UTF-16 and EUC-JP if that's what's needed.

"First-class Unicode Support" is and always will be nonsensical. Tell us
what features you want for Unicode handling in Ruby. Most of the time,
if you're not doing, say, per-character analysis, you'll never even care
that Ruby 1.8's String values are raw byte streams.

> 4. I guess we will never agree on the IDE issue - but I will admit
> that it MAY be a matter of taste. However, I hope you do understand
> that it is an issue for some (and properly for most people taking into
> account how many professionals that uses IDEs).

Sure, it's mostly an issue for PHBs, though. I, for one, am unconcerned
about IDE vendors or PHBs that depend on them. I will be trying
ActiveState Komodo, though.

IME, IDEs promote excessively large programs.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca