Re: Why Ruby?

Ruby is my language of choice for many applications because of the
following:

(1) the lack of boilerplate. It encourages you to partition your problem
into small digestible bits because you only need to type

class Foo
...
end

to get a class - virtually zero effort. Compare the line noise required
in Perl to do the same thing.

(2) the supremely sane data model - *all* values are references to
objects. (In Perl you have Scalars, Arrays, and References to Arrays,
the latter being held in a scalar variable, and a load of special case
nonsense like filehandles and typeglobs. C++ is worse; you have
integers, pointers to integers and references to integers).

(3) pure personal preference, e.g. I don't like python's run-off-a-cliff
indentation syntax. I had to use it in Occam years ago, and I didn't
like it then either.

(4) the ruby 1.8 C intepreter ("MRI") is portable and runs on lots of
things, even tiny embedded systems with 4MB of flash (e.g. OpenWrt)

(5) it's easy to work in different programming styles. Functional
languages made a lot more sense once I was familiar with things like
blocks and enumerables in ruby.

(6) it's not Java.

The downsides for me are a lot of accumulated warts and special cases in
the language, generally aimed at "doing the right thing" but sometimes
catching you out. Examples: auto-splat, lambda-vs-proc-vs-block,
different behaviour of ^ and $ in regular expressions. I also detest
ruby 1.9's String handling which means I'm staying on 1.8; I know I'll
ultimately have to move to a different language entirely.

The documentation is variable from poor to bad. The language is not
formally defined, neither its syntax nor semantics, and sometimes you
just have to treat it like a black box and experiment to find out how
things actually behave.

Sometimes it can be hard to find your way around other people's code,
because ruby doesn't enforce that class Foo::Bar is defined in file
foo/bar.rb (or that it's even defined in source code at all; it might be
defined dynamically at run time). You're reliant on the good sense of
the person who wrote the code to organise it sensibly, and you can write
bad code in Ruby just as in any other language.

Finally, in some spheres there are simply better tools for the job. If
you want to handle ten thousand concurrent client connections then
erlang is probably a better fit (yeah, there are event-driven libraries
in Ruby which with effort can achieve the same, but this is an area
where erlang excels). Ditto if you want to build systems with huge
uptime and zero-downtime live code upgrades. But try deciphering an
erlang backtrace and you'll wish you were back with ruby.

HTH,

Brian.
--
Posted via http://www.ruby-forum.com/.

On 2010-02-06, Brian Candler <b.candler@pobox.com> wrote:
> I also detest
> ruby 1.9's String handling which means I'm staying on 1.8; I know I'll
> ultimately have to move to a different language entirely.

I'm stumped on this one. Overall, I rather prefer 1.9's string model, and
wish it had been that way all along. It makes more sense to me that
"foo"[1] == "o" than that "foo"[1] = 111. It is a little surprising if I
think of it from a C perspective, which is certainly my native perspective,
but overall it's a cleaner answer and more consistent with string handling.
In particular, it's cleaner because it's consistent with slices of more than
one character.

Or is there something else in the new String that you don't like?

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs wrote:
> Or is there something else in the new String that you don't like?

It's as complex as hell. I took the trouble to document about 200
behaviours of String in 1.9, and I still haven't really scratched the
surface. http://github.com/candlerb/string19/...er/string19.rb

The scariest bit for me is that a simple expression like

a = b + c

(where b and c are both Strings) can raise exceptions. Writing your
program so that you can be *sure* it won't raise an exception is hard.
Even the same program running on two different computers with the same
version of ruby 1.9 and the same input data may crash on one but not on
the other.

I don't want to have to expend effort working around artefacts of the
language, especially when dealing with binary data.
--
Posted via http://www.ruby-forum.com/.

Brian Candler wrote:
> Seebs wrote:
>> Or is there something else in the new String that you don't like?
>
> It's as complex as hell. I took the trouble to document about 200
> behaviours of String in 1.9, and I still haven't really scratched the
> surface. http://github.com/candlerb/string19/...er/string19.rb
>
> The scariest bit for me is that a simple expression like
>
> a = b + c
>
> (where b and c are both Strings) can raise exceptions.

So what?

> Writing your
> program so that you can be *sure* it won't raise an exception is hard.

Not at all. That's what rescue is for.

> Even the same program running on two different computers with the same
> version of ruby 1.9 and the same input data may crash on one but not on
> the other.
>
> I don't want to have to expend effort working around artefacts of the
> language, especially when dealing with binary data.

Binary data doesn't belong in Strings. Period. The only reason you
have it in there in the first place is that 1.8's piss-poor String
handling allows you to treat strings as byte arrays.

