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 everything else out (say, file I/O, logging, whatever) into neatly abstracted boxes makes sense. More sense than most of the monolithic piles of Matlab and Java and C and Fortran I've seen, because people were rushing to finish a paper.

But hey, it's not like the next generation of grad students has anything to do but spend long hours debugging poorly-documented and poorly-designed code, right?

And it's not like there is any sort of commercial financial or reaction modeling software that needs to be anything other than inscrutable monoliths, right--you know, something which could actually hurt somebody physically or fiscally. Performance is king, after all.

(Hint: people who sacrifice engineering and design for performance or simplicity deserve neither.)

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.

You and I know there is a middle ground, but there is something very appealing about deriding the (hard) work of building abstractions and meditating on design principles in favor of "get shit done" coding.

This article was an interesting little exploration--mostly point out that by not using rails but by conforming to the interfaces you could do some interesting things. It was a harmless little piece, not something you might want to do in production but interesting nonetheless in its own right.

The tone of my comments is in regards to the top-level objections and phrasing these people are using--"wankery", "architecture astronauts", etc.

Look, I get it; most of us at one point or another have dealt with JavaEnterpriseFactoryBridgePatternAdaptorAnnotationAnnotationFlyweights and have had to meander through scores of abstracted calls to finally figure out something that should've been a direct function invocation. The dot-com bubble hurt many programmers, sure. Enterprise Jabba is a bloated king in a crumbling castle; whatever floats your boat.

There are people--in this very thread!--who are arguing against any abstraction. They do so in the name of performance, and in the name of domain modeling, and in the name of a dozen other half-articulated little fears and inconveniences.

I've had to deal with code written by academics that implemented brilliant solutions to some problems, and yet remained impenetrable. If asked, "figure it out yourself". These are the same chucklefucks that don't comment their code, that are uncooperative on projects trying to clean up and make libraries out of their work, and generally are people who think that making it out of a doctorate program with a paper about their tiny slice of new human knowledge somehow grants them any weight whatsoever in discussion about software engineering or working on teams.

It makes sense that they'd be against abstraction--them and the trading folks and game developers and everyone else whose livelihood depends on excruciatingly-specific implementation details which are nothing more than an artifact of their time, a form of technical arbitrage which pays for their miserable existence.

Of course they hate abstraction, because it is very hard to convince somebody of something when their livelihood depends on them not understanding it!

Abstractions and "proper design architecture" of the sort in this article have very little place in scientific code meant for the efficient study of complicated systems, at least.

It usually gets in the way of what's important: performance and scientific correctness.

That might be fine if the majority of software developers worked on game engines, compilers, or operating systems. But we're talking about Rails applications here.

Yes, Web applications are somehow magically exempt from sound engineering practices.

If you want to make the argument that shitty Rails hairballs that don't scale aren't a problem, because they fulfill a business need and fill it quickly, I'll agree.

That said, that's a business decision, not a technical one.

Every application can benefit from sound engineering practices. Creating a complicated monstrosity when you're not going to need it is not sound engineering practice. At least I don't think it is, but then again I don't consider myself an "engineer."

Once again, Java is a great example. For over a decade, Java developers have piled on more and more "sound engineering practices." Maybe it's just me, but these Java applications are not easy to extend or modify in any way.