Forum: Ruby Why Ruby?

I've asked several friends and associates (application developers) what
programming language they recommend for new development.  The most
prevalent answer was Ruby (with Ruby-On-Rails a close second).  This was
surprising to me, since my understanding is that Java and C (et al) are
most prevalent.

So I asked why.  I received at least a handful of reasons from each
respondent, no answer consistently offered, none all that obviously
compelling.  My initial reaction was "It's just the buzz", that is - a
fad.  Further research revealed a thriving and mature community around
Ruby, so that initial reaction was probably too dismissive.  So let me
ask the question more specifically and of a broader audience with
greater specific knowledge.

Is Ruby a good programming language for general purpose usage?  That is,
is it worth the time and effort to become proficient?

The problem is that ANY programming language will probably require tons
of study and years of practice before a developer achieves proficiency.
Is Ruby worth the investment for someone seeking a new programming
language?

I don't want to skew responses by specifying a particular application or
usage.  However, please DO respond with qualified answers if you feel
that is appropriate.  Again, I don't want to sway responses by
specifying a background for the learner.  Might be a relatively new
student of programming, might be an old-timer with decades of
development experience.  Let's just assume reasonable intelligence,
interest and inclination to learn a new programming language.  Given
that,

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

On Feb 2, 2010, at 7:19 AM, Jim Maher wrote:

> The problem is that ANY programming language will probably require tons
> of study and years of practice before a developer achieves proficiency.
> Is Ruby worth the investment for someone seeking a new programming
> language?

I'm far from an expert on this list, but in my two years of experience 
with Ruby I'd say unequivocally yes, Ruby is worth learning.  It's 
improved my programming generally.

Rails is a framework for the web written in Ruby, so if you're coming to 
this as a web developer, then Rails is an excellent introduction to 
Ruby.  That's where I started and it's branched out to where Ruby has 
become my sysadmin scripting language of choice as well.

Jose
.......................................................
Jose Hales-Garcia
UCLA Department of Statistics
jose.halesgarcia@stat.ucla.edu

>
> This was surprising to me, since my understanding is that Java and C (et
> al) are
> most prevalent.
>

It all depends on the application. For desktop apps on Linux, for 
example,
you'll find that C and C++ are the most popular. For web apps, it's 
probably
still PHP. For "The Enterprise," it's Java or .NET.


> Is Ruby a good programming language for general purpose usage?  That is,
> is it worth the time and effort to become proficient?
>

I personally feel that every language is worth the time and effort. But
languages are what I'm into, so my opinion is slightly skewed. However, 
Ruby
is tied for my favorite language, so I'd still think that it's worth
learning.


> The problem is that ANY programming language will probably require tons
> of study and years of practice before a developer achieves proficiency.
> Is Ruby worth the investment for someone seeking a new programming
> language?
>

Well, again, it depends on what you want to do. Writing GUI apps in 
Windows?
Yeah, Ruby will work, and would probably be more enjoyable for me than 
using
.NET, but it's probably easier to use C#. Writing web applications?
Absolutely use Ruby. Want to do some cross-platform scripting tasks?
Absolutely use Ruby. Want to put a little bit of joy and fun back in
programming? That's Ruby. There's other reasons, too, but those are my 
main
uses.


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

Well, without context, Ruby is a great language because when most people
think of OOP, they think of the C++/Java version of OOP, not Smalltalk 
style
message-passing OOP.

Actually I made up the term "object-oriented", and I can tell you I did 
not
> have C++ in mind.

 - Alan Kay


So if you've never programmed in that style, Ruby will teach you a thing 
or
two. Also, (some) Ruby emphasizes meta-programming more than any 
language
this side of Lisp, which is a wonderful, mind-expanding experience.

While the Rails culture is not the Ruby culture, it's absolutely the 
most
forward thinking group of people I've ever been involved with in terms 
of
software engineering. You won't find another community that's more 
obsessed
with Doing Things the Right Way. No other community values testing like
Rails does, for example.


Anyway, by now, I'm kind of rambling. Final word: Yes, absolutely worth
learning.

Yes, it is a good general programming language. Three main features I 
have
in mind:

- the syntax helps you expressing what you want easily and intuitively

- high-level abstractions (from iterators/blocks to complex 
meta-programming
features) help you breaking big problems in smaller problems without 
being
required to introduce explicit interfaces, templates, etc.

- test/unit and rspec help you writing a lot of tests without being 
annoyed
by the task.

In my opinion you cannot answer the question without reasonably 
"specifying
a background for the learner". A good language should make you a better
developer everyday, helps you reading other's code, helps you learning 
about
test-driven devel, and so on. Ruby expects some background, but also 
helps
you getting that background quickly.

B

On Tue, Feb 2, 2010 at 4:32 PM, Jose Hales-Garcia <

What languages do you already know?

Every good programmer must know at least on scripting language.
Ruby is a good choice.

Ruby: (I'm still noob)
  + nice language. You can be productive without being proficient!
  However for very large projects you may prefer languages which have
  static typing features (which catch more errors at compile time).
  I've read one thread telling that Ruby is bad for large projects
  because many things can be done in different ways. If you have
  different programmers working on projects you have to think about them
  all.
  However it is at least as good as Python(?), Perl(?) and much better 
than
  PHP. So learning Ruby will never be a waste of time.

What alternatives could you learn?

PHP:
 + you can get many code
 + many (all?) hosting services provide PHP support
 + it will never die because it's used often
 + easy to get started with
 - Basically they clone Java .. But fail because PHP is slower
   and it lacks behind.
 - you never know when syntax or similar errors occur..
   So live with this risk.
 - no lambda like functions
 - projects such as Phalanger or roadsend are not widely used.
   So I think the language is kind of stalled. It's kept alive
   because many projects are using it. But if you start learning a new
   language don't choose PHP.


- bash,zsh,.. (shell scripting)
  You can get many tasks done with Ruby. Unless you want to use
  interactive functions in Shell I'd even recommend ruby.

- Python
  I don't know the language that well. But I think that Ruby can express
  some things nicer. However they have some cool libraries such as SQL
  alchemy. (Don't know about Ruby ORM mappers)

- Scala (based on JVM)
  If you already know Java I'd say you should at least know about it.
  I don't know it very well. Nice: you can reuse Java libraries.

- Haskell
  It's cool. However it's not that widely used. Many libraries are still
  missing. Community is small but growing.
  It's interesting how much the small community has done.
  However it takes some time until packages are updated to run with
  latest GHC.
  However you will never have decent completion. So writing using
  foreign libraries always mean you have to dive into the type and look
  functions up yourself.
  - : no stack traces (there is monad-error library)
  - : big binaries (?). So don't write simple scripts in it..
  +/-: it's lazy. This can be nice and it can be hard to find bugs.
       Eg if you use
         contents <- readFile f
         writeFile f $ map (\_ -> 'x') contents

       you should think this does what you expect:
       read a file, change each character to 'x' and
       write the file into the same location..
       Now Haskell is lazy. It opens the file but doesn't read it.
       The second line truncates it so nothing is left to be read..

  When ignoring this kind of issue it's a very powerful language.
  If your application compiles it almost always work.

HaXe:
  Small community. But they get done a lot. HaXe targets C/C++, Neko,
  PHP, JavaScript, ActionScript (Flash). They are working on IPhone
  support etc as well (AFAIK).
  It has a strong type system.
  However because it's not use by very much users you may have to write
  some libraries yourself. However you can reuse them on any platform
  then.

Java:
  + great IDE's
  + many libraries (for everything you can think of?)
  - Some things are hard to learn, much xml.
  compared to Ruby you can't just write list.map {|v| conevrt v }.
  You end up writing for loops over and over again.
  But that's why other languages on top of JVM have been invented.

F#,C# .. The way to go on Windows today (?)

C: If you want to learn about segmentation faults and what a pointer is
  or if you want to do Linux kernel development you have no choice. You
  have to learn this language.

Erlang: Many concurrency frameworks? Well suited to get 99% uptime
  (At least they claim it..) don't know much about it.

Lisp: I don't know it very well. There is some movement as well. They
have webframeworks and there are dialects running on JVM as well which
indicates that the community (or parts of it) are moving as well.
http://clojure.org/.list

Be aware that a new language is being invented at least once a month.
So it depends on what you're looking for.

I'd say you should know basics of
C (so that you know what a pointer is ..)
Java (because you'll learn about IDEs. )
Haskell (to see what can be done if you study the language for over 2 
years.. hehe)
PHP (kidding. PHP is only good for web development. But then I'd rather 
choose Ruby)

In any case it may be faster to hire someone knowing the tool of choice
for a given task then learning the language yourself.

So in the end if you know many people knowing Ruby well. Go for it.
It will help you a lot if you can just ask your neighbor occasionally
when you're stuck. If you want to solve a particular problem do some
research. If a solution exists take that (no matter which language it
was written in).

I hope this helps you a little bit.
Marc Weber

El Martes, 2 de Febrero de 2010, Marc Weber escribió:
> - Python
>   I don't know the language that well. But I think that Ruby can express
>   some things nicer. However they have some cool libraries such as SQL
>   alchemy. (Don't know about Ruby ORM mappers)

Sequel, ActiveRecords, DataMapper... :)

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

Ruby is an object-oriented language.  If you like OOL languages, then 
Ruby is perfect for you.  It allows you the freedom to create without a 
lot of constraints.

Ruby on Rails is not a language but a framework, much like PHP is a 
language but it is also composed of different frameworks.  Ruby on Rails 
is a big reason why people learn Ruby, but it's not the only reason, 
just one of them.

Here are the absolute PROs to using Ruby:

* You can setup multiple ruby installations anywhere -
C:\ruby
C:\ruby19
C:\rubyisgood
C:\myrubyisbetter
.. for multiple versions and work with all of them.  It supports 
Windows, Linux, and MAC.

* There are multiple types of ruby, each suited just for you!

Ruby EE (Enterprise Edition - non windows)
JRuby (Java compiled Ruby)
Ruby 1.8.7 (standard)
Ruby 1.9.x (latest)
etc..

* You have multiple graphical libraries you can use, dependent
 on your style of GUI design:

FxRuby
WxRuby
Tk
Monkeybars
etc. etc. the list goes on and on

* You have one of the biggest if not the best frameworks to use with 
Ruby on Rails and a community that is so thriving around it, that there 
is an average of 200+ emails per day just from that community alone in 
support of development and response.  So, if you like web development, 
this is the right place for that.

In only one year of ruby development and 10 months of ruby on rails 
development, I've created 3 full production web-sites, including one 
paid subscription site, and a handful of console applications.  I'm 
working on a full-featured GUI application and having a lot of fun with 
wxruby.

In other-words, you can do a lot with Ruby in a short amount of time. 
There is instant gratification.

And, lastly, there are multiple testing environments for your code from 
TDD to BDD with Rspec, Cucumber, etc. and not many language communities 
thrive on the idea of testing - ruby does.

The CONS:

For me the cons really revolve around documentation, but mainly with the 
older RDOC styles that Ruby uses.  The older RDOC styles are harder to 
read, IMO, compared to something like Microsoft's MSDN library where 
everything is search-able and organized in a way that I enjoy.  Others 
might disagree with me and feel that the older RDOC style is fine.  But, 
to each his own.

Versioning differences can be difficult to understand and follow unless 
you are in the core mainstream hub and understand all of the nuances of 
what is being changed, updated, or coerced.  But, if you are new to the 
language, you might not suffer from that as badly if you stick with 1.9+ 
as there is now a compiler for windows and you can easily install from 
mac and linux.

===

Other than that, you have my take on it.  I have programmed in many 
different languages and Ruby is the one for me now.

I am not encouraging to learn PHP instead of Ruby, but:

<…>
> PHP:
<…>
>  - you never know when syntax or similar errors occur..
>   So live with this risk.

What?

>  - no lambda like functions

Available since PHP 5.3

<…>


Regards,
Rimantas

Ruby is a delight to program in. After spending the (short) time it 
takes to grok Ruby, every other language you use will feel tedious and 
limiting by comparison. You will feel like other languages are wasting 
you, the programmer's, time.

Ruby is also the rising star of the programming world. The main thing 
that was holding it back--execution speed--is going to be addressed 
quite well with the upcoming Ruby 2.0 release. The new version is as 
fast than the closest competing language, Python.

I think everyone should know a high-level "scripting" language and a 
lower-level compiled language. Ruby and Java are a good combo, 
especially since you can easily use Ruby together with Java thanks to 
JRuby.

On Tue, Feb 2, 2010 at 3:19 PM, Jim Maher <jdmaher@jdmaher.com> wrote:

>
> Is Ruby a good choice as a general usage programming language?  Why (or
> why not)?
>
>
Quick answer: Yes.

Ruby is a more sophisticated language than either Java or C# that you
mention.
Technically Java/C# have less features, so there should be less to 
learn, in
practice
that means a lot of your learning is postponed until you encounter the
various
parts of the ecosystem required to be productive.

However, you can be productive at a very early stage when learning Ruby.
Mastery
is not a requirement to get useful work done. Checkout the Ruby toolkit
Shoes or
HacketyHack to get an appreciation of what can be accomplished by 
complete
novices
in Ruby.

I have over a decade of experience with Java, and the largest ruby 
program I
have
written, barely tips the scales at 1000 LOC, but I still turn to Ruby 
when I
need to
get stuff done. In many cases I find I am more productive in Ruby than 
in
Java for
equivalent tasks.

I'm more of application developer and  hacker than professional
programmer, but I've  learned the rudiments and used to varying degree
maybe 10 languages, and dabble in many, many more, and I seem to always
checking out some new one, it's a fascinating evolution.  Learning Ruby
is fun and a  good investment if this is what you like, the more
languages you learn,  indirectly you learn more about  computer
operating systems, theory, etc  and the easier it is to learn new ones.
Each one has  a crowd of  passionate advocates. Ruby was very innovative
when it first came out, it was the first language  specifically for
rapid web site development,and has been very influential, but many of
it's best ideas have been subsumed into Java (groovy, gails) and php
(cake/php), for example. Ruby has a wonderful group  of users, and
because of them it will probably continue to be very influential, but
only  has a tiny market share. As an example, Twitter was founded on
Ruby, however has found not to be sufficiently scalable.

Brian Wolf
gOgO development, ltd
sedona,az

Brian Wolf wrote:
[...]
> As an example, Twitter was founded on
> Ruby, however has found not to be sufficiently scalable.

That wasn't the fault of Ruby.  It was the fault of poor DB design, and 
possibly of Rails.

> 
> Brian Wolf
> gOgO development, ltd
> sedona,az

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org

>
>   As an example, Twitter was founded on Ruby, however has found not to be
> sufficiently scalable.
>
>
http://highscalability.com/blog/2009/9/22/how-ravelry-scales-to-10-million-requests-using-rails.html

On Tue, Feb 2, 2010 at 11:29 AM, Brian Wolf <brw314@gmail.com> wrote:

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

I think the problems that lead Twitter to move their backend to Scala 
are
more architectural than they are issues with Ruby as a language.

Tony Arcieri wrote:
> On Tue, Feb 2, 2010 at 11:29 AM, Brian Wolf <brw314@gmail.com> wrote:
> 
>> As an example, Twitter was founded on Ruby, however has found not to be
>> sufficiently scalable.
>>
> 
> I think the problems that lead Twitter to move their backend to Scala 
> are
> more architectural than they are issues with Ruby as a language.

My point exactly.  And to the OP's question:

I use Ruby because it's better designed than virtually any other 
language in common use.  It's object-oriented from the ground up (unlike 
Java or C++), with a healthy dose of functional programming thrown in. 
This combination is extremely powerful and expressive -- not to mention 
exhilarating.  With Ruby, I can develop better code faster than other 
languages, and have more fun doing it.  It is my language of choice for 
applications programming.

Why not Ruby?  Unless you're doing low-level systems programming or 
certain real-time applications, I can't think of a good reason.  And 
even in those domains, Ruby might be a good choice as a wrapper around C 
or something...

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org

El Martes, 2 de Febrero de 2010, Marnen Laibow-Koser escribió:
> With Ruby, I can develop better code faster than other 
> languages, and have more fun doing it.

I think this is one of the keys of Ruby: it's really *fun* to code it.


> Why not Ruby?  Unless you're doing low-level systems programming or 
> certain real-time applications, I can't think of a good reason.  And 
> even in those domains, Ruby might be a good choice as a wrapper around C 
> or something...

Well, when you need some features as real parallelism (various native 
threads
running at same time using different CPU's) Ruby is not a good choice 
(well,
JRuby allow it thought).

On 2 Feb 2010, at 20:33, Iñaki Baz Castillo wrote:
> El Martes, 2 de Febrero de 2010, Marnen Laibow-Koser escribió:
>> Why not Ruby?  Unless you're doing low-level systems programming or 
>> certain real-time applications, I can't think of a good reason.  And 
>> even in those domains, Ruby might be a good choice as a wrapper around C 
>> or something...
> 
> Well, when you need some features as real parallelism (various native threads 
> running at same time using different CPU's) Ruby is not a good choice (well, 
> JRuby allow it thought). 

And you've always got parallelism via multiple processes - often a much 
saner architectural choice.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On 2 Feb 2010, at 15:19, Jim Maher wrote:
> Is Ruby a good choice as a general usage programming language?  Why (or
> why not)?

Ruby is a fun language to learn and incredibly flexible to work with: 
pick your favourite coding paradigm and Ruby will support it easily. 
Indeed of the many languages I've mucked about with in three decades of 
hacking it's the one I find closest to natural language, and that makes 
it ideally suited to writing simple programs that solve real-world 
problems in a maintainable manner.

If you're working in a Unix or Windows environment Ruby also meshes 
quite nicely with existing libraries and the underlying operating 
system. There's some work involved but that'd be equally true in most 
other high-level languages.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

On 2010-02-02, Jim Maher <jdmaher@jdmaher.com> wrote:
> I've asked several friends and associates (application developers) what
> programming language they recommend for new development.  The most
> prevalent answer was Ruby (with Ruby-On-Rails a close second).  This was
> surprising to me, since my understanding is that Java and C (et al) are
> most prevalent.

Seems plausible.

> Is Ruby a good programming language for general purpose usage?  That is,
> is it worth the time and effort to become proficient?

I think so.

Background:  I'm a pretty decent shell programmer (I wrote a book on
portable shell scripting), and a pretty decent C programmer (was on 
standards
committee for quite a while, also I actually write code).

I love working in C.  It's a very comfortable language for me.  However, 
it's
sort of a hassle to do some kinds of things, like string manipulation. 
You
can, and if you do it carefully you can have it be both bulletproof and
reasonably efficient... But it's a lot of work.  So sometimes I like to 
use
scripting languages.  Obviously, I learned perl, way back when perl5 
wasn't
even out yet.  I've also done C++ (only a little), Java (a bit more),
Objective-C (a fair bit), and a few others.

Ruby is a really pleasant language to work in.  It's expressive, and
well-suited to putting things clearly without a lot of extra verbiage. 
The
language favors writing tiny little helper functions which make it easy
to express things clearly, and help you avoid repeating yourself.
The object model is clear and, well, pretty.  It avoids the hassle Java
has with some things being Objects and other things being Not Really 
Objects,
partially through trickery.

A big part of the fun of Ruby is that it doesn't feel all half-baked and
rushed.  It seems to attract programmers who think a lot about the 
developer
experience of using an interface, rather than treating it as a checklist 
of
necessary functions, haphazardly named.  A strong sense of effective 
style
and good conventions (the ? and ! suffixes on method names), for 
instance,
makes Ruby code often much more readable.

-s

Twitter just needed to spin up a few more dynos ;) <3 Heroku

So I started programming in C, a couple years ago, and pretty much 
started
in Ruby at that same time, but I didn't know anything about programming, 
and
anything about Ruby. My class taught me C, and I figured out how to
translate that into Ruby. As a consequence, my Ruby programs were 
directly
mappable (pretty much line by line) into C programs, lol.

I think that C has some important things to offer, but as a first 
language,
it's offerings seem limited to weeding out students in a 100 student 
"first
programming" course. C, being directly translatable into assembly, which 
is
just a software representation of actual hardware implemented commands, 
is
very "close to the road". And there are a lot of potholes, and steep
embankments. I think you should know about pointers, and you should have
some idea of how what you are learning is represented in hardware. C 
seems
good for this purpose, and it does seem like a good language for really
learning about data structures, because it is so close to the road, very
little implementation is hidden away in magic. But that said, while it 
has
some educational benefits, students will not come out of it feeling 
prepared
(or being prepared) to do anything actually useful. It will feel too 
much
like academic masturbation, and will be frustrating as well, because 
there
are so many nuances and subtleties in C that will keep you up all night
banging your head until you finally find some blog post or article about 
it.
So, I don't recommend C as a first language, it is too discouraging, 
with
too little reward.

Java was the next thing we learned, and my C-styled ruby code suddenly 
began
to look like my Java code, because I finally figured out what a class,
instance, method, etc were. I absolutely loved this class ( to be fair, 
I
mostly loved the C class as well, b/c of what we were learning, even 
though
I didn't like the language ). Java is able to show you a lot of the same
things as C, without all the headache. We went through a thousand pages 
in
Walter Savitch's book Absolute Java (honestly, the best text book I've 
ever
had), and I decided that I wished I would have learned Java first, you 
can
get all the same knowledge (and more), except for pointers, which 
probably
need to be understood before references make sense (meaning underneath 
the
hood) And it has a nice API with lots of functionality. But, it does 
have a
lot of  boiler plate code, you make your method, then you make your 
setter,
then you make your getter. Think about the wall of code necessary to
implement a Swing application. So all in all, I would consider Java a 
decent
first language.

Then I took Assembly, which was where I really began to figure out what 
goes
on underneath the hood of C. Earlier I said you should be able to map 
what
you learn to what the computer is _actually_ doing, well, I think most 
of
that happened when I took Assembly. Which is even more of a pain to 
write in
than C. But it implies something interesting, it contradicts most of the
academic reasons for choosing C as the first language. It seems that to
someone starting out, programming is programming, it is all magic,
regardless of it's abstraction, and only later does it get grounded to
anything realistic. With that thought, it makes sense to choose a 
language
that allows for high levels of productivity, with low levels of
configuration, boiler-plate, headache, hoop-jumping, special cases, etc.
They say if you throw a frog into a boiling pot, he'll jump right out, 
but
slowly increase the temperature, and he'll stay until cooked. If you are
trying to keep the interests of beginning programmers, take out 
pointless
hurdles, give them a language with a nice learning curve, that they can
quickly see the fruits of their efforts, and enjoy it long enough to 
want to
take languages like C and Assembly, for the knowledge it will give them.

So I was able to do Ruby, at least as well as my C and Java, then I got
excited about it, started reading books, began interning at a design 
shop
that used Rails, and somewhere along the way realized that I quite like 
Ruby
:) My ability to do anything meaningful with Ruby exceeds my ability to 
do
anything meaningful with C or Java a thousand times over, because of 
things
like ruby-toolbox.com and gemcutter.org

You can still teach recursion and stacks and queues and hashes with 
Ruby. It
might be a little more mocking of your efforts since those are all
implemented in the language by default, but you're reinventing the wheel
regardless of whether you code one in C or Java or Ruby. The point is 
the
abstract knowledge, which you can get with any of these languages.

So, why Ruby as opposed to some other high level language? I don't know,
probably any high level language would be appropriate. I don't know 
enough
about others to compare them. But I will say that Ruby has a certain 
ability
to express ideas in ways that feel natural, as opposed to syntactic. It 
is
also very easy to get started, but there are a large amount of things 
you
can learn, which will give you a better survey of other languages out 
there.

As far as Rails goes, I tried going through AWDWR, and it took forever, 
and
was frustrating. Probably this is due to the book being aimed at web 
devs
from other languages, which I was not, but there is a lot to know with 
Rails
before you can get started. In this regard, I think that Sinatra makes a 
lot
of sense as a first web framework. Like Ruby, it has a very low barrier 
for
entry, and you can get off the ground and start going with just a little 
bit
of knowledge. It also translates quite nicely into Rails relevant 
knowledge
as it's programs grow in complexity. Rails I think is worth learning, it 
is
a truly amazing framework written in Ruby. It will help you see 
effective
ways to create, use, and design your code, and teaches a lot of good 
coding
practices. If you are interested in Rails, I think that after you get 
the
really basic basics down, then guides.rubyonrails.org is probably the 
best
resource out there (better than the api, and most books).

So, yes, I think that Ruby would be a good first language, and will 
progress
nicely into fun/interesting/useful code quickly, but wouldn't say it
_should_ be the first language, just that it would probably be a 
rewarding
choice, allowing you to focus on programming at an abstract enough level 
to
easily touch on important concepts without the overhead of syntax vomit,
contorted workflows, and tedious grinding away that some languages turn
into. And I think that Rails is a fantastic framework, but for a first
framework, I'd suggest Sinatra.

I know of three Ruby books aimed at newcomers to Ruby, but haven't read
them.

The Well-Grounded Rubyist (Manning) *http://tinyurl.com/yba72rn *by 
David A
Black, which is supposed to really present Ruby in a clear way that 
makes it
easy to understand what is happening and why. I'd expect to come away 
with a
really solid understanding of the language itself, and how to program in
general. In other words, I'd expect to "get it".

Beginning Ruby (Apress) *http://tinyurl.com/ybssb2x* by Peter Cooper, 
which
is aimed at taking people from beginner status, teaching them Ruby, and
introducing them to lots of useful/cool/rewarding gems, the Amazon page 
says
it hits Sinatra, so that might make a good choice if you are interested 
in
it.

Learn to Program (PragProg) *http://tinyurl.com/y9a9g4x *by Chris Pine, 
I
don't know much about him/the book, but it seems geared towards people 
brand
new to programming.

Hope that helps :)*
*

> >  - you never know when syntax or similar errors occur..
> >   So live with this risk.
> What?
If you compare PHP with Java you can extend abstract classes in PHP
which will give a runtime error. I'm sure there are some PHP analysis
tools which can detect this kind of error before running your web
application.

> >  - no lambda like functions
> Available since PHP 5.3
He thanks. I only knew about create_function.
For those who are to lazy to look it up (PHP lambda summary):
  Syntax looks like this:

    [static] function (/*args*/) use (&$x, $y) { /* body */ };

  You can use "use" to put vars into the scope of the function body.
  Note that & will create references to the var, no matter which type
  its contents has. If you don't use "use" vars which are also present 
in
  outer scope will be null.. [static] is used to not include the $this
  reference.

So maybe PHP get's closer. Can you do this as well now?
  echo new FooBar()->fun();

About parallelism: I only used ruby to run some php -l commands to check
syntax in parallel. It's perfect for this kind of task: Create a quick
work list, start 3 threads and pop items off from that list.
That's why I recommended learning Ruby rather than PHP. Because PHP
can't get this job done although it is a scripting language.

Marc Weber

I realize I'm late to the party, but...

On Tuesday 02 February 2010 09:19:32 am Jim Maher wrote:
> I've asked several friends and associates (application developers) what
> programming language they recommend for new development.  The most
> prevalent answer was Ruby (with Ruby-On-Rails a close second).  This was
> surprising to me, since my understanding is that Java and C (et al) are
> most prevalent.

