The 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 , 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." * Bullshit! It's possible to be objective BUT misleading. If you have a topic "X versus Y" and start out saying, "X does A", that strongly implies that Y does NOT do A. ** Re: "but that's just because he likes "classic" procedural programming" is NOT OBJECTIVE, fucking shithead! ** ''It's no different from "but that's just because they like 'higher-order' programming." Do you think "'classic' procedural programming" is bad? I don't.'' ** Irrelevant; it's not objective. ** ''Both views are observations.'' ** One cannot observe internal emotions directly, only signs that SUGGEST emotions. ** [Personal preferences aren't emotions, and direct observation is not the only possible form of observation. It's perfectly reasonable to assert "X likes Y" as a result of observing that X, all else being equal, tends to choose Y rather than Z -- it's also objective, if possibly incorrect (say, if X chose Y with a deliberate intent to mislead). Indeed, the fact that "X likes Y" can be an incorrect statement is a demonstration of its objectivity, as has been discussed many times on this wiki before. -DavidMcLean] ** "Assert", yes, but that's not solid proof, especially if there are a lot of variables. For example, I drive to work almost every Monday through Friday, but that frequency alone does not mean "I like to drive to work". I ''hate'' the commute, but it's a means to an ends. Thus, "tend to choose" is not telling the whole story. (I'm avoiding a LaynesLaw mess over "emotion".) -t ** [I said "tends to choose Y rather than Z". Are there alternatives to driving to work that, all else being equal, you would prefer? As for not being solid proof, you're right; it's just a reasonable inductive inference, not an irrefutable deductive one. Nonetheless it is reasonable. -DavidMcLean] ** "Reasonable" speculation, yes. Reasonable conclusion, no. ** It's not strong enough to make a conclusion for reasons already given. There are a lot of complex factors when it comes to work-place behavior. If we were dealing with amoeba's instead of human beings, I may tend to agree with you because amoeba's typically don't delay short-term gratification to achieve longer-term gratification, but the reverse is true with humans. -t * [It doesn't say "X does A". It says "In X vs. Y discussions, A happens". -DavidMcLean] * That's still a strong implication that Person X causes A, in a bad way. * ''You appear to be inferring something here that's neither stated nor implied. There is no "in a bad way" anywhere on this page, except for your inference of it.'' What "topic title renaming" are you referring to? This is a new page, with content moved from TopOnWhyTopIsHated. ''Then call it T''''''opOnWhyTopIsHatedTwo.'' 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 C''''''oncretistsVsAbstractionists. 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.'' * Then why focus the title on Mr. Top? You seem to be admitting it's more general and/or wider than one individual. * ''Because it's an explanation for debates where you (i.e., "Mr. Top") are always a participant. Debates characterisable as "Mr. Top vs Others" have been a defining feature of WardsWiki since you arrived.'' * I believe it would be better to focus on concepts and patterns (of both tools and IT staff) rather than individuals. I believe most WikiZens would agree this wiki should not unnecessarily focus on individuals. Doing so is confusing to new readers and can generate a lot of personal animosity. * ''Yes, it would be better to focus on concepts and patterns rather than individuals, but when a particular individual is uniquely prominent in a particular role, it may be helpful to understand -- if nothing else -- why it is fruitless to engage in debates with that individual.'' Would the alleged outcome be different if it were ''not'' about "personal preference"? ''Probably not. I don't know. Does it matter?'' * If it doesn't matter, why mention it? That intro is already a confused soup of 3 sub-topics (below), so if it doesn't matter, slice it out. Plus, it's accusative. * ''I mention it because it appears to be a fundamental motivation. It's certainly not accusative, because the "accusative" (usually short for "accusative case") is the grammatical case of a noun used to indicate the direct object of a transitive verb. I assume that's not what you meant, because it doesn't exist in English. If you meant "accusatory", it isn't. You seem to think I'm accusing you of something bad. I'm not.'' The intersection (or lack of) between Mr. Top, lack of studies, and personal preference is too confusing. The relationships need clarification. ''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.'' * I honestly believe that typical shops, as I have encountered, are not ready to absorb them in a way that produces net benefits. If you think I am lying or being self-deceiving, so be it. It appears I cannot change your impressions of such and so will have to live with that impression exiting in your mind. I don't believe you guys are consciously pushing HOF's beyond what the market is ready for, rather you focus on the code itself first in terms of parsimony and ''potential'' "purity" etc., but staffing and economic issues are second because you are not used to thinking that way. Your mind is "equation geared" out of habit and perhaps preference and personality. You process symbols first in your mind; and economic, business, and staffing get the attention of far fewer cycles or neurons in your mind. Thus, your priorities are not in sync with owner/manager priorities. * ''I spent years running a software company. I work with software companies. I teach developers. There are many things far, far, far more difficult for developers to grasp than "higher order" programming. I see more developers having difficulties configuring Apache than I see having difficulty with HigherOrderFunctions. In fact, beginning developers seem have little problem with the idea of treating functions as values; it seems to be more natural than treating them as static constructs. That may -- at least in part -- be why so many developers readily (even eagerly) grasp JavaScript, despite its quirks.'' * Fine, my experience differs. LetTheReaderDecide which experience best matches their own. JavaScript kind of forces them on people because of its awkward OOP syntax and maybe they eventually get used to them. QwertySyndrome. If you are forced to use to assembly, you get used to assembly. If you are forced to use COBOL, you get used to COBOL. I personally don't see a need for HOF's if the language supports decent OOP and the libraries are not goofy. HOF's may reduce code size by a few percent points in some instances, but that's not enough to justify adding another paradigm into the stack to reduce staffing-related requirements. Code size is not the end-all-be-all. As far as hype-detection, it's still more art than science, for sometimes hype does actually bear fruit, although it may be largely accidental. For example, the dot-com bubble was indeed largely hype, but in general the Internet is taking over everything, just not the way early investors imagined. Christopher Columbus hyped his "India shortcut", but we mostly remember his grand discovery. Possibly related: CarlSagansBaloneyDetectionKit, ItFadSmell, DilbertIsNoJoke. -t ''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 FunctorObject''''''s 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. ---- See TopOnWhyTopIsHated, PatternsOfClaimsAgainstTop