[poll] What are your ruby rough cuts ?

[Joseph Lenton]

Charles Nutter wrote in post #975363:

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

That hadn't occurred to me, and would be the best option for getting
Ruby running in a browser.

However it wouldn't work well for my particular site. I've built lots of
applets in the past and although they can work they are far from being
as reliable as Flash or HTML 5. Java penetration is still pretty bad,
only about 60% of users have Java 6 which is over now over 5 years old.
No potential for ever targeting mobile devices. Lots of netbook OSs ship
with Java, like ChromeOS. Start up time is still terrible (especially on
low-end machines). Finally there are lots of smaller issues like caching
bugs and differences in the implementation; I've seen several sites that
host applets saying underneath "if it doesn't appear then try reloading"
(you shouldn't need to have to write that).

David Masover wrote in post #975355:

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.

It's not entirely new syntax, it's mostly the same (or very similar).
But that's a fair point as on the surface it does look like "change for
the sake of change". I'd argue far more people have heard of null rather
then nil, I bet more languages use C style single-line comments over
hash comments, and Ruby block comments are really ugly and almost
unusable. So I have changed items for common well known syntax rather
then just random stuff.

I also really do prefer these changes and believe that language
designers should build languages they would enjoy writing (hence why
it's also heavily influenced by Ruby). So that's ultimately why I went
with them.

 

[Johnathon Wright]

Found this recently... probably the least intuitive thing I've seen in
Ruby

## some base-10 things must be preceded by 0

ruby-1.8.7-p302 > .123
SyntaxError: compile error
(irb):4: no .<digit> floating literal anymore; put 0 before dot
(irb):4: syntax error, unexpected '.'
from (irb):4

ruby-1.8.7-p302 > 0.123
=> 0.123

## others can't be preceded by 0 --

ruby-1.8.7-p302 > 0123
=> 83

## meanwhile... you would think it would be the same as...
ruby-1.8.7-p302 > "0123".to_i
=> 123


## I would prefer that this be configurable...

ENV['ALLOW_DECIMALS_TO_CONTINUE_TO_BE_DECIMALS'] = f_course

=> # Also, there would be some easter egg where Ruby responds
with Smileys.

 

[David Masover]

Charles Nutter wrote in post #975363:

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

[snip]
I've built lots of
applets in the past and although they can work they are far from being
as reliable as Flash or HTML 5. Java penetration is still pretty bad,
only about 60% of users have Java 6 which is over now over 5 years old.

Aside from this, the browser already has a perfectly good language and runtime
already running (JavaScript), so adding another one can't be good for
performance.

I will definitely consider applets when I can actually dictate the client to
some extent -- for instance, right now I'm taking a physics class which
requires Java, Flash, _and_ Silverlight (moonlight doesn't _quite_ work). If I
were writing software with that much freedom to declare "You WILL have browser
plugin X", then sure.

For the moment, however, my strategy has been to keep the client as simple as
I reasonably can, and try to actually learn JavaScript as well as I know Ruby.
JavaScript isn't a bad language, it's just ugly.

It's not entirely new syntax, it's mostly the same (or very similar).

Maybe "entirely new" was the wrong word, but consider: I _like_ Ruby syntax.
Occasionally, I'm forced to write C, even C++. But I'm still not going to do
something like this:

#define self (*this)

But that's a fair point as on the surface it does look like "change for
the sake of change". I'd argue far more people have heard of null rather
then nil, I bet more languages use C style single-line comments over
hash comments, and Ruby block comments are really ugly and almost
unusable.

Lots of Rubyists, Perlists, Pythonistas, and shell ninjas disagree.

So I have changed items for common well known syntax rather
then just random stuff.

But see, the problem is that rather than closely tracking an existing
language, you're building a hybrid of both. In other words, your new language
is really only going to be comfortable to those fluent in at least Java and
Ruby, if not more languages. I like to consider myself fluent in both Java and
Ruby, and it'd _still_ be problematic for me, as I'd have to constantly be
wondering whether I should be following the Ruby or Java convention.

I guess my real question is, why'd you go with a new language rather than
trying to implement an existing one? Why Quby instead of Ruby-on-JavaScript?

If the reason was to add this compile-time verification and make these
language tweaks, I guess I understand, and don't really have much more to say
about it other than that I strongly disagree.

 

[Robert Klemme]

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"

Keeping the bang notation discussion aside I don't think that your
quote correctly describes the situation in Ruby. Basically the state
of an object is the transitive closure of all objects reachable
through instance variables. There are two ways that state can change:

1. An instance variable somewhere in that graph is update to point to
a different object.
2. An instance of a mutable core class changes its internal state
(e.g. String#gsub!, Array#delete etc.).

I don't see how you want to derive your statement about "state as
immutable data" from this.

Kind regards

robert

 

[Robert Klemme]

Most importantly: improve Ruby's usage of native threads, i.e. get rid of GIL.

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

That's why there are \A and \z (and also \Z). If you want to ensure
match at string start or end use those.

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

A bit of cleanup there would be nice but it doesn't really hurt me the
way it is.

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

Yes, get rid of class variables! That's on position 2 of my list.

* The whole of ruby 1.9 String handling is arguably one huge paper cut.
http://github.com/candlerb/string19

Um, yes: it *is* tedious to use.

Cheers

robert

 

[Tony Arcieri]

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

Most importantly: improve Ruby's usage of native threads, i.e. get rid of
GIL.

This is largely an implementation problem, not a language problem. JRuby,
IronRuby, Rubinius Hydra, and MacRuby all support GIL-free concurrent
multithreading.

It would be nice if there were some kind of standard memory model across all
implementations. It sounds like Rubinius Hydra aims to match JRuby's, which
I believe comes straight from Java.

You probably aren't ever going to see YARV get rid of the GIL. It would
require a complete rewrite.

 

[Charles Oliver Nutter]

Charles Nutter wrote in post #975363:

That hadn't occurred to me, and would be the best option for getting
Ruby running in a browser.

However it wouldn't work well for my particular site. I've built lots of
applets in the past and although they can work they are far from being
as reliable as Flash or HTML 5. Java penetration is still pretty bad,
only about 60% of users have Java 6 which is over now over 5 years old.
No potential for ever targeting mobile devices. Lots of netbook OSs ship
with Java, like ChromeOS. Start up time is still terrible (especially on
low-end machines). Finally there are lots of smaller issues like caching
bugs and differences in the implementation; I've seen several sites that
host applets saying underneath "if it doesn't appear then try reloading"
(you shouldn't need to have to write that).

All valid points. Part of the big push for JavaFX before Sun died
included improving the plugin. If they'd continued, they might have
been able to achieve better market penetration. The newer plugin had
much better startup characteristics, good performance, and better
access to the browser itself.

That work is continuing at Oracle, but it's still years out before
we'd see any uptick. If you require that your users have a working
application in-browser without any additional install, I agree
JavaScript is your best option. If you can control the user machines
and ensure they have Java+applets+latest plugin, JRuby's probably the
better option.

As far as mobile...JRuby works fine on Android devices, which is a
nontrivial segment of the market. But again the penetration is not as
high as JS in-browser.

Problems loading applets are usually the fault of the applet...they're
inconsistently erroring out at startup and not handling it properly.
That would affect badly-implemented code in any plugin system.

- Charlie

 

[Eric Christopherson]

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.

1. I know it's a small thing, but I nominate the inability of instance
variables to have ? tacked onto the end. It would be nice to be able
to do:

def reasonable?
return @is_reasonable
end

Instead you could just do:

attr_reader :reasonable?

It just doesn't make sense to me to have a convention where accessors
are named the same as their instance variables, *except* in the case
of booleans; nor do I see how methods are "special" in such a way as
to allow them to show graphically that they return a boolean. One
argument is that allowing ? on instance variable names is tantamount
to marking them with a type sigil, but I think this is pretty
ridiculous since method names can already have ?. And besides, Ruby
still wouldn't be doing any checks to make sure ?-marked variables
actually are boolean.

2. It would be nice to have a little sugar for initialize methods that
set instance variables without any checking or computation, similarly
to how attribute writers work. I believe constructors in Scala have an
elegant way of doing this.

3. StringScanner#pos should return a *character* position, not a byte one.

 

[Christopher Dicely]

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?

Scheme (which, I think, is where Ruby got the specific notational
convention for marking "dangerous" methods) comes much closer to
meeting this description than Ruby does.

 

[Robert Klemme]

2. It would be nice to have a little sugar for initialize methods that
set instance variables without any checking or computation, similarly
to how attribute writers work. I believe constructors in Scala have an
elegant way of doing this.

Often you can use Struct:

Foo = Struct.new :name, :age do
def to_s
"name=#{name},age=#{age}"
end

def any_other_method
self.age += 1
end
end

f = Foo.new "bar", 17
puts f

Cheers

robert

 

[Tony Arcieri]

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

On Tue, Jan 18, 2011 at 5:14 PM, Eric Christopherson <

2. It would be nice to have a little sugar for initialize methods that
set instance variables without any checking or computation, similarly
to how attribute writers work. I believe constructors in Scala have an
elegant way of doing this.

Reia allows you to use instance variables as parameters to initialize, e.g.

def initialize(@foo, @bar, @baz); end

 

[Tony Arcieri]

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

Scheme (which, I think, is where Ruby got the specific notational
convention for marking "dangerous" methods) comes much closer to
meeting this description than Ruby does.

Correct me if I'm wrong, but I believe Scheme uses this notation for
destructive assignments, not state mutations.