Poof and then Rails was gone • Hacker News Board

Re: Poof and then Rails was gone

#51

Post by jdminhbg » Thu, May 15, 2014, 8:39 PM UTC

ryanjshaw wrote: post #41

jdminhbg wrote: post #30

Earlier quoted context omitted.

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD a…

> Similarly, any criticism of overcomplexity Come on. Nobody is defending "overcomplexity", which is by definition a rather indefensible position. The issue is the frequent arrogance exhibited here by commenters who insist that certain commonly and successfully used design patterns have no place in the world.

Of course I mean defending against the charge of overcomplexity rather than defending overcomplexity itself.

I am sure there are arrogant commenters around, but these commonly used design patterns applied in this case have made his code worse for next to no practical benefit. Besides test speed, there's no reason you'd want to divorce your Employee model from the database it lives in -- the fact that ActiveRecord reflects against the database to decide what attributes an Employee has should be a clue that coupling to the DB is the point of using it in the first place.

Re: Poof and then Rails was gone

#52

Post by jrochkind1 » Thu, May 15, 2014, 8:40 PM UTC

edwinnathaniel wrote: post #5

jrochkind1 wrote: post #3

I'm not a huge fan of Rails architecture neccesarily, but I have to admit I have trouble following the 'hexagonal architecture' stuff, even in simple examples like this. It does seem to be a lot of abstraction. Of course, with abstraction comes flexiblity, that's the point, I get it. But with (some kinds? all?) abstraction also comes complexity and cognitive load for the developer. If you're not careful, you end up i…

... and of course for those who applies modern Java development patterns, we no longer see plenty FactoryGeneratorFactory. I find it a bit odd that the community who has railed Java hard suddenly came up with something more complex than... gasp ... the solution in Java-land.

I didn't mean to imply that everything in Java was over-engineered, just that certain historical common Java practices were examples of what happens when you over-abstract and over-engineer. Certainly over-abstracting and over-engineering happens in every language too though, it's a hazard of the trade.

What community is it that you think has "suddenly" come up with what solution that's more complex than what "the" solution in Javaland? I'm not even sure what you're talking about. There are of course many solutions in Javaland, naturally, and in every other code land.

I think engineering code, especially code shared between multiple developers/installations, is a constant tension between simplicity and abstraction/flexibility. It's sometimes possible to optimize both, but it requires a lot of skill and a lot of domain experience, and domain experience especially seems to be under-valued and under-present in the current environment. (Plus if the domain changes fast enough, nobody ever has enough domain experience!)

I think individual developers, as well as teams and communities (language-based or industry/domain-based) often swing from end to the other. This legacy thing is too complicated, let's start over with new principles to keep it simple! This simple thing isn't as flexible as I want, let's add in some abstraction to make it possible to do what everyone needs; then do it again; then do it again; then start over at 0.

Re: Poof and then Rails was gone

#53

Post by kaonashi » Thu, May 15, 2014, 8:45 PM UTC

jdminhbg wrote: post #30

adamors wrote: post #14

Earlier quoted context omitted.

I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? The constant negative reaction to anything a little…

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD a…

> but why in the world would you want to do that?

To get your tests to run in > but why in the world would you want to do that?

Build better software faster

Re: Poof and then Rails was gone

#54

Post by jarrett » Thu, May 15, 2014, 8:47 PM UTC

adamors wrote: post #14

ubernostrum wrote: post #9

So... poof, and then Rails was J2EE? I have a deep dislike for overabstracting a system merely because someone has a list of hypothetical use cases. And make no mistake: it is always about supporting the hypotheticals, never about supporting what's actually really needed by the system. Down this road lie dozens of layers of abstracted factories and strategy implementations which exist just in case someone wants to "p…

I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed. Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? The constant negative reaction to anything a little…

> I don't understand how anything on HN that discusses a more complex software architecture is immediately called J2EE/enterprisy and dismissed.

I wouldn't say that always happens. It often happens when a 500-word blog post suggests effectively re-architecting a mature, successful framework like Rails. Let's think about why such a post is problematic.

Rails has evolved over quite a few years in response to actual needs on the ground. Tremendous amounts of ink have been spilled, and tremendous amounts of brainpower have been expended to create a mature framework like Rails (or similar frameworks).

Despite the battle-tested history of the framework, so many of these architecture blog posts imply that Rails' architecture is somehow insufficient. And then propose to fix that architecture, spending, say, 500 words explaining the idea. There's hardly any discussion of the idea's wide-ranging implications, of the trade-offs, or of the conveniences that are lost. If this idea is so good, why hasn't it ever found its way into Rails, even in diluted form? Why has the Rails team built the architecture they have, instead of yours? (Hint: They probably have a good reason.) Do you have strong evidence that your proposed architecture will serve me better than the one that I've been using successfully for years?

All that being said, I have no problem with idiosyncratic Rails techniques that only step a little outside what the framework provides. For example, service objects. Used appropriately (which usually means sparingly), they can help with organization without fundamentally warping the Rails app. Using a few service objects is a departure similar in magnitude to writing your JS in TypeScript instead of CoffeeScript. It's not built into Rails, but it doesn't really change any of the core concepts either.

Re: Poof and then Rails was gone

#55

Post by jdminhbg » Thu, May 15, 2014, 8:48 PM UTC

kaonashi wrote: post #53

jdminhbg wrote: post #30

Earlier quoted context omitted.

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD a…

> but why in the world would you want to do that? To get your tests to run in > but why in the world would you want to do that? Build better software faster

Test speed is not the only limiting factor in your ability to produce better software faster. Readability, comprehensibility, and approachability all matter too, and this architectural technique is bad for all of those.

Re: Poof and then Rails was gone

#56

Post by jarrett » Thu, May 15, 2014, 8:53 PM UTC

kaonashi wrote: post #53

jdminhbg wrote: post #30

Earlier quoted context omitted.

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD a…

> but why in the world would you want to do that? To get your tests to run in > but why in the world would you want to do that? Build better software faster

> To get your tests to run in In principle, the current Rails architecture can support that. Rails permits the test environment to use a different database adapter. There's nothing stopping anyone from decoupling the database at that level. I.e. you can pick a super-fast persistence strategy for the test database adapter, if you so choose. If there isn't an adapter you find fast enough, you can even create one. (Such a project would not doubt be well-received.)

Anyway, for my part, I prefer to run my tests against the same kind of DB I use in production. It gives me greater assurances. Especially when a web app can sometimes depend on the peculiarities of a certain persistence layer. E.g., your app has a search engine that runs custom SQL--you really want to test that against the DB.

Would it be nice to run some of my tests without the DB? Absolutely. Some tests just don't need to test anything DB-related. My guess is that Rails' support for that use case will grow organically over time.

Re: Poof and then Rails was gone

#57

Post by joncooper » Thu, May 15, 2014, 8:53 PM UTC

jowiar wrote: post #7

When I read code like this and find that half of the tests are, more or less, a typechecker, it reduces to an argument for static typing.

Indeed. Once you realize this it doesn't take very long to get excited about statically typed languages, especially with type inference.

Re: Poof and then Rails was gone

#58

Post by jarrett » Thu, May 15, 2014, 8:57 PM UTC

ryanjshaw wrote: post #41

jdminhbg wrote: post #30

Earlier quoted context omitted.

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD a…

> Similarly, any criticism of overcomplexity Come on. Nobody is defending "overcomplexity", which is by definition a rather indefensible position. The issue is the frequent arrogance exhibited here by commenters who insist that certain commonly and successfully used design patterns have no place in the world.

> who insist that certain commonly and successfully used design patterns have no place in the world.

I don't think the architecture skeptics claim as much. I believe you're restating the claim in a more extreme way that it's commonly expressed, thus making it clearly indefensible.

The claim isn't that certain architecture patterns have no place in the world. Rather, the claim is that those patterns aren't a good fit for most Rails apps.

Pretty much any pattern (that's not a commonly-accepted antipattern) has some good use case, somewhere.

Re: Poof and then Rails was gone

#59

Post by jarrett » Thu, May 15, 2014, 8:59 PM UTC

sanderjd wrote: post #43

jdminhbg wrote: post #30

Earlier quoted context omitted.

Similarly, any criticism of overcomplexity is immediately met with a dismissal as anti-intellectualism rather than a justification of why it's necessary. > Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)? This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD a…

> why in God's name did you use Rails Because it is actually a very good, mature application server with lots of sane defaults and good, mature plugins, even if you aren't using a database. Basically, people are interested in using it for more complex applications than you are, because lots of its conventions are still quite good for those applications, even if it makes sense to reject or reconsider some other conven…

> using it for more complex applications than you are

Are you sure? How complex do you mean? How complex do you presume the parent commenter's apps to be? Could you give an example of one of those more complex apps? I'm wondering if I'm currently building apps of the "simple" or "complex" variety, according to your terminology.

Re: Poof and then Rails was gone

#60

Post by timr » Thu, May 15, 2014, 9:04 PM UTC

angersock wrote: post #47

timr wrote: post #24

Earlier quoted context omitted.

I've written more scientific code than most people here, and the OP is right: it's the last place you want wanker abstractions. KISS applies to scientific code in spades. The concepts are hard enough to get right without all sorts of meta-logic muddling your thinking. Only when applications are truly trivial (i.e. "boring") do developers go on architecture spaceflights to keep themselves entertained.

The best way to keep things simple is to keep them small and composable, right? Like, say, in the Unix way? I'm all for brutally-efficient and single-minded code in domains like mathematics or simulation modeling, where things like object encapsulation maybe don't make a great deal of sense (classic array-of-structs vs struct-of-arrays sort of thing). That said, keeping that stuff neatly boxed and then moving everyth…

The choice is not "monolithic piles of Fortran" or abstraction hell...there is a middle ground.

All of your comments on this thread seem to be predicated on the assumption that this blog post is an example of something good. It isn't. It's a complicated, overwrought non-solution to an imagined problem.

Nobody here is arguing against abstraction, but abstraction needs to be used judiciously, and the best abstractions don't stray far from the application domain. It's a subjective thing that comes largely from experience, but you've likely gone off the path to enlightenment when you start creating ("hexagonal") meta-frameworks to create framework frameworks.