Live data from Hacker News

Ruby 2.5.0 Released

ruby-lang.org

101–110 of 113 posts

Re: Ruby 2.5.0 Released

#101
post #96
post #92

Earlier quoted context omitted.

Would agree with your view, but Lisps are arbitrarily powerful by the means of macros and interop. In my daily work (Clojure) I can use different concurrency and typing models than Clojure originally envisioned, via core.async, clojure.spec. This is not some fairy tale or toy/PLT project. How many languages can fundamentally change themselves without breaking things or getting awkward?

Lisps are arbitrarily powerful, yes, sure. Once I too was a Lisp head, I am familiar with the advocacy. They also read awfully even with an editor designed for them. They aren't human-first languages. S-expressions are easy for a computer , they are hard for a human . So, yeah, that can be improved, too. "But you can do it with macros"--other people won't , and so you are thus devolved to the minimum set everyone can…

Threading macros (-> / ->>) can greatly improve readability, putting lisps on par with Ruby (which I appreciate much).

Best of all, emacs/Cursive lets you trivially transform a sexpr into a threading form, and back. So one doesn't even have to do much effort for refactoring nested (a(b(c(d calls.

Re: Ruby 2.5.0 Released

#102
post #96
post #92

Earlier quoted context omitted.

Would agree with your view, but Lisps are arbitrarily powerful by the means of macros and interop. In my daily work (Clojure) I can use different concurrency and typing models than Clojure originally envisioned, via core.async, clojure.spec. This is not some fairy tale or toy/PLT project. How many languages can fundamentally change themselves without breaking things or getting awkward?

Lisps are arbitrarily powerful, yes, sure. Once I too was a Lisp head, I am familiar with the advocacy. They also read awfully even with an editor designed for them. They aren't human-first languages. S-expressions are easy for a computer , they are hard for a human . So, yeah, that can be improved, too. "But you can do it with macros"--other people won't , and so you are thus devolved to the minimum set everyone can…

By the way I agree with `There is a better thing, even if you must make it`!

But I make those 'things' within lisp rather than by exploring new languages. If done sensibly, colleagues will be able to use those custom abstractions too.

Re: Ruby 2.5.0 Released

#103
post #69

Earlier quoted context omitted.

Nothing precludes a similar approach in Python: def backoff(wait=5, exponent=1.5): while True: yield sleep(wait) wait = wait ** exponent for backoff(): connect_to_a_thing() Here's the question: do you need exponential backoff in more than one place? Because if you don't, bundling all of that doesn't buy you anything and the original works just fine. > This is trivially composable with any other control flow you might…

Your solution is much cleaner to me, except (not really knowing Python) it looks like it might have a bug, in that the `while True` will never terminate.

I think you can break the for loop after the function call and it'll end after the wait is successful. Bit of a hack though

Re: Ruby 2.5.0 Released

#104

Earlier quoted context omitted.

It's not just you. I've been running a company on Rails for four years - never heard of that book.

As a Ruby ops programmer who came to Rails via Chef I had no exposure to Sandi Metz or any of the other Ruby OO thinkers. However, several years later, now that I have read and integrated the ideas in POODR to my work, I highly recommend it. Besides Sandi Metz, another Rubyist that I rate highly for delivering clear ideas about design is Avdi Grimm. His RubyTapas series quite radically changed my approach to building…

Thank you for the recommendation, I may just pick it up.

Re: Ruby 2.5.0 Released

#105
post #14
post #8

Earlier quoted context omitted.

Can’t beat reversing the backtrace output for making Ruby even more enjoyable. Slogging up through a huge pile of calls was one of the few things that drove me mad.

Just need to rework all these e.backtrace.first lines to e.backtrace.last Or maybe my favorite which is still good puts “#{e.message} #{e.backtrace.join(“\n”)}”

That code will still work, they are using the experimental feature only when the backtrace is printed to a tty.

Re: Ruby 2.5.0 Released

#106

Oh, it looks like Bundler didn't make it into the standard library for the 2.5 release. The commit to bring it in was reverted just before the release, with very little explanation. I mean, it's not like `gem install bundler` is that hard to do, but I'd be curious to hear why.

Same thoughts here, I thought that was the important step to gemify everything in 2.6. Are they reverting course?

Re: Ruby 2.5.0 Released

#108
post #101
post #96

Earlier quoted context omitted.

Lisps are arbitrarily powerful, yes, sure. Once I too was a Lisp head, I am familiar with the advocacy. They also read awfully even with an editor designed for them. They aren't human-first languages. S-expressions are easy for a computer , they are hard for a human . So, yeah, that can be improved, too. "But you can do it with macros"--other people won't , and so you are thus devolved to the minimum set everyone can…

Threading macros (-> / ->>) can greatly improve readability, putting lisps on par with Ruby (which I appreciate much). Best of all, emacs/Cursive lets you trivially transform a sexpr into a threading form, and back. So one doesn't even have to do much effort for refactoring nested (a(b(c(d calls.

I totally get that--what I'm saying is that, much like something like C++, you can only practically use the subset everybody you have to work with will agree is acceptable. Threading macros, IMO, help but don't really solve the readability problem, and it's still a far sight from Ruby, but it's a good step. But you have to get Bill the chin-stroking graybeard down the hall to use them when they're "not how he uses Lisp." Contrast this to a language with more guardrails--the equivalent of that threading macro in Ruby (or in Scala, or in F#) is just...The Way You Do It, it's the standard of the tools involved.

You're transforming a linguistic readability issue into a cultural problem of agreement and that's a waaaay harder problem to solve, IMO. Lisps are cool. But every problem raised to "cultural problem" is so much harder to solve. (When was the last time you saw an indent war in Ruby?)

Re: Ruby 2.5.0 Released

#109
post #101

Earlier quoted context omitted.

Threading macros (-> / ->>) can greatly improve readability, putting lisps on par with Ruby (which I appreciate much). Best of all, emacs/Cursive lets you trivially transform a sexpr into a threading form, and back. So one doesn't even have to do much effort for refactoring nested (a(b(c(d calls.

I totally get that--what I'm saying is that, much like something like C++, you can only practically use the subset everybody you have to work with will agree is acceptable. Threading macros, IMO, help but don't really solve the readability problem, and it's still a far sight from Ruby, but it's a good step. But you have to get Bill the chin-stroking graybeard down the hall to use them when they're "not how he uses Li…

Your observations are on point, and collaborating with lispers is not free of bitter moments.

At work we use cljfmt (similar to gofmt) plus a variety of hacky formatters and conventions. It works for us and I hope to open-source part of our stack at some point!

The experience is similar to that of Rubocop - which btw is the reason why there aren't indent wars (or similar) on Ruby.

Great to decomplect how code is written (however you please), from how it is committed (autoformatted).

Re: Ruby 2.5.0 Released

#110
post #61
post #46

Earlier quoted context omitted.

I started a new contracting gig a couple of months ago, in Ruby. I had used it briefly years before in another project, but it was so long ago that I had to learn it again basically from scratch. Although I don't really think the language is anything special (i.e. it's a standard dynamic OO language), what really turns me off Ruby is this dogmatic, almost religious aspect of its community. Take POODR - it's more or l…

Huh... didn't even know what POODR was... Guess I've been faking it for the past nine years... I mean, I did start a company that used Ruby/Rails as the primary platform. And I've worked the last six years in a shop that currently has a team of about 12 Ruby/Rails developers... Don't get me wrong, Ruby's a tool in my toolbox; I use it like I would any other tool. I like solving problems. Most modern languages make it…

You may enjoy Practical Object Oriented Design with Ruby by Sandi Metz. Speaks about OO software design in very clear and easy to grasp way.

I often share it with non-ruby devs because it’s about design much more than it is about ruby.

Here are a couple of talks by the author which examplify her style of thinking and approaching problems.

https://m.youtube.com/watch?v=29MAL8pJImQ

https://m.youtube.com/watch?v=8bZh5LMaSmE

Post reply on HN