Why Ruby?

[Joel VanderWerf]

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.

Additionally, this usage of strings and unpack can be made more
palatable with bit-struct and similar libs.

 

[Albert Schlef]

It makes more sense to me that
"foo"[1] == "o" than that "foo"[1] = 111.

Languages that support a character data-type return foo[1] as a
character. OTOH, languages that don't support a character data-type (all
scripting languages I know) return foo[1] as a string.

The reason Ruby behaves differently (till 1.8) than other scripting
languages is, I think, because it was influenced by LISP. LISP does have
a character data-type. The "proof" is that Ruby even copies LISP's
character literal (a question mark followed by a raw character).

I think the reason you need a single-character-string now is that
things like UTF-8 may make it ambiguous what the next "character" is

And because, IIUC, each strings in 1.9 carries an encoding (that's what
makes if different than many other languages, that always represent
strings in unicode). An integer doesn't have a "place" to store an
encoding, so you have to use a string object.

 

[Robert Klemme]

So what?


Not at all. =A0That's what rescue is for.


Binary data doesn't belong in Strings. =A0Period. =A0The 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.

IMHO what 1.9 does better is the awareness of encoding. What it does
worse IMHO is that binary is a special encoding of string and not a
separate type (Java did it better here). Also, returning a String
from String#[] with a single index does not seem the right thing to
do. In this case I preferred the 1.8 solution - even better would be
the Java solution to have a separate data type for characters.

On one hand I can see how this all came about and class String is
really versatile. On the other hand, it seems that String is growing
overly complex. Maybe Ruby 2.0 should be used to clean this up and
really separate handling of binary and character data.

My 0.02EUR.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[botp]

IMHO what 1.9 does better is the awareness of encoding. ...
On one hand I can see how this all came about and class String is
really versatile.
agree.

On the other hand, it seems that String is growing
overly complex. =A0Maybe Ruby 2.0 should be used to clean this up and
really separate handling of binary and character data.

can i disagree? i still like to think they are all strings. It's the
methods and their names that's difficult to implem. who say's binary
data were easy, if it were, wouldn't it be called string..?

best regards -botp

 

[Marnen Laibow-Koser]

can i disagree? i still like to think they are all strings. It's the
methods and their names that's difficult to implem. who say's binary
data were easy, if it were, wouldn't it be called string..?

A string is composed of characters. Binary data is composed of bytes.
They're two different things and should be supported as such in the
language.

best regards -botp

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
(e-mail address removed)

 

[Mike Owens]

I'm not a language aficionado, but I think Ruby is amazing. I started
with C/C++, later learned Perl and did some big projects with it, then
Python, Lua, and then Ruby. I loved Python. Years later I sat down to
learn Ruby and I never looked back. I never imagined that I would be
so pleased with a language. I'm not going to bother with a checklist
of whys -- you've just got to try it for yourself -- but It's really
is true what they say: Ruby makes programming fun. Even for jobs that
are otherwise loathsome, Ruby actually adds an element of fun. And it
is very powerful.

The other thing worth noting is its C API. I have done a number of C
extensions for various languages over the years -- in Python, Lua, and
also used SWIG. I think Ruby's C API is by far the friendliest and
easiest to use. It is considerably easier than Python's IMHO. Once you
get the hang of it, it is very easy to interface Ruby with C libraries
or wrap C++ classes or call into Ruby from C/C++.

All around I think Ruby is just a wonderful language. I'm just a
lurker on this list (I don't think I've ever posted anything before).
But as for whether Ruby is worth the time to learn -- I would say
absolutely. It will more than pay you back. It's just a pleasure to
use -- powerful, versatile and fun.

-- Mike

 

[Bill Kelly]

A string is composed of characters. Binary data is composed of bytes.
They're two different things and should be supported as such in the
language.

I was about to disagree. But then I remembered I have some ruby 1.8
code like this:

while line = gets
line.length.times do |i|
line ^= 0x80 if (line & 0x7f).between?(0x21, 0x7e)
end
print line
end

...which while it's still technically operating on "text", it's
7-bit ASCII text where I need to toggle the 8th bit.


With 1.9, I guess this becomes something like:

while line = gets
line.force_encoding Encoding::BINARY
line.length.times do |i|
val = line.getbyte(i)
if (val & 0x7f).between?(0x21, 0x7e)
line.setbyte(i, val ^ 0x80)
end
end
print line
end

....except, I don't trust the 'gets' and the 'print' here. If I
were doing I/O to a file I'd opened directly, I'd use "rb" and
"wb" modes to get ASCII-8BIT encoding. But this is stdin/stdout.
So I can't expect the encoding to be binary-compatible.

Maybe before the loop, instead, setting:

Encoding.default_external = Encoding::BINARY
Encoding.default_internal = Encoding::BINARY

while line = gets
line.length.times do |i|
val = line.getbyte(i)
if (val & 0x7f).between?(0x21, 0x7e)
line.setbyte(i, val ^ 0x80)
end
end
print line
end

