3 ms·
>They rewrite things from scratch with the next fancy-tech-du-jour, just to make the exact same mistakes again. Exactly. That is certainly part of it. There is
by unclebucknasty 13y ago
>They rewrite things from scratch with the next fancy-tech-du-jour, just to make the exact same mistakes again.
Exactly. That is certainly part of it. There is a tendancy to replace one thing with another, simply because we can.
>However, there is room for a solution in between
Making improvements, abstracting ugly details, etc., can definitely be a good thing and there are certainly projects that do this well. What I have learned to dislike is "solutions" that make the problem worse and that abstract the problem rather than the solution. The data access layer seems to suffer disproportionately here. For instance, with the OP, we now we have ugly database code with added layers. Over-engineering at its worst. Not sure why we don't just ask the simple question: is this really the simplest, most efficient, maintainable, way to do x?
jOOQ: thanks for the pointer. I will have a closer look, but at first blush, it is quite a bit like what I wrote all of those years ago. Perhaps I should have just pushed to standardize it. edandersen would have it on his resume, and we wouldn't be having this discussion. ;)
- lukaseder 13y ago> it is quite a bit like what I wrote all of those years ago. Perhaps I should have just pushed to standardize it. edandersen would have it on his resume, and we wouldn't be having this discussion. ;) Could be. The idea isn't novel. But no one has (publicly) gone as far as jOOQ before, from my marketing research. Here's what I mean by going "far": http://blog.jooq.org/2013/05/03/sql-query-transformation-fun-predicates-with-row-value-expressions/ http://blog.jooq.org/2013/05/03/sql-query-transformation-fun...