Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 2.0.0 Released

ruby-lang.org

Post reply on HN
Print view View original

251–260 of 303 posts

Re: Ruby 2.0.0 Released

#251

Post by jroesch »

tomstuart wrote: post #79
nnq wrote: post #74

Earlier quoted context omitted.

> but I tend to write very functional code A bit offtopic, but since you said that and you seem to be both fond of functional programming and in touch with latest ruby developments, you're probably a good person to ask: How the heck do you do "normal/proper" currying in Ruby? And how do you do it with keyword arguments? (I'm trying to compile a list of functional-idiom examples in popular dynamic language, and when I…

Ruby only has built-in support for currying procs: >> add = -> x, y { x + y } => # >> add.call(3, 5) => 8 >> add.call(3) ArgumentError: wrong number of arguments (1 for 2) >> curried_add = add.curry => # >> add_three = curried_add.call(3) => # >> add_three.call(5) => 8 If you want a no-brainer way of currying methods , you're SOL.

You can do:

    "Hello".method(:split).to_proc.curry[""]
     => ['H', 'e', 'l', 'l', 'o']
If you want to even make the receiver an argument it would take a little more hoop jumping, but with a tiny monkey patch you can enable something like this:

    "Hello".curry.split[""]

Re: Ruby 2.0.0 Released

#252

Post by philwelch »

Ingaz wrote: post #231
philwelch wrote: post #222

Earlier quoted context omitted.

> Perl: sigils, regexp everywhere (when it not needed), parameters passing, "use strict", strange OOP - all those features makes it impossible for prototyping. > Ruby: it's the same as for perl Nothing you said about Perl can be applied to Ruby.

"The same" means "ruby as pseudocode is the same as perl". You need to explain that 0 is True. You need to explain blocks, (int_number).times and other cute things. And I heard a lot of complains for whitespace, but begin-end is more irritable for many.

> "The same" means "ruby as pseudocode is the same as perl".

Right, except none of the reasons you gave for why perl is a poor pseudocode apply to Ruby, so you need to make that point yourself.

> You need to explain that 0 is True.

The truth values of integers don't usually come up in pseudocode.

> You need to explain blocks, (int_number).times and other cute things

I agree that the concept of passing around a block of code is hard to implement in less expressive languages, though cases like "each" and "map" can be simply translated to for loops. You could make the same criticism about Python's lambdas or list comprehensions.

n.times is perfectly useful pseudocode, though. Think of it as a shorthand for "for(i = 0, i < n; i++)".

Re: Ruby 2.0.0 Released

#253

Post by rjbond3rd »

coldtea wrote: post #171
rjbond3rd wrote: post #148

Earlier quoted context omitted.

> ...we would consider them mostly irrelevant languages. And apparently "we" are using "irrelevant" to mean not fashionable. Or does it mean, "Do not use for new IT projects" or something? What does it matter what other people do, especially those with a strong (if small) community, frameworks, libraries, books, articles, conferences... And where does Smalltalk fall? I hate to tell those people their language is "irr…

> And apparently "we" are using "irrelevant" to mean not fashionable. Or does it mean, "Do not use for new IT projects" or something? What does it matter what other people do, especially those with a strong (if small) community, frameworks, libraries, books, articles, conferences... It matters because there is not enough of "community, frameworks, libraries, books, articles, conferences". If I want to do something in…

I appreciate that you write really well, but I think your argument boils down to "there's safety in numbers."

And that is a totally valid strategy for IT careers, but I would quit programming if I had to follow that advice. It feels too much like, "Stick with the herd." Just one person's opinion.

Re: Ruby 2.0.0 Released

#254

Post by calinet6 »

naner wrote: post #224
vidarh wrote: post #111

Earlier quoted context omitted.

As a Ruby user that finds Rails annoying and not something I like working with, I don't think that's all that relevant. A lot of people have come to Ruby because of Rails, but a lot of Ruby people dislike Rails too. There's a plethora of web frameworks for Ruby that have sprung up exactly because of people who want to use Ruby but don't like Rails. In terms for barrier to entry with Python, the issue is that a lot of…

Pythons whitespace usage, for example, makes it DOA for me. I'm not touching it. If it works for you, great. It doesn't work for me. This has to be up there with people claiming they don't like Lua because array indexing starts at 1 instead of 0. Of all the weaknesses of Python, focusing on something so superficial just seems lazy. Perhaps in the future just say that you're experienced and comfortable with Ruby and h…

You can compare the trivial differences all you want, but the truth is, they are real differences in the way you think about your code and programming.

Indexing starting at 1 is not only irritating, it's mathematically difficult. Certain concepts actually can't be described (as easily) with array indices that start at 1. It's not a trivial argument.

Similar with white space; having to write code which obeys white space and tab rules is not the way some people like to think. As much as I love Python (and I do), I find it more restrictive and less fun than Ruby. It's not just superficial, it changes the way you think, and what you think about. Of course Python has its advantages, lots of them. But it also has its own style, which may not be everyone's song and dance.

I do program in both Python and Ruby frequently, and I have to say that it has nothing to do with experience or comfort, it's truly a judgement, and a valid one at that. Nice try :)

Re: Ruby 2.0.0 Released

#255

Post by Kerrick »

stormbrew wrote: post #194
jacquesc wrote: post #63

Earlier quoted context omitted.

I'm not 100% sure on the history, but I believe 1.9.x started as a dev release and then they changed their minds and decided it was a wide release. That initial confusion might be why the community took the time to go from 1.8 to 1.9. I think they've learned from that, as 2.0 looks like a much cleaner/easier transition.

