YourLanguageSucks

Kiswono_P · March 5, 2013, 2:40am

Hi, i found this link… YourLanguageSucks - TheoryOrg
on part “Ruby sucks because:”
i guess nearly half of them are just made up /irrelevant /deprecated…

String#downcase? Who calls it “downcase?” It’s called “lower case,”
and the method should be called “lowercase” or “lower”. And
String#upcase should have been called “uppercase” or “upper”.

i agree, i found this annoying when i learn Ruby for the first time

Unicode support should have been built in from 1.0, not added after
much complaining in 1.9/2.0 in 2007

deprecated

No support for negative / positive look-behind in regular expressions in
1.8

deprecated

Regular expressions are always in multi-line mode

?

No real support for arbitrary keyword arguments (key=value pairs in
function definitions are positional arguments with default values)

?

The documentation is not versioned.

is it?

Using @ and @@ to access instance and class members can be unclear at a
glance.

no!

There are no smart and carefully planned changes that can’t break
compatibility; even minor releases can break compatibility: See
“Compatibility issues” and “fileutils”. This leads to multiple
recommended stable versions: both 1.8.7 and 1.9.1 for Windows. Which
one to use?

deprecated

Experimental and (known to be) buggy features are added to the
production and “stable” releases: See “passing a block to a Proc”.

?

The documentation is unchecked: it has dead links, like Things Any
Newcomer Should Know

?

The documentation is not up to date: Ruby C API Reference refers to
version 1.8.4, but the latest stable release is 1.8.7.

deprecated?

There’s some minor gotchas. nil.to_i turns nil into 0, but 0 does not
evaluate as nil. nil.to_i.nil? #=> false

i disagree, this is fine

String#to_i just ignores trailing characters, meaning: “x”.to_i == 0

i disagree, this is fine

Ruby allows users to modify the built in classes, which can be useful,
but limited namespace means addons can conflict. Experienced
programmers know to add functionality through modules rather than
monkey patching the built in classes, but is still prone to abuse.
This has been promised to be resolved in ruby 2.0

deprecated

Aliased methods in the standard library make reading code written by
others more confusing. E.g. Array#size/Array#length,
Array#[]/Array#slice

i disagree, this one is fine

Mutable strings in a dynamic language! This means e.g. when a string
is passed to a setter it should copy the string so the object can be
sure that it won’t change unexpectedly.

?

Mutable types like arrays are still hashable. This can cause a hash to
contain the same key twice, and return a random value (the first?)
when accessing the key.

?

Omitting parenthesis in function calls enable you to
implement/simulate property setter, but can lead to ambiguities.

?

Minor ambiguities between the hash syntax and blocks (closures), when
using curly braces for both.

?

Suffix-conditions after whole blocks of code, e.g. begin … rescue
… end if expr You are guaranteed to miss the if expr if there are a
lot of lines in the code block.

?

The unless keyword (=if not) tends to make the code harder to
comprehend instead of easier.

no, i guess not

Difference between unqualified method calls and access of local
variables is not obvious. This is especially bad in a language that
does not require you to declare local variables and where you can
access them without error before you first assign them.

?

“Value-leaking” functions. The value of the last expression in an
function is implicitly the return value. You need to explicitly write
nil if you want to make your function “void” (a procedure).

just adding nil would be find right?

pre-1.9: No way to get stdout, stderr and the exit code (all of them
at once) of a sub process.

deprecated?

`` syntax with string interpolation for running sub processes. This
makes shell injection attacks easy.

?

Regular expressions magically assign variables: $1, $2, …

?

Standard containers (Array, Hash) have a very big interfaces that make
them hard to emulate.

emulate for what reason?

Symbols and strings are both allowed and often used as keys in hashes,
but “foo” != :foo, which led to inventions like
HashWithIndifferentAccess.

i believe this is fine

Parser errors could be more clear. “syntax error, unexpected kEND,
expecting $end” actually means “syntax error, unexpected keyword
‘end’, expecting end of input”

Kiswono_P · March 5, 2013, 3:34am

