What are your ruby rough cuts?

Ruby
21

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 . 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’] = :of_course
=> :slight_smile: # Also, there would be some easter egg where Ruby responds
with Smileys.

22

Charles Nutter wrote in post #975363:

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

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 M. wrote in post #975355:

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.

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.

23

On Monday, January 17, 2011 05:20:10 am Joseph L. wrote:

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

This just shouldn’t factor into it.

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.

24

On Sun, Jan 16, 2011 at 6:55 AM, Tony A. [email protected]
wrote:

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”

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

25

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

On Sat, Jan 15, 2011 at 9:36 AM, Brian C. [email protected]
wrote:

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

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.

Um, yes: it is tedious to use.

Cheers

robert

26

On Tue, Jan 18, 2011 at 9:17 AM, Robert K.
[email protected]wrote:

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.

27

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

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.

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

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

28

On Mon, Jan 17, 2011 at 5:20 AM, Joseph L. [email protected] wrote:

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
29

On Sat, Jan 15, 2011 at 9:55 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?

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.

30

On Tue, Jan 18, 2011 at 5:14 PM, Eric C. <
[email protected]> wrote:

  1. 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
31

On Wed, Jan 19, 2011 at 1:14 AM, Eric C.
[email protected] wrote:

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

32

On Wed, Jan 19, 2011 at 1:15 AM, Christopher D.
[email protected]wrote:

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.