Quite possible, but it depends entirely what you're doing.

> Is Ruby a good programming language for general purpose usage?

That depends what you're trying to do.

> I don't want to skew responses by specifying a particular application or
> usage.  However, please DO respond with qualified answers if you feel
> that is appropriate.

A quick analysis of Ruby's weaknesses:
 - Even once you hack in support for Lisp-like macros, it's likely not 
going
to feel as natural as Lisp.
 - Slow. Not as slow as people suppose it is, but it's not C, or even 
Lisp.
 - Can be difficult to bundle into one exe, so it _may_ be difficult for
Windows desktop applications.

Now, I never got enough into Lisp to get really good at macros, and 
Ruby's
syntax is still flexible enough to do interesting things with it -- in 
fact,
at least a few of the great examples I've seen of Lisp macros can be 
done in
Ruby, though they obviously aren't Macros in Ruby.

So my answers are mostly going to be qualified by the other two 
concerns. Ruby
is my favorite language in every other respect, so I'm going to say, 
choose
Ruby for everything except places where you actually need vertical 
performance
(performance on a single machine) -- but actually measure it, don't just
assume! -- and for places where your target output is a single .exe, 
unless
you can figure out a better way to bundle a Ruby app for Windows.

This does mean, by the way, that Ruby is ideal for web development. You
control the installation (so you just make sure to get a web host which
supports Ruby, or which gives you enough control to use it), and you can
always throw more hardware at it, which is cheaper than developer time. 
There
are exceptions to this rule, but when you actually get to the point 
where
you're so big that it's worth a few months of developer time to shave 
10% off
in performance, that's a nice problem to have, and it's worth getting 
there
before your competitors do.

