From: tamouse mailing lists Date: 2013-03-05T13:24:16+09:00 Subject: Re: YourLanguageSucks On Mon, Mar 4, 2013 at 9:52 PM, Cliff Rosson 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 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 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.