Ruby 2.5.0 Released (opens in new tab)

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 easy and fun to solve problems.

I don't like when it's easy to see where a language is encumbered by poor choices (I seem to have a diametrically opposed viewpoint of your opinion of the Javascript community; to me, the redundancy, low quality and churn of community libraries is one of Javascript's greater liabilities). But if it works for you, that's great.

Language Holy Wars are necessary for young, budding languages and young, budding programmers. Language Holy Wars help young communities draw others to their banner and young programmers define themselves. Unfortunately, having causes and "bad guys" is a big part of the underlying way we work as people.

But at some point, once a language's adoption has reached critical mass & once you've reached a point where you're comfortable with the underlying paradigms of programming, these Language Holy Wars get left behind for more interesting problems.

I mean, I definitely have opinions about what language I'd prefer to be working in and why, but at this point, I make my determination of technology based on the right tool for the job, not necessarily my opinion of any given language.

As a counterpoint, I have been writing Ruby as a primary language for about five years, both as an employee and a consultant. I am consistently solicited for advice on both code and architecture in Ruby by colleagues to positive results (and I do the same, don't get me wrong--that's how collegiate relationships should work). And, yet, I had to google what POODR was. I've also never used Rails; on this Christmas morning I'm noodling on a Grape API that uses grape-swagger for API documentation.

I have never seen any resistance to experiments or diversity in the space. There's a happy path, but there's plenty of room, and welcoming communities, outside of it.

(I like JavaScript, too, for much the same reasons you do.)

I'll pile on here with another counter data point to say that having written Ruby (both Rails and otherwise) for 7 years, and having read POODR, I do not understand where you're getting this dogma idea from. I have yet to experience a single instance of "It's POODR's way or the highway."

> Take POODR - it's more or less the community bible. If it's not written in POODR - don't do it. If it is - do it that way or else. It's POODR's way or the highway.

Sandi Metz would tell anyone espousing that the text written in POODR is to be taken at face value as gospel that they're completely wrong and completely missing the point. I've actually personally seen her correct this behavior at a conference and at a workshop and I've heard her say it many times in many places and mediums (podcasts, blogs, interviews).

Anyone who says "it's POODR or the highway" should be corrected, because they are very dangerous to any software engineering endeavor.

hey pka,

some comments here mention that they've been doing ruby for years and never even heard of poodr. i think that's less of a point.

it sounds more like you feel stifled at your current job. there's no right answer when it comes to a software stack and it doesn't sound like your coworkers are excited about the same things you are. it doesn't have to be that way! i hope you find a new consulting (or full time gig) that stimulates you intellectually. merry christmas and happy new year.

I've been writing Ruby for 4 years, and I had never heard of POODR before.

I've also never come across any particular dogma in the Ruby community -- there are established best practices for formatting code, but individual projects vary widely style and design decisions. Most Ruby codebases I've worked on come with a custom `.rubocop.yml`, and that's it.

Ruby & Rails developer since 1.8/2.2, never heard about POODR

What is POODR?

Disagree 1000%.

Just because you can write a monstrosity in Ruby doesn’t make the language itself inelegant.

Ruby, of the many languages I’ve used, has by far the highest potential for code being poetry. You can find solutions that are incredibly simple and understandable due to so much boilerplate being remove from the syntax. Likewise you can write code that’s impressively concise without being inscrutable — I’m continually astonished by how readable Ruby can be.

One exercise in particular sticks out in my mind. Many years back, I implemented the first few dozen Project Euler problems in Ruby. However, I imposed a limitation: each solution had to be under 72 characters (library inclusions are fine), a single logical line, and readable. The end result was surprising at how naturally it ended up working — the solutions ended up being little more than the high-level conceptual approach, translated literally to code. Solutions ended up looking like the following:

    (2 ** 1000).digits.sum
    (2..10_000).amicable_numbers.sum
    1901.to_year.upto(2001.to_year - 1).select {|d| d.mday + d.wday == 1 }.count

Sure, these depended upon injecting new methods into core classes, but who cares? For this problem it led toward incredibly straightforward and readable solutions for these problems. If this were library code I wouldn’t dream of doing it this way, but for application code — why not?

I have yet to see any other language with Ruby’s capacity for readable conciseness.

I think there's a lot about its expressiveness that's elegant. You can't pick one inelegant practice and define the entire language by that — nothing would pass that test.

But for example, Ruby's method-based control flow allows for sophisticated ideas to be expressed in a way that's clear but doesn't demand undue attention. A while back I needed to implement a common structure in Python for basically "repeat this operation with increasing sleep times until it succeeds" in the context of a particular library. Every option I could come up with was fairly inelegant, either requiring more attention than it deserved or being excessively oblique or just reading like a neural networks trained on Python, and none of the senior Pythonistas at my work could come up with anything much better. But I could clearly picture how to do it in Ruby, and it wouldn't have had any of those problems there. The extra expressiveness allows it to express the idea elegantly.

I don’t think you can call monkey patching inelegant or a hack. Monkey patching is the absence of extra rules - not allowing a method to be defined more than once - and the prescence of consistency - all methods can be redefined.

It’s certainly problematic when used! But the feature itself is elegant and the opposite of a hack. Disallowing monkey patching requires extra conditions and rules, not less.

Arguing that something isn't elegant is a lost cause.

What's an example of one of those kludges? "Ruby concise" at least looks elegant, whereas, say, "Perl concise" is hideous.

minitest also provides a spec-style DSL. Rspec is a hog, minitest is much, much cleaner and leaner, even if you use the DSL.

Note how I said compiled languages, I expect Python to have some very similar capabilities. :) But as an example, take the cleanness of the following mock:

  allow_any_instance_of(Set).to receive(:member?).and_return(true)
  <rest of test code>

Contrast this for example with testing IO monad code in Haskell, where the best practice is to define a new monad 'underneath' your original monad stack, rewrite all your functions signatures to have a type constraint (of your new MonadIO type) and then switch out functions for their mocked equivalent as required by the test. Rspec can do the same switching out on any object or class, without any code required outside the test code. (Although as far as "handle with care" goes, monkeypatching the 'send' method has to score pretty high)

rspec’s internal DSL is based on Ruby’s multi-line anonymous functions. I don’t know how you achieve a similar design in Python where you don’t have those in the same way. How do you write the equivalent of ‘it ‘does something’ do ... end’ in Python syntax?

> Groovy (a compiled language)

Because of its use in scripting on the JVM(e.g. glue code and Gradle builds), Apache Groovy files are usually stored in the file system as text. Each time they're run, they are "compiled" into JVM bytecode. Although you can get pre-compiled .class and .jar files for Groovy, it's not common for people to build large systems with it.

Patron, from here: https://github.com/toland/patron. We use it in combination with our (open source) FastSend gem to keep the streamed data away from the Ruby garbage collector, since it gets a bit emotional if it has to clear out hundreds of MBs every second. If you're interested why we chose this architecture instead of just redirecting to S3, our lead engineer gave a talk about the reasoning behind this structure. You can find the slides at https://speakerdeck.com/julik/streaming-large-files-with-rub....

ERB generation should be a lot faster, which will be a boon for a lot of Rails apps, and according to the release notes there's a 5-10% performance improvement overall from removing all trace instructions from bytecode.

In addition to the ERB generation and removing all the tracepoints mentioned in the sister comment, there is also a change in the hash function used for Hashmaps. The new one needs roughly half the hashing iterations so it should slightly speed up any application that uses hashtables. (aka pretty much every ruby app)

Among others, from the linked article:

    About 5-10% performance improvement by removing all 
    trace instructions from overall bytecode (instruction 
    sequences). The trace instruction was added to support 
    the TracePoint. However, in most cases, TracePoint is 
    not used and trace instructions are pure overhead. 
    Instead, now we use a dynamic instrumentation technique. 
    See [Feature #14104] for more details.

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's true until you decide to delete tests/code that is no longer in use. Then it becomes much more difficult to track down dead code paths

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?