Managing different projects with different Ruby versions with rbenv has been the bane of my existence the past couple weeks. Why isn’t this experience fleshed out better by now?
An Ode to Ruby
51–60 of 204 posts
Re: An Ode to Ruby
#52I think Ruby might be the antithesis to Java. For all that I despise Java's ridiculous boiler plate, I always know exactly what's going on. In Ruby, I feel like there are unknowns in every file. I hate Java, but Ruby makes me miss Java.
> For all that I despise Java's ridiculous boiler plate, I always know exactly what's going on
Not my experience at all when doing Spring Boot, talk about magic. Rails looks dead simple compared to that.
Re: An Ode to Ruby
#53Earlier quoted context omitted.
"I still can't think of a better language for scripting." Python I find equally if not more simple. Would you agree?
Equally maybe. Simpler? I'm not sure, I don't know Python very well. A couple of things I found surprising about Python was having to do the whole `re.compile` thing instead of just `//` in Ruby. Also, no one will ever convince me that a list comprehension is simpler than `map` and related functions. Also, it's hard to beat the convenience of libs that let you do `1.day.ago`. Ruby gets complicated when people start t…
> Ruby gets complicated when people start throwing around metaprogramming where they shouldn't.
This is true. Thankfully it appears that the broader Ruby community has recognized this as well, and has moved away from metaprogramming to a large extent. It's still there, but you don't see it utilized nearly as frequently as you once did.
Re: An Ode to Ruby
#54Earlier quoted context omitted.
To be fair, you almost never should use the map builtin instead of the pythonic equivalent, list comprehensions. `print([x + 1 for x in [1, 2, 3])` I agree that the ruby approach is better in terms of consistency, but most developers will be aware of the conventions python uses.
You're splitting hairs about what the op said. How about len() ?
[1,2,3].__len__()
Re: An Ode to Ruby
#55One of my goals for 2022 is to write my first real web app. I want to understand things like authentication, creating an API, and security. My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.
> My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.
God, yes. Especially with Hotwire [1], which advertises being able to do modern web apps with a minimum of JS. I've played around with it, and for me it completely eliminates the need for AngularJS/React/whatever.
Re: An Ode to Ruby
#56Earlier quoted context omitted.
"I still can't think of a better language for scripting." Python I find equally if not more simple. Would you agree?
Having done both professionally, I'll take Python any day of the week. The "Expressivity" lauded by Ruby fans translates into a lack of readability. But the things that drives me crazy is the optional/alternative syntax of ruby.
Ruby is a lot like spoken language in that regard. When the many ways in which to do things are chosen well, Ruby reads like pure poetry. For that I will always enjoy Ruby.
Moreover, the choice of which idiom to use conveys the intent and mindset of the author.
But like any complex language, it's also possible to write very unpoetically, and like any complex language, readability is a function of familiarity with the language's syntax and idioms.
Re: An Ode to Ruby
#57Earlier quoted context omitted.
Nope. Can't stand that Python uses built-in functions for basic things like list, map, fold, etc... instead of methods on base classes. Here's a super basic example. Add one to an array [1,2,3] and print results. Python: print(list(map(lambda x: x + 1, [1,2,3]))) Ruby: print [1,2,3].map {|x| x + 1} So much more readable, easy to write, etc... Ruby keeps it consistent by making pretty much everything an object and you…
To be fair, you almost never should use the map builtin instead of the pythonic equivalent, list comprehensions. `print([x + 1 for x in [1, 2, 3])` I agree that the ruby approach is better in terms of consistency, but most developers will be aware of the conventions python uses.
Python, I think, has n number of ways of doing the same thing while Ruby's everything is object approach forces you down a single approach. So while reading ruby code, you usually don't have to shift your mental model from OOP to procedural/list comprehension etc.
If Ruby gets a good machine learning library on par with something like Pytorch, I am sure many folks will shift to it and we might see new DSL emerge.
Re: An Ode to Ruby
#58Managing different projects with different Ruby versions with rbenv has been the bane of my existence the past couple weeks. Why isn’t this experience fleshed out better by now?
Use rvm with .ruby-version (and optionally .ruby-gemset) files in each project. RVM hooks into the cd command so it's automatic.
For CI scripting you use "rvm (path) do (command)."
Re: An Ode to Ruby
#59I think Ruby might be the antithesis to Java. For all that I despise Java's ridiculous boiler plate, I always know exactly what's going on. In Ruby, I feel like there are unknowns in every file. I hate Java, but Ruby makes me miss Java.
> For all that I despise Java's ridiculous boiler plate, I always know exactly what's going on Not my experience at all when doing Spring Boot, talk about magic. Rails looks dead simple compared to that.
This has been my experience too.
I constantly fear Spring Boot magically reconfiguring itself based on what it finds in the classpath, and half the codebase being annotations and import statements.
I've found the metaprogramming in Ruby much easier to understand and teach than Java's reflection and annotation processing.
Re: An Ode to Ruby
#60I love Ruby - Rails has been my day job for the past decade and my life is so much more pleasant when working with it than the odd time I've ventured off into things like Go or Java. For personal things, my bread and butter is Sinatra and Sequel and that's a great combo as well. My only real issue with it is differences in building native extensions on macos vs linux, usually need to set different compiler flags in t…
I'm curious, do you know what function was being declared implicitly? That's really atypical in modern C code, so there's probably a missing #include somewhere that could be fixed upstream.