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 <[email protected]> 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 > > -- [email protected] | https://groups.google.com/d/forum/ruby-talk-google?hl=en --- You received this message because you are subscribed to the Google Groups "ruby-talk-google" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
