Top Vs Others
Top Vs OthersThe majority of Top vs Others discussions here on WardsWiki appear to boil down to repeated assertion of personal preference for tools and approaches.
Top argues for "classic" procedural programming, where coding is reduced to its fundamental TuringComplete essence: expressions, variables, IF statements, loops, sticking to canonical primitive built-in types and DynamicTyping, using the occasional procedure or function as needed to remove duplication. Where higher-order capabilities might be suggested, Top would prefer to rely on a pre-built tool (e.g., SQL DBMSs, or off-the-shelf libraries) rather than code them.
Top's detractors typically argue for what (for lack of a better term) I shall call "higher-order" programming: FunctionalProgramming, HigherOrderFunctions, LogicProgramming, StaticTyping but avoiding ManifestTyping, metaprogramming, polymorphism and inheritance, TypefulProgramming, etc. When low-level coding might become objectionably tedious, Top's detractors would prefer to subsume it under a(nother) level of abstraction.
Both views have a sincere common goal -- making programming "better" -- but they're really just stating personal preference for a favoured programming approach. Top believes programming is improved by using simpler elements, but that's just because he likes "classic" procedural programming. Top's detractors believe programming is improved by using more abstract elements, but that's just because they like "higher-order" programming.
Unfortunately, neither SoftwareEngineering nor ComputerScience have provided definitive evidence of which personal preference is "better" -- a good start would be to define "better", but that's an unresolvable debate right there -- and there's nothing to suggest they ever will, so debates over tools and approaches are effectively little more than two (or more) participants repeatedly shouting, "I like <x>, so you should too [because of the following beliefs that I hold to be true]!"
If that's the case, debating with Top is isomorphic to arguing over which is the best flavour of ice cream. I.e., pointless, unproductive, and best avoided.
Counter-view at MathVsPeople
"The majority of Top vs Others discussions here on WardsWiki appear to boil down to repeated assertion of personal preference for tools and approaches."
This strongly implies that the "others'" evidence is direct solid research as a contrast, and thus is a misleading introduction in my opinion. It's a technique often used by sleazy marketers. It's a way to lie without directly lying. I don't know if this is intentional spinning or just poor writing, but either way it should be repaired. The topic title renaming is also suspicious in terms of spinning. Wiki should emphasize ideas and concepts, not voting and people. I plan to change it back. -t
It doesn't imply any such thing, and I'm not sure how or why you inferred it. The views of Top vs Others are presented here in an objective fashion with no intended bias. The sentence that you quoted suggests that Top, and Others, both make "repeated assertion of personal preference for tools and approaches."
Then call it TopOnWhyTopIsHatedTwo.
I don't think that would be appropriate. There's no evidence that you're hated, nor is it about why you are hated, nor is there any reason to make reference to emotion.
I disagree with this summary. I approach it from what techniques are economical in terms of staffing, not just MY preferences. As pointed out in GreatLispWar, my own abstractions have had complaints about "being too abstract" by organizations. If you use certain advanced techniques, there's a decent chance you'll confuse future maintenance programmers, perhaps halting the project. Slow maintenance is often better than no maintenance to an organization. Slow maintenance is annoying; halted maintenance is a problem. Often lower abstraction is simply the least of two evils. -t
You may claim and even fervently believe it's what's "economical in terms of staffing" or that "lower abstraction is simply the least of two evils", but in the absence of any evidence to support it, I suspect it really is just your preferences. After all, your preferences that have lead you to work in places that (I would assume) avoid higher abstraction.
It's quite possible our professional surroundings are ALL shaped by our preferences, whether we know it or not. Either way, I don't insist staffing economic issues trump theoretical elegance, but am merely saying I believe it to be a more important and it should get a fair hearing in tool evaluation rather than insist theoretical elegance trumps staffing economics. As far as "evidence", neither side has any solid research in terms of practical net effectiveness; it's an AnecdoteImpasse. Thus, complaining about lack of evidence is hypocritical. The true default is NOT that theoretical evidence trumps economic evidence, but rather "unknown". -t
I have not made any claims about the value of theoretical elegance. I have claimed that theoretical evidence is valuable, but we need to include more than just theoretical elegance. It also includes simplicity, parsimony, flexibility, composability, extensibility, safety, and so on. Until you cite outcomes of research into staffing economic issues and demonstrate their relevance, theoretical evidence does trump staffing economics, because you've presented no evidence to suggest "staffing economics" matters, let alone how much.
Strangely you left out grokkability. Please reply at StaffingEconomicsVersusTheoreticalElegance if any, since those are listed there also. Thank You. (As far as evidence, see above. I've added more since.) -t
The list was not intended to be comprehensive. I included readability at StaffingEconomicsVersusTheoreticalElegance, but probably dropped something else important. Again, the list here (and there) was (and is) illustrative, not comprehensive.
of what?
Things of value resulting from theoretical evidence.
Quantity of People Note
This wiki tends to not be a representative of typical developers, as I encounter them. It leans toward those with an academic and/or teaching background. Thus, a wiki "vote" here is probably not a representative sample of developers in terms of their WetWare and preferences. -t
This page is about the participants of this wiki, not developers or people in general. Whether this wiki is representative of typical developers or not is irrelevant.
It's unproven speculation about my motivations and internal goals. Put it back or I will make a similar page about FP zealot motivations. You've been warned.....
Go ahead. What is speculated on here is the motivations and internal goals of all parties involved in discussions with you. You and Others are treated equally. I find it curious that you believe otherwise.
Where is the equivalent of "but that's just because he likes "classic" procedural programming."
[Notice that the next sentence ends with 'but that's just because they like "higher-order" programming.' -DavidMcLean?]
You shouldn't put words in ANYBODY'S mouth.
It's a speculation, hence the words "appear to boil down to" in the introductory sentence.
It's also very unclear whether the key point is versus-ness or personal preference. If the second, then rework it to make versus-ness a mere example, including the title.
The "key point" is neither. It intends to suggest a cause for the typical positions in typical debates here.
And the final sentence, "If that's the case, debating with Top is isomorphic" wouldn't need to mention Top if that's not the key point. Remember in English class? Examples don't belong in the ending summary.
It needs to mention Top because typical debates involve Top on one side with Others agreeing with each other on the other. If that were not the case -- say, numbers were more evenly balanced -- the final sentence would use the same analogy but would say "some participants" instead of "Top", and the PageName would be ConcretistsVsAbstractionists. However, that is not the reality we experience, is it?
I cannot put my finger on it yet, but something is very wrong about the way it's presented.
When you do put your finger on it, please let us know.
I don't want to know where you put your finger.
That's fine. It's not my finger that's at issue here.
Questions
How is the issue of a lack of rigorous studies different for top-vs-others versus ANY debate over software tools?
It isn't.
Probably not. I don't know. Does it matter?
Really? How so?
I can't say because I don't know what was intended. I just know it's fuzzy.
All that was intended was to provide a possible explanation for the debates between you and Others, and point out that because they appear to be rooted in personal preference there's no point in debating them. Debates about personal preference are pointless; as pointless as debating about the "correct" ice-cream flavour.
Whats the alternative? If that is the general and unavoidable state of IT tool comparisons, then the title and intro focus should be on that, not individuals.
It isn't a "general and unavoidable state of IT tool comparisons". Indeed, many of us discuss tools without basis in personal preference. We may discuss performance, expressiveness, flexibility, re-use, homoiconicity, and many other attributes that are not motivated by personal preference. The arguments involving you and Others, however, seem to be rooted in personal preference because they're not about (say) how to make a given feature run faster or be more flexible, but about categorical elimination of an entire category of programming. It's baby with bathwater, out -- and on fairly flimsy evidence. It's not like you've researched some fundamental programming problem -- or even a fundamental SoftwareEngineering problem like reliability or time-to-market -- and are suggesting that eliminating FunctionalProgramming will fix it. With evidence, that would, perhaps, be reasonable. Instead, you're predicting that FunctionalProgramming facilities will make programming more difficult for some programmers. From here, it looks like you're really saying, "I don't like FunctionalProgramming!" to which we can only respond with something akin to "We like FunctionalProgramming!"
There is a "fundamental SoftwareEngineering problem". ProgrammingIsInTheMind but too many stubborn people won't face this ugly truth. The primary purpose of software is to communicate with human beings. The machine is secondary. You guys seem to want to ignore the mind JUST BECAUSE it's difficult to measure. Selecting which factors to weigh the heaviest is perhaps the REAL "personal preference" issue, not so much the (alleged) result. If a given factor doesn't matter or slows down the typical coder mind, then that's the way it is. I'm just the messenger. I know WetWare being difficult to measure is frustrating, and tempts one to go look for their missing iWatch where the light is brighter, even though it was lost in a dim area. MathVsPeople.(And "expressiveness" is either subjective or difficult to measure, by the way.)
What is the evidence of this "fundamental SoftwareEngineering problem"? What are its effects?
Bigmouths pushing high-brow fads, creating confusion, tension, and wasted time. And I only have personal anecdotes from experience. Your heavy academic background probably puts you in organizations or conditions that are not typical, and thus you don't see the high-brow conflicts.
[On the other hand, I would like to thank these otherwise intelligent people for spending so much time with me helping me refine my ideas. I admire their resilience in the necessarily confrontational way I present my ideas.]
That sounds more like an oblique reference to a vaguely irritating personal problem than evidence of an industry-wide general problem. Your choice of emotional language -- "bigmouths", "fads", "high-brow", "stubborn people" -- clearly indicates your personal biases. If it was an industry-wide problem, shouldn't it be drawing media attention? Shouldn't there be a raft of consultants offering to solve it? Shouldn't there be books and 'blog posts written about it and programming languages that purport to fix it?
When I get frustrated, I sometimes vent with rude language I admit. Sometimes I go back and tone it down after I cool off. (Note I didn't single out any individual up there.) I can also point to rudeness on the other side if you really want to score rudeness levels.
I've noticed that, and yes I would like to see examples of equivalent "rudeness on the other side". However, your recent choice of language does not appear to be frustration-related, unlike (for example) "fucking shithead" which appears toward the top of the page, or "bigmouths" later. Terms like "fads" and "high-brow" lack the emotional venom of "fucking shithead", and therefore seem reflective of your personal view of "higher order" programming in general.
Be that as it may, it's not clear how it's relevant here.
I answered the "media attention" question as I understood it. If I misinterpreted what you were asking, it wasn't intentional. I cannot read minds.
Incidentally, I generally deny that I am simply pushing my preferences, although my preferences may mirror what I feel the market demands or expects because I intentionally try to keep in sync. Without market influence, I'd heavily lean toward more TOP and something akin to MaspBrainstorming in production. Thus, the assertion that it's all about pushing personal preferences alone is wrong. See footnote 2 under PatternsOfClaimsAgainstTop for more.
If your preferences "may mirror what [you] feel the market demands or expects" and you feel the market demands or expects avoidance of "higher-order" programming, then your personal preferences are what I described. I don't think anyone is intentionally "pushing personal preferences", but I think it's what everyone in these debates winds up doing whether they know it or not.
But then the root shaper is industry patterns, not so much preferences. My preferences would then merely be a middle-man side-effect. Your intro is "issue soup" without a clear relationship still.
No, in this case the root shaper is your preferences. I'm not assuming the market demands or expects avoidance of "higher-order" programming -- indeed, I see no evidence of that. I'm arguing that your preferences lead you to work for organisations that demand or expect avoidance of "higher-order" programming, and as a result you think that's the majority of the industry.
That's a pretty big assumption. I know you personally see no evidence of that, but to word everything like that's the default is quite presumptuous. And that's largely why the topic intro is stupid. --top
Top is very argumentative, and, regardless of the details, must win. -- ChaunceyGardiner
I find the same of my most common opponents. And it's not true. For example, I agreed that HOF's may be better for patching bad OOP API's and/or languages than living with bad OOP. But opponents are not satisfied winning battles, they want the whole fricken planet. -t
{It's a strange point to claim you "agree" with, given that the claim that HOFs "may be better for patching bad OOP API's and/or languages than living with bad OOP" is yours alone. HOFs are functions that accept functions as parameters or return a function, typically used for generating or executing TypeSafe, pre-compiled customised function definitions that support implicit closure over their defining environment. They are simpler than FunctorObjects because they implicitly close over their defining environment; the environment does not need to be explicitly passed as it does with a FunctorObject, typically via its constructor. HigherOrderFunctions can indeed be used to "patch bad OOP APIs", but only to the same degree that any other programmatic construct can be used to "patch bad OOP APIs". You can use loops to "patch bad OOP APIs" when loops are needed, too. Therefore, that HOFs can "patch bad OOP APIs" is not a defining or even a distinguishing characteristic of HOFs.}
As I mentioned somewhere else, your HOF-versus-FO may be a strawman or over-simplistic because the competitors to HOFs may depend on the situation. It's why I'd prefer to focus on scenarios rather than general claims.
{I've never seen an event handler, callback, or internal iterator that varied by application domain. An event handler for an accounting application looks exactly the same as an event handler for a videogame. We're talking about code requirements, not business requirements.}
And at this point I am partially impressed by HOF's ability to assist with or work around the faults of certain problem/fault-having languages and/or API's. I am listing it as a benefit of HOFs in my mind for now. -t
{It's only a short step from that to recognising that HOFs are nothing more than a programming construct that some languages have. Just like FOR loops are good for implementing certain things, HOFs are good for implementing certain things. I'm not clear what that has to do with "certain problem/fault-having languages and/or API's", but I'm not sure it matters, either.}
Moved discussion to IndividualExperienceShapesPerceptions.
EditText of this page
(last edited September 9, 2014)
or FindPage with title or text search