Live data from Hacker News

Ruby delights built into the language

technology.doximity.com

71–80 of 89 posts

Re: Ruby delights built into the language

#71

I appreciate the Ruby love in this post, but it's worth pointing out that the author is clearly new to the language. I say that because he writes Ruby as if he's writing some other language, and not idiomatic Ruby. This: dirp = Dir.open(".") for f in dirp case f when /\.rb\z/ print f, "\n" else # do not print end end dirp.close Could be made much more Ruby-native (and simpler!) as: Dir.open('.').each do |f| puts f if…

So the weirdest part is that the OP is literally just a cut and paste of a bunch of scripts found in the ruby distribution "samples" folder (that I had no idea even existed). That pretty not great ruby wasn't written by the author -- it's actually included in a "sample" file with the ruby distro? https://github.com/ruby/ruby/blob/ruby_3_1/sample/dir.rb A file whose commit history shows... it's part of the very first…

I think the idioms develop over time. Or perhaps being samples, they were presented in a more language neutral way?

In any case, I wonder if the OP's motives were good or if this was just some SEO game... we have enough of the latter on the internet.

Re: Ruby delights built into the language

#72
post #68
post #54

Earlier quoted context omitted.

This was written by matz some time between 1993 and 1994. It appeared in the very first preview release of ruby, version 0.49. The original tarball has the file modification timestamps: $ curl -s https://cache.ruby-lang.org/pub/ruby/1.0/ruby-0.49.tar.gz | tar -tvz | grep dir.rb -rw-r--r-- 0 matz root 127 Jun 3 1994 ruby/sample/dir.rb

That file is very different with an added rewind and now case/when. dirp = Dir.open(".") dirp.rewind for f in dirp if (~/^\./ || ~/~$/ || ~/\.o/) else print(f, "\n") end end dirp.close

   if (~/^\./ || ~/~$/ || ~/\.o/)
ah, the perl heritage is strong here!

Re: Ruby delights built into the language

#73
post #16

This article is kind of niche... My favourite Ruby delights are among others, methods provided by the Enumerable mixin https://rubyapi.org/3.1/o/enumerable . There's a pile of functionality there that helps with tedious tasks. E.g. here's a solution to this year's AOC challenge #6 using Enumerable's each_cons method: File.read('input6.txt').chars.each_cons(4).find_index { _1.uniq == _1 } + 4

I struggle with code like this (also, complicated piped shell statements). How do you debug/reason about this? I know this specific example may be an exercise, but still.

It's important to separate this example from the general concept.

The concept is (generally) called functional composition.

The way one reasons about it, is to mentally split the statement at each function, and think about each step separately. The readability of functional composition comes from the fact there is interrelation exclusively between each adjancent couple of functions - in practice, the reader needs to keep only one result in mind at a time.

Functionally composed statements read like a sequence of statements, rather than a single one. The advantage is that they avoid having to use throwaway temporary variables for each step.

Shell pipes work the same. Even if they're long, assuming that they don't obscure features or use complex intermediate results, they're interpreted the same way - one transformation at a time.

Back to the example. It's not good for a few reasons:

1. it's not properly formatted

2. it uses an uncommon feature (named block variable, `_1`)

3. the sum at the end of the statement breaks the flow.

One would typically write the example like:

    index_found = File
        .read('input6.txt')
        .chars
        .each_cons(4)
        .find_index { |sequence| sequence.uniq == sequence }

    index_found + 4
Writing functional composition in Rust tends to be a bit cleaner, not because of the language, but because of the autoformatting, that indents the statement (but not the sum; that one, I've separated it manually).

Regarding debugging: you can split the statement as convenient, and recompose it once you're done with debugging. Depending on the given statement, one can also put breakpoints inside the blocks.

Re: Ruby delights built into the language

#74

As a newb, what editor to use for Ruby? It's one of those languages that VS Code does not cover properly and I can't really find good setup for nvim or emacs. RubyMine works wonders but I'm poor. Also, why is Ruby "editor responsiveness" (not sure what to call it) so much worse than e.g. Python?

You can pay for RubyMine once and use that version forever (or until you are not poor :) )

Re: Ruby delights built into the language

#75
How do I run these? For example:

```

ruby sample/biorhythm.rb

ruby: No such file or directory -- sample/biorhythm.rb (LoadError)

```

(I know I could simply copy these files off GitHub, but does the IRB on my computer already know about these biorhythm/calendar files somehow). Am I missing something?

Re: Ruby delights built into the language

#76
most of the posts here are criticisms of the OPs efforts. they seem misplaced. Ruby lacks accessible, consistent, example-based explorations that cover the breadth of the language in practice-- as a programming language, rather than just a dsl for OO and REST apps.

