Re: YourLanguageSucks

On Mon, Mar 4, 2013 at 9:52 PM, Cliff Rosson <[e-mail]> wrote:
> 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....
>
>
> On Mon, Mar 4, 2013 at 6:34 PM, Chris Hulan <[e-mail]> wrote:
>>
>> if only people with this much energy for complaining could channel it into
>> fixing the problems, or even creating their own perfect language...
>>
>>
>> On Mon, Mar 4, 2013 at 8:39 PM, Kiswono Prayogo <[e-mail]> wrote:
>>>
>>> Hi, i found this link..  https://wiki.theory.org/YourLanguageSucks
>>> 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"
>>> >> ?
>>>
>>> --
>>> Regards,
>>> Kiswono P
>>> GB
>>>
>>
>
>
>
> --
> vizualize.me/cliffrosson

Never underestimate the power of boredom.