Slashdot Mirror
Interviews: Ask Ruby on Rails Creator David Heinemeier Hansson a Question
David Heinemeier Hansson created the Ruby on Rails open-source web framework in 2003. David is also the founder and CTO of Basecamp, a project management tool that's been used by more than 15 million people. In addition, David is the best-selling author of REWORK, a book about starting and running businesses a better way. David has agreed to take some time to answer some of your questions.
Ask as many questions as you'd like, but please, one per comment. (And feel free to also leave your suggestions for who Slashdot should interview next.) We'll pick the very best questions -- and forward them on to David Heinemeier Hansson himself.
Ask as many questions as you'd like, but please, one per comment. (And feel free to also leave your suggestions for who Slashdot should interview next.) We'll pick the very best questions -- and forward them on to David Heinemeier Hansson himself.
"Ruby on Rails" ? Is there a good reason for the name, or were you watching too many old western train movies?
LOLOLOL!!!
Why didn't you let more guide books be written back in the day to try and promote it when you had the chance?
What do you think of Elixir and Phoenix? I haven't used Ruby on Rails but I really like Phoenix and looking at Rails I can see a lot of influences. But it's hard to beat the foundation that Erlang brings. Maybe I should have taken a better look at Rails while I was still using Python.
Remember, Apple just taught the FBI better phone security after it came about incidentally that the iPhone security was just too handsome.
Ruby On rails had a huge spike in popularity a decade ago. Then the traditional forms of development had taken over. How do you plan on keeping the language up to date on the current trends?
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Windows 10 CoMeS with Pearls on Tails
If you buy a license for free before December 2019, you get unlimited access to download a free trial of OFFICE 366
It is soo fucking good you get a day added to your year FOR FREE.
promo code: SLASHDOT
What in god's name possessed you to create this monstrosity?
Anons need not reply. Questions end with a question mark.
MOD PARENT UP hahaha!! 10, Funny
You ended up with something that reads almost as the same as Python, which has a much larger audience and library set. Couldn't you have just started with Python?
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
This interview will surely contain relevant commentary, given the subject matter... I've read nothing but love for Rails here on Slashdot </sarcasm>
exactly. being spied on is not free.
What were the influences (I mean, other frameworks, even in other languages) you used while building the first Rails version?
Do you believe, as we do, that God has a plan for us all?
What are your thoughts on bacon?
Maybe you can get dual phones and bust nuts.
Or I read on Slashdot, Windows phones come with Windows 10 FREE
I worked on a project around 2007 that used Ruby on Rails. That was my first experience with Ruby and my first experience with a real web product. I liked Ruby and Rails, but it was easy to get bitten by some of the abstractions. I remember the site bogged down really bad whenever we searched for a record in a large database table. The problem was that the database was hidden behind ActiveRecord, so it was easy to forget we were using a database at all. Writing a for loop to search for a record that matched some criteria felt natural, because our interface was with objects, not the underlying tables. However, behind the scenes, each iteration was a separate query. The result was thousands and thousands of queries, instead of just a single query with a simple WHERE clause. We were essentially doing in Ruby what we could have done much more efficiently in SQL. Once we realized the problem, we rewrote that kind of code so it used more or less raw SQL. The result was much faster, but we lost the readability of the abstraction. Everyone on the team was new to Ruby and Rails (grad students who shuffled in and out each semester), so it's possible that we were just doing things completely wrong. Still, it feels like it shouldn't have been that easy to shoot ourselves in the foot. Have things improved since then? How do you balance nice abstractions like ActiveRecord with performance? How do you make it clear to novices what's going on internally, so they can avoid the mistakes that we made?
Are you in the mindset of embracing Angular, React, Ember, etc, or is your vision focused solely on Turbolinks as the future of Rails?
Real talk.
Using the power of hindsight what would you have done differently if you were to start Rails again from scratch?
Here's my question: Why is ROR so bloody SLOW?
And while we're on the subject, why is it sooooo hard to do anything outside the "approved" way of doing stuff in ROR?
How on earth did writing a loop to query for records that match a criteria feel 'natural' when ActiveRecord has find/find_each/etc as native operators?
I might accept such naïveté from freshman students, but grad students absolutely should have known better.
What are your thoughts on the MEAN stack ( MongoDB, Express.js, Angular, and Node.js)?
I can't believe I just read all this crap from these whining beaches. It's like Slashdot gulped a keg of Red Bull while doing an 8-Ball off a teenage hookers ass listening to Nickelback's entire catalog on shuffle repeat.
I guess I don't understand the hate, since I still use Rails almost daily. I work efficiently, my clients pay me well, and because I have enough experience I guess, I don't ever run up against the platform's "performance issues". Granted, I am not building applications that have millions of users per month. Neither are most of the rest of these people. I guess it all boils down to- Haters gonna hate.
On to the questions. I'm going to ask a few, because so many other people threw their questions away already:
1. What's next for Rails 6 (or whatever is beyond Rails 5)?
2. I do notice that people are still talking about performance like it's 2005, and a few programmers I respect have already moved on to Elixir or React. Have you played around with either? Any good ideas we can steal? Better integration opportunities?
3. I feel like I'm always finding out about better "Rails Way" design patterns too late. For instance, when you explained your controllers setup/philosophy on Full Stack Radio. That was a situation where I'd kind of been doing that, but because I never really labeled it or gave it enough thought, it was more like I sometimes got lucky and made good decisions. Sometimes I didn't. Where, in the Rails community, is a resource to pick up on those more advanced patterns? Real world solutions that aren't necessarily a rails default, but are a good idea that will make life easier for developers at all stages of their careers?
Thanks for doing this. I don't know why you would have picked Slashdot for a Q&A though. It's like Reddit's garbage disposal in here.
Can you explain to me why a Computational Mathematician would use an insecure language that is also slow , instead of using something that real scientists use like C or maybe even NodeJS which actually works properly and doesn't have as broken of a package management system as Ruby. Can you do us all a favor a hang yourself?
I tried to "get" the philosophy of RoR, but ultimate failed. It seems RoR has a steep learning curve; but once mastered, one is allegedly more productive. Some use the analogy of becoming a medical doctor: a long slog through medical school, but big benefits (such as money) await you in the end. Do you agree with this alleged trade-off profile of RoR?
And, how can this approach work for decentralized departmental groups with lots of coder turn-over, especially if the bureaucracy makes it difficult to hire such that coders from other platforms are to be retrained? The ramp-up time for re-training seems hard to justify under such an environment without a RoR-only edict from on high. Would you agree RoR may not fit certain organizational environments? Thank You.
Table-ized A.I.
Aren't abstractions supposed to hide the need for specialized knowledge? One should only have to ask it to "save", and the details of how to talk to the database should then be hidden away from the abstraction user.
Table-ized A.I.
The problem was that the database was hidden behind ActiveRecord, so it was easy to forget we were using a database at all. Writing a for loop to search for a record that matched some criteria felt natural, because our interface was with objects, not the underlying tables.
Object-Relational Impendance Mismatch
Law of Leaky Abstractions
This problem is not unique to Ruby on Rails usage of the ActiveRecord pattern. People blindly using Hibernate and other ORMs run into the same thing, and it is, in general, what happens when people fall for one or more of the fallacies of distributed computing ("latency is zero" and "bandwidth is infinite".)
ActiveRecord pattern provides a theoretically pleasing abstraction, that is OK when accessing one row out of a relation. Trying to operate on a set of relations, as if they were a locally maintained collection however, that's where you hit the problems you mentioned.
Without some clever caching planned up front, your resources are always remote and not everything is supposed to fit an object-oriented model. Projects turn to shit when they forget these general rules.
Aren't abstractions supposed to hide the need for specialized knowledge?
Not all abstractions are correct. You cannot abstract the reality of remote resources. And your abstractions should be related to your domain model, not on treating remote resources as if they were a local array of things. I suggest you google "Fallacies of Distributed Computing".
One should only have to ask it to "save",
This level of abstraction is correct (but only if the abstraction has been developed properly).
and the details of how to talk to the database should then be hidden away from the abstraction user.
Define "talk". If the abstraction lets you iterate a set of remote resources as if they were a local array without regard to bandwidth or latency, then the abstraction is poorly written and of an amateurish quality.
Systems that talk to a database (even if the database is a co-located process) are in essence distributed systems. And successful distributed systems know when to hide remoteness (or when to force developers to cope with it.)
Don't take it the wrong way, but that answer of yours would come as a deal breaker in an interview.
Do you have an example or scenario?
The internal guts of an access coordinator could "watch" the timing of requests to know to batch operators together, for example.
Also, one could tell the abstraction how important "recency" is, such as whether it's okay to delay actual writes or not. Perhaps a delay threshold in seconds can be given.
In other words, the abstraction can "ask" one to rank the relative importance of performance-related factors so as to select the best internal or vendor-specific implementation choices to fit the trade-off profile given to it.
That may be difficult or impractical to fully implement, but not necessarily impossible in terms of abstracting away details.
Sometimes a DBA will ask me whether to optimize a database or table for quick writing or quick querying, or an in-between balance. I usually don't have to really know how the DBA does that, only give him/her my or my boss's preference.
Perhaps the existence of performance trade-offs cannot be hidden away, but the implementation of those choices largely can.
Table-ized A.I.
Do you have an example or scenario?
The internal guts of an access coordinator could "watch" the timing of requests to know to batch operators together, for example.
Also, one could tell the abstraction how important "recency" is, such as whether it's okay to delay actual writes or not. Perhaps a delay threshold in seconds can be given.
In other words, the abstraction can "ask" one to rank the relative importance of performance-related factors so as to select the best internal or vendor-specific implementation choices to fit the trade-off profile given to it.
That may be difficult or impractical to fully implement, but not necessarily impossible in terms of abstracting away details.
Sometimes a DBA will ask me whether to optimize a database or table for quick writing or quick querying, or an in-between balance. I usually don't have to really know how the DBA does that, only give him/her my or my boss's preference.
Perhaps the existence of performance trade-offs cannot be hidden away, but the implementation of those choices largely can.
You are providing counter-examples that are very constrained by nature. I'm referring to general cases of remote resources.
In particular we are referring to the case of executing a predicate on a sequence of remote resources (specifically a sequence of database rows matching some criteria.)
I didn't think I have to make it clearer, but I guess I have to. Very specifically I was referring to general abstractions. Why? Because executing a predicate on a sequence of remote resources is, typically very specific to a domain.
So any such abstraction must be custom build for that domain. And that's the Achilles's Hell for ActiveRecord and ORMs in general.
ActiveRecord, and ORMs in general fail at this. You have to go up so up in the domain model to create an appropriate abstraction. The abstraction has to be custom-build to a domain and the nature of it will change according to the relations in the database.
ActiveRecord and ORMs sit at a much lower level of abstraction, a level that makes it impossible to efficiently abstract out remoteness in the general case.
And when such low-level abstractions provide a way to iterate remote resources as if they were local sequences, that's a failure, that is the wrong abstraction. There is a reason why people come with things like Map/Reduce, futures, batched sql statements or even the old (but still useful) technique of encapsulating execution of predicates on relations within stored procedures.
First of all, thank you for Rails, it helped me to convince my former employer to look beyond Java for web application development and now about half of the projects I do is helping teams of smart people who've painted themselves into a corner using the platform. What a beautiful statefull mess we living in!
I personally feel your contribution to web application development in general is not Rails but the explosion of batteries included web frameworks we are seeing around us now. Things got shaken up 10+ years ago and they are still stirring. Yes, the github is full of failed frameworks withering away but also some really cool stuff spawned in the ripples Rails caused.
My question: now that things have cooled down a bit regarding Ruby on Rails (merb and arel have been assimilated, framework upgrades are almost doable, most have settled on minitest, etc) what still makes you excited about this project or are you secretly migrating basecamp to phoenix and assimilate that into Rails too?
I'm still asking for a specific example/scenario/use-case to illustrate your point. You are talking in generalities. Take an example from a university grade tracking system or airline reservation system or something from everyday life to construct a specific scenario. Make a quick and dirty schema for your example, and walk through the scenario steps.
Table-ized A.I.
Have you ever had a eureka or solved a bug while you were racing, or at least driving?
More generally, do the abstractions that help you learn to race assist you in understanding parts of your web & technology systems?
Eggs well done.
Bacon is not just for bacon and eggs any more.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
As I said, this was a long time ago, so maybe I'm not remembering the exact performance problem we hit. My larger point still stands: we were burned by an abstraction, possibly made worse by our own lack of expertise. In our defense, we weren't there to build a website. Or research was in a totally unrelated area, not even really within the realm of computer science, and none of us had expertise building websites that scaled. The website was just the thing we used to collect data and do experiments. We built it because we couldn't get someone wide to do it for us. Someone before my time picked Ruby on Rails because it was supposed to be something people like us could use.
Hi DHH. How much of the code for basecamp 3 did you personally write? and is it a challenge to clear out long stretches of time for concentrating on development (vs meetings, etc) due to your seniority at the company? From your blog posts it seems that you're definitely still significantly involved in day to day development.
Python has gained what could be called a critical mass of popularity and works at a similar level of abstraction to Ruby. If you were creating Rails today, would you still choose Ruby? What are its advantages?
You are quite famous for being loudly dismissive of Rails critics.
But do you ever get the urge to learn from your experience (and mistakes) and build a new framework that's different from Rails?
In other words, if you could burn Rails to the ground and start over without the need to maintain any sort of backwards compatibility, what would you do differently?
With the rise of Javascript front-end frameworks (Ember, Angular, etc.), is there really a serious place for large opinionated server-side frameworks any more?
Is Rails destined to be a framework for writing APIs to feed front-end frameworks? And if so, is that enough?
As far as I can tell, by default ActiveRecord does not enforce referential integrity at the database level. Is there a reason for this omission? Also is there any plan to introduce parameterized queries for raw SQL queries. I still keep seeing people on stack-overflow recomending inerpolation as an alternative, and this seems rather dangerous.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
I think this is where optimization really kicks in.
AR is great for getting stuff out the door quick, and for most products its fine (After all its cheaper to add hardware than it is to add developers). However there are some problems where "throw hardware at it" wont solve fundamental problems. This is the point where you look at the profiler and realise AR is messing up performance and drop back to SQL.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
I am impressed by all the sour bitching about RoR in /.
If you tried, and cannot learn it, then programming just might not be for you.
Granted, it might not be the perfect fit for everybody, but RoR has an impressive merit on the growth of the web.
10 years ago I discovered it, and the framework taught me how to structure complex business applications and back them with proper unit and integration testing.
Today we run a company on the 6 digit revenue that is backed mostly by RoR.
Thanks Daniel!
Why Denmark is so keen to develop languages? When do we see an interview of Bjarne Stroustrup?
Slashdot, fix the reply notifications... You won't get away with it...