I'm fairly new to Ruby and to programming in general. I've found so far that Ruby is sorely underdocumented. Coming from JS, where we have MDN, the docs for Ruby are obtuse and don't provide examples.

If you do google search you get wordy, outdated, non-idiomatic code examples that often feel incomplete or are even flat out wrong. There are a lot of gotcha's and hangups in the language* that you can sometimes find in books-- but not consistently and never in blog posts.

My learning process so far has been to look at the docs, which often are EMPTY (see Symbol#to_proc)*. Then I'll read through 5-6 blog posts from 2016, not find the answer, then do searches through multiple (expensive) books that are almost always nothing succinct (not reference style). I eventually have to ask on a chatroom or some other asynch forum, in which case that knowledge has no foward discoverability and the experts in the language find themselves in a samsara of questions/answers.

I could (and often) do github-wide searches of usages of a specific method or idiom, but that is tedious, inconsistent, and overly dependent on one of many features on a 3rd-party service.

TL;DR: what i'd like to see as a newcomer to the language is a canonized and community-driven knowledge base, ala wiki.

*an example of a hangup: some types are immutable and others not. array.each on an array of intergers will not behave the same as an array of strings.. so for ints you have to use map for certain transformations

*the doc entry for Symbol#to_proc is exactly one line and doesn't even use the method! it uses the &: operator.

Re: Ruby delights built into the language

#77
post #75

How do I run these? For example: ``` ruby sample/biorhythm.rb ruby: No such file or directory -- sample/biorhythm.rb (LoadError) ``` (I know I could simply copy these files off GitHub, but does the IRB on my computer already know about these biorhythm/calendar files somehow). Am I missing something?

I will update the article, but all of the code snippets were run from the root of the ruby source code. So before you run them:

git clone https://github.com/ruby/ruby.git && cd ruby

Re: Ruby delights built into the language

#78

most of the posts here are criticisms of the OPs efforts. they seem misplaced. Ruby lacks accessible, consistent, example-based explorations that cover the breadth of the language in practice-- as a programming language, rather than just a dsl for OO and REST apps. I'm fairly new to Ruby and to programming in general. I've found so far that Ruby is sorely underdocumented. Coming from JS, where we have MDN, the docs f…

> array.each on an array of intergers will not behave the same as an array of strings

What do you mean by this?

Re: Ruby delights built into the language

#79
post #5

Earlier quoted context omitted.

Yet there's almost no real discussion of how to use the standard library here, and a lot of talking about example code that's mostly useless (seriously - why is biorhythm pseudoscience #2, and how is displaying a calendar on the CLI going to help me...?) I agree with the top post - I have a very different idea about what "built-in" means than the author of this article.

> seriously - why is biorhythm pseudoscience #2 It's an interactive tutorial on using the `Date` and `OptionParser` classes and printing stuff to stdout. > and how is displaying a calendar on the CLI going to help me It's an interactive tutorial on using the `Date` and `GetoptLong` classes and printing stuff to stdout :)

And that's fine. But that topic in the article is not Date/OptionParser/GetOptLong - it's

"This week I'm sharp-as-a-tack, and slow and sad as a sack. Here's to next week!"

and I don't see any value add above linking to examples (not built-ins).

Ex - why not explore OptionParser (the actual built-in!) - and compare to ARGV, or contrast with gets.chomp. Or explain how similar the concept is to something like Yargs from the node side.

Also, as a personal aside - I don't really see a bunch of custom formatted printf statements with no attempt at explanation a very good example at all.

Re: Ruby delights built into the language

#80
Hey everyone! OP and author here.

I would like to thank everyone for such a lively discussion! It has been a joy reading through and feeling the sentiment ebb and flow in that traditional HN fashion

For those curious and inquisitive minds out there, this article was intended to provoke emotion, fuel your creative soul, and pull you in to the Ruby source code. The precursor to this article was one I wrote on how IRB works and many of it's features. I had accidentally stumbled upon this "samples" directory and like many here wondered _why_ it is there and _what purpose_ was it serving. While many of the examples are a bit dated, they all make use of the standard library in various ways, and many make use of Ruby in ways _I_ hadn't seen before. Even if you don't care for the examples themselves, I hope to leave you with ample reading material to explore those unfamiliar crevices of Ruby.

As many have shouted, there are quite a few pain points in the Ruby language documentation, best practices, discoverability, and onboarding of new comers. This is an incredible time to be a part of this community and make this language as enjoyable to learn as it is to write.

Post reply on HN