I haven't used 1.9 yet, so take this with a grain of salt, but my
impression is that encoding-aware Strings that aren't byte arrays is
exactly the right thing for Ruby to have.

Best,
--Â*
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
--
Posted via http://www.ruby-forum.com/.

Marnen Laibow-Koser wrote:
> Binary data doesn't belong in Strings. Period.

And Ruby doesn't provide any other suitable data type. At least, IO#read
and #write only operate with Strings.

Python 3 is going down the route of two different data types: one for
binary data, one for character data. Erlang similarly has "binaries" but
also list of integers (if you want a list of codepoints)

--
Posted via http://www.ruby-forum.com/.

On 8 February 2010 21:12, Brian Candler <b.candler@pobox.com> wrote:
> Seebs wrote:
>> Or is there something else in the new String that you don't like?
>
> It's as complex as hell. I took the trouble to document about 200
> behaviours of String in 1.9, and I still haven't really scratched the
> surface. http://github.com/candlerb/string19/...er/string19.rb
>
> The scariest bit for me is that a simple expression like
>
> =C2=A0 =C2=A0a =3D b + c
>
> (where b and c are both Strings) can raise exceptions. Writing your
> program so that you can be *sure* it won't raise an exception is hard.
> Even the same program running on two different computers with the same
> version of ruby 1.9 and the same input data may crash on one but not on
> the other.
>
> I don't want to have to expend effort working around artefacts of the
> language, especially when dealing with binary data.

The complexity stems from the inherent issues of handling strings in
multiple encodings. In 1.8 the support was nearly non-existent. In 1.9
the support is improved at the cost of increased complexity.

I think it would be nice if somebody wrote a library that adds
autoconversion to strings. While it's not hard to hack the support for
a particular piece of code doing it as a general library would
probably require a bit of thinking, especially since we still don't
have namespaces.

You can't do much better than what 1.9 has. In 1.8 a =3D b + c was
guaranteed to not throw an exception but it could easily produce
complete nonsense as result in exactly the cases where 1.9 would throw
an exception. Obviously, you can override the 1.9 + method to do a
conversion automatically instead and face the consequences if the
encoding information in the string was wrong.

I agree that having to deal with this for binary data as well is the
somewhat unfortunate result of sharing the string class for both text
strings and binary data. The upside of such sharing, especially in 1.8
which lacked the subtyping of String by encoding was the ability to
interpret binary data as text when looking for textual magic such as
GIF89a.

You can't have everything at once. A simple solution fails for some
more complex problems, a more complete solution has to be set up for
any particular simple case.

Thanks

Michal

On 2010-02-08, Brian Candler <b.candler@pobox.com> wrote:
> It's as complex as hell. I took the trouble to document about 200
> behaviours of String in 1.9, and I still haven't really scratched the
> surface. http://github.com/candlerb/string19/...er/string19.rb

Ahh.

> The scariest bit for me is that a simple expression like
>
> a = b + c
>
> (where b and c are both Strings) can raise exceptions. Writing your
> program so that you can be *sure* it won't raise an exception is hard.

I'd rather get an exception than silently get incoherent output, though.

> I don't want to have to expend effort working around artefacts of the
> language, especially when dealing with binary data.

To some extent, I agree, but I was under the impression that you could
address this by specifying a desired encoding.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 2010-02-08, Marnen Laibow-Koser <marnen@marnen.org> wrote:
> I haven't used 1.9 yet, so take this with a grain of salt, but my
> impression is that encoding-aware Strings that aren't byte arrays is
> exactly the right thing for Ruby to have.

It is certainly a useful thing to have, but I'm not sure that it's a good
idea to do away with byte arrays.

I have a program which listens for UDP packets containing a hunk of data,
which is a string of binary bits and pieces, such as 3-byte integer values,
flag bits, and so on. I can't change the format of the packets. I have
some Ruby code which is doing the obvious thing -- taking the byte arrays
that are returned as string objects by the underlying syscall, and managing
it using unpack(), etcetera.

If strings are not the right tool for holding hunks of binary data, such as
those you'd get from performing a raw binary read(2) on a data file, what is?
The array type seems INCREDIBLY expensive for this -- do I really want to
allocate over two thousand objects to read in a 2KB chunk of data?

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

[Note: parts of this message were removed to make it a legal post.]

On Mon, Feb 8, 2010 at 2:00 PM, Seebs <usenet-nospam@seebs.net> wrote:

> I'd rather get an exception than silently get incoherent output, though.
>

Amen to that, nothing worse than PHP's "3 dog night" + 2 = 5