if only people with this much energy for complaining could channel it
into
fixing the problems, or even creating their own perfect language…

Kiswono_P · March 5, 2013, 4:53am

It is kind of a neat webpage. The guy goes through a whole list of
languages. I wonder how much of it is accurate? Like Chris said that is
a
whole lot of time spent…

Kiswono_P · March 5, 2013, 5:25am

On Mon, Mar 4, 2013 at 9:52 PM, Cliff R. [email protected]
wrote:

i disagree, this is fine

Mutable types like arrays are still hashable. This can cause a hash to

?
Difference between unqualified method calls and access of local
pre-1.9: No way to get stdout, stderr and the exit code (all of them
Standard containers (Array, Hash) have a very big interfaces that make
‘end’, expecting end of input"

–
Secure & Reliable End-To-End Credentials Support | Parchment

Never underestimate the power of boredom.

Kiswono_P · March 5, 2013, 7:12am

On Mon, Mar 4, 2013 at 7:39 PM, Kiswono P. [email protected]
wrote:

Regular expressions are always in multi-line mode

?

Was this ever true? It hasn’t been since I’ve been using Ruby (about 5
years), unless I was just too noob when I started to realize it.

No real support for arbitrary keyword arguments (key=value pairs in
function definitions are positional arguments with default values)

?

Deprecated as of Ruby 2.0

The documentation is not versioned.

is it?

It is:
http://ruby-doc.org/core-2.0/
http://ruby-doc.org/core-1.9.3/

Although, it’s not obvious how to switch between versions at other docs
sites.

Using @ and @@ to access instance and class members can be unclear at a

glance.

no!

Frankly, I’m of the opinion that @@ should be removed altogether, it
makes
no sense and is dangerous.

There are no smart and carefully planned changes that can’t break
compatibility; even minor releases can break compatibility: See
“Compatibility issues” and “fileutils”. This leads to multiple
recommended stable versions: both 1.8.7 and 1.9.1 for Windows. Which
one to use?

deprecated

I don’t think this is deprecated, there is nothing that I know of which
enforces this. Though people typically try to follow standards such as
http://semver.org/ to mitigate the issue.

Experimental and (known to be) buggy features are added to the

production and “stable” releases: See “passing a block to a Proc”.

?

I don’t really know what this means, beyond maybe something like lambda { |&block| block.call }.call { 'whatever' } in which case, I’ve never hit
the bug (and I do a lot of stuff like this).

Ruby allows users to modify the built in classes, which can be useful,
but limited namespace means addons can conflict. Experienced
programmers know to add functionality through modules rather than
monkey patching the built in classes, but is still prone to abuse.
This has been promised to be resolved in ruby 2.0

deprecated

Not really deprecated, there are refinements, but they’re experimental,
and
polarizing. There are lots of libs which litter the core classes, sadly
(I’m of the opinion that you should never do it in library code, and
generally avoid it everywhere).

Mutable strings in a dynamic language! This means e.g. when a string
is passed to a setter it should copy the string so the object can be
sure that it won’t change unexpectedly.

?

People complain about things like this a lot, but I’ve only ever ran
into
issues with it once or twice so I’m not sure what they’re concerned
about.
Maybe I’m just more conscientious about things like this?

Mutable types like arrays are still hashable. This can cause a hash to

contain the same key twice, and return a random value (the first?)
when accessing the key.

?

This is true, but how frequently do you use mutable keys (and also
mutate
them?) I don’t think I’ve ever been hit by this one.

Omitting parenthesis in function calls enable you to
implement/simulate property setter, but can lead to ambiguities.

?

This is true, e.g.

class A
attr_accessor :value
def initialize
value = 1
end
end
A.new.value # => nil

Really, though, this is caused by the ambiguity between initialization
and
assignment. What this person is complaining about here, I actually
consider
a feature (it encapsulates implementation details from code that invokes
those methods, consider an alternative like JavaScript, where if you
switch
from an attribute to a method, then you have to go update everything
that
uses it).

Minor ambiguities between the hash syntax and blocks (closures), when
using curly braces for both.

?

This is still true, but pretty rare. Only really comes up for me when
doing
things like RSpec let blocks, which I might have defined to return a
hash
of initialization params.

Suffix-conditions after whole blocks of code, e.g. begin … rescue
… end if expr You are guaranteed to miss the if expr if there are a
lot of lines in the code block.

?

This is true, but pretty uncommon.

The unless keyword (=if not) tends to make the code harder to
comprehend instead of easier.

no, i guess not

I don’t find this to be the case.

Difference between unqualified method calls and access of local

variables is not obvious. This is especially bad in a language that
does not require you to declare local variables and where you can
access them without error before you first assign them.

?

Already addressed: I consider this a feature

“Value-leaking” functions. The value of the last expression in an
function is implicitly the return value. You need to explicitly write
nil if you want to make your function “void” (a procedure).

just adding nil would be find right?

This is true, but only a problem if you code in a way that I would
consider
peculiar (I guess I code in such a way that things like this are just
not a
problem, e.g. I minimize my public api, often to just a #call method,
and
anything which leaks such a value is clearly a command and not intended
to
have a return value).

pre-1.9: No way to get stdout, stderr and the exit code (all of them
at once) of a sub process.

deprecated?

This isn’t true, but it’s an understandable oversight. For this, you use
the open3 stdlib (
Module: Open3 (Ruby 2.0.0)), not
system/backtix/%x

`` syntax with string interpolation for running sub processes. This
makes shell injection attacks easy.

?

Just don’t put user submitted code in backticks. It can be a little
cumbersome, but if you’re passing it as an argument, you just don’t
interpolate it into the string (e.g. system “ls”,
user_submitted_filename),
and if you do need to interpolate for some reason, there is the
shellwords
stdlib for this (
Module: Shellwords (Ruby 2.0.0))

Regular expressions magically assign variables: $1, $2, …

?

This is true. I believe it comes from Perl. It’s a bit awkward, but I
don’t
really see a problem with it.

Standard containers (Array, Hash) have a very big interfaces that make
them hard to emulate.

emulate for what reason?

I have found this to be true, e.g.

github.com

JoshCheek/seeing_is_believing/blob/496c5350c1e641d9d26213af1a3ebc56b1e38205/lib/seeing_is_believing/line.rb#L12-18


      
          class SeeingIsBelieving
            # thin wrapper over an array, used by the result
            class Line
              def self.[](*elements)
                new(elements)
              end
          
          
    include HasException
              include Enumerable
          
          
    # delegate all methods to the array, but return self where the array would be returned
              Array.instance_methods(false).sort.each do |method_name|
                define_method method_name do |*args, &block|
                  result = @array.__send__ method_name, *args, &block
                  result.equal?(@array) ? self : result
                end
              end
          
          
    def to_a
                @array.dup
              end

Symbols and strings are both allowed and often used as keys in hashes,
but “foo” != :foo, which led to inventions like
HashWithIndifferentAccess.

i believe this is fine

I think this person is completely correct here, I have lost many hours
to
issues stemming from this. There’s even multiple implementations of
“indifferent access” hashes, which try to mitigate the issue, but really
just make it easy to lose track of what type the keys should be.

Parser errors could be more clear. "syntax error, unexpected kEND,

expecting $end" actually means “syntax error, unexpected keyword
‘end’, expecting end of input”

?

This particular example is better in newer Rubies: “syntax error,
unexpected keyword_end”, but in general, I totally agree. For example, I
think that errors like “`exit’: wrong number of arguments (3 for 1)
(ArgumentError)” could be much more helpful. In one of my libs, I show
the
signature if the method is incorrectly invoked

github.com

JoshCheek/surrogate/blob/master/lib/surrogate/argument_errorizer.rb#L16I


      
          attr_accessor :name, :empty_lambda
          
          
def initialize(name, lambda_or_method)
            must_be_lambda_or_method lambda_or_method
            self.name, self.empty_lambda = name.to_s, lambda_with_same_params_as(lambda_or_method)
          end
          
          
def match!(*args)
            empty_lambda.call *args
          rescue ArgumentError => e
            raise ArgumentError, e.message + " in #{name}(#{lambda_signature empty_lambda})"
          end
          
          
private
          
          
def lambda_with_same_params_as(lambda_or_method)
            eval "->(" << lambda_signature(lambda_or_method) << ") {}"
          end
          
          
def lambda_signature(lambda_or_method)
            lambda_or_method.parameters.map { |type, name| param_for type, name }.compact.join(', ')

should probably also add the arguments.

Anyway, a pretty read. We should pay attention to things like this, it’s
relevant feedback as it highlights things we’ve grown accustomed to, but
that stick out to newcomers.

-Josh

Kiswono_P · March 5, 2013, 8:59am

On Tue, 05 Mar 2013 07:12:05 +0100, Josh C. [email protected]
wrote:

Regular expressions are always in multi-line mode

?

Was this ever true? It hasn’t been since I’ve been using Ruby (about 5 years),
unless I was just too noob when I started to realize it.

Yes, and still is. “multi-line mode” means that ^ matches the beginning
of a line, and $ the end of a line, instead of beginning/end of a string
(Ruby uses \A and \Z / \z for this).

Kiswono_P · March 5, 2013, 1:09pm

On Tue, Mar 5, 2013 at 8:57 AM, Bartosz D. [email protected]
wrote:

Yes, and still is. “multi-line mode” means that ^ matches the beginning of
a line, and $ the end of a line, instead of beginning/end of a string (Ruby
uses \A and \Z / \z for this).

Note that Ruby’s “multi line” mode is about matching of “.” and not
about anchoring of ^ and $. I’m not even sure there is a general
definition of “multi line mode” for regular expressions across
language.

“a\nb\nc”[/^.$/]
=> “a”
“a\nb\nc”[/^.$/m]
=> “a
b
c”

Cheers

robert

Kiswono_P · March 5, 2013, 1:27pm

On Tue, 05 Mar 2013 13:08:24 +0100, Robert K.
[email protected] wrote:

c"
In reasonable languages this is called a ‘dotall’ mode and denoted with
an ‘s’ modifier.

Calling it ‘multiline’ is dumb and confusing, so let’s not do this ;
it is in fact also called ‘singleline’ in some sources (which is even
dumber).

Kiswono_P · March 5, 2013, 1:16pm

On Tue, Mar 5, 2013 at 4:39 AM, Kiswono P. [email protected]
wrote:

String#downcase? Who calls it “downcase?” It’s called “lower case,”
and the method should be called “lowercase” or “lower”. And
String#upcase should have been called “uppercase” or “upper”.

i agree, i found this annoying when i learn Ruby for the first time

I disagree. There is a general pattern of using verbs for method names,
and
I personally read both String#upcase and String#downcase as verbs and
find
them more consistent than the suggested “lower[case]” and “upper[case]”:
while “lower” can be a verb, “upper” definitely can’t.

Anyway, it’s a minor point, but it is the one I can comment on for now.

Regards,
Yaser

Kiswono_P · March 5, 2013, 3:16pm

On Tue, Mar 5, 2013 at 1:26 PM, Bartosz Dziewoński [email protected]
wrote:

=> “a”

“a\nb\nc”[/^.*$/m]

=> “a
b
c”

In reasonable languages this is called a ‘dotall’ mode and denoted with an
‘s’ modifier.

What is a “reasonable language”?

Calling it ‘multiline’ is dumb and confusing, so let’s not do this ; it
is in fact also called ‘singleline’ in some sources (which is even dumber).

Since there are two different anchors for begin / end of line and
begin / end of string a multi line mode which switches anchoring
behavior of ^ and $ does not really make sense in Ruby. For me the
issue claimed on the web site referenced does not exist.

Glancing over the list I wouldn’t worry too much. Some information is
outdated, some information is completely subjective. There are also
“issues” which are common to multiple language. That might be an
indication that the criteria are not widely shared.

Kind regards

robert