6 ms·

I was listening to a recent interview with DHH and he makes a great point that Rails and Ruby are about optimizing for developer happiness and dev speed. Comput

I was listening to a recent interview with DHH and he makes a great point that Rails and Ruby are about optimizing for developer happiness and dev speed. Computing power keeps becoming cheaper and ruby keeps getting faster but developer's salaries continue to be the number one cost for software companies.

yebyen 7y ago
100% agree. Developer happiness, conceptual compression is another important concept that DHH likes to talk about. If there's a hard topic that devs need to understand sometimes, Rails makes it a point to guarantee that devs don't need to understand all those things all the time. Conceptual compression means that you can unpack those ideas and work with them when you need them, or pack them back up and don't pay attention to them when you don't need them. The biggest example that I can think of is ActiveRecord. I can't tell you the number of times I've seen presentations by programmers who work with other frameworks like .NET, who have embedded large, complex SQL queries into their code. They don't think twice about it, don't even flinch, parsing SQL is part of the cost of doing business in this language.
- mikekchar 7y ago
  Just a disclaimer, I work with Rails every day, but I don't really like it all that much and I really don't like ActiveRecord. We have Rails legacy apps and I maintain one of them. I'd still use Rails for some things, but it I'm pretty picky about what I think it's good for. Having said that, it makes me a bit sad that there are quite a few developers who actively avoid SQL. Granted the syntax is absolutely awful, but it is a very useful and powerful language. The concepts behind relational databases are embraced by SQL in ways that I can't imagine in any other language (I'm sure there must be other good relational query languages somewhere, but I've never been exposed to them). Honestly, if I have developers working with a relational DB doing anything even a little bit complex I want them to not not think twice or even flinch to use or read it (and I say that not really being all that accomplished with the language myself). Rails has some good niches where it is very well suited. ActiveRecord is OK if you have a very particular data model. However, as they say, if a hammer is your only tool, every problem starts to look like a nail. You may find that if you approach the problem differently, you will find reasons why people choose not to use very simplified ORMs.
  - vinceguidry 7y ago
    As a counterpoint, I love ActiveRecord. It's a Swiss Army knife that's got pretty much everything you need, you just need to find the right tool and use it. What ActiveRecord isn't is discoverable. Which is to an extent understandable. Its domain is literally anything you could express in SQL. But you really can do anything you want with it, you just have to find the right abstraction. A tool I use a lot is to .to_sql which will show you the compiled SQL fragment in a debugging session. You can compose with bare SQL fragments and ActiveRecord even includes an intermediate library so that you can work at the relational algebra level if you want. It's not that ActiveRecord forces you to work a certain way. It just doesn't advertise all its features.
    - Dangeranger 7y ago
      Long ago I liked ActiveRecord(AR), then I worked at a company that did large aggregations in SQL and found it to be severely limited in working with complex queries which use many JOIN statement and sub-queries. During that time I came to enjoy working with the Sequel[0] gem, and its fantastic documentation. Now, after working with Ecto[1] in Elixir, I've found that the ROM[2] builder pattern is a better approach to abstracting SQL and mapping the results to Ruby objects. It's much cleaner and more maintainable than a long mess of AR queries. Ryan Bigg wrote a great book about breaking away from AR in Rails called Exploding Rails[3]. It's a good read. [0] http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/ [1] https://github.com/elixir-ecto/ecto https://github.com/elixir-ecto/ecto [2] https://rom-rb.org/5.0/learn/introduction/active-record/ https://rom-rb.org/5.0/learn/introduction/active-record/ [3] https://leanpub.com/explodingrails https://leanpub.com/explodingrails
      - JohnBooty 7y ago
        From what I've seen of Sequel is looks awesome and I've been dying for an excuse to use it. found [ActiveRecord] to be severely limited in working with complex queries which use many JOIN statement and sub-queries I'd humbly suggest that this is not a flaw of ActiveRecord whatsoever! I think this is AR working exactly as designed. I would certainly agree that SQL > AR once your queries grow past a certain (fairly low) complexity threshold. But, AR (wisely) doesn't try to be a complete replacement for SQL. It very happily (and even elegantly, I might say?) lets you use raw SQL pretty much any time you, the developer, feel it's more convenient/productive. That principle is pretty explicitly baked into AR. Many ORM frameworks don't make this easy at all, whereas with AR it's very painless. I have a lot of beef with AR but I think this is one of its strong points.
pizza234 7y ago
It's not so easy. Computing power can be increased by scaling vertically or horizontally. Vertical scaling has an upper limit, and when one reaches it, in certain contexts, end of the happiness :-) Case in point: GitLab; they have Go microservices. GitHub was also hiring Go developers, so very likely they've done the same. Of course, few companies are GitLab/GitHub, but the point is that it's not possible to make absolute statements about power being cheap.
- Dangeranger 7y ago
  Agreed. Yet even if you don’t reach Gitlab scale, languages like Go and Elixir can help you deliver the same service at 10-20% the cost. By being able to run your service on a single server instead of ten allows your team to focus on features instead of scaling your application using background concurrency, caching, or “micro-services”. Imagine what you could do when you don’t need to manage a fleet of web-servers.

