New year, new comment! :D
jzakiya wrote:
Ruby has borrowed concepts/idioms from allot of languages.
This is true; ruby has always been multi-paradigm and " more than one way ", even though I think its core strength has been "flexible" OOP. Or at the least that is the style variant that is closer to the way I think; sort of like Alan Kay's "objects everywhere". I'd even like to think of Erlang/Elixir as a bit of "distributed objects", but the syntax is weird ... even elixir's syntax is a bit weird. Ruby's syntax is, for the most part, IMO the best among all programming languages - not all of the syntax perhaps, but the subset one can use.
However had there are also many idioms ruby has NOT integrated.
So I don't think you can generalize from the addition of some features, while not ignoring how other features/changes were rejected in the past or were not a great fit; matz sometimes said this before, such as the perl $ variables that are very short (I can never remember them offhand; I always have to look at a cheat sheet to remember what they do).
mame once explained this in another thread in regards to feature suggestions and discussions, e. g. when matz does not like a particular feature. :-)
(It's also explained in the very old interview matz gave about ruby's philosophy and orthogonality of features/ideas, so this is a trade-off that exists AT THE SAME TIME in regards to "more than one way". The "more than one way" never meant to be a "have so many ways nobody understands anything now". Ruby is still designed. I think an example for this is the pattern matching change. For me personally it is too complicated to use, but I understand the use case and "batch-variable assignment" that you can do via pattern matching.)
My own personal style in ruby is much closer to a "prototyping", flexible/dynamic OOP variant, without much restrictions to it (so I don't really use private, excluding a few libraries).
Other ruby users use a different style , such as zverok with a more functional-centric style approach - which is quite creative too. For me personally, while it is an interesting style, it's a style I can not see myself wanting to use; for similar reasons I don't use haskell. It's simply way above my brain powers; more importantly I can't be bothered to want to have to think about code that much, I just want to write something and move on. Monad discussions are fun to have, though. :-)
jzakiya wrote:
Thanks is advance of giving this proposal serious consideration.
Ultimately you only have to convince matz. The ruby core team tends to recommend to focus on the use case(s) - evaluating the use cases, or potential use cases, helps a LOT. But matz also commented on other proposals before, where people making a suggestion often don't evaluate trade-offs or potential drawbacks from a suggestion. You can see these problems with the type discussion; some love types and want them everywhere. Others don't love types and don't want them everywhere.
In regards to the proposal here, I personally don't really see why that is necessary, but your mileage may vary.
One problem I see in general is that ruby branches out a lot and includes many disparate "functionality", and syntax changes, some of which may all end up with an orthogonal design (I don't mind it when I can avoid it, so I just focus on the "subset" of ruby that I use). I am not saying this should be the primary point to consider, but it sort of creates a problem when you add more and more features that are not quite "the ruby way", whatever that way is.
jzakiya wrote:
As 3.0 has introduced many new features and idioms, this could be introduced with no breaking change too.
I don't think this can be a criterium as to why any new functionality should HAVE to be added, merely because OTHER functionality/feature was added before. My recommendation would be to simply focus on what the proposal adds, irrespective of any other feature that was added.
Forth is an interesting language but ruby is not forth. There is no "compilation" as such in MRI, although it would be interesting for this as a new, or VM-like language on top of ruby (e. g. some meta-ruby language that people could target; then you could add a "layer" that the type-liking folks focus on, without this modifying MRI itself, such as the .must!() suggestion or similar changes). IMO the main focus of MRI is still sort of like an "improved perl" and these use cases. :-)
Or perhaps python; I feel these are all part of the same "family" of languages.
I am not matz, so I don't make the decisions, but I think matz much prefers to keep the "ruby philosophy" as it was (so, within that "family" of languages, in regards to MRI itself), while adapting ruby to current usage patterns in the present day - I guess ractors are sort of a way to move forward there, e. g. more easily taking advantage of multiple cores and trying to avoid the GIL block.
Otherwise, I think Benoit really gave a great statement in regards to the suggestion here, that I personally agree with most in this regard:
I think this feature would just confuse people. Constants are a thousand times clearer, and simpler.
I think so too. Then again I also prefer simplicity at all times. And strict definitions. :-)
(I do like ruby being dynamic and flexible too, though. But for my own code quality, and in my own projects, I want to focus on simplicity, and being strict helps a LOT, IMO. For example, specifications. I always found it simplifies so many other things when specifications are strict, and correct at all times.)
So my personal opinion: I don't think this would be a good change. But as said, ultimately you only have to convince matz; it may be interesting to see what matz has to say about this feature or similar proposals in this regard. See nobu's code example (although I have to admit, I also don't like the suggested syntax. I do, however had, use END sometimes, which is a great feature. I avoid "begin" and "after" or whatever the names were ... BEGIN/END or something, though, as I always feel as if I lose control over my own code whenever I use it. I noticed this in a gem, where this was triggered from someone else using it, and I did not know how to avoid or prevent it. And I dislike when I have no control over ruby code, so I also started to avoid that. But I digress.)