Im new to programming and Im thinking of downloading and starting with
Ruby. I learned the very basics of programming in Python and with Python
most people seem to be using the 2.7 version instead of 3.x.
So should I download the Ruby 1.9.2 or the Ruby 1.8.7 installer?
On Sep 3, 2011, at 10:20 PM, Vladimir Van B. wrote:
Im new to programming and Im thinking of downloading and starting with
Ruby. I learned the very basics of programming in Python and with Python
most people seem to be using the 2.7 version instead of 3.x.So should I download the Ruby 1.9.2 or the Ruby 1.8.7 installer?
1.9.2. Most of the Ruby community is definitely over the hill now.
I actually use Ruby 1.9 as a filter. If a project is not 1.9-compatible
nowadays, its usually deadwood or not well maintained.
Regards,
Florian
Florian G. wrote in post #1019967:
On Sep 3, 2011, at 10:20 PM, Vladimir Van B. wrote:
1.9.2. Most of the Ruby community is definitely over the hill now.
I actually use Ruby 1.9 as a filter. If a project is not 1.9-compatible
nowadays, its usually deadwood or not well maintained.Regards,
Florian
Thanks, that’s helpful
On Sat, Sep 3, 2011 at 3:20 PM, Vladimir Van B. <
[email protected]> wrote:
Im new to programming and Im thinking of downloading and starting with
Ruby. I learned the very basics of programming in Python and with Python
most people seem to be using the 2.7 version instead of 3.x.So should I download the Ruby 1.9.2 or the Ruby 1.8.7 installer?
–
Posted via http://www.ruby-forum.com/.
I use 1.9.2 (p290) by default, and occasionally 1.8.7 and 1.9.3
(preview)
Agreed. Ruby 1.9 has been the standard version of Ruby for almost two
years now.
On Sep 3, 2011, at 2:20 PM, Vladimir Van B.
[email protected] wrote:
So should I download the Ruby 1.9.2 or the Ruby 1.8.7 installer?
1.9 is the future, faster, “better”, and sufficiently stable and
well-supported at this point.
Gavin K. wrote in post #1020001:
On Sep 3, 2011, at 2:20 PM, Vladimir Van B.
[email protected] wrote:So should I download the Ruby 1.9.2 or the Ruby 1.8.7 installer?
1.9 is the future, faster, “better”, and sufficiently stable and
well-supported at this point.
Just beware: the semantics of String are both complex and very poorly
defined in 1.9.x (that is, they aren’t actually defined anywhere except
in the code itself), and unless you are very careful, may introduce
subtle bugs in your programs.
If you want to try to understand them, here’s as far as I got:
The difference between ruby 1.8 and 1.9 is a little bit like the
difference between python 2.x and 3.x. However, the semantics of both
python 2.x and 3.x are clearly defined; well enough that they can
provide an automated tool for translating from one to the other.
All of Ruby is poorly defined, not just strings. :p. RubySpec does a
decent
job codifying it though.
And have you used 2to3? It’ll get you started, but it is not a cure-all
for
moving to Python3x. That transition is still in the middle of the 5 year
plan for a reason.
On Sun, Sep 4, 2011 at 1:50 AM, Vladimir Van B. <
[email protected]> wrote:
Im new to programming and Im thinking of downloading and starting with
Ruby. I learned the very basics of programming in Python and with Python
most people seem to be using the 2.7 version instead of 3.x.So should I download the Ruby 1.9.2 or the Ruby 1.8.7 installer?
As i think 1.9.2 because it will also support to latest Ruby On Rails
3.x,
if you are interested in learning RoR.
Better if you use rvm for the installation, which will allow you to
install
both and move in between ruby versions smoothly
–
I myself am stuck on 1.8.x and will move to python rather than use
1.9.x’s brainless Encoding situation.
It is not brainless.
But I agree on one point indeed - 1.8.x will eventually die (waves a
sad goodbye) and I think the official homepage should ACTIVELY
recommend to use 1.9.x ALONE.
It does already?
As should all of the community.
Has there been any posts in this thread that recommend 1.8?
You guys are aware that newbies will always have this question?
It is a HUGE problem for any language to support two different
implementations (or worse, even more).
I myself am stuck on 1.8.x and will move to python rather than use
1.9.x’s brainless Encoding situation.
But I agree on one point indeed - 1.8.x will eventually die (waves a
sad goodbye) and I think the official homepage should ACTIVELY
recommend to use 1.9.x ALONE. As should all of the community. A hard
break is better than a slow one… it slows down changes to the
language.
It is much less confusing for newcomers to ruby and perhaps they manage
to do something which I failed at - embrace 1.9.x with love. (I just
don’t feel it anymore due to the Encoding crap I don’t need, crap which
was not existing in 1.8.x, but it was my personal decision to not switch
to 1.9.x and instead do a hard switch to another language altogether, so
it is ok.)
You guys are aware that newbies will always have this question?
Newcomers to a language will always have common questions that are often
covered by official documentation. That’s nothing that’s going to
change.
It is a HUGE problem for any language to support two different
implementations (or worse, even more).
But in a majority of cases it’s necessary. When you’re dealing with
programming languages people are often split into two distinct camps.
The first is those who always want to live on the bleeding edge, always
picking up new technology as it comes. On the other hand is the slower
moving side. They are more resistant to change and tend to prefer
working with something as long as possible until upgrades are absolutely
essential. Some of the logic behind this is that if they stick with what
they have
I myself am stuck on 1.8.x and will move to python rather than use
1.9.x’s brainless Encoding situation.
Python won’t save you from the complexities of encoding. You have to
remember, Ruby has its base in Japan. In Japan you roughly have the
following encodings to deal with:
But I agree on one point indeed - 1.8.x will eventually die (waves a
sad goodbye) and I think the official homepage should ACTIVELY
recommend to use 1.9.x ALONE. As should all of the community. A hard
break is better than a slow one… it slows down changes to the
language.
The only real mentions of the 1.8 series are those referring to system
specific implementation. My Mac for example has 1.8 installed by
default. Solaris as noted has 1.8 as well. Some people like to stick
with the system version and not go through the whole rvm/source install
dance.
It is much less confusing for newcomers to ruby and perhaps they manage
to do something which I failed at - embrace 1.9.x with love. (I just
don’t feel it anymore due to the Encoding crap I don’t need, crap which
was not existing in 1.8.x, but it was my personal decision to not switch
to 1.9.x and instead do a hard switch to another language altogether, so
it is ok.)
That’s your decision, just remember that every language has its ups and
downs. Python 3 for example has many external libraries, including
Django and some of the ui toolkits, that are not supported. However it’s
also the latest cutting edge version.
Regards,Chris W.Twitter: http://www.twitter.com/cwgem
On Mon, Sep 5, 2011 at 1:47 PM, Marc H. [email protected]
wrote:
You guys are aware that newbies will always have this question?
It is a HUGE problem for any language to support two different
implementations (or worse, even more).
1.8.7 EOL is already being discussed (they may have even set a date).
But I agree on one point indeed - 1.8.x will eventually die (waves a
sad goodbye) and I think the official homepage should ACTIVELY
recommend to use 1.9.x ALONE.
The downloads page Download Ruby has only 1.9.2
and
1.9.3 under compiling. The RVM section only shows 1.9.2. The Linux
section
only talks about 1.9.2. The Mac section talks about 1.8.x, but that’s
just
because they come preinstalled on OSX. The Solaris section talks about
both
1.8.7 and 1.9.2.
So while there is some deviation, I’d say that for the most part, it
clearly
prefers 1.9.2.
As should all of the community. A hard
break is better than a slow one… it slows down changes to the
language.
I doubt anyone is recommending or selecting 1.8 for new projects. The
Ruby
community is rather progressive.
It is much less confusing for newcomers to ruby and perhaps they manage
to do something which I failed at - embrace 1.9.x with love. (I just
don’t feel it anymore due to the Encoding crap I don’t need, crap which
was not existing in 1.8.x, but it was my personal decision to not switch
to 1.9.x and instead do a hard switch to another language altogether, so
it is ok.)
IDK what your use case is, but I rarely need to deal with encodings at
all,
and if I did, I think I’d prefer Ruby 1.9 as my understanding is that it
is
encoding aware, whereas 1.8 only swept the issue under the rug by
casting
everything to ASCII-8bit (ie unknown binary data). I guess I could go
back
and read Brian’s long post about it, but for now I have more important
priorities.
But in a majority of cases it’s necessary. When you’re dealing with programming
languages people are often split into two distinct camps. The first is those who
always want to live on the bleeding edge, always picking up new technology as it
comes. On the other hand is the slower moving side. They are more resistant to
change and tend to prefer working with something as long as possible until
upgrades are absolutely essential. Some of the logic behind this is that if they
stick with what they have
Woops, I was addressing another point and forgot to complete this
thought… Some of the logic behind this is that if they stick with what
they have, everything will work as expected. “If it ain’t broke don’t
fix it” as they say. If you keep on upgrading it increases the chance
that some random change somewhere will introduce unwanted behavior and
require the need for putting out fires. Whether or not this is a good
idea is another topic of discussion (especially with regards to security
updates).
Regards,Chris W.
One issue with 1.9 is that it requires an existing Ruby interpreter. I
imagine the build process could be changed so miniruby is used for this
purpose, but somehow it doesn’t seem to be a priority.
Jos
Chris W. wrote in post #1020283:
Python won’t save you from the complexities of encoding.
No, but the language does have very clearly defined semantics. It also
makes a clear distinction between “a character” and “an encoded
representation of that character”, and it has two distinct classes for
those things.
It is then pretty much foolproof: if you forget to decode your bytes
into characters, or encode your characters into bytes, or try to combine
characters with bytes, then you’ll get an immediate and consistent
runtime error.
Ruby has a hazy notion of these things, and hazy(*) rules which allow
you sometimes to combine strings of characters and binary strings, and
sometimes not. If your program runs successfully once, it doesn’t mean
that it’s going to run successfully with different input data.
Furthermore, any library in ruby 1.9 which either accepts a String or
returns a String needs to document its encoding-related behaviour;
almost none of them do. In Python 3, all you have to say is whether it
uses String or Bytes.
(*) Even data which I explicity tag as being BINARY is taken to be
ASCII-8BIT, whether that is true or not.
You have to
remember, Ruby has its base in Japan. In Japan you roughly have the
following encodings to deal with:
- UTF*- EUC-JP- SJIS- ISO-2022-JP
The confusion between “encodings” and “character sets” is pretty
endemic, and I have fallen prey to it myself many times.
Python partly dodges this issue because it supports only one character
set - unicode - and then various encodings of it (like UTF*) and
encodings of subsets of the character set (like ISO-8859-*)
I understand that there are various Asian character sets which are not
proper subsets of unicode, and so can’t be converted losslessly to and
from unicode. If Python3 were to be extended to handle them, then I
imagine there would be separate classes for EUCJPString and GB2312String
or whatever, and methods to transcode between them (and options for what
to do about missing characters)
And of course, Ruby 1.9 doesn’t really handle ISO-2022-JP anyway,
because it’s a stateful encoding; I’m pretty sure you can’t index or
take the length or regexp-match an ISO-2022-JP string in ruby 1.9,
without first transcoding it.
This is just a very broad generalization. There are even more issues
such as multiple versions of SJIS.
Absolutely. So it’s vital to have a clear distinction between
encoded sequence <-----------> set of characters
of bytes
which Python 3 has; whereas ruby 1.9 tries to work with the encoded
sequence of bytes as-is, hoping you’ve remembered to tag the encoding
correctly every time, and remorselessly tagging binary data as being
text anyway.
just remember that every language has its ups and
downs. Python 3 for example has many external libraries, including
Django and some of the ui toolkits, that are not supported.
That’s true, and it’s Django which keeps me from skipping python 2
entirely and just going to 3.
Regards,
Brian.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs