Hacker News Reader

Comment by danielsju6 | Hacker News Reader

This is bullshit. I'm no fan boy but you can't blame yourself when you've cornered yourself in an complex case of interdependencies. BREAKING NEWS: OVER-ENGINEERED PIECE OF SOFTWARE IS REVEALED TO BE OVER-ENGINEERED.

I don't use Refinery, Devise, OmniAuth, Unicorn, Rack Rewrite, Fog, AMQP, or Heroku.

I use Passenger with Apache or Nginx, self-host, and write my own core functionality like authentication.

Rails is still great at having an idea and throwing together a proof of concept in one day; running "rails s" still works out of the box. It still allows you to defer the hard choices, until you actually have to make them. If you've cornered yourself by making your stack too complex too early, that's your own damn fault—in Java you have to make those architecture choices day 1.

Dynamic typing: if you treat Rails like Java, it acts like Java.

View on HN

+1 on keeping things simple and not using a "F"ramework for every concern from the very beginning.

>in Java you have to make those architecture choices day 1.

That's just not true. Very easy and advantageous to start out with say a simple container-less app with in-memory/flat file persistence and build up as you need. It's no different in Java and much more the norm in other JVM languages like Scala/Clojure.

Thanks.

Perhaps the Java bit isn't true... or isn't true anymore; I haven't done much serious development in Java since I started doing Rails consulting in college. I remember it being XML hell where you needed to plan ahead a lot more in terms of choices, but that said I've probably become a much better developer too.

So what you're saying is you like to re-invent the wheel? Suffer from "not invented here" syndrome much?

No, what he's saying is that engineering is about tradeoffs. Adding another framework introduces another node in the graph, and n edges. If you don't need fancy authentication and are pretty confident you never will, then don't add devise. If you don't know or understand why you would use some bleeding edge web server or framework, use what is well-understood and has the least moving parts.

Leaning on the code of other people is something you do very deliberately, and it's a mistake to think that it always saves you time.

If you think you're saving yourself from reinventing wheels by adding Yet Another Gem into your gemfile, then you'll quickly find yourself constrained by the code of other people instead of your own code and mental model.

Your app becomes a mat woven of interdependent Things That Almost Do What You Want and you'll spend more time wrestling with other people's code than the time it would've cost you to write and maintain exactly what you needed in the first place and no more.

It's sort of like that time you thought Devise was going to save you all this trouble but soon realized you merely moved the battlefront from (A) a diff'able domain that you control to (B) Google SERPs, Stack Overflow answers, and a Github wiki page of customization boilerplate and copy-and-paste'able incantations that sorta do what you want.

Who said anything about Dynamic typing?

I agree with you that Rails still excels at allowing you to slap together a quick prototype, but I think that the world has caught up with Rails (and possibly bested it at this point).

It was a joke/metaphor about Ruby's duck typing, not a literal reference.

Kindly refrain from swearing, all caps, and 4chan-isms. I prefer to not read that kind of noise, and no doubt others here feel the same.

It was a sensational claim, I'm responding with "sensation". Since we're talking Rails I'll leave this here for you http://david.heinemeierhansson.com/posts/15-potty-mouths

Reply on news.ycombinator.com