From: Josh Cheek Date: 2013-03-05T15:12:05+09:00 Subject: Re: YourLanguageSucks --f46d042f9642fed3c904d72759fa Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 4, 2013 at 7:39 PM, Kiswono Prayogo 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/ http://ruby-doc.org/downloads/ 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 ( http://ruby-doc.org/stdlib-2.0/libdoc/open3/rdoc/Open3.html), 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 ( http://ruby-doc.org/stdlib-2.0/libdoc/shellwords/rdoc/Shellwords.html) 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. https://github.com/JoshCheek/seeing_is_believing/blob/496c5350c1e641d9d26213af1a3ebc56b1e38205/lib/seeing_is_believing/line.rb#L12-18 > 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 https://github.com/JoshCheek/surrogate/blob/master/lib/surrogate/argument_errorizer.rb#L16I 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 --f46d042f9642fed3c904d72759fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2013 at 7:39 PM, Kiswono Prayogo <kiswono@gmail.com>= 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.
=A0
No real support for arbitrary keyword arguments (key=3Dvalue pairs in
function definitions are positional arguments with default values)
>> ?


Deprecated as of Ruby 2.0=A0
=A0
The documentation is not versioned.
>> is it?


It is:
http://ruby-doc.org/core-2.0/
http://ruby-doc.org/core-1.9.3/
http://ruby-doc.org/downloa= ds/
=A0
Although, it's not obvious how to switc= h between versions at other docs sites.


Using @ and @@ to access instance and class members can be unclear at a gla= nce.
>> no!


Frankly, I'm of the opinion that @= @ should be removed altogether, it makes no sense and is dangerous.
=A0
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


I don't think this is deprecated, = there is nothing that I know of which enforces this. Though people typicall= y try to follow standards such as=A0http://s= emver.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 mean= s, beyond maybe something like `lambda { |&block| block.call }.call { &= #39;whatever' }` in which case, I've never hit the bug (and I do a = lot of stuff like this).
=A0
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 refin= ements, but they're experimental, and polarizing. There are lots of lib= s which litter the core classes, sadly (I'm of the opinion that you sho= uld 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&#= 39;m not sure what they're concerned about. Maybe I'm just more con= scientious 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 yo= u use mutable keys (and also mutate them?) I don't think I've ever = been hit by this one.
=A0
Omitting parenthesis in function calls enable you to
implement/simulate property setter, but can lead to ambiguities.
>> ?


This is true, e.g.

class A
=A0 attr_accessor :value
=A0 def ini= tialize
=A0 =A0 value =3D 1
=A0 end
end
=
A.new.value # =3D> nil

Really, though, this is caused by the ambiguity b= etween initialization and assignment. What this person is complaining about= here, I actually consider a feature (it encapsulates implementation detail= s from code that invokes those methods, consider an alternative like JavaSc= ript, where if you switch from an attribute to a method, then you have to g= o update everything that uses it).
=A0
Minor ambiguities between the hash syntax and blocks (closures), when
using curly braces for both.
>> ?


This is still true, but pretty rare. O= nly really comes up for me when doing things like RSpec let blocks, which I= might have defined to return a hash of initialization params.
=A0
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.
=A0
The unless keyword (=3Dif 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.<= /div>

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 f= eature
=A0
"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 yo= u code in a way that I would consider peculiar (I guess I code in such a wa= y that things like this are just not a problem, e.g. I minimize my public a= pi, 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).
=A0
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 u= nderstandable oversight. For this, you use the open3 stdlib (http://ruby-doc.o= rg/stdlib-2.0/libdoc/open3/rdoc/Open3.html), not system/backtix/%x
=A0
`` 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. sys= tem "ls", user_submitted_filename), and if you do need to interpo= late for some reason, there is the shellwords stdlib for this (http:= //ruby-doc.org/stdlib-2.0/libdoc/shellwords/rdoc/Shellwords.html)

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.=
=A0
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.=A0<= a href=3D"https://github.com/JoshCheek/seeing_is_believing/blob/496c5350c1e= 641d9d26213af1a3ebc56b1e38205/lib/seeing_is_believing/line.rb#L12-18">https= ://github.com/JoshCheek/seeing_is_believing/blob/496c5350c1e641d9d26213af1a= 3ebc56b1e38205/lib/seeing_is_believing/line.rb#L12-18
=A0
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


I think this person is completely corr= ect here, I have lost many hours to issues stemming from this. There's = even multiple implementations of "indifferent access" hashes, whi= ch 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<= br> 'end', expecting end of input"
>> ?


This particular example is better in newer Rubies: &= quot;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. I= n one of my libs, I show the signature if the method is incorrectly invoked= =A0https://github.com/JoshCheek/surrogate/blob/= master/lib/surrogate/argument_errorizer.rb#L16 I should probably also a= dd the arguments.

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

-Josh
--f46d042f9642fed3c904d72759fa--