Earlier quoted context omitted.
Yes, maybe my problem is more with Rails. (Because of monkeypatched APIs, it’s not always obvious to me whether a particular weirdness originates from Ruby’s standard library or is a Rails addition. Arguably this is something the language has also encouraged though.) Is there any reason to use Ruby outside Rails? Its niche seems to completely overlap with Python and modern JavaScript, and those have enormously more e…
Python already existed when Ruby came out and before rails was a thing. I understand you don't care for the language but the main reason for its creation was to have a completely object-oriented (in the Smalltalk sense) scripting language which python just isn't. Personally, I like a language where everything is classes and methods and I don't have to remember to use a function rather than a method to get (for exampl…
Happy Birthday, Ruby
201–210 of 239 posts
Re: Happy Birthday, Ruby
#202Ruby is the very least favorite of all the programming languages I've had to use regularly over my career. Its syntax strongly favors cuteness over familiarity. Wherever Ruby can diverge from expectations to give you a pointless little tickle of whimsical inventiveness instead, it seems to do so. Visually it looks like an unwanted love child of Pascal and Python. There's no clear rhyme or reason to the use of sigils…
https://apidock.com/ruby/Hash/flatten
Which doesn't recursively flatten like Array#flatten, even when depth is specified. To me, most of these choices are arbitrary or done for performance reasons which get less compelling with each passing year.
I never know from one day to the next which new concept is going to be thrown at me, or how much I'm going to have to memorize. Whether it's Rails, or Rspec, or any other gem - each has its own ecosystem of technobabble that can't be derived from first principles.
In the end, I don't know what problems Ruby is trying to solve. I find it no faster to write than PHP or Javascript. I find that having multiple ways to specify blocks with begin/end and {} merely increases the permutations I must hold in my head as I'm trying to grok code. This is all very perl-like, which makes sense for a 90's language. But I wouldn't advise learning Ruby or using it in production today. Better to go with a more formal language such as Go/Rust/Swift/Kotlin, even though each of those has its own unique set of flaws and pain points.
P.S. If you are struggling with learning Ruby, I highly recommend learning PHP/Laravel first. It has most of the same concepts as Rails/.NET but builds on the existing context that C-style language programmers tend to be familiar with. Then from there you can create a virtual errata document in your mind to store any arbitrary conventions that Rails introduces.
Re: Happy Birthday, Ruby
#203Earlier quoted context omitted.
> having two distinctly different types of strings You must be talking about Python 2, the deprecated version for 12 years now, with support ending next year. Because last time I checked, current, modern Python only has one type of string.
Lots of shops still use Python 2 I was writing brand-new applications in it for my job as late as early last year Why the defiant tone?
As I do a lot of Python for a living, and still work on both Python 2 and Python 3, I have talked a lot with people writing new P2 apps in the last few years.
My experience is, either you have very niche constraints, or somebody made an unwise/uneducated engineering decision. Unfortunatly, I meet way more of the second type, and of course, most of them pretend to be of the first.
Re: Happy Birthday, Ruby
#204Ruby is the very least favorite of all the programming languages I've had to use regularly over my career. Its syntax strongly favors cuteness over familiarity. Wherever Ruby can diverge from expectations to give you a pointless little tickle of whimsical inventiveness instead, it seems to do so. Visually it looks like an unwanted love child of Pascal and Python. There's no clear rhyme or reason to the use of sigils…
So, I'm old, and have done lots of stuff in lots of languages in frameworks. For about a dozen years, Rails was my go-to toolkit. I've written a couple dozen production applications with it. Unfortunately, Rails has really fallen out of favor lately. Even a Rails-specialty shop I worked for briefly has pivoted to using ASP.NET. I've played around in that stack, and found it lacking. (EF just doesn't compete as an ORM…
I'm a former RoR developer (about 5 years) who's now been a full time Elixir developer for two years, so I'll make the obvious suggestion of Phoenix, which is very rails inspired.
It's a little more clunky in the basics, but it has that "magical" feel that hooked me on Rails back in the day, if you want websockets. And there's a new feature coming down the pike, called LiveView[0] that I think could be a total game changer the way Rails was.
For right now, I think of Phoenix as another rails, better in some ways worse in others, but not better enough for most people to switch. But if LiveView pans out the way I think, then it'll absolutely be the killer feature that will get new apps started in Phoenix, and it's only possible due to Elixir/Erlang's concurrency foundation.
Briefly, it takes the React data model – state at the top of the tree, render the tree based on the current state, change the state and the tree re-renders appropriately – and moves it to the server, using websockets to keep the client up to date. So every connected client has its state in a little elixir process, and interacting with the page transparently is calling functions on the server so you can update the DB or whatever with your normal server side code. And if you had a normal server-side rendered view with an `` in it, and that condition changed, then voila, that part of the page will change because Phoenix will re-render it, and send down the diff and the page will put in the new HTML.
On all the Rails apps I've worked on we've inevitably added a bit of React here or Angular there to make certain pages a little more dynamic, and then exposed an API for those to hit, and then had frontend and backend development to do. I think what LiveView will provide hits the sweet spot for most apps, so you can stay in your comfortable backend language and get a bit of dynamism for free.
[0] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
Re: Happy Birthday, Ruby
#205Earlier quoted context omitted.
I don't get this Elixir as the natural progression for Rubyists. OO/mutable Ruby and functional/immutable Elixir are worlds apart beyond the superficial syntax similarities.
> worlds apart beyond the superficial syntax similarities I never understood this argument. That "superficial" syntax is what I have to stare at, reading and writing, for 8 hours a day. That I actually enjoy doing so is therefore hugely important to me. I mean, you can make the same argument against Elixir itself, and I've seen it done - Erlang old-timers arguing against the necessity of these "superficial" syntax im…
Re: Happy Birthday, Ruby
#206Earlier quoted context omitted.
Python already existed when Ruby came out and before rails was a thing. I understand you don't care for the language but the main reason for its creation was to have a completely object-oriented (in the Smalltalk sense) scripting language which python just isn't. Personally, I like a language where everything is classes and methods and I don't have to remember to use a function rather than a method to get (for exampl…
I'm learning Java and was surprised to read your comment about ruby being completely object oriented. I always assumed ruby was very similar to Python. I would be interested in learning ruby especially if it is easier for someone with an object oriented background in Java. So, how difficult would coming from Java to Ruby be? And what books or MOOCs would you recommend for the transition?
Re: Happy Birthday, Ruby
#207Earlier quoted context omitted.
> "Whimsical inventiveness is the one thing that keeps me enjoying the art of programming." A personality difference then. Reading clever code does nothing for me. I'm much happier digging around hulking layered codebases that may look ugly but do something valuable for the user. I agree that the cuteness of a programming language is just a matter of taste and habit. I'm not going to pretend my criticism was anything…
I think there's more to it. Ruby, to me at least, seems objectively more difficult to understand intuitively when scanning the code. Maybe it's just a superficial lack of knowledge on my part, but my brain makes base assumptions on how code should work, and whenever something magical happens, it's cool, but slows down the cognitive understanding enough that it seems to me to be a net negative. There's a crossover poi…
Reading Ruby code always reminds me a bit of trying to understand how xmonad configs work.
E.g. the Sequel example:
require 'sequel'
Nitpick: IMHO import-operators should operate on names not strings, because they essentially are equivalent to "foo := $magic". DB = Sequel.sqlite # memory database, requires sqlite3
Why isn't this a function call? How would I pass options, e.g. the file name here? Why is it Sequel. here, but "sequel" above? Does "require" dump a bunch of unspecified names in my namespace? DB.create_table :items do
primary_key :id
String :name
Float :price
end
What kind of construct is this? Where do all these names ("primary_key", "String", "Float") come from? They were never imported. Is this like ":name => foo" but because that doesn't nest we now have ":name do ... end" for nesting dictionaries? items = DB[:items] # Create a dataset
? # Populate the table
items.insert(:name => 'abc', :price => rand * 100)
items.insert(:name => 'def', :price => rand * 100)
items.insert(:name => 'ghi', :price => rand * 100)
I guess ":name => foo" is some sort of keyword argument. # Print out the number of records
puts "Item count: #{items.count}"
# Print out the average price
puts "The average price is: #{items.avg(:price)}"
If ":name => foo" is some sort of keyword argument, then what value has "price" here?Re: Happy Birthday, Ruby
#208Earlier quoted context omitted.
Python already existed when Ruby came out and before rails was a thing. I understand you don't care for the language but the main reason for its creation was to have a completely object-oriented (in the Smalltalk sense) scripting language which python just isn't. Personally, I like a language where everything is classes and methods and I don't have to remember to use a function rather than a method to get (for exampl…
I'm learning Java and was surprised to read your comment about ruby being completely object oriented. I always assumed ruby was very similar to Python. I would be interested in learning ruby especially if it is easier for someone with an object oriented background in Java. So, how difficult would coming from Java to Ruby be? And what books or MOOCs would you recommend for the transition?
I enjoyed “Eloquent Ruby” when I needed to learn Ruby for my previous job. Highly recommend it.
Re: Happy Birthday, Ruby
#209Earlier quoted context omitted.
I think there's more to it. Ruby, to me at least, seems objectively more difficult to understand intuitively when scanning the code. Maybe it's just a superficial lack of knowledge on my part, but my brain makes base assumptions on how code should work, and whenever something magical happens, it's cool, but slows down the cognitive understanding enough that it seems to me to be a net negative. There's a crossover poi…
> Ruby, to me at least, seems objectively more difficult to understand intuitively when scanning the code. Reading Ruby code always reminds me a bit of trying to understand how xmonad configs work. E.g. the Sequel example: require 'sequel' Nitpick: IMHO import-operators should operate on names not strings, because they essentially are equivalent to "foo := $magic". DB = Sequel.sqlite # memory database, requires sqlit…
The do...end bits are "blocks" and are the most powerful feature in Ruby, not just because of what they do but also because how they do it. Similarly for other comments.
When I first looked at Rust code it looked weird to me too but once you are familiar with the language a little bit it makes sense. The only thing special about Ruby here is that it allows you to be very terse.
Re: Happy Birthday, Ruby
#210Earlier quoted context omitted.
Lots of shops still use Python 2 I was writing brand-new applications in it for my job as late as early last year Why the defiant tone?
FUD is never easy to read, and I'm not always wise enough to answer in the proper tone. As I do a lot of Python for a living, and still work on both Python 2 and Python 3, I have talked a lot with people writing new P2 apps in the last few years. My experience is, either you have very niche constraints, or somebody made an unwise/uneducated engineering decision. Unfortunatly, I meet way more of the second type, and o…
I would, however, like to question this wisdom of always having to run the latest and greatest. Yes there are security considerations but properly hardened, old software and runtimes run fine. You need an actually security guru, though, and not some startup promising turn-key solutions.