Live data from Hacker News

... because Ruby isn't terse enough yet

weblog.raganwald.com

21–28 of 28 posts

Re: ... because Ruby isn't terse enough yet

#21

What is a "point-free holomorphism" ? I study math, hack Scheme, and find myself totally confused by terminology. Maybe it's a riddle or something -- "What does complex-smoothness have to do with lambda calculus?"

It was actually a typo. Fixed, thank you.

No, thank you.

I've just been forced to learn about a new language proposal, a new (to me) set of morphisms, and a nonstandard approach to proving stuff in topology. That's a rich link.

Re: ... because Ruby isn't terse enough yet

#22

Earlier quoted context omitted.

"these folks" There are at least two kinds of folks: those who are "fixing" Ruby the language, such as the Rubinius team, and those who are "using" the language. I am in the latter camp. So sometimes I complain about what is broken-- http://weblog.raganwald.com/2007/02/why-ruby-is-not-acceptab... sometimes I hack around it. But no, I am in no position to change the language. If I was, I would actually implement the p…

I cannot get foo.[3] to work: syntax error, unexpected '[' But please don't spend too much time explaining what I'm doing wrong, because I'm afraid I don't like foo.[3] anyway. :) Let me demonstrate my problem by taking a simulated tour through my brain as it encounters foo.[3] for the first time: "WTF? "Did someone mistype foo[3]? "No, wait, surely it's supposed to be foo(3). I'm pretty sure that foo is a function.…

"I cannot get foo.[3] to work"

Hey, neither can I. Quite possibly because foo.[3] actually doesn't work, it's foo[3] that works and I made a typo.

Sorry about that, and especially too bad considering how your first reaction was to consider the possibility that your version of Ruby was at fault instead of the possibility that I made a careless error. I appreciate the implied vote of confidence, but I'm aghast at the consequences.

I appreciate your taking the time to share your reaction. I'm mulling over exactly what I prefer about the point-free syntax, and the prod to think thinks over may help me understand my own views in more depth.

Re: ... because Ruby isn't terse enough yet

#23

Earlier quoted context omitted.

"these folks" There are at least two kinds of folks: those who are "fixing" Ruby the language, such as the Rubinius team, and those who are "using" the language. I am in the latter camp. So sometimes I complain about what is broken-- http://weblog.raganwald.com/2007/02/why-ruby-is-not-acceptab... sometimes I hack around it. But no, I am in no position to change the language. If I was, I would actually implement the p…

I cannot get foo.[3] to work: syntax error, unexpected '[' But please don't spend too much time explaining what I'm doing wrong, because I'm afraid I don't like foo.[3] anyway. :) Let me demonstrate my problem by taking a simulated tour through my brain as it encounters foo.[3] for the first time: "WTF? "Did someone mistype foo[3]? "No, wait, surely it's supposed to be foo(3). I'm pretty sure that foo is a function.…

It's foo.[](3)

Re: ... because Ruby isn't terse enough yet

#24

Earlier quoted context omitted.

I cannot get foo.[3] to work: syntax error, unexpected '[' But please don't spend too much time explaining what I'm doing wrong, because I'm afraid I don't like foo.[3] anyway. :) Let me demonstrate my problem by taking a simulated tour through my brain as it encounters foo.[3] for the first time: "WTF? "Did someone mistype foo[3]? "No, wait, surely it's supposed to be foo(3). I'm pretty sure that foo is a function.…

"I cannot get foo.[3] to work" Hey, neither can I. Quite possibly because foo.[3] actually doesn't work, it's foo[3] that works and I made a typo. Sorry about that, and especially too bad considering how your first reaction was to consider the possibility that your version of Ruby was at fault instead of the possibility that I made a careless error. I appreciate the implied vote of confidence, but I'm aghast at the c…

So, part of me is tempted to use this as an example of the reason why languages benefit from a certain amount of redundancy and consistency. :)

The other part of me is quite embarrassed, because I thought I had tried foo[3] and failed. I guess that's why everyone in the Ruby community prefers automated testing!

Of course, if I thought that applying an array reference to a Proc made any sort of intuitive sense, I might have tried it more carefully. :) I still wish that I could just say foo(x).

Anyway, I'm glad you appreciated my report from the field. And of course you prefer the point-free syntax -- you know Haskell, you know Lisp, you seem to know a certain amount of mathematics. It all makes perfect sense to you, just as I can only dimly remember the time when vector calculus didn't make perfect sense to me.

