You can tell this very easily if you’ve written any “pure” Ruby in the past and you’ve had to search for how to do something on SO. There’s so many (mostly old) answers that use methods that are only available in ActiveSupport and most of the time they don’t even mention it because they assume you’re using Rails.

I used to write a lot of Ruby on my own but I never used Rails (though I did end up reimplementing ActiveRecord once or twice…) and I remember this issue driving me crazy sometimes.

It’s a lot like JS and JQuery a few years ago, if you wanted to write something in pure JS and ended up on SO while searching for how to do something, you had to trudge through a lot of JQuery before finding a pure JS solution, if there even was one.

I find it so interesting thinking about the way that programming languages can reflect natural language with dialects.

I feel like you could also think about writing with a particular ‘accent’ when you are writing code that isn’t idiomatic to the language you are using. For example, if you came from Go to Ruby you might start writing a bunch of for loops, which is valid but not typically how Ruby is written. You are speaking Ruby, with a Go accent.

I completely agree with the points the author makes, but not the summary. To say that a monkey-patched DSL of this sort “isn’t Ruby” is like arguing that any particular use of macros “isn’t Lisp”.

That’s correct in the sense that the language has been extended (far more elegantly in the latter case, I’d argue), but extension in that manner is idiomatic use of the language itself. To take a concrete example from Common Lisp:

CL-USER> (loop
	   for x in '(1 2 3 4)
	   sum x into y
	   collect y)

(1 3 6 10)

That LOOP is most certainly not Lisp … for, sum, collect, read more like an RDBMS dialect. However, it also most certainly is Lisp because …

CL-USER> (macroexpand `(loop
			 for x in '(1 2 3 4)
			 sum x into y
			 collect y))
(BLOCK NIL
  (LET ((X NIL)
	(#:LOOP-LIST-648
	 (SB-KERNEL:THE* (LIST :USE-ANNOTATIONS T :SOURCE-FORM '(1 2 3 4))
			 '(1 2 3 4))))
    (DECLARE (IGNORABLE #:LOOP-LIST-648)
	     (IGNORABLE X))
    (SB-LOOP::WITH-SUM-COUNT #S(SB-LOOP::LOOP-COLLECTOR
				:NAME Y
				:CLASS SB-LOOP::SUM
				:HISTORY (SB-LOOP::SUM)
				:TEMPVARS (Y)
				:SPECIFIED-TYPE NIL
;; ... snip ...
	  (GO SB-LOOP::NEXT-LOOP)
	 SB-LOOP::END-LOOP
	  (RETURN-FROM NIL
	    (SB-LOOP::LOOP-COLLECT-ANSWER #:LOOP-LIST-HEAD-649)))))))

So while it’s fair to say that LOOP isn’t Lisp … also, in a more fundamental sense, it is, because Lisp is for creating DSLs (in the same way that Ruby is).

I’m surprised that the article doesn’t mention Ruby’s refinements feature. That feature, introduced in Ruby 2.0, provides a safer alternative to monkey-patching by limiting the monkey-patch to an explicit lexical scope. I would liken using a refinement to opting into a dialect only for a small piece of code, which I think would not be much riskier than using a non-monkey-patching library that provides a DSL.

With refinements, a library could mimic ActiveSupport’s 1.day.ago API without adding methods to numbers in the rest of the project:

def user_trusted_yet?(user)
  using SomeRefiningDateLibrary

  user.signup_time < 1.day.ago
end

I don’t often work with Ruby or RoR, but when I do I constantly mix up which features are Ruby-native and which ones are only present in RoR. This does not happen in Django, for example, where the code itself is without a doubt a clear Python, even if it’s wrapped in layers of abstractions. So I agree with an author even if I find the title a little bit clickbait‘y.

In the same vein, the Linux kernel is not written in C. It immediately becomes apparent when you read and write kernel code. This has many reasons, for example that Linus Torvalds thinks that the ISO C Standard is a “piece of garbage” that imposes “braindamage” which needs to be undone [1] and also because the kernel uses non-standard GNU C extensions [2]. Think of that what you will, I guess it works well enough to power most devices on the planet. Makes you wonder if the Linux way of writing C should be the actual C standard.

[1] https://lkml.org/lkml/2018/6/5/769

[2] https://www.kernel.org/doc/htmldocs/kernel-hacking/conventions-gnu-extns.html

This reminds me of the old prototype JavaScript framework. Back in the day, it was a serious contender for becoming the frontend framework of choice. It did many of the tasks that jQuery or UnderscoreJS do.

It took the idea of JavaScript having prototypical inheritance and ran with it - extending core object prototypes (mostly of DOM objects, but also Array and even Object) with useful shorthand methods. For example, you could write Document.getElementById('foo').className += ' bar' as $('foo').addClassName('bar'). The $ is not like in jQuery where it returns a special proxy object that operates on the DOM objects it points to, but literally just a shorthand for Document.getElementById. (well, not 100% the same, because IE didn’t support manipulating prototypes of DOM objects…) It also allowed you to write [1, 2, 3].map(function(x) { return x * x; }) to square numbers in an array, back when such functional idioms were mostly unheard of in JS.

I think it fell out of favour when jQuery hit the scene because it did much of the same but in an even more concise way, even if it didn’t rely on extending objects in the original (Self-inspired) spirit of the language. I found the idea quite elegant, but in retrospect I can certainly see (potential) problems with it when Prototype’s added methods would clash with ones from additional (Prototype-unaware) libraries or with native methods.

Basically, the problem with approaches like Prototype and Rails is that they’re polluting the “global” namespace of methods defined on core objects. It’s not exactly as introducing global variables or methods, but it comes close to it, as they’re adding methods to object types they don’t own (now referred to in the derogatory term “monkey patching”). Also, it’s no wonder the Rails authors originally baked in Prototype as the frontend library for dynamic UI stuff - it shares the same ethos.

I think that’s a great way of putting it. While Ruby isn’t my major language and RoR isn’t my framework of choice, I maintain a RoR project and when other developers interact with it it’s hard to explain, when they mix up RoR and Ruby a lot.

For some of them I think RoR gave them a very bad opinion about Ruby. So while it might be that Rails in a way made Ruby popular, it feels like it also put people off trying to use Ruby. I noticed that once when I realized how hard it was to find maintained libraries outside of the real of web frameworks. At least some areas felt like an abandoned ghost city.

I think Ruby picks up a lot of interesting concepts from Smalltalk in a language that is more accessible to how we usually develop things today. A lot of them are really missing, everywhere else.

Anyways, it feels like we switched from that class of languages being maybe over-used to not using them anymore, yet sometimes end up hacking in bits here and there in things that are usually called frameworks, so where enough code accumulates that it is considered okay. Those could be considered dialects or accent as well.

What I want to say with all of that is that a lot of languages gravitate into the same direction, making them more similar, which might be nice for switching, but I think is overall a bad thing, because then having various tools with different strengths and weaknesses turn into tools of trends and hypes, mostly described by which decade they stem from, like fashion.

Overall it seems like a lot of reinventing the wheel and having to keep up with fashion trends in order to find jobs, or other developers and a reinforcement of the newer is better “logic”.

I don’t know that the conclusion follows the opening. Dialects evolve to fit a distinct group of people as the needs of those people diverge from the general population. Contrast this with a domain’s jargon which is extra terminology to apply to a specific problem set that some speakers of the language may have. In the programming world this is frameworks and libraries. Frameworks each have their own particular way of speaking the language, and libraries can add extra vocabulary in to any framework. In terms of natural language, if I already speak the Beijing dialect of Chinese I will have an easier time adjusting to the Sichuan dialect than a non-Chinese speaker. And a speaker of either dialect can learn the jargon required for Computer Science. In terms of programming, if I already know the React dialect of JS, I will have an easier time learning Vue than a non-JS programmer. And I would also posit that React and Vue have both been a step up from vanilla JS for the needs of application building. Though vanilla JS has grown and improved during the time those projects have existed and the dialects in the future may weaken

Lack of scope, a properly module/import system is what makes Ruby harder than it looks.

Imagine you open a file and see this code

https://apidock.com/rails/v6.1.3.1/Class/class_attribute

class Base class_attribute :setting end

https://apidock.com/rails/Module/mattr_writer

module HairColors mattr_writer :hair_colors end

What do you do ? Literally somones just google class_attribute for Ruby docs, only to found it in Rails doc and confuse? Where does class_attribute come from? If it’s Python we have to do something like from .. import foo as and they know where it comes. In Ruby, it pops up out of no where, populate the current scope where you see it like a walk in the part.

So to me, the problem is that Rails tried to mimick a lot of core Ruby method. mattr_writer to mimick attr_wrtiter ?

If it was written this way

class Base Rails.class_attribute :setting end

everyone will be happy

Reading all the comments about wanting to make a dialect or whatnot within a language and no mention of Forth, where you can define essentially anything and even redefine words within scopes! Just how real world languages can have the same words/sounds but different meanings.

The article makes a lot of good points. Monkey-patching is dangerous and a bad practice for libraries. Randomly patching core classes can very quickly turn into a massive headache. In my opinion, the ruby community has largely learned this lesson in this regard. It was used far too much a decade ago.

But the rest of the article falls flat. ActiveSupport is special and it does have a monopoly… on being ActiveSupport.

This is because ActiveSupport isn’t a library, it’s a language extension, and it is so widely used that is has become a standard on its own. Rails Ruby is its own language. You might as well complain that python has a monopoly on being python.

Overall, this is a very, very old argument. I started with Rails 1.2 in 2007 and saw this on IRC. Some years later, I remember going to a ruby meetup in Seattle in 2011. There were some very angry people there that hated Rails for ruining their language. And it was clear this was going on for years before I ever started programming.

I wrote my first ruby program in over 15 years last week. all my ruby experience predated rails, and I hit this situation almost immediately with my new program.

This is why namespaces.

In Poland we speak Polish, which is a really difficult language, it’s actually considered one of the top-10 most difficult languages to learn in the world.

I get annoyed with this kind of comment.

I bet if you ask the Chinese, English is the hardest language to learn in the world. Yet it’s the language most widely spoken around the world.

I don’t know what kind of ethnic pride comes into play when people say “my language is difficult” or “my language is easy”. Usually they just mean the orthography matches closely the pronunciation or not. For example, most “English is difficult” jokes come from its spelling; almost no English speakers even complain about phrasal verbs or even know about them, and that’s arguably a far less predictable aspect of spoken English.

Polish is really easy to learn if you know, say, Russian. Polish is extremely easy to learn if you’re a Polish child. I don’t know by what kind of metric one could reasonably classify the 10 most difficult natural languages of the world.