yebyen 7y ago

100% agree. Developer happiness, conceptual compression is another important concept that DHH likes to talk about. If there's a hard topic that devs need to understand sometimes, Rails makes it a point to guarantee that devs don't need to understand all those things all the time. Conceptual compression means that you can unpack those ideas and work with them when you need them, or pack them back up and don't pay attention to them when you don't need them. The biggest example that I can think of is ActiveRecord. I can't tell you the number of times I've seen presentations by programmers who work with other frameworks like .NET, who have embedded large, complex SQL queries into their code. They don't think twice about it, don't even flinch, parsing SQL is part of the cost of doing business in this language.

mikekchar 7y ago
Just a disclaimer, I work with Rails every day, but I don't really like it all that much and I really don't like ActiveRecord. We have Rails legacy apps and I maintain one of them. I'd still use Rails for some things, but it I'm pretty picky about what I think it's good for. Having said that, it makes me a bit sad that there are quite a few developers who actively avoid SQL. Granted the syntax is absolutely awful, but it is a very useful and powerful language. The concepts behind relational databases are embraced by SQL in ways that I can't imagine in any other language (I'm sure there must be other good relational query languages somewhere, but I've never been exposed to them). Honestly, if I have developers working with a relational DB doing anything even a little bit complex I want them to not not think twice or even flinch to use or read it (and I say that not really being all that accomplished with the language myself). Rails has some good niches where it is very well suited. ActiveRecord is OK if you have a very particular data model. However, as they say, if a hammer is your only tool, every problem starts to look like a nail. You may find that if you approach the problem differently, you will find reasons why people choose not to use very simplified ORMs.
- vinceguidry 7y ago
  As a counterpoint, I love ActiveRecord. It's a Swiss Army knife that's got pretty much everything you need, you just need to find the right tool and use it. What ActiveRecord isn't is discoverable. Which is to an extent understandable. Its domain is literally anything you could express in SQL. But you really can do anything you want with it, you just have to find the right abstraction. A tool I use a lot is to .to_sql which will show you the compiled SQL fragment in a debugging session. You can compose with bare SQL fragments and ActiveRecord even includes an intermediate library so that you can work at the relational algebra level if you want. It's not that ActiveRecord forces you to work a certain way. It just doesn't advertise all its features.
  - Dangeranger 7y ago
    Long ago I liked ActiveRecord(AR), then I worked at a company that did large aggregations in SQL and found it to be severely limited in working with complex queries which use many JOIN statement and sub-queries. During that time I came to enjoy working with the Sequel[0] gem, and its fantastic documentation. Now, after working with Ecto[1] in Elixir, I've found that the ROM[2] builder pattern is a better approach to abstracting SQL and mapping the results to Ruby objects. It's much cleaner and more maintainable than a long mess of AR queries. Ryan Bigg wrote a great book about breaking away from AR in Rails called Exploding Rails[3]. It's a good read. [0] http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/ [1] https://github.com/elixir-ecto/ecto https://github.com/elixir-ecto/ecto [2] https://rom-rb.org/5.0/learn/introduction/active-record/ https://rom-rb.org/5.0/learn/introduction/active-record/ [3] https://leanpub.com/explodingrails https://leanpub.com/explodingrails
    - JohnBooty 7y ago
      From what I've seen of Sequel is looks awesome and I've been dying for an excuse to use it. found [ActiveRecord] to be severely limited in working with complex queries which use many JOIN statement and sub-queries I'd humbly suggest that this is not a flaw of ActiveRecord whatsoever! I think this is AR working exactly as designed. I would certainly agree that SQL > AR once your queries grow past a certain (fairly low) complexity threshold. But, AR (wisely) doesn't try to be a complete replacement for SQL. It very happily (and even elegantly, I might say?) lets you use raw SQL pretty much any time you, the developer, feel it's more convenient/productive. That principle is pretty explicitly baked into AR. Many ORM frameworks don't make this easy at all, whereas with AR it's very painless. I have a lot of beef with AR but I think this is one of its strong points.

pizza234 7y ago

It's not so easy. Computing power can be increased by scaling vertically or horizontally. Vertical scaling has an upper limit, and when one reaches it, in certain contexts, end of the happiness :-) Case in point: GitLab; they have Go microservices. GitHub was also hiring Go developers, so very likely they've done the same. Of course, few companies are GitLab/GitHub, but the point is that it's not possible to make absolute statements about power being cheap.

Dangeranger 7y ago
Agreed. Yet even if you don’t reach Gitlab scale, languages like Go and Elixir can help you deliver the same service at 10-20% the cost. By being able to run your service on a single server instead of ten allows your team to focus on features instead of scaling your application using background concurrency, caching, or “micro-services”. Imagine what you could do when you don’t need to manage a fleet of web-servers.