> That is,
> is it worth the time and effort to become proficient?

That's a different question.

I never use Lisp, and I still consider it worth the time and effort to 
at
least learn the language. Ruby is very easy to pick up, and you should 
be able
to see very quickly whether or not it's worth the time and effort to 
become
_more_ proficient.

If you already know Java, many concepts will translate right over, but 
the
beauty of Ruby's syntax will make it hard for you to look at a Java 
program
again.

The biggest reason you should learn Ruby is to understand what it means 
for
code to look pretty, and why you might want your code to look pretty. 
Look at
some Ruby on Rails examples, and try to keep in mind that Rails is 
written in
pure Ruby -- that is, Rails is a Ruby library that adds this kind of 
thing:

30.seconds.from_now

However...

> Again, I don't want to sway responses by
> specifying a background for the learner.  Might be a relatively new
> student of programming, might be an old-timer with decades of
> development experience.

This is also not something you can remove from the question. Again, if 
you
already know Java, some of the object model will be easier to 
understand, like
the concept of object references. If you know C++, it may take a bit for 
you
to understand why it's weird to ask about "passing by value" in Ruby, 
versus
"passing by reference".

Similarly, if you're just starting out, it depends who you ask -- I 
would say
you should learn Ruby, so you get excited about programming, and so you
actually start programming faster, without having to learn about nasty 
low-
level things like pointers and memory allocation. Others would say just 
the
opposite -- you should start low-level, so that by the time you get to 
Ruby,
you understand exactly what the language is doing under the covers. 
Either
way, you should eventually learn both high-level and low-level 
languages, for
the same reason -- you want to understand just what you're asking the 
language
to do for you.

On the other hand, if you are already incredibly proficient in something 
like
assembly language or COBOL, you might find that you've already found 
your
niche, and your job will likely not become obsolete -- so you might want 
to
learn Ruby as a curiosity, but it's questionable how useful it will be 
to the
actual work you do. If you're already incredibly proficient in Lisp, 
Ruby
might be a hard sell, because there are specific, measurable ways that 
Ruby is
less powerful than Lisp -- the biggest reason I prefer Ruby is syntax, 
and
most Lisp people _like_ s-expressions.

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.

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

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/blob/master/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.

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/blob/master/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

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)

