Hi R,
R Mason wrote:
So should one abandon all attempts at optimization
merely because it takes more time than writing
sloppier, less-well-thought-out code?
'Sloppy' is not the converse of 'optimized'. IME, the converse of 'optimized' is typically 'readable, testable, easily maintained, ...'
... while I'm still learning Rails, wouldn't it be
better to take my time and learn?
Absolutely.
Perhaps it was just my reading of the query. Here are the two things in your post that jumped out at me:
To save database space,
This would be way easier if I just
I'm just saying, perhaps my approach is wrong,
Rereading your original post in light of what you've said here, I see we're using 'approach' to mean two different things. Based on my reading of your post, I took you to mean 'optimize early' vs. 'only optimize when it solves an _existing_ problem.'
but you picked it apart on a capitalistic aspect
instead of actual design.
Perhaps it's not intuitively obvious, but Rails is fundamentally about personal, not machine, productivity. If it weren't, we wouldn't have Rails' very readable 'Actor.find_by_role_and_location_and_skills(...)'. We'd be writing raw SQL because 'it uses fewer cycles'. We wouldn't have ActiveRecord because 'meaningless id's waste space'. In fact, we wouldn't even have Ruby, since interpreted languages are inherently less efficient users of machine resources. Productivity is an Economic, not a Computer Science, concept. That's why my response focused on the 'capitalistic aspect'.
Having said that, I'm sorry my response offended you. Welcome to the community and good luck!
Best regards,
Bill