[ale] Ruby vs C, a non-technical chat

[DJ-Pfulio]

TL;DR - I love ruby AND perl.  Too many noobs using php.

On 08/06/2015 11:00 AM, Derek Atkins wrote:
> James Sumners <james.sumners at gmail.com> writes:
> 
>> On Thu, Aug 6, 2015 at 9:19 AM, leam hall <leamhall at gmail.com> wrote:
>>
>>     With Ruby, I can say "It's on the machines, so I can use it".
>>
>> That's an important bit of information. Under such circumstances my preference
>> is for Python. I just like the language better (truly, I can't stand the sight
>> of Ruby). As for contrived performance, they're pretty much even -- 
>> http://benchmarksgame.alioth.debian.org/u64/ruby.php
> 
> Strangely, I'm quite the opposite -- I can't stand the sight of Python!
> (Syntactic whitespace??  YUCK -- Reminds me of RPG-2).

The day I have to care how many spaces I put into a program is the day they will
shot me in the head.

I'm all for whitespace - beautifiers should enforce that, NOT the language.
There are many reasons for this, but I suppose those reasons don't matter in
python, because there isn't any choice.  In other languages which do allow
optional blocking, one of the most common errors is when people decide not to
use the blocking syntax and assume a 1 liner after an "if" carries on when a 2nd
line is entered.  The indentation CAUSED the issue/bug.

>> One of the things to consider is who else will have to maintain your code?
>> Which languages do they prefer or are proficient with? Around my shop we've had
>> a Ruby guy leave which meant all his stuff died because no one knows the
>> language (or cares to).
> 
> I spent a few months teaching myself Ruby and RoR a few years ago.  I
> actually like the Ruby language a lot; it has all the best features from
> many different langauges thrown together.  My biggest beef with RoR,
> however, is that it's a constantly moving target.  If I write a RoR app
> today and use a bunch of gems, if I want to then share that development
> with another group it's just... hard!  Every system needs to have the
> exact same environment.  And then god help you if you need to pick up a
> system a year later; everything has moved on and you can't get the old
> gems anymore and the new gems have changed something fundamental such
> that your app doesn't work...  :-(

Actually, this forces people to deploy application containers. I've been out of
the RoR stuff for awhile, but we used either rvm or rbenv back in the day.  This
is actually a best-practice for anyone not using the system version of the
languages (which is a worst-practice) for any non-trivial application. You CAN
get the old gems.  That is what bundler is for.

However, you aren't wrong.  Seems the primary way the core ruby guys make money
is forcing everyone to buy a new book every year to learn where they've moved
stuff in the new Rails.  I can open **any** rails app and know where 95% of the
things are - THAT is convenient.  By checking the ruby and rails versions used,
the other 5% become clearer.  There are lots of "magic places" with RoR - that
is certain.

Chef has lots of "magic places" too - I left some all-day training after 3 hrs
when that became clear.  "Magic places" that don't follow an existing pattern
make me crazy - that's part of the reason I love Ansible.  No magic. Stuff goes
where you put it. It uses relative paths. It is clear from where included files
come.

> So you're basically in a situation where you're constantly using
> bleeding-edge code because if you don't (and don't keep up) you get
> stuck.
> 
> But this has nothing to do with Ruby as a language.

I love ruby as a language too. Just hope they make it faster someday.  I'm still
waiting for Java to be fast like Sun promised in 1995. Glad I didn't hold my breath.

I must admit, after programming in Rails for a day, it is good to get back to
Perl and Dancer.  I miss perl after being forced to use anything else. Ugly perl
is easy to create. Elegant perl exists too.  Perl is like the English language -
there are subtle constructs which behave completely different from each other,
yet accomplish the same goal.  1 might be 20x faster than the other and in
expert hands, perl can be the most beautiful language. In expert hands, perl can
be unreadable by noobs. Perl isn't the answer to everything, but the last decade
it seems to be a pariah. OTOH, the quality of shared perl code (via CPAN) is
probably higher than the shared repos for any other language. That's what
happens when noobs find a language too hard.

Sadly, that hasn't been an issue for php. I wish people writing php would learn
that just because something works, that doesn't mean it is correct or secure. I
won't hold my breath on that.

In my career, I've learned perhaps, 35 languages. Most of which people here have
never heard of - they were for support of real-time GN&C systems unrelated to
Windows, MS-DOS, Unix.

I don't have enough desire to learn javascript - all the javascript code I've
ever seen looks like spaghetti. It is an ugly language, from what I've seen.