On the other hand, it means we've now had point and minor releases that broke everything (1.9, 1.8.7, and I think even one or two of the 1.8.7 patch releases actually backported breaking 1.9 features), while the major release is apparently one where nothing from the prior release should break. I'm not convinced that means they've 'learned their lesson' so much as that they still don't know how to version things. We'l…

Indeed. I hope that ruby itself starts following the semantic versioning [0] that is so popular with ruby developers. Now that they have a "clean slate" with a 2.0.0 release, they could!

[0] http://semver.org/

Re: Ruby 2.0.0 Released

#256

Post by zaius »

whalesalad wrote: post #203
jdelsman wrote: post #196

Just submitted a pull request to Homebrew to have this added. Can't wait :-)

I'd definitely look at rbenv. Combined with it's plugin ruby-install, you've got a pretty simple and powerful alternative to rvm. I use it exclusively.

rbenv is definitely better than rvm, but if you use the same ruby version between all your projects, a single version of ruby installed through homebrew is a much better way to go.

Re: Ruby 2.0.0 Released

#257

Post by alexanderh »

calinet6 wrote: post #254
naner wrote: post #224

Earlier quoted context omitted.

Pythons whitespace usage, for example, makes it DOA for me. I'm not touching it. If it works for you, great. It doesn't work for me. This has to be up there with people claiming they don't like Lua because array indexing starts at 1 instead of 0. Of all the weaknesses of Python, focusing on something so superficial just seems lazy. Perhaps in the future just say that you're experienced and comfortable with Ruby and h…

You can compare the trivial differences all you want, but the truth is, they are real differences in the way you think about your code and programming. Indexing starting at 1 is not only irritating, it's mathematically difficult. Certain concepts actually can't be described (as easily) with array indices that start at 1. It's not a trivial argument. Similar with white space; having to write code which obeys white spa…

I would love to see an example of a large project in another language besides python, that uses frequent cases of non-pythonic indentation.

Sure, there are certain edge cases when I wish I could represent something all in one line, or something similar, but they are so few and far between that I really cant see it as a major argument against not wanting to use python.

I felt the same way about whitespace at one time, but then I got used to it, and wonder why I ever felt so strongly one way or the other. The cases when my indentation isnt exactly like python in other languages is very rare.

If you find yourself using frequent cases of non-pythonic indentation in other languages, you may be writing some very unfriendly/unreadable code in a lot of instances.

It may make sense to you, but I wouldnt want to work on the same team.

Re: Ruby 2.0.0 Released

#258

Post by steveklabnik »

PommeDeTerre wrote: post #240
darkandbrooding wrote: post #236

Earlier quoted context omitted.

Python's whitespace-as-logic means that, for any given project, every editor used by every developer needs to have the same the same definition of what a "tab" is, because mixing tabs and spaces can introduce logic errors. You can reasonably argue that a project team should already have and enforce a coding style guide, so specifying a "tab" isn't a big deal. But what if you're part of two separate projects which dif…

This is a non-issue. Just follow PEP 8, which clearly suggests to "Use 4 spaces per indentation level." PEP 8 has been around for over a decade, so there's no excuse for not following its recommendations.

Even Rubyists always use 2 spaces, no tabs, even though whitespace is (mostly) insignificant.

Re: Ruby 2.0.0 Released

#259

Post by steveklabnik »

fruchtose wrote: post #211
grey-area wrote: post #116

There are some nice features here: Keyword arguments, which give flexibility to API design This looks good to replace all those options hashes in rails for example, though I wish they'd made it an all or nothing thing, apparently you can still do this: def foo(x, str: "foo", num: 424242) i.e. use some named and some unnamed in the same method which looks ugly. Module#prepend, which is a new way to extend a class Comp…

Speaking of the video you posted, go to 8:43. "I know someone who is working on a Ruby implementation and making very good strides and is not talking about it publicly at all--and I think you'll be surprised when you find out about it." Is Brian Ford talking about Topaz [1]? [1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/

Probably, yes. If you hung out in #rubinius over the last year, you'd see Alex Gaynor hanging out.

Re: Ruby 2.0.0 Released

#260

Post by MBCook »

TylerE wrote: post #200
copx wrote: post #198

I like Ruby but keywords arguments are the solution to a problem which shouldn't exist in the first place. Namely functions like.. myFunction(something, 23,23,100, somethingElse, true) People should write smaller, more specialized functions instead (less arguments). That makes software both: more efficient and more maintainable. If you start thinking: "Damn I wish I had keyword arguments to make this function call mo…

100% disagree. For some use cases they are very useful. Like, imagine a function that generates an HTML snippet, and can optionally assign some specific class names/ids to some of the elements.

As much as many people seem to hate the way Objective-C does things, I really like how it intersperses the arguments in the function name. It makes it so easy to identify parameters.

Most languages:

  someObject.throwProduce(apple, myEnemy, 14, 17);
Objective-C:

  [someObject throwProduce:apple at:myEnemy withForceInN:14.0 maxDisanceInM:17.0];
As long as you name the function appropriately, it's clear what each parameter does without having to look up the name. Many people complain about the long names (in this case throwProduce:at:withForceInN:maxDistanceInM:thenWaitInMS:), but it avoids the situation you have in other languages where there are 4 functions with the same name but different signatures. In Obj-C the naming conventions discourage such ambiguity and encourage self-documenting names.
Post reply on HN