[poll] What are your ruby rough cuts ?

[Jonas Pfenniger (zimbatm)]

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 )
* 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

 

[David Masover]

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.

 

[Brian Candler]

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.
http://github.com/candlerb/string19

Regards,

Brian.

 

[Joseph Lenton]

David Masover wrote in post #975080:

On Friday, January 14, 2011 07:34:04 am Jonas Pfenniger (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.

 

[Ryan Davis]

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

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.

 

[Brian Candler]

Joseph Lenton 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)

 

[Joseph Lenton]

Ryan Davis wrote in post #975115:

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.

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

On Fri, Jan 14, 2011 at 7:34 AM, Jonas Pfenniger (zimbatm) <

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 )
* 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

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. http://ruby-doc.org/core/classes/Module.html#M000497

* 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 Talim 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.

 

[Kedar Mhaswade]

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

 

[David Masover]

David Masover wrote in post #975080:

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.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

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)

 

[Christopher Dicely]

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!.)

 

[Clifford Heath]

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 Heath.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Tony Arcieri]

[Note: parts of this message were removed to make it a legal post.]

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.

 

[Ryan Davis]

=20
I already do use a proper editor and indent my code correctly, but = there=20
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
=20
rest_of_method
=20
end

or you wind up with:

def x
if x then
blah
end
=20
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.=

 

[Joseph Lenton]

David Masover wrote in post #975191:

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.

 

[David Masover]

David Masover wrote in post #975191:

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...)

 

[Charles Oliver Nutter]

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

 

[Shadowfirebird]

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.