From: Cliff Rosson Date: 2013-03-05T12:52:28+09:00 Subject: Re: YourLanguageSucks --0016e6d27525e4cfb504d725669f Content-Type: text/plain; charset=ISO-8859-1 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 --0016e6d27525e4cfb504d725669f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is kind of a neat webpage. The guy goes through a whole= list of languages. I wonder how much of it is=A0accurate? Like Chris said = that is a whole lot of time spent....

<= br>
On Mon, Mar 4, 2013 at 6:34 PM, Chris Hulan <chris.hulan@gmail.com> wrote:
if only people with this much=A0energy=A0for complaining c= ould channel it into
fixing the problems, or even creating their own=A0= perfect=A0language...


On Mon, Mar 4, 2013 at 8:39 PM, Kiswono Prayogo <kiswono@gmail.com>= wrote:
Hi, i found this link.. =A0https://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 "l= ower case,"
and the method should be called "lowercase" or "lower".= And
String#upcase should have been called "uppercase" or "upper&= quot;.
>> i agree, i found this annoying when i learn Ruby for the first tim= e

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=3Dvalue 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 gla= nce.
>> 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 m= ultiple
recommended stable versions: both 1.8.7 and 1.9.1 for Windows. Which
one to use?
>> =A0deprecated

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.
>> =A0deprecated?

There's some minor gotchas. nil.to_i turns nil into 0, but 0 does not evaluate as nil. nil.to_i.nil? #=3D> false
>> i disagree, this is fine

String#to_i just ignores trailing characters, meaning: "x".to_i = =3D=3D 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 (=3Dif 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" !=3D :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<= br> 'end', expecting end of input"
>> ?

--
Regards,
Kiswono P
GB





--
=
vizualiz= e.me/cliffrosson
--0016e6d27525e4cfb504d725669f--