This seems infinitely better than dynamically adding instance attributes. Dynamic instance attributes was absolutely the worst thing about "old school" Python programming. The language, community, and ecosystem are much better off now that it's considered bad style and is strongly discouraged. Unfortunately we are stuck with it in the stdlib logging framework and the Tornado web framework, but it's mercifully absent just about everywhere else, and help platforms will almost universally discourage people from doing it.
I mean if we talk about the creators/inspiration around these languages we have creators of Ruby from Japan where things are tidy, elegant and mindful of others. An inspiration for the name of Python is from Monty Python creators of the Ministry of Silly Walks which is kinda clunky looking when you watch it. https://www.youtube.com/watch?v=eCLp7zodUiI
> I wonder if the language influences the aesthetics.
The community does. You’ll notice that JavaScript command line tools are much fancier than other languages, with emojis and cool spinners. Being that many JS programmers are web developers there’s a sense of aesthetics baked in the community. Other communities don’t have to care about “pretty” in their day-to-day so their tools reflect it.
The languages don't directly influence the aesthetics. Rather, there's a culture that precedes a language, and the audience it attracts, and it defines the marketing of that language, among other things. Of course, there's always interaction and mutual feedback. But I'm just saying I don't see this as the high order bit.
In the case of Ruby, in fact the culture didn't come from Ruby, but Ruby on Rails, which marketed almost exclusively to non-programmers. "Classic" programmers suck at design.
Probably just selection bias. Ruby is way more niche than Python so Ruby programmers are less likely to be complete beginners.
It's quite a bit problem for Python actually IMO. It is so popular among beginners that a lot of libraries and StackOverflow answers are beginner-quality.
> Disclaimer: The point of the post is not that we should all be creating instance variables dynamically from now on, but just to show one way to do it for those rare cases when you actually do need it
Make sure you absolutely need it
Trying to track variable names and finding specific code when they are being generated dynamically can quickly become nightmare
Not really a problem I've come across but I'd say if you're passing 100 arguments to your initialize method, you probably need to refactor somewhere? Personally, I like seeing the instance variables I have rather than having them hidden in a magic list of attributes.
Your example is not equivalent to the Ruby code. You’re just assigning a value to a property which is always exposed, you’re showing getters/setters. The instance variables are not by default exposed or accessible outside the class/object.
> No such shorthand exists in Ruby (and I'm glad that Ruby doesn't have the feature bloat like TypeScript and C#)
I find that while Ruby’s syntax may have a smaller surface area there are so many more ways to do things than with other languages that I reach for others first.
Also Ruby encourages so much metaprogramming that it can be very very difficult to work out where a behavior comes from. You _really_ have to document everything and getting a good editor config for Ruby is very important. That said I still struggle to get basic autocomplete working with Ruby in vs code
I use ruby-lsp and solargraph and copilot. Personally I'm rarely tempted to get very meta at work, but side projects are another thing entirely. I think one project has six DSLs?
Here’s an example: https://github.com/rubymonolith/demo/blob/main/app/controlle...