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

Ruby delights built into the language

technology.doximity.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Ruby delights built into the language

#61

Post by sodapopcan »

empthought wrote: post #49
sodapopcan wrote: post #42

Earlier quoted context omitted.

Metaprogramming is powerful for making really nice, easy-to-use _libraries_. It shouldn't ever be used for business logic. Ever. Unless you're going to go all in and make a DSL for your business, but I don't know of anyone who actually does that.

Businesses are typically the ones hiring programmers (especially Ruby ones). The smart programmers want to write libraries. This is actually a problem for businesses, because they often don't need libraries.

I agree. That’s a whole blog post or essay worth of shit to unpack there, though.

Re: Ruby delights built into the language

#62

Post by kgeist »

area51org wrote: post #30

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…

I'm not familiar with Ruby, so I have a question: the first snippet has the .close method called while the second doesn't. Does the second example leak resources, or it's automatically closed after a GC in a finalizer, maybe? Does .each close the directory? Or, maybe, .close is a no-op in newer versions?

Re: Ruby delights built into the language

#63

Post by semiquaver »

kgeist wrote: post #62
area51org wrote: post #30

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…

I'm not familiar with Ruby, so I have a question: the first snippet has the .close method called while the second doesn't. Does the second example leak resources, or it's automatically closed after a GC in a finalizer, maybe? Does .each close the directory? Or, maybe, .close is a no-op in newer versions?

You’re quite right. OP’s rewrite contains a bug: it leaks one file descriptor per invocation. The correct version passes a block to `open` directly so that it’s automatically closed when the block is done executing. Maybe golfing down to be “idiomatic” isn’t always best :)

  Dir.open('.') do |dirp|
    dirp.each do |f|
      puts f if f.match?(/\.rb\z/)
    end
  end
https://ruby-doc.org/core-3.1.0/Dir.html#method-c-open

There are a few ruby stdlib classes like Tempfile that use the finalizer trick you mention to free resources on GC but Dir isn’t one of them. Here’s it’s implementation:

https://github.com/ruby/ruby/blob/1a24442193fe437e761e941d1a...

Re: Ruby delights built into the language

#64

Post by lioeters »

Lammy wrote: post #60
brasic wrote: 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

Fun retrocomputing diversion: Initial Ruby development was done on Sony NEWS, the same type of workstation that hosted the earliest PlayStation development boards: https://en.wikipedia.org/wiki/Sony_NEWS

Hilarious origin story of Sony NEWS, how the engineers built a UNIX workstation they wanted, not what they were told to build.

> Sony's NEWS project leader, Toshitada Doi, originally wanted to develop a computer for business applications, but his engineers wanted to develop a replacement for minicomputers running Unix that they preferred to use.

> In the beginning, Doi's concept of the workstation was a device, which was essentially an extension of current [MIPS (Media Information Products and System) Business Group] projects. He saw it as consisting of "a 32-bit CPU developed in a short time with unrestricted applications." Basically, he thought of it as an OA computer.

> However, the engineers Doi selected for his team did not listen to what Doi told them to do. They wanted to develop a workstation that could replace the VAX Super Mini Computer developed by Digital Equipment Corp. (DEC). This was a computer that the engineers often fought with each other to use while at MIPS because of the limited number. They wanted to develop something they themselves could use for their own day to day work.

Re: Ruby delights built into the language

#65

Post by dragonwriter »

n0tth3dro1ds wrote: post #31
tra3 wrote: post #16

Earlier quoted context omitted.

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.

> How do you debug/reason about this? Debug? You don’t. You have to break your sexy chained-functional-style 1-liner into a “boring” multi-line loop to actually set meaningful breakpoints and work through any problems that may arise. Which is why I dislike this style of code — once something goes wrong, it’s WAY more cumbersome to debug and almost always makes you “unroll” it into its boring, “classic” form. And, of…

> Debug? You don’t.

If by “debug” you mean “step through with a debugger” (at least Ruby’s standard debugger), sure (except at the steps with blocks, which you can easily insert as noops as needed with #tap). But, honestly, I almost never resort to using a debugger in practice, so minor variations in where breakpoints can be set aren’t something I see as a big deal.

> and almost always makes you “unroll” it into its boring, “classic” form.

No, it never makes you unroll it in Ruby.

Re: Ruby delights built into the language

#66

Post by TomK32 »

jrochkind1 wrote: post #46
area51org wrote: post #30

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…

Then the reasoning for this weird code is that it's meant as a base to be extended. E.g. handling more variants of filenames? Anyways, maybe it's worth submitting a pull request with simpler code.

Re: Ruby delights built into the language

#67

Post by barrenko »

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?

Re: Ruby delights built into the language

#68

Post by TomK32 »

brasic wrote: post #54
ysavir wrote: post #50

Earlier quoted context omitted.

> A file whose commit history shows... it's part of the very first commit recorded in git history, in 1998 by matz, the original author of ruby. So not necessarily written by Matz, but part of the body of work that eventually saw a `git init`, and early enough that much of the modern standard Ruby formatting was still emerging. Doesn't seem all that surprising to me in the context of when it was written.

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

Re: Ruby delights built into the language

#69

Post by steve_gh »

jrockway wrote: post #18
phoronixrly wrote: post #14

Earlier quoted context omitted.

I mean, no one's making you use this functionality, why should it be removed?

Once things are in the standard library, they're basically impossible to remove, unless you want to break everyone's code and prevent them from updating. If you're making a new programming language today, the standard library is a place where you should think very carefully about everything you add. Every programmer learning the language will have to be familiar with the standard library, so keeping it small is good.…

Depends also on what you mean by the "Standard Library".

Back in the day Ruby had built in language features (e.g. Innumerable), and a standard library that was bundled into the distribution (e.g. GServer).

More recent versions of ruby have significantly streamlined the standard library, pushing a lot of the functionality into Gems (libraries). Given that the use of a Gemfile to list library dependencies is absolutely standard practice, the upgrade path simply involves adding a line to the Gemfile.

In practice, these changes have been very well signposted before they have happened.

Re: Ruby delights built into the language

#70

Post by isomorphic »

barrenko wrote: post #67

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?

If you're looking for IDE-level language assistance, I can't help you, but since you mentioned nvim: I use regular vim with CoC / Conquer of Completion (vim plugin; LSP server, may not strictly be necessary for nvim), Solargraph (Ruby Gem; language server), and Rubocop (also a Gem) for linting. I previously/still use ALE (vim plugin; Asynchronous Lint Engine) because I haven't gotten CoC+Solargraph to play nice with Rubocop, probably due to something silly.

https://github.com/neoclide/coc.nvim

https://solargraph.org/

https://rubocop.org/

https://github.com/dense-analysis/ale

My impression with all of this running under MacVim... it's plenty responsive. It can take a while for Solargraph to index everything on startup if you're working in a big project; once it loads, it's snappy. (There's probably a way to cache that startup scan.)

Post reply on HN