4 ms·

>everything needs to be dumbed down to the lowest common denominator That kind of ought to be the default for most code. However, it's the natural tendency of

>everything needs to be dumbed down to the lowest common denominator That kind of ought to be the default for most code. However, it's the natural tendency of code to become abstruse and unnecessarily complicated. Since market forces will often tend to exploit rather than reward the work done by programmers to "dumb their code down" and inadvertently reward "clever magic understood by a limited number of experts" there's more of an incentive to amplify this effect than to work against it - especially where money is involved. I'm a bit conflicted because on the one hand I don't want to help developer compensation get ground down by billionaires or other business owners with an entitlement complex who consider developers to be "spoiled brats", but I do prefer working with clean, straightforward code.

barrkel 9y ago
There are times when you simply have hard problems. For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. You'd also like the code generation itself to be fast. That puts a limit on how much you can break it up into parts that can be understood individually and in isolation. Optimization works in opposition to abstraction because the optimal often requires steps that span multiple abstraction layers, and often requires multiple instances of the specific over few instances of the general. Personally, I think the two biggest reasons code becomes unnecessarily complicated these days are (a) testing and (b) local modifications. Unit testing in particular encourages over-parametrization so that dependencies can be replaced for the purposes of testing; while normal software maintenance under commercial pressure leads to local modification because nobody has time to understand the whole. People instead make conservative local changes by adding parameters, extra if-statements, local lookup maps, etc. I've found elegant solutions are often on the other side of a hill from over-engineering. You write specific solutions, then you climb the a hill of abstraction as you add layers, indirections, parameters etc., until you reach a summit, where you can see the whole, and can then start boiling things back down again, only retaining abstraction where it's actually necessary, or perhaps replacing multiple abstractions with a single more powerful abstraction (I've found this to happen a lot with monads; another one is converting control flow into data flow).
- crdoconnor 9y ago
  >There are times when you simply have hard problems. > >For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. Yeah sometimes you do, and that is exactly the kind of problem that is irreducibly complex, but I think new kinds of problems like this don't tend to crop up in the wild very often and when they do they tend to show up in subtle and non-obvious ways. The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. Furthermore, if I were working on a team where a developer has uttered the words "I've created my own ORM" (or something to that effect), my face has probably already landed in my palms. The rest of what you wrote I'm in vigorous agreement with though- especially the parts about unit testing, local modifications and "the other side of the hill". Seen all of that.
  - barrkel 9y ago
    > The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. This is digression. I have in mind something I wrote, the most complex piece of code I've written in the past couple of years. It isn't actually well covered by ORMs. ORMs are usually tuned for (a) static schemas, and (b) graph navigation in OO-style. Give them a problem like "here's a filter in the form of a syntax tree, please give me the top 100 results from this 10 million line table" - where the table schema is determined at runtime - well, most ORMs can't even answer this question because schemas are assumed to be static. And if you want to control the join order using nested subtable joins, with predicates that don't need joins pulled out of the filter expression and pushed down, because MySQL's optimizer observably doesn't reliably do the right thing, ORMs don't give you that control. It wasn't an ORM kind of problem; think more something like a read-only Excel spreadsheet, but with typed columns, and a rich autofilter, on the web, scaling to millions of rows. The output of the database query is a page of tuples, not objects in any behavioural sense. In some ways a database seems like the wrong solution, but morphologically it's exactly right: the user data is rectangular, relational, has foreign keys to other tables, and needs to be sorted, filtered and joined with other user-defined schemas. Modelling the user schema as database columns performs better than any other database solution, and database solutions are preferred because shared state, transactions, etc. Because the product is closer to being an actual database than a program using a database, ORMs aren't tuned for it.

barrkel 9y ago

There are times when you simply have hard problems. For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. You'd also like the code generation itself to be fast. That puts a limit on how much you can break it up into parts that can be understood individually and in isolation. Optimization works in opposition to abstraction because the optimal often requires steps that span multiple abstraction layers, and often requires multiple instances of the specific over few instances of the general. Personally, I think the two biggest reasons code becomes unnecessarily complicated these days are (a) testing and (b) local modifications. Unit testing in particular encourages over-parametrization so that dependencies can be replaced for the purposes of testing; while normal software maintenance under commercial pressure leads to local modification because nobody has time to understand the whole. People instead make conservative local changes by adding parameters, extra if-statements, local lookup maps, etc. I've found elegant solutions are often on the other side of a hill from over-engineering. You write specific solutions, then you climb the a hill of abstraction as you add layers, indirections, parameters etc., until you reach a summit, where you can see the whole, and can then start boiling things back down again, only retaining abstraction where it's actually necessary, or perhaps replacing multiple abstractions with a single more powerful abstraction (I've found this to happen a lot with monads; another one is converting control flow into data flow).

crdoconnor 9y ago
>There are times when you simply have hard problems. > >For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. Yeah sometimes you do, and that is exactly the kind of problem that is irreducibly complex, but I think new kinds of problems like this don't tend to crop up in the wild very often and when they do they tend to show up in subtle and non-obvious ways. The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. Furthermore, if I were working on a team where a developer has uttered the words "I've created my own ORM" (or something to that effect), my face has probably already landed in my palms. The rest of what you wrote I'm in vigorous agreement with though- especially the parts about unit testing, local modifications and "the other side of the hill". Seen all of that.
- barrkel 9y ago
  > The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. This is digression. I have in mind something I wrote, the most complex piece of code I've written in the past couple of years. It isn't actually well covered by ORMs. ORMs are usually tuned for (a) static schemas, and (b) graph navigation in OO-style. Give them a problem like "here's a filter in the form of a syntax tree, please give me the top 100 results from this 10 million line table" - where the table schema is determined at runtime - well, most ORMs can't even answer this question because schemas are assumed to be static. And if you want to control the join order using nested subtable joins, with predicates that don't need joins pulled out of the filter expression and pushed down, because MySQL's optimizer observably doesn't reliably do the right thing, ORMs don't give you that control. It wasn't an ORM kind of problem; think more something like a read-only Excel spreadsheet, but with typed columns, and a rich autofilter, on the web, scaling to millions of rows. The output of the database query is a page of tuples, not objects in any behavioural sense. In some ways a database seems like the wrong solution, but morphologically it's exactly right: the user data is rectangular, relational, has foreign keys to other tables, and needs to be sorted, filtered and joined with other user-defined schemas. Modelling the user schema as database columns performs better than any other database solution, and database solutions are preferred because shared state, transactions, etc. Because the product is closer to being an actual database than a program using a database, ORMs aren't tuned for it.