[poll] What are your ruby rough cuts?

ruby-talk
21

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

···

On Sat, Jan 15, 2011 at 4:45 PM, David Masover <ninja@slaphack.com> wrote:

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

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

22

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

···

On Sat, Jan 15, 2011 at 2:59 PM, Tony Arcieri <tony.arcieri@medioh.com> 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.

23

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.

···

On Jan 15, 2011, at 04:07 , Joseph Lenton wrote:

24

David Masover wrote in post #975191:
>> > 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.

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

···

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

> On Saturday, January 15, 2011 04:42:58 am Joseph Lenton wrote:

25

Charles Nutter wrote in post #975363:

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

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

···

On Sat, Jan 15, 2011 at 4:45 PM, David Masover <ninja@slaphack.com> > wrote:
On Sunday, January 16, 2011 07:33:04 am Joseph Lenton wrote:

--
Posted via http://www.ruby-forum.com/\.

26

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.

···

On Sat, Jan 15, 2011 at 5:34 PM, Christopher Dicely <cmdicely@gmail.com>wrote:

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

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

--
Tony Arcieri
Medioh! Kudelski

27

Charles Nutter wrote in post #975363:
>>> > 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

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

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

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.

···

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

> On Sat, Jan 15, 2011 at 4:45 PM, David Masover <ninja@slaphack.com> > > > > wrote:

28

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

···

On Mon, Jan 17, 2011 at 5:20 AM, Joseph Lenton <jl235@kent.ac.uk> wrote:

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

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

29

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

···

On Sat, Jan 15, 2011 at 10:54 PM, Tony Arcieri <tony.arcieri@medioh.com>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?

--
Tony Arcieri
Medioh! Kudelski

30

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

···

On Sun, Jan 16, 2011 at 6:55 AM, Tony Arcieri <tony.arcieri@medioh.com> wrote:

On Sat, Jan 15, 2011 at 5:34 PM, Christopher Dicely <cmdicely@gmail.com>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"

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

31

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.

···

On Sat, Jan 15, 2011 at 9:55 PM, Tony Arcieri <tony.arcieri@medioh.com> 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?

32

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

···

On Wed, Jan 19, 2011 at 1:15 AM, Christopher Dicely <cmdicely@gmail.com>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.

--
Tony Arcieri
Medioh! Kudelski