I do think this is the culture of Ruby, appealing to some and not to others.

Ruby is a practical language by design and it's common to see good-natured poking fun at academic concepts that sound good in theory, but fall apart on corner cases (and real projects are full of corner cases).

Case in point: https://twitter.com/dhh/status/216238003817938944

People looking for conceptual purity should look elsewhere.

Please don't look elsewhere for conceptual purity. Ruby is absolutely ideal for exploring any concept that can be expressed in object oriented programming, and even many that are expressed in algebra.

Ruby has been designed fundamentally as an Alan Kay style object oriented programming language. In that light in my opinion it is more suitable for conceptual purity than most other scripting languages.

DHH's criticism of SRP has to do with legitimate drawbacks. I think all of us have experienced the over-engineering SRP can invoke when applied naievely. Also note that DHH's framework Rails has made significant steps in enabling SRP for modern Rails applications, so this is not a flat out rejection of the idea.

I'm not sure Ruby is ideal for exploring OO concepts, as fine a language as it is. Missing, for example, are: inheritance of class attributes/methods, constraints on overriding methods (e.g. declaring as abstract or un-overridable/final), dynamic attributes.

Thankfully it's a very flexible and forgiving language, so there are third-party libraries (e.g. Hashie, ActiveSupport's Concern) to accomplish these kinds of things, but the core language doesn't offer them.

The SRP isn't really an academic concept, it's an industry concept: https://en.wikipedia.org/wiki/Single_responsibility_principl... I'd say it's more of a question of taste and organization.

I think that's mostly Aaron being Aaron, it's not necessarily some form of anti-intellectualism but more like just his personality at work.

I don't really have a problem with the tone of the interview but more with how vague the proposed objectives are.

Also, there seem to be some rather misleading facts in it - like the AOT and the 30% speed-up - in practice, after testing it - it helped to load Rails faster but other than that the benchmarks were virtually identical (don't get me wrong, booting Rails faster is great but they imply something completely different in the interview)

In fact what they said is that AOT only helps in the startup phase, making it 30% faster.

Aaron: 30%?

Matz: 30% is huge.

Aaron: Yeah!

Jonan: That seems like a pretty good improvement to me.

Koichi: I do think so.

Aaron: We just need a few more 30% improvements then Ruby 3x3 is done.

Matz: Yeah, that means 30% of the time is spent in the compiler.

EDIT: maybe they were joking once again?

> Koichi: I do think so.

This is mistake. I said "I don't think so". 30% is not enough.

I think there was a miscommunication in the interview. He meant load/parse/compile time. See http://www.atdot.net/~ko1/activities/2016_railsconf_pub.pdf

Of course Aaron was joking at that point.

I hope so. I always thought that Ruby could greatly benefit from something like .pyc files in Python.

I love working with Ruby; I get lots of work done in very little time. However, sometimes I just can't wrap my head around certain language design, documentation, and implementation decisions.

What about this seems anti-intellectual? Anti-intellectualism is not the same as having a decent sense of humor. They're obviously joking around and being a bit irreverent here.

The Haskeller was probably talking about the same 'deep freezing' feature that they mentioned above, right? Except it already has a name...immutability. But even as they were joking, the Ruby folks assumed it was some obscure theoretical feature that they didn't have any use for.

I don't quite read into it as much as you are.

They're after true immutability for threading and optimization reasons. They recognize it has a value. I get the feeling this is them joking about giving their Haskell friends a hard time, in response to said friends giving them a hard time. Some standard friendly back-and-forth tongue-in-cheek language snobbery.

Ruby makes a piss poor Haskell. For one, it's not Haskell - for two, it's not even trying to be Haskell. Even if Ruby fully embraces the joys and wonder of full immutability and pure functional programming now, the cat is out of the bag - there's a ton of mutable procedural impure code out there in Ruby. It simply wasn't built on pure functional programming and immutability as first principles in the same way that Haskell was. Ruby is a language that lets you, at runtime, monkey patch classes with new methods or new variations to old methods - letting you mutate constructs (methods, types, etc.) that in most other languages are immutable after and even during compilation. If you want Ruby to be Haskell, you're going to be disappointed. Fortunately Ruby still makes a pretty good Ruby.

This is in no way saying Haskell is a bad language, just that you should use Haskell if you want Haskell, and Ruby if you want Ruby. This is also in no way saying that Haskell concepts can't be borrowed, stolen, and brought over to Ruby - just that doing so will not turn Ruby into Haskell, no matter how much one might wish it.

The wordsmanship and joking about "real" immutability are in no way unfamiliar stuff to people in other languages, Ruby aside. In Java, it's the same deal, where maybe you can't change an object's fields, but it's fields' fields might be mutable. One layer deep, shallow freeze, shallow copy are actually pretty well understood concepts by "non-Haskellers", as well as the drawbacks and the need oftentimes for 100% deep guaranteed immutability--and the advantages and safety that brings. I think that the joke is that the label "immutability" in languages that don't support it from the ground up--unlike like Haskell--isn't really worthy of the name. But since we already dubbed them as immutable objects (even though they weren't really) you need some extra emphasis for true immutability...super immutable, seriously immutabile, really-really-immutabile, etc.

> So yes, they all agree that Ruby's current 'frozen' feature doesn't grant real immutability guarantees.

It grants immutability for the object itself. What they are pointing out is that other than fundamental objects like String, Fixnum etc., those objects will usually contain references to other objects (EDIT: any member variables etc., as well as the class, which means the ojbects observable behaviour can also change even if instance variables don't), and those will still be mutable unless they too are frozen.

So we can do immutability in Ruby currently, it's just a pain to do and requires knowledge about the objects - you could implement a generic "deep_freeze" that iterates over instance variables etc., but it would have uninented consequences because it would know nothing about which object references are shared where it's ok to break that by "dup"'ing the object to freeze it (and without dup'ing it, you risk other code that isn't prepared to work with a frozen object breaking)

This is mostly a "problem" because writing Ruby to work on immutable objects would often result in code that's not idiomatic Ruby, and so you won't get many Ruby developers to agree it's a real concern, though the trend is towards freezing more objects.

I suspect you don't know many of the Ruby core committers. They're an incredibly jovial bunch. Aaron loves puns and word play, just check out his twitter feed: https://twitter.com/@tenderlove. After rereading it, I can see why their sense of humor may have been lost in transcription.

That's fair. I got that they were joking, but I guess I didn't know to what extent.

They're being ironic. This is part of the Ruby culture in general, and Jonan and Aaron in particular tend to double-down on it. I don't think there's any hostility to Haskell or anti-intellectualism here.