--
Tony Arcieri
Medioh! A Kudelski Brand

On 8 February 2010 22:00, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-02-08, Brian Candler <b.candler@pobox.com> wrote:
>> It's as complex as hell. I took the trouble to document about 200
>> behaviours of String in 1.9, and I still haven't really scratched the
>> surface. http://github.com/candlerb/string19/...er/string19.rb
>
> Ahh.
>
>> The scariest bit for me is that a simple expression like
>>
>> =C2=A0 =C2=A0 a =3D b + c
>>
>> (where b and c are both Strings) can raise exceptions. Writing your
>> program so that you can be *sure* it won't raise an exception is hard.
>
> I'd rather get an exception than silently get incoherent output, though.
>
>> I don't want to have to expend effort working around artefacts of the
>> language, especially when dealing with binary data.
>
> To some extent, I agree, but I was under the impression that you could
> address this by specifying a desired encoding.

Unless you forget ;-)

Thanks

Michal

On 08.02.2010 20:55, Seebs wrote:
> It makes more sense to me that
> "foo"[1] == "o" than that "foo"[1] = 111. It is a little surprising if I
> think of it from a C perspective, which is certainly my native perspective,
> but overall it's a cleaner answer and more consistent with string handling.
> In particular, it's cleaner because it's consistent with slices of more than
> one character.
>
By that logic array[index] should return a single-element array
instead of the element itself to be more consistent with array
slicing.

Strings are just fine for binary data, IMNSHO. That's what 'BINARY'
encoding is there for.

Is this a poll? *laugh* It's starting to sound like one.

Aaron out.

Seebs wrote:
> On 2010-02-08, Brian Candler <b.candler@pobox.com> wrote:
>> The scariest bit for me is that a simple expression like
>>
>> a = b + c
>>
>> (where b and c are both Strings) can raise exceptions. Writing your
>> program so that you can be *sure* it won't raise an exception is hard.
>
> I'd rather get an exception than silently get incoherent output, though.

Likewise.

>> I don't want to have to expend effort working around artefacts of the
>> language, especially when dealing with binary data.

It seems to me encodings are less artifacts of *the* language and more
artifacts of *language*.

> To some extent, I agree, but I was under the impression that you could
> address this by specifying a desired encoding.

Indeed, one can force_encoding ASCII-8BIT, if one wants "a = b + c" to
simply concatenate bytes without complaining that one may be jamming two
incompatible encodings together.

Also, reading a file opened in "rb" mode returns strings with encoding
already set to ASCII-8BIT.

So it's still possible to treat strings as binary in 1.9.


If it were really true that at any given point in my program, I can't
be sure that string 'b' doesn't have some random, incompatible encoding
from string 'c', then I think I'd agree with Brian that string handling
in 1.9 has become unreasonably complex.

But in practice, so far it has worked well for me to transcode to UTF-8
at I/O boundaries. (Or, to use "rb" or force ASCII-8BIT if I know I'm
specifically dealing with binary data.)

So far, I'm just not experiencing much pain in dealing with encodings in
1.9. And the places I have encountered exceptions, have been occasions
when I really would have been jamming incompatible encodings together,
and I was glad to know about it rather than be producing bogus data.

(In this case I was reading lines via popen() from a program ostensibly
outputting ISO_8859_1, but which under some circumstances, for some
fields, could output UTF-8 or MACROMAN. So yes, I had to do some extra
work at the I/O boundary to try to handle such cases as well as possible;
but that is hardly Ruby's fault.)


Regards,

Bill

On 2010-02-08, Sebastian Hungerecker <sepp2k@googlemail.com> wrote:
> On 08.02.2010 20:55, Seebs wrote:
>> It makes more sense to me that
>> "foo"[1] == "o" than that "foo"[1] = 111. It is a little surprising if I
>> think of it from a C perspective, which is certainly my native perspective,
>> but overall it's a cleaner answer and more consistent with string handling.
>> In particular, it's cleaner because it's consistent with slices of more than
>> one character.

> By that logic array[index] should return a single-element array
> instead of the element itself to be more consistent with array
> slicing.

Hmm. You have a point.

I guess, to me, "foo"[1] should be an o. If printing it yields a number,
instead of the letter o, something has gone wrong.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On 09.02.2010 00:20, Seebs wrote:
> I guess, to me, "foo"[1] should be an o. If printing it yields a number,
> instead of the letter o, something has gone wrong.
>
We agree on that. I've always thought ruby should have a Char class, so
"foo" could
behave basically like a collection of Char. At least as far as [] is
concerned.