...the above indeed appears to work. (I presumably instead could
have specified -EBINARY:BINARY on the command line, but I didn't
want to have to remember that when running this tool.)



So..........

I guess this is a weird hybrid case, since I'm doing binary
processing on text.

So even if Ruby had a data type for binary data that was separate
from String, I'm not sure that would help in my hybrid case where
I still want to use 'gets'.

:shrug:


Regards,

Bill

 

[Rimantas Liubertas]

A string is composed of characters. =C2=A0Binary data is composed of byt=
es.
Binary data is composed of bytes, string is composed of bytes. These
are exactly the
same till you get some meta knowledge about the data, namely the
encoding, which then
lets you to figure out characters from the bytes.


Regards,
Rimantas

 

[Raveendran Perumalsamy]

Is Ruby a good choice as a general usage programming language? Why (or
why not)?

Hi Jim,

Technical reply :

Ruby also has open source testing tools like

Watir
Selenium (On Ruby)
Celerity
and lot .....

Lot of open source PROJECT management tools still using ruby.


Non-Technical Reply:


NOTE: I didn't mention any technical terms because already lot of
peoples explained about it. I am just sharing my experience with Ruby.
SO if it is not relevant to this topic then PLEASE IGNORE IT. But I hope
it will gives confidence for few peoples who are learning ruby.


After read all the replies, I also want to say something about my
experience on ruby. I didn't studied any languages (even OOPS concept)
in college life(Last Bench Student ..). But I got a offer from a
company as a TESTING ENGINEER. In my company they all did Only RAILS
Projects. So I started with Watir. Without learning Ruby, its very tough
to learn watir. So I started to learn Ruby. Within 20 days I can able to
write multiple ruby files and also I can able to combine and manage all
the ruby codes. Because comparing with other languages, RUBY is very
easy to cover the following topics,

1. FixNum, String,Array,Hash
2. If,For,While,Case
3. Methods,Classes
4. Single Inheritance, Multiple Inheritance(Mixin)
5. Include, Require, Load
6. File Concept
7. Error handling.
8. DB connectivity (mysql)

So within 20 days I had learned Ruby but I couldn't able to learn other
languages for 4 years(In My College life).

In these 20 days only, I got programming knowledge and also oops
concept.

Now I have 3 years experienced in Ruby. Except my company works, I have
earned $5000(I am in India).Because I can automate anything with
RUBY(Watir,Selenium,Mechanize,Hpricot....).

So shortly --> learning Ruby is worth. (learn RUBY earn RUPEE)


Thanks

 

[David Masover]

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.

They're still around, they're just slightly ugly. You have to specify a weird
encoding, something like ASCII-8BIT, to mark the string as raw.

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?

If they're bytes, sure. I don't know enough about the Ruby internals to know
if it's worse than a string -- it probably is, since arrays can hold arbitrary
values -- but if it's an array of integers, remember that while integers
behave like objects, they aren't actually allocated like objects. Ruby appears
to be using an old Smalltalk trick here, in that a single bit in the object
reference (itself an integer) signals whether this particular reference is an
int or an actual reference -- thus, ints lose some precision, but gain a LOT
of speed.

On second thought, that is expensive -- an int is probably bigger than a byte
-- but not _that_ expensive.

But really, it seems to me that the answer here would be to follow python --
add a separate binary type. To be especially idiomatic, we could make strings,
arrays, and binary data all have a similar duck-type.

And the short-term answer is to use "raw" strings, because they're already
used everywhere and they're already efficient.

 

[Robert Klemme]

They're still around, they're just slightly ugly. You have to specify a w= eird
encoding, something like ASCII-8BIT, to mark the string as raw.


If they're bytes, sure. I don't know enough about the Ruby internals to k= now
if it's worse than a string -- it probably is, since arrays can hold arbi= trary
values -- but if it's an array of integers, remember that while integers
behave like objects, they aren't actually allocated like objects. Ruby ap= pears
to be using an old Smalltalk trick here, in that a single bit in the obje= ct
reference (itself an integer) signals whether this particular reference i= s an
int or an actual reference -- thus, ints lose some precision, but gain a = LOT
of speed.

On second thought, that is expensive -- an int is probably bigger than a = byte
-- but not _that_ expensive.

Plus, bytes inside a ByteString need not necessarily be represented as
object types. The conversion could happen on extraction. And, there
are at most 256 byte objects needed (assuming they are made
immutable). Even if these would be objects that would not introduce
major inefficiency.

But really, it seems to me that the answer here would be to follow python= --
add a separate binary type. To be especially idiomatic, we could make str= ings,
arrays, and binary data all have a similar duck-type.
Absolutely.

And the short-term answer is to use "raw" strings, because they're alread= y
used everywhere and they're already efficient.

Yuck. But still, I think Matz should give it a thought to introduce a
type for byte sequences and probably for single bytes in Ruby x (with
x > 1).

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[Tony Arcieri]

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

As an example, Twitter was founded on Ruby, however has found not to be
sufficiently scalable.

Watching Twitter's "code swarm" video... I'm not seeing a lot of Scala: