Second, I cannot refute your arguments. That is because I see them more of a personal preference or somehow expectations based on your programming history (I might be wrong of course as I don't know your programming history). As Ruby feels similar with other programming languages I think some kind of expectations of how things should be kick in. But Ruby has a specific design that is for example focused on "brevity" or "beauty" among multiple other thigs.
I worked so far in the last 15 years in multiple codebases in Ruby: large Rails apps, Sinatra apps but also smaller webapps. In all kind of combinations some of them I built and maintained alone and some of them were built in a team.
This being said, I don't remember a time when we have a big name conflict because we used a couple of gems and they were colliding.
I do remember when some colleagues were over using meta-programming too much or changing default behaviour of stdlib. But this can be fixed with coding guidelines and I take imposing coding guidelines over removing these features from Ruby as sometimes they make more sense than anything else.
Regarding ".self" I don't feel the need to use it. Once I got the call hierarchy I prefer not needing to write "self" where it is not needed.
But also in Ruby everything* is an object thus I feel that self is a bit more powerful so it should be used when when it is really needed like when defining methods and you want to indicate where that method belongs.
Regarding having multiple ways of doing the same stuff in stdlib, here we diverge as I prefer this diversity. I really like that we are multitudes in this community so code can be written in multiple ways, it is for me almost like a form of art when I read some case and I see how expressive can it be and how easy it is to get what it does even if it uses a different std method than I normally use.
I think if you want to get Ruby you should start by thinking that Ruby is a programming language created (IMHO) with the intention to let you express yourself but also make it so that other people should easily understand it.
It also worth reading this beautiful essay by the creator of Ruby: https://www.oreilly.com/library/view/beautiful-code/97805965... (sorry I could not find a direct link unwalled) and from there you will get a glimpse of why Ruby is in a specific way and see if you agree or not with that.
For example regarding your point with no leading self, Matz says in that essay "programs should ideally contain no unnecessary information" thus a lot of what you see in Ruby including having prepend instead of "insert(0, object)" is a manifestation of that.
https://www.oreilly.com/library/view/beautiful-code/97805965...
My favourite use of popcount is for packing sparse vectors.
- https://www.oreilly.com/library/view/beautiful-code/97805965...
- https://github.com/stormtrooper96/books/blob/master/software...
So I'll definitely give it a read. Thanks!
http://shop.oreilly.com/product/9780596510046.do
“The Architecture of Open-Source Applications”
You also might be interested in “Coders at Work”.
If you're interested in more detail about how a VFS (Virtual File System; the bit where it finds the file and then finds the data in the file) works, Chapter 17 (Another Level of Indirection) in Beautiful Code (http://shop.oreilly.com/product/9780596510046.do ) is well worth a read.
It explains how the VFS in FreeBSD works. How disks, partitions, volumes, filesystems, offsets, etc all get orchestrated together so that the Unix "single directory hierarchy" abstraction works as intended even tho' the actual data may be spread around a number of locations (both local and remote).
The concepts and ideas are largely applicable to other Unixes and Unix-like operating systems.
It's also a great example of how elegantly one can express polymorphic code, even in plain C.
I particularly liked Brian Kernighan's description and implementation of a regex matcher, and Travis Oliphant's discourse about multidimensional iterators in NumPy.
Worth a read.
Beautiful Code [2] is a well-known book that attempts to examine the development of some successful software projects from the perspective of the lead developers, and how they came to design decisions.
Beautiful Architecture [3] is a similar book focusing on large-scale project design.
Maybe if a user's submission becomes well liked they could be asked to write a more in-depth explanation or article.
- Javascript: The Good Parts (http://oreilly.com/catalog/9780596517748/) - High Performance Javascript (http://oreilly.com/catalog/9780596802806/) - Information Architecture for the WWW (http://oreilly.com/catalog/9780596527341/) - Javascript: The definitive guide (http://oreilly.com/catalog/9780596101992/) - Beautiful Code (http://oreilly.com/catalog/9780596510046/)