Goal Frame Of Reference Mismatch

(TE = Theoretical elegance)

It seems these "staffing versus theory" debates ultimately hinge on different base assumptions about goals in terms of what we are optimizing for.

I start from the view of those who hire developers: they want to maximize profits (or something roughly comparable). Theoretical elegance only matters to them in terms of those profits. If one says that theoretical elegance translates into profits, I would expect thoughtful and clear explanations on how that goes about. So far the explanations seem rather round-about to me. I agree that factors like parsimony are "good" to optimize, all else being equal, but they are not equal in my observation.

High-brow techniques have caused staffing headaches in multiple organizations I have worked for. The complainers don't say such code is "bad", but merely that "that kind of code has confused our developers in the past" (see GreatLispWar). They are usually managers and not (current) coders and so have no direct or heavy concern or personal investment in coding style. Confused staff interferes with their profits because it slows down or stops maintenance. That's a real hit to their production stack, and thus a hit to their profits.

It's not clear to me if the TE-leaning WikiZens believe these anecdotes to be false or unrepresentative of the more common situation, or if the managers' staffing concerns should be ignored because TE has OTHER benefits that such managers are not aware of. Are you questioning my anecdotes, or saying manager/owner beliefs should NOT matter?

TE may perhaps result in fewer bugs (for the sake of argument), but a stumped maintenance coder appears to be a bigger concern to managers. Big bumps in the road are a bigger concern to them than lots of smaller bumps. They value predictability over total average productivity and will accept lots of smaller bumps to avoid big bumps. Whether that's rational or not, it's not my job as a developer to question their priorities (beyond giving recommendations and relevant evidence). I should code to the manager/owner's goals, NOT my own. I am hired to solve their problems, not mine.

Is that not rational?

--top

My colleagues and I have been using what you call "high-brow techniques" since the 1980s. I've never seen a maintenance programmer have difficulty with them. So-called "high-brow techniques" may be more difficult for end-user developers and casual developers to grasp, but that's a developer group that tends to have equal difficulty with anything that isn't simple conditionals, loops, linear I/O, and trivial expressions. Drawing attention to their difficulties with (say) HigherOrderFunctions is misleading; such developers have equal difficulty with with low-level coding, such as assembly language. They have difficulty with nested loops, and nested conditionals. They have difficulty with functions, parameters, pointers, references, events, objects and classes. They have difficulty with everything. HOFs just wind up in the same "difficulty" bag with the rest.

By the way, it's been pointed out multiple times that no one is arguing for "theoretical elegance". The beauty and symmetry (i.e., elegance) of "high-brow techniques" has only been mentioned by you. However, multiple arguments have been made in favour of theoretical evidence, which is something quite different.

Our experience differ about what "typical" developers are like. So why does that make me bad or a troll? Do you think I am lying? Somewhere is a discussion about how different histories and personalities may gravitate toward different kinds of organizations such that none of our experiences may be a good sample such that we should LetTheReaderDecide which characterization fits their organization.

And calling something "evidence" does not by itself automatically make it evidence. I can say that having less semicolons is "evidence" of being better, but without tying it to some goal, it's not really evidence, or so weak of evidence that it doesn't deserve the name evidence.

Who said you're bad or a troll? I haven't said that, even though others have. You appear to be quite inclined to argue that HigherOrderFunctions are inherently bad without showing any code highlighting either the badness or equivalent alternatives. If you'd like to LetTheReaderDecide, wouldn't it be more helpful to help them decide with code examples?

I did give code samples.

Then your job is done. You can now move onto other topics and LetTheReaderDecide.

Others keep bringing it up, or extending existing topics. (I may have also at times.) FP is an "active" topic right now in the industry.

Yes. Bringing it up, or extending existing topics, is part of what makes it an "active" topic.

I do think the GUI discussion has been interesting in that it reveals how different people think about GUI API's.