What are your ruby rough cuts?

[luislavena]

Hi rubyists,

this is a general census to get developer feedback. Please post the
issues you encounter when developing in ruby. This can range from
syntax issues, to library support, documentation, or anything that is
a roadblock when developing in ruby.

After the thread settles down, I will build a report. This could be
useful to know, for example, what actions to take next to make our
favorite language shine even better. I can’t guarantee it will be
taken in consideration by the core developers, but at least I can
assure you I will try to pick the ones I can handle and solve them
myself.

To avoid having this thread get out of hand, please follow these three
rules:

• Don’t post more that once in this thread (+1 count as a post :-p)
• Try to be constructive on your remarks
• If you really have to answer a specific point, make a new thread
  (it can be done by changing your reply’s subject)

Let the remarks flow !
zimbatm

[zimbatm]

Here are a few things I can think of:

• Regexp ^ and $ work match more than just start and end of string. For
  example, /^abc$/ does not match only “abc” but also “rm -rf /*\nabc”

• http://innig.net/software/ruby/closures-in-ruby.rb

• Using write accessors: you must write self.foo=123 instead of foo=123
  (the latter sets a local variable)

• Similarly, having to use self.class instead of class

• auto-splat

• class variables (@@foo), just try working out the semantics

• Lots of junk inherited from Perl, such as implicit operations on $_
  and flip-flop operator

• Spaces are semantically important, even within a line

  puts (-3).abs # prints 3
  puts(-3).abs # raises NoMethodError

• The whole of ruby 1.9 String handling is arguably one huge paper cut.
  GitHub - candlerb/string19: Runnable documentation of ruby 1.9's M17N properties

Regards,

Brian.

[zimbatm]

David M. wrote in post #975080:

On Friday, January 14, 2011 07:34:04 am Jonas P. (zimbatm) wrote:

A final point: Browsers are getting fast enough that we should be able
to do
Ruby in Javascript. And not a server-side implementation, either – I
want the
equivalent of JRuby. But this isn’t really a limitation of Ruby, it’s a
limitation of browsers that we’d be working around. The above rants are
things
I actually feel are broken about Ruby as it is today.

I’m sorry to take this slightly off topic, but I just can’t let this
comment pass. I am currently building a language called Quby, which is a
very Ruby-like language, that runs 100% in the browser (about 4,000
lines of JS). There are differences (as it’s Ruby-like not Ruby) with
the main one being that it’s tied to a canvas. But AFAIK it’s the
closest pure JS implementation of Ruby (although it’s Quby, not Ruby).

It’s still incomplete (no modules, classes but no inheritance and no
line numbers reported for runtime errors) but you can already build
things with it. Some examples are here: http://playmycode.com/play and
you can play about with it here: http://playmycode.com/build/sandbox
(feel free to signup and build something).

Back on topic, my number one gripe with Ruby has always been ‘unexpected
$end, expecting keyword_end’ parse error. It’s given when you load a
file but you’ve missed out an ‘end’ keyword somewhere in your script.
The parser has reached the end of the file and still expects to see one.
The main issue is that you could be missing an ‘end’ anywhere in your
script, yet it reports the error on the very last line (which is just
useless).

The workaround is to usually cut out large chunks of my code and re-run
until it parses, as this will tell me which chunk I am missing the end.
Even if your file is only 500 lines long this is very tedious work for
something that all other languages are typically good at.

I can understand why this might be very difficult (or impossible) for
Ruby to catch, but that doesn’t detract from it being very annoying. One
thing that could be done would be to just try to predict where the end
might be missing. This could be achieved if it looked at the tabbing of
the lines.

[zimbatm]

On Friday, January 14, 2011 07:34:04 am Jonas P. (zimbatm) wrote:

this is a general census to get developer feedback. Please post the
issues you encounter when developing in ruby. This can range from
syntax issues, to library support, documentation, or anything that is
a roadblock when developing in ruby.

In no particular order…

I wrote a long post because I don’t have time to write a short one. To
summarize:

RubyGems:

• Play nice with other package managers
• Better installers for end-users
• gems/rvm/bundler confusion

Library management:

• Better namespacing
• Better handling of monkeypatching

Multithreading:

• Threads are too primitive
• Actors would be cool, but have issues

Wish list:

• Lisp-style Macros.
• Ruby-in-Javascript.

And now the rant:

Right now, Rubygems is both the biggest win and the biggest blocker for
newbies. I haven’t been keeping track, so I find I now have to learn RVM
and
Bundler just to keep up with the best practices for deploying a Rails
app. And
how do these interact with the system Ruby? If I install a system
package that
depends on a particular version of Ruby, will it get the version it
expects,
or will it get my default RVM version?

Unfortunately, I don’t have a good answer for this, and I don’t really
know
much about the solutions that do exist, but nearly every one I’ve tried
has
been very messy in many ways. Installing gems to my home directory is
just not
a good idea.

Another thing that I’d like to see more work on – though I think
alright
solutions exist, especially for JRuby – is the ability to distribute
Ruby
clients. It seems like there are two solutions, one for developers, and
one
for end-users. The developer solution is to build it as a gem, but it’s
not
reasonable to ask an end-user to install Ruby, Rubygems, and then your
gem.
The end-user solution is to build it as a giant monolithic file which
includes
all relevant gems. Surely there’s a middle ground – a nice, intuitive
installer, but one which actually sets up a system Ruby and Rubygems for
the
user, so that multiple programs don’t have to separately download and
install
the same libraries.

And Rubygems itself – while it seems it’s capable of understanding
reverse
dependencies, I want to be able to automatically clean stuff that I
don’t need
anymore. Gemfiles are kind of a decent start, but I’m thinking something
along
the lines of “manual” vs “automatic” in Debian, or even better, Gentoo’s
/var/lib/portage/world. In particular, I want to be able to install a
gem just
to see what it does, and if I don’t like it, uninstall that gem and then
clean
up every gem that was only installed because it was depended on.

RVM’s gemsets are kind of cool, but they seem to be a workaround for not
having that functionality. The only other reason to have them seems to
be when
developing a gem.

One more thing about gems: How do we know what a good gem is? I love how
decentralized it is now, at least in theory, but occasionally it means I
need
to go through two or three gems and try each of them before I find
either that
none of them does what I want, or some oddly named and maybe
semi-obscure gem
is perfect.

Moving away from rubygems and installation, and to semantics…

A bit more namespacing would be awesome. The current practice of just
dumping
something you hope is appropriate into the global namespace of constants
is
bad enough. It’s worse when we start monkey-patching other stuff.

I don’t know how big a problem this actually is. It doesn’t seem to
actually
cause problems in practice, so maybe I’m overreacting. Still, I like how
Perl
and Python handle this, where there’s a difference between loading a
library
and importing it into your namespace.

Namespacing constants aggressively shouldn’t be too much of a burden, as
Ruby
has the same shortcuts JavaScript does. Take JRuby. Sure, you can do
this:

import java.util.PriorityQueue

But you can also do this:

pq = java.util.PriorityQueue

That’s locally-scoped, which means you aren’t polluting any namespace
past the
end of the current block. Or you could do something like:

module MyMod
PQ = java.util.PriorityQueue
…
end

In both of these cases, you aren’t affecting anything else in the same
runtime. But if you ‘import’ it globally, you’ve declared it, well,
globally.
Point is, I don’t think we should be afraid to do stuff like this,
though we
could use just a bit of sugar to make it easier:

module FooCo
module LibFooVersion213
class Foo
…
end
end
end

Ok, yes, people will get sick of typing that, but again:

foo = FooCo::LibFooVersion213::Foo

Problem solved.

Monkey-patching is harder. Is there a way we can scope things like
Activesupport’s hacks? Stuff like:

‘bird’.pluralize
5.days.ago
foo.should be_valid

I love these things, but I wish there was a way I could declare them to
be
only available in a certain context or scope. This seems like it needs
some
language support to be really effective – we could fake it now by
mixing them
in and out of the core classes as needed, but that would affect any
other
threads, so it kind of defeats the purpose if you’re using
multithreading.

Essentially, the idea here is that when multiple libraries inevitably
end up
using the same name for something, we should be able to work around it.
When
they don’t, we don’t want it to be a burden. (I think JQuery is a
perfect
example of this done right.)

Let’s get some proper multithreading, to start with. It’s 2011. There is
really no excuse for a GIL. Either drop it or mainstream COW GC –
otherwise,
JRuby becomes the only real option for multicore on Ruby.

How about some higher-level threading constructs, too. There are a few
gems
which add interesting ideas… However, there are limits to what you can
do
with Ruby as it is, and these are partly due to the fact that it’s not
Erlang.

Again, I’m not sure of the best way to do this, but…

We have objects, and objects can, in principle, completely encapsulate
their
state. We’ve actually got that implemented properly – just look at
send,
method_missing, the fact that we need accessors, etc. This would be a
perfect fit for the actor model, and it’s something I tried to do once,
but
never really finished – but essentially, why not “just” make all Ruby
objects
actors?

Aside from performance issues, but I was going to do a proof-of-concept
and
ignore those…

Well, I didn’t quite finish it, but one problem I ran into in the design
phase
is the fact that there’s entirely too much Ruby code which wouldn’t work
at
all with this kind of design. For example:

foo.a += 1

Sure, you can override foo.a and foo.a= and either add a giant mutex, or
push
them off to a separate thread. Either way, you’re still going to have a
race
condition between getting the value of a and setting it again. Something
like
this might work:

foo.increment! :a

If you were to view each object as an actor, and each method call as a
message, stuff like that works very, very well. I still want to finish
my
idea, because I think you could get a lot of mileage out of new objects
which
were designed from the start to be actors. I think you could do that
without a
lot of language overhead. I had a proof-of-concept partly done.

But that still doesn’t change the fact that this will never work:

foo.some_hash[:a] += 1

Even after you make sure foo is an actor, and the some_hash it returns
is some
sort of proxy object that serializes all access, you still have the race
condition between the call to [] and the call to []=.

I think that this kind of problem is exactly the kind of thing Ruby
should be
concerned with. The typical Ruby battle cry has been “Hardware is
cheaper than
programmers!” Well, alright, here’s a machine with a few thousand cores.
How
is Ruby going to handle that? Can the language itself be fixed, or does
there
need to be a new one that combines the best of Ruby with the best of
(say)
Erlang? (In other words, is something like Reia the way forward?)

I don’t know, but while it’s sort of workable now, it’s probably the
single
language flaw that keeps me up at night.

There is one other that just annoys the purist in me…

Is there any way we can get anything like Lisp sexps? As I understand
it, we
have a few Ruby parsers, but nothing standardized to the point where I
can ask
the runtime itself to give me a parse tree for a given expression. The
closest
I could find was various implementation-specific things and ruby_parser,
which
is cool but buggy, missing a few of the 1.9 features.

But that I can live without. My rationale is, pretty much any syntactic
ugliness can be worked around with a preprocessor if it’s really
bugging me
(see lazibi), and Ruby is pretty anyway. It’s semantic ugliness that’s
tricky.
Ruby doesn’t have GOTO, it doesn’t have pointers or malloc, it’s done
away
with pretty much every bit of low-level nastiness associated with
single-
threaded programming – but the Thread system makes me feel like I’m in
C
again, where the slightest mental mistake could lead to my entire
program
screwing up in unimaginably arcane ways.

A final point: Browsers are getting fast enough that we should be able
to do
Ruby in Javascript. And not a server-side implementation, either – I
want the
equivalent of JRuby. But this isn’t really a limitation of Ruby, it’s a
limitation of browsers that we’d be working around. The above rants are
things
I actually feel are broken about Ruby as it is today.

[zimbatm]

Joseph L. wrote in post #975106:

Back on topic, my number one gripe with Ruby has always been ‘unexpected
$end, expecting keyword_end’ parse error. It’s given when you load a
file but you’ve missed out an ‘end’ keyword somewhere in your script.
The parser has reached the end of the file and still expects to see one.
The main issue is that you could be missing an ‘end’ anywhere in your
script, yet it reports the error on the very last line (which is just
useless).

I understand your pain, I used to do the binary-chop thing too

The solution is to run your code through ruby 1.9 with -w flag; it warns
about indentation mismatches, which generally show where the problem is,
exactly as you described.

(This is the only reason I have a copy of ruby 1.9 installed)

[zimbatm]

On Jan 15, 2011, at 02:42 , Joseph L. wrote:

The workaround is to usually cut out large chunks of my code and re-run
until it parses, as this will tell me which chunk I am missing the end.
Even if your file is only 500 lines long this is very tedious work for
something that all other languages are typically good at.

The solution is to use a real ruby editor (emacs, vim, textmate, I’m
sure many others) that supports proper indentation. The problem pops out
visually and is easily solved before it is even a problem.

It is also prevented by using various “electric” (that’s the emacs term)
modes that keep your do/end/{}'s balanced automatically. I don’t use
this mode, but I see it preventing this problem automatically.

[zimbatm]

Ryan D. wrote in post #975115:

On Jan 15, 2011, at 02:42 , Joseph L. wrote:

The workaround is to usually cut out large chunks of my code and re-run
until it parses, as this will tell me which chunk I am missing the end.
Even if your file is only 500 lines long this is very tedious work for
something that all other languages are typically good at.

The solution is to use a real ruby editor (emacs, vim, textmate, I’m
sure many others) that supports proper indentation. The problem pops out
visually and is easily solved before it is even a problem.

I already do use a proper editor and indent my code correctly, but there
are times when they can still slip through. Regardless of if you chop up
your code or read straight through for mismatches, it’s still time
wasted on a really trivial typo.

[zimbatm]

On Fri, Jan 14, 2011 at 7:34 AM, Jonas P. (zimbatm) <
[email protected]> wrote:

taken in consideration by the core developers, but at least I can

Let the remarks flow !
zimbatm

Can’t help but notice that 2/3 of the OP’s rules are already violated

In no particular order

• All the gross-ness that is working with files.
  For an example, $ bones create some_project > /dev/null ; cat some_project/lib/some_project.rb
  Also, having to constantly File.dirname(FILE) everywhere. I always
  feel
  so embarrassed when I am showing non-rubyists code, and have to write
  something like that. Current dir is so common, it should have its own
  thing.
  And if I am going to see it in normal coding (which I am with the 1.9.2
  changes) then can it please not be wrapped in underscores.

• define_method should be public.
  Even the docs have to violate that in order to show how it could ever be
  useful. class Module - RDoc Documentation

• define_singleton_method should exist
  So you don’t have to do (class << self ; self ; end).send :define_method
  “meth” do end
  (okay, I know there is finally a singleton_method, and a public
  define_method would get rid of the send hack, but still

• Ranges should be able to go up and down
  I feel like they are a great idea, but have just way too little power.
  Really only used for things where there are already equivalent
  alternatives
  like iteration
  (1…5).each{} vs 1.upto(5).each{}

and checking boundaries (1…5) === 3 vs 1<=3 && 3<=5

• Ranges have weird behaviour when defined with 2 vs 3 dots.
  I would expect the internal representation to be the same, like single
  vs
  double quoted strings, but instead they are different. I assume this is
  to
  make it so you can use any data at all with a range, including your own.
  But
  I don’t think anyone ever does this, and I think it handicaps ranges and
  makes it dangerous to use them for anything more than the simplest of
  examples, like the ones given just above.

r1 , r2 = 0…5 , 0…4

enum1 , enum2 = r1.each , r2.each
r1.all? { |e1| e1 == enum2.next } # => true
r2.all? { |e2| e2 == enum1.next } # => true

r1 == r2 # => false

r1.first == r2.first # => true
r1.last == r2.last # => false

r1.last == r1.to_a.last # => false
r2.last == r2.to_a.last # => true
r1.to_a == r2.to_a # => true

• The ability to ask a method what file / line of code it was defined
  on.
  When code is defined with metaprogramming and it is hard to know where
  to go
  to figure out how it behaves
  http://twitter.com/tenderlove/status/25614816215310336
  http://twitter.com/tenderlove/status/25615989907394560

• It would be nice if we could play well with the Debian folks.
  I don’t know if there is a good solution to that or not, but I think it
  hurts our community. For example, they took Ruby off our school
  computers, I
  think for this reason (I don’t know that for certain, but our sysadmin
  doesn’t go for it if it isn’t blessed by Debian, and I’ve never heard of
  any
  other language being removed).

• Well documented STDLIB
  Somehow I keep finding new gems in here. I think it is because when I
  sat
  down to go through all the stdlibs, I didn’t have the knowledge to know
  what
  some stuff was, or how to use it, and it wasn’t documented. I think it
  would
  be a lot easier to appreciate if it was well documented. It also makes
  Ruby
  look neglected that some of it has no documentation at all.

• It would be nice to have a way to distribute work to non-developers
  I’m with David on this one, when I realized I had no way to reliably
  distribute something that was working on my computer to someone else,
  that
  was a sad day for me. I think it also makes other people take it less
  seriously, because all the programs they interact with are somehow
  distributed to them, but mine can’t. I tried playing with a few, I think
  they were ruby2exe, and ocra, but couldn’t figure out how to get them to
  work.

• I’d love to see a Ruby wiki
  Okay, this isn’t a language thing, but where people can aggregate
  knowledge
  on different topics. For example, we love to talk about how great
  testing
  is, but I had to wait more than a year to get the RSpec book. What if
  that
  information was easy to find, and comprehensive, and easy to update.
  Then
  instead of condescendingly saying “and you are testing, aren’t you?”
  (can’t
  remember who said that, but I wanted to smack them) you could say “go
  here
  for a tutorial to get you bootstrapped into the topic”. I still don’t
  know
  wtf a runner is, but at least I know how to make my rake files just as
  capable as if I ran the command by hand (which is how I have been
  handling
  it until now).

Or just generally, some community affirmed path to go from not knowing
something to knowing it. Rails has a wiki (not sure how good it is), and
they have the guides (which are really amazing), and they have
screencasts
that the whole community rallies behind.

I just learned about sockets a couple of days ago. From a Lisp book.
They
were always scary to me, but then I saw how easy they are, and couldn’t
help
but think “That’s it?! Why don’t I already know this?”

I guess I feel like I shouldn’t have to find my own way out of
ignorance, I
wish we had conspicuous, empowered, accredited, exciting, easy ways to
get a
piece of knowledge. And if anyone saw Uncle Bob’s Rails talk (
http://blip.tv/file/2089545/), he said “There is a tremendous amount of
effort being put in by people trying to create testing frameworks, and
easy
ways to test. So I am very encouraged by that, but I am not entirely
encouraged, because I think that this community is growing very rapidly,
and
the disciplines may not grow with it.” @ 27min. This is part of his
concern
that “what killed Smalltalk could kill Ruby too”.

That’s not to say that we don’t have anything, Satish T. and Gregory
Brown have each put a lot of work into really helping educate people. I
would like to see more of that, and have it be more comprehensive, and
more
prevalent.

Anyway, those are mine Hope they are helpful. If anyone wants to
address
any of them, just start a new thread.

[zimbatm]

On Saturday, January 15, 2011 04:42:58 am Joseph L. wrote:

I actually feel are broken about Ruby as it is today.

I’m sorry to take this slightly off topic, but I just can’t let this
comment pass. I am currently building a language called Quby, which is a
very Ruby-like language, that runs 100% in the browser (about 4,000
lines of JS). There are differences (as it’s Ruby-like not Ruby) with
the main one being that it’s tied to a canvas. But AFAIK it’s the
closest pure JS implementation of Ruby (although it’s Quby, not Ruby).

There are two major issues I have with that:

First, why did you feel the need to fork Ruby syntax? I think I saw your
post
earlier, and I remember writing a long rant and then not sending it, but
that’s really my main problem with it. Why create a new programming
language?

Reia has a good answer for that, incidentally, which was my other
complaint
about Ruby – in Reia, as I understand it, every object is an actor.
This at
the very least forces a different standard library, and so many Rubyisms
wouldn’t work that by the time you had a version of Ruby running on
Erlang, it
would look so different from Ruby on MRI that it’d hardly be worth
calling
Ruby.

The browser just doesn’t seem that way at all.

Also, why tie it to a canvas?

Back on topic, my number one gripe with Ruby has always been ‘unexpected
$end, expecting keyword_end’ parse error.
[…]
The workaround is to usually cut out large chunks of my code and re-run
until it parses, as this will tell me which chunk I am missing the end.
Even if your file is only 500

I agree that it’s annoying, but especially once you’re at the point
where
you’ve got 500-line files, you really should be using version control.
Then
it’s just a matter of looking at the ten or so lines you changed since
the
last revision, where it worked.

[zimbatm]

On Sat, Jan 15, 2011 at 3:45 PM, David M. [email protected]
wrote:

Reia has a good answer for that, incidentally, which was my other complaint
about Ruby – in Reia, as I understand it, every object is an actor. This
at
the very least forces a different standard library, and so many Rubyisms
wouldn’t work that by the time you had a version of Ruby running on Erlang,
it
would look so different from Ruby on MRI that it’d hardly be worth calling
Ruby.

In Reia, everything (including objects) falls into two fundamental
categories: immutable data, or concurrent processes (i.e. actors).

In its original incarnation, it’s true that all objects were actors.
However, this is no longer true. I haven’t yet reimplemented
concurrent-objects-as-actors, and instead the only objects presently
available in the language are implemented as immutable data only.

Ruby, interestingly enough, generally views state as immutable data. You
generally have to explicitly specify you want to mutate state by placing
a !
on the end of a method name (e.g. Array#reverse vs Array#reverse!). Most
operations are not mutable by default, but instead return new versions
of
the object in question with the given transformation applied.

The differences between Ruby and Erlang are not as large as many would
make
them seem (particularly in the Erlang camp)

[zimbatm]

This is a great post. Thank you! And just reading everyone’s response
helps so much!

@zimbtam, One request: Can you please post this as a wiki somewhere?
That way people can add to it as they go.

Some of mine:

1. A (somewhat) philosophical resistance to Enumerator.next? or
   Enumerator.has_next? IMO, reaching the end of iteration is not an
   exceptional condition, but Ruby treats it that way. So much so that 1.9
   adds a method in Kernel (loop) that squelches the StopIteration
   exception but continues to not provide this method.

2. Sometimes, I do think that Strings not being immutable bites in odd
   ways. I wish (sometimes) Strings were treated like Fixnums.

More as I run into them.

Regards,
Kedar

[zimbatm]

On Sat, Jan 15, 2011 at 2:59 PM, Tony A. [email protected]
wrote:

Ruby, interestingly enough, generally views state as immutable data. You
generally have to explicitly specify you want to mutate state by placing a !
on the end of a method name (e.g. Array#reverse vs Array#reverse!). Most
operations are not mutable by default, but instead return new versions of
the object in question with the given transformation applied.

That’s fairly misleading. There are lots of mutating operations in
Ruby that don’t have a ! at the end of the method name (and, IIRC,
there are some non-mutating methods that do have a !). The bang
notation generally distinguishes a more-dangerous operation from a
less-dangerous operation that has (aside from the bang) the same name.
It is very common for the danger noted by the distinction to be
between non-mutating and mutating operations that are otherwise
similar, but where no similar non-mutating method exists, mutating
methods generally don’t have a bang in their name (e.g., for instance
methods of Hash, clear, delete, delete_if, keep_if, rehash, replace,
store, and update are all mutating methods without the bang in their
method names, while only the three mutating methods with non-mutating
equivalents of otherwise-identical name have bangs: reject!, select!,
and merge!; in fact, update – with no bang – is a synonym for
merge!.)

[zimbatm]

On 01/15/11 21:42, Joseph L. wrote:

I am currently building a language called Quby

Sounds like fun! What are you using for parsing?

Back on topic, my number one gripe with Ruby has always been ‘unexpected
$end, expecting keyword_end’ parse error. It’s given when you load a
file but you’ve missed out an ‘end’ keyword somewhere in your script.

When I find one of these hard to see, ‘rbeautify’ almost always
clarifies things for me. Because it re-indents your source, you
can see where indentation doesn’t return to where you expected it.
It’s better than bisecting, anyhow.

Clifford H…

[zimbatm]

On Sat, Jan 15, 2011 at 5:34 PM, Christopher D.
[email protected]wrote:

Ruby, interestingly enough, generally views state as immutable data.

That’s fairly misleading. There are lots of mutating operations in Ruby

I don’t mean to be condescending, but if that’s your reaction, I don’t
think
you understand the meaning of the word “generally”

Can you provide an example of a mutable state language that defaults to
immutable operations and explicitly marks mutable operations as well as
Ruby
does?

Hint: it’s not Python.

[zimbatm]

On Jan 15, 2011, at 04:07 , Joseph L. wrote:

The solution is to use a real ruby editor (emacs, vim, textmate, I’m
sure many others) that supports proper indentation. The problem pops out
visually and is easily solved before it is even a problem.

I already do use a proper editor and indent my code correctly, but there
are times when they can still slip through.

I almost never have this happen in emacs (past a couple lines of
coding). It is pretty much automatically pointed out as soon as I hit
return and then later hit tab to indent. (I used to bind return to
newline-and-indent, but that gets really slow with larger files–esp w/
ruby).

Either you wind up with code like:

def x
if x then
blah

rest_of_method

end

or you wind up with:

def x
if x then
blah
end

rest_of_method
end
end

Hanging end or repeated end is a clear indicator that you slipped up and
either missed an end or added one too many.

[zimbatm]

On Sat, Jan 15, 2011 at 10:54 PM, Tony A.
[email protected]wrote:

Can you provide an example of a mutable state language that defaults to
immutable operations and explicitly marks mutable operations as well as Ruby
does?

Note: if you call Clojure a mutable state language, Rich Hickey will
kill
you and shit on your corpse.

[zimbatm]

David M. wrote in post #975191:

On Saturday, January 15, 2011 04:42:58 am Joseph L. wrote:

I actually feel are broken about Ruby as it is today.

I’m sorry to take this slightly off topic, but I just can’t let this
comment pass. I am currently building a language called Quby, which is a
very Ruby-like language, that runs 100% in the browser (about 4,000
lines of JS). There are differences (as it’s Ruby-like not Ruby) with
the main one being that it’s tied to a canvas. But AFAIK it’s the
closest pure JS implementation of Ruby (although it’s Quby, not Ruby).

There are two major issues I have with that:

First, why did you feel the need to fork Ruby syntax? I think I saw your
post
earlier, and I remember writing a long rant and then not sending it, but
that’s really my main problem with it. Why create a new programming
language?

First lots of small things I don’t such as nil, hash comments and Ruby’s
block comments. Secondly one of my main motivations was that I really
don’t like that so many trivial compile time bugs in the static
languages become runtime errors in dynamic ones, such as calling a
function or method that doesn’t exist anywhere in your code. Last year I
into a bar and got chatting to film student. When I mentioned I was web
developer he had a huge rant at me about how annoying these type of bugs
were in PHP. It also allows me to add extra things that I’d like to have
in Ruby.

Also, why tie it to a canvas?

The language was built specifically for that site where people can write
games, and those games use a canvas for graphics. The language itself is
built separately and could be deployed without a canvas, it’s just no
other site uses my language.

[zimbatm]

On Sunday, January 16, 2011 07:33:04 am Joseph L. wrote:

There are two major issues I have with that:

First, why did you feel the need to fork Ruby syntax? I think I saw your
post
earlier, and I remember writing a long rant and then not sending it, but
that’s really my main problem with it. Why create a new programming
language?

First lots of small things I don’t such as nil, hash comments and Ruby’s
block comments.

This is exactly what I’m talking about. I already know how to write
Ruby
with things like nil and hash comments. I don’t see why I should have to
learn
an entirely new syntax, and teach my editor an entirely new syntax, for
such
trivialities as replacing nil with null.

This just shouldn’t factor into it.

Secondly one of my main motivations was that I really
don’t like that so many trivial compile time bugs in the static
languages become runtime errors in dynamic ones, such as calling a
function or method that doesn’t exist anywhere in your code.

That’s fair – if this actually changes the language significantly, I
guess I
don’t see a problem with tweaking the syntax somewhat, although I
strongly
disagree with some of your improvements. (For example, there’s a good
reason
‘initialize’ is different than ‘new’.)

I think the general consensus among Rubyists is that the only difference
between stuff you catch statically and stuff you catch at runtime is
what
stage in your automated test run it will be caught. If you have code
which
calls a method that doesn’t exist, for example, and it never gets run in
your
tests, that’s a bug in your tests.

In any case, it sounds cool, but it also doesn’t quite fit what I was
asking
for. The main reason I dislike being forced to use Javascript isn’t that
I
don’t like Javascript, it’s the context switch between thinking in Ruby
and
thinking in Javascript. (I did seriously consider stuff like node.js…)

[zimbatm]

this is a general census to get developer feedback. Please post the
issues you encounter when developing in ruby. This can range from
syntax issues, to library support, documentation, or anything that is
a roadblock when developing in ruby.

Very little about Ruby annoys me, to be honest. By some freak of design
it seems that it synergises with the way my brain works.

However, nothing is perfect:

1. +1 for the whole “Gem is annoying” thing. “Gem install” works for
   me. But when I try to share my programs with non-ruby-coders, the
   whole thing gets silly and embarrasing. “I have to install what and then
   do WHAT?” To me it’s a hangover from the worst bits of Perl. And don’t
   get me started on Bundler and the like: improving Gem by installing a
   Gem? That’s not a solution, it’s an ugly band-aid.

2. Evens this is me and not Ruby, but what is it with ‘ri’? I can’t get
   it to return information about Gems I have installed - which would sort
   of be half the point? And sometimes it returns obscure information when
   I want basic information. ‘ri File’, for example, tells me about
   “Ftools - extra tools for the File class” - and not about the File class
   itself…

3. I dabbled with Python a while ago and got a bit jealous with the way
   it could automatically wrap a C library for you. Oh, I know we can do
   something similar; but not automatically as such. That’s more of a
   whine on my part than a genuine complaint.

4. If I’m reduced to whining, I wish some developers would realise that
   an online Rdoc is not the same as documentation. It’s useful, but if
   you have only the barest idea of what the Gem/whatever actually does,
   it’s hardly going to help that much.

There. I feel much better now.

[zimbatm]

On Sat, Jan 15, 2011 at 4:45 PM, David M. [email protected]
wrote:

things
I actually feel are broken about Ruby as it is today.

I’m sorry to take this slightly off topic, but I just can’t let this
comment pass. I am currently building a language called Quby, which is a
very Ruby-like language, that runs 100% in the browser (about 4,000
lines of JS). There are differences (as it’s Ruby-like not Ruby) with
the main one being that it’s tied to a canvas. But AFAIK it’s the
closest pure JS implementation of Ruby (although it’s Quby, not Ruby).

I have to ask…does an applet not give you what you want? JRuby does
run fine in an applet, and with recent improvements to the Java
browser plugin it can do anything a Flash or other language plugin can
do (traverse and manipulate DOM, etc).

• Charlie