But I shouldn't indulge my love for German by randomly German syntax into my English prose inserting. Unless I have a very good reason: perhaps I want to borrow the uniquely compact German word shadenfreude, or perhaps essential it is the alien character of Yoda to establish. When you break the rules in Ruby code that you intend to show to someone else (and is there really any other kind of code?) you need to convince the reader that you had a very good reason, because you're making him or her work harder to understand you.

Keep playing with the syntax for a while. You may find that it's so elegant that it is worth defending against the inevitable skeptics. And, if not, at least golf is a very pleasant way to pass the time!

Re: ... because Ruby isn't terse enough yet

#25
post #23

Earlier quoted context omitted.

I cannot get foo.[3] to work: syntax error, unexpected '[' But please don't spend too much time explaining what I'm doing wrong, because I'm afraid I don't like foo.[3] anyway. :) Let me demonstrate my problem by taking a simulated tour through my brain as it encounters foo.[3] for the first time: "WTF? "Did someone mistype foo[3]? "No, wait, surely it's supposed to be foo(3). I'm pretty sure that foo is a function.…

It's foo.[](3)

Okay, I thought you were pulling my leg. But, in fact, that does work. Thanks!

Meanwhile: My head just exploded.

Re: ... because Ruby isn't terse enough yet

#26
post #18
post #17

Earlier quoted context omitted.

The python implementation looks overly complicated. I was thinking that the ruby and python implementations would be very similar. Here it goes def foo(n): return lambda i:n+i Tried it (Python 2.5) and it works.

Actually it doesn't work - calling the returned lambda should increment n - your implementation doesn't.

That holds true for the given ruby implementation as well, since n is incremented only in the scope of foo and not in the calling scope.

def foo (n)

    lambda {|i| n += i } 
end

n=5

a = foo(n)

puts a.call(3) #prints 8

puts n # still prints 5. n is not incremented

I agree that the python one is strictly not according to the problem definition, but for all practical purposes both python equivalents are the same, aren't they? or am I missing something?

Re: ... because Ruby isn't terse enough yet

#27
post #2

In Paul Graham's Accumulator Generator comparison ( http://www.paulgraham.com/accgen.html ) Ruby is now terser than any language except Arc. foo = 'n -> x -> n += x'.to_proc f = foo[4] f[2] # => 6 f[2] # => 8 (This would be even terser: foo = &'n -> x -> n += x' but the ampersand syntax is only allowed after a method call.)

For comparison, the original Ruby version: def foo (n) lambda {|i| n += i } end It's five characters longer, but approximately 350% more readable. Of course, a lot of that is because I'm more familiar with standard Ruby syntax than I am with this hack... but doesn't that tend to prove my point?

Other measures of brevity:

The original ruby definition is 15 tokens, the .to_proc version is 13 tokens.

Orthogonality:

to_proc

        3 variables (foo, n, x)
        1 method call (to_proc)
        1 type of separator (')
        2 assignment ops (=, +=)
        2 binary operators (->, .)

        9 different kinds of tokens, in 5 (arbitrary) categories.

        Original:
        
        3 keywords (def, lambda, end)
        3 variables (foo, n, i)
        5 Separators (|, {, }, (, ))
        1 assignment (+=)

        12 different kinds of tokens, in 4 categories.
So the only way the original ruby version comes out ahead by these measures is that it has "fewer categories" of token types that are required. Also I think that with the 'def foo' declaration, 'foo' is not technically a variable. I don't really know ruby well enough. But you get the idea.

Re: ... because Ruby isn't terse enough yet

#28

Earlier quoted context omitted.

"I cannot get foo.[3] to work" Hey, neither can I. Quite possibly because foo.[3] actually doesn't work, it's foo[3] that works and I made a typo. Sorry about that, and especially too bad considering how your first reaction was to consider the possibility that your version of Ruby was at fault instead of the possibility that I made a careless error. I appreciate the implied vote of confidence, but I'm aghast at the c…

So, part of me is tempted to use this as an example of the reason why languages benefit from a certain amount of redundancy and consistency. :) The other part of me is quite embarrassed, because I thought I had tried foo[3] and failed. I guess that's why everyone in the Ruby community prefers automated testing! Of course, if I thought that applying an array reference to a Proc made any sort of intuitive sense, I migh…

"golf is a very pleasant way to pass the time!"

Golf is a good walk spoiled => Golf is good code spoiled.

Post reply on HN