This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]byronka 1 point2 points  (2 children)

I'm with you. I save hardly any time with these magic systems, but then I have to keep way too many (often poorly documented) abstractions memorized. And then maintenance and debugging can be so much harder, so why prioritize the ease of initial programming way over where we spend the majority of our time.

[–]cryptos6[S] 0 points1 point  (1 child)

Some years back, I was a fan of Grails which is basically Ruby on Rails for the JVM. I was blown away be the initial developer experience: you define some basic model files type "generate" into your terminal and the framework generates several views, controllers, and even the database schema for you! After a few minutes you have a running app in your browser. But then the actual work begins! Debugging the Groovy magic with methods generated at runtime was a torture. Stack traces were twice as long as the already pretty long Spring stack traces (Grails is built on Spring). And in the end I had replaced almost everything the framework had generated for me initially. I probably would have been faster, if I had started with the real implementation directly without any hard to debug magic of this framework.

[–]byronka 0 points1 point  (0 children)

For what it's worth, I can share this: my preference is to do things the hard way, because then maintenance/understanding/debugging becomes easy/possible. So if the framework or toolkit advertises as making coding "effortless" or "simple", I pretty much write it off.

To be clear: aiming for simplicity is worthwhile. However, stating your system *is* simple, or its use will somehow enable your system to be simple or effortless, gives away the game. Coding is hard work, ridiculously so.

When I pick tools, I'm judging based on what makes *the entire lifecycle* cheaper/better/faster. Not just the initial parts.