Live data from Hacker News

Poof and then Rails was gone

patmaddox.com

31–40 of 66 posts

Re: Poof and then Rails was gone

#31
post #11

The problem with software is that it is too easy to get it working. If you would do completely stupid shit while designing an analog electronic circuit you would get completely stuck in your "inventions" very soon and would not be able to deliver anything working beyond the simplest stuff, the difficulty would just force you to adapt a sensible design approach or resign from doing any electronics in the first place.…

All of your examples don't exactly make the point you're trying to make: Ask anyone who's had to debug game engine code, compilers, operating systems, or the worst of the lot, scientific code. Most of those systems would actually benefit from proper design and architecture, but people like you decrying their "wankery" have relegated such introspection to the dustbin. And that attitude is why software engineering is m…

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.

Re: Poof and then Rails was gone

#32
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…

The examples in the OP, as in basically every article that describes these kinds of practices, are horribly contrived. The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to…

Correct me if I'm wrong, but one of the points of using dummy persistence is testing. You can delay using a database for a long time this way, have tests that finish quickly etc. Doing this within the confines of a Rails like MVC is next to impossible.

Re: Poof and then Rails was gone

#33
post #32

Earlier quoted context omitted.

The examples in the OP, as in basically every article that describes these kinds of practices, are horribly contrived. The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to…

Correct me if I'm wrong, but one of the points of using dummy persistence is testing. You can delay using a database for a long time this way, have tests that finish quickly etc. Doing this within the confines of a Rails like MVC is next to impossible.

I am also a strong non-fan of faking persistence mechanisms in testing. If you're faking it, you don't actually know that the real thing will work.

Re: Poof and then Rails was gone

#34
Like others here I'm not sure if this is a joke post or not, but... the TerminalAdapter example is not an abstraction. It's simply reimplementing a very specific protocol that implements "render" and "redirect_to". This protocol is not something that could automatically be adapted to other scenarios than HTTP — say, to a mobile app or to a desktop GUI app. The terminal, for one, might "render", but it cannot "redirect".

Re: Poof and then Rails was gone

#35
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.

Completely agree with you. Many of the tests don't do any kind of assertion, simply ensure that an exception isn't thrown on the invocation of a method. An interface defined in a static language would render the majority of these tests unnecessary.

Re: Poof and then Rails was gone

#37
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…

The examples in the OP, as in basically every article that describes these kinds of practices, are horribly contrived. The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to…

> And make no mistake: it is always about supporting the hypotheticals, never about supporting what's actually really needed by the system.

> The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to happen.

So is abstraction always about supporting hypotheticals or only when you're exaggerating?

Implementing a switch statement and hardcoding references into 10,000 line modules with different behaviour (e.g. different rules for different jursidictions) is untestable and unmaintainable. Abstraction has value in these scenarios. And just like everything, it can be abused (e.g. abstracting over 3 scenarios with 5 lines of code in total to support a particular once off business case that is going to be discarded after running once). That doesn't mean abstraction no longer has value.

Furthermore, languages with static type checking require different styles of testing and coding (e.g. abstraction) vs languages with dynamic type checking. Neither approach is universally better for all problem solving. Criticizing features of well designed code in one language that wouldn't be necessary in code written in another language is like criticizing a car for having wheels given that boats do fine without them.

Re: Poof and then Rails was gone

#39
I kind of skimmed the post, so maybe I'm missing something, but what exactly is the "architecture" described here? Dynamically-typed languages will allow the passing around of objects of different types as long as they implement the necessary methods. This is a nice property in some cases, but a lot of times I'd prefer to have static-typing and well defined protocols. It seems like that post ignored the more important parts of the discussion.

Re: Poof and then Rails was gone

#40
I love thinking up intricate software design patterns as much as the next guy. They'll cater not only to the current requirements for my project, but also to all possible future eventualities. It'll allow me to, by simply changing one or two lines of code, change my entire database backend, implement system-wide magic caching and to expose my HTTP service as a custom telnet protocol.

The issue I have with posts like this is that they are decidedly NOT just about thinking up wild new designs. Instead, they claim that these designs are somehow BETTER. Unless you can give me a real world use case, I won't believe you.

Post reply on HN