On 8 February 2010 21:12, Brian Candler <b.candler@pobox.com> wrote:
>
> (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 = 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/blob/master/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

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

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

On 8 February 2010 22:00, Seebs <usenet-nospam@seebs.net> wrote:
>>
>> (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

Hi!

Ruby is nice when you want to have a straight-forward, easy to use 
language.
You can write stuff very quickly, there are few restrictions and it is 
very
constistent (OOP). There are also some nice specials like blocks and 
mixins.
Ruby has good support for additional libraries (e.g. Qt+KDE for GUI).
But also when you simply want to calculate some things you can easily 
write
100 lines of Ruby. You should also consider that Ruby is terribly slow. 
E.g.
if you want to try it a few billion cases in an algorithm, that is often
possible in realistic time in C++ or even Java but not in Ruby. It is 
even
slower than scripting-languages like Python or Falcon. Currently C++ and 
Ruby
are my favourtire language, C++ does not know a lot of limits, is very 
fast
and provides very cool things with templates etc. (compile time meta-
programming), but it is also a bit complicated and inconstistent, Ruby 
is a
really nice toy I use wheneverit is easily possible.
A lot of people say that C++ is horrible, very inconsistent and 
complicate.
But that is not true. Most stuff is very consistent but it takes more 
time to
learn it, it is easier to think like Ruby than to think like C++.
And please do not learn Java, it is simply a stupid language, 
inconsistent
like C++, not as dynamic as Ruby and not as fast and not as many 
compile-time
capabilities as C++.

Jonathan

------------------------
Automatisch eingefügte Signatur:
Es lebe die Freiheit!
Stoppt den Gebrauch proprietärer Software!
Operating System: GNU/Linux
Kernel: Linux 2.6.31.8-0.1-default
Distribution: openSuSE 11.2
Qt: 4.6.2
KDE: 4.4.62 (KDE 4.4.62 (KDE 4.5 >= 20100203)) "release 2"
KMail: 1.13.0
http://gnu.org/
http://kde.org/
http://windows7sins.org/

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.

Jonathan Schmidt-Dominé - Developer wrote:
> Hi!
> 
> Ruby is nice when you want to have a straight-forward, easy to use 
> language.
> You can write stuff very quickly, there are few restrictions and it is 
> very
> constistent (OOP). 

Yup.

> There are also some nice specials like blocks and 
> mixins.

Those aren't specials; they're core language features.

> Ruby has good support for additional libraries (e.g. Qt+KDE for GUI).
> But also when you simply want to calculate some things you can easily 
> write
> 100 lines of Ruby. You should also consider that Ruby is terribly slow. 
> E.g.
> if you want to try it a few billion cases in an algorithm, that is often
> possible in realistic time in C++ or even Java but not in Ruby.

Depends on the implementation.  MRI is slow (I wouldn't say "terribly" 
slow).  Ruby EE and YARV are faster.  JRuby is probably faster yet.  All 
are plenty fast enough for most general-purpose applications.

> It is 
> even
> slower than scripting-languages like Python or Falcon. Currently C++ and 
> Ruby
> are my favourtire language, C++ does not know a lot of limits, is very 
> fast
> and provides very cool things with templates etc. (compile time meta-
> programming), but it is also a bit complicated and inconstistent, Ruby 
> is a
> really nice toy I use wheneverit is easily possible.
> A lot of people say that C++ is horrible, very inconsistent and 
> complicate.
> But that is not true. Most stuff is very consistent but it takes more 
> time to
> learn it, it is easier to think like Ruby than to think like C++.

Sorry, no.  C++ looks inconsistent because it is: it's C with some 
object orientation bolted on.

> And please do not learn Java, it is simply a stupid language, 
> inconsistent
> like C++, not as dynamic as Ruby and not as fast and not as many 
> compile-time
> capabilities as C++.

Java's more consistent than C++, and more portable.  I don't much like 
Java, but I'll use it over C++ any day.  And of course the JVM is 
fabulous when coupled with a *decent* language like JRuby.

> 
> Jonathan
> 
> ------------------------
> Automatisch eingef�gte Signatur:
> Es lebe die Freiheit!
> Stoppt den Gebrauch propriet�rer Software!
> Operating System: GNU/Linux
> Kernel: Linux 2.6.31.8-0.1-default
> Distribution: openSuSE 11.2
> Qt: 4.6.2
> KDE: 4.4.62 (KDE 4.4.62 (KDE 4.5 >= 20100203)) "release 2"
> KMail: 1.13.0
> http://gnu.org/
> http://kde.org/
> http://windows7sins.org/

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org

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

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.

On 2010-02-08, Sebastian Hungerecker <sepp2k@googlemail.com> wrote:
> 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.

That might work.

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 not 
all
characters are a single byte.

So there's really two *separate* semantic changes.

1.  Subscripting gives textual data rather than raw numbers.
2.  Sometimes that textual data isn't a single byte.

These are related, but not quite the same.  The issue, I think, is that 
the
first implies the second, because some encodings have single bytes which 
are
not a character, but rather, the preamble to a character.

-s

Seebs wrote:
> 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.

Seebs wrote:
> 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.

2010/2/8 Marnen Laibow-Koser <marnen@marnen.org>:
>>     a = b + c
>> Even the same program running on two different computers with the same
> 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

on Tue, Feb 9, 2010 at 3:46 PM, Robert Klemme
<shortcutter@googlemail.com> wrote:

> 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.  Maybe 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

botp wrote:
> on Tue, Feb 9, 2010 at 3:46 PM, Robert Klemme
> <shortcutter@googlemail.com> wrote:
> 
>> 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. �Maybe 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..?

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
marnen@marnen.org

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

Marnen Laibow-Koser wrote:
> 
> 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[i] ^= 0x80 if (line[i] & 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

>> 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.

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

Jim Maher wrote:

> 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

On Monday 08 February 2010 03:05:18 pm Seebs wrote:
> 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.

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.

2010/2/10 David Masover <ninja@slaphack.com>:
> encoding, something like ASCII-8BIT, to mark the string as raw.
> 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 strings,
> arrays, and binary data all have a similar duck-type.

Absolutely.

> And the short-term answer is to use "raw" strings, because they're already
> 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

On Tue, Feb 2, 2010 at 11:29 AM, Brian Wolf <brw314@gmail.com> wrote:

> 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:

http://vimeo.com/9225227