BowtieOrientedProgramming comes along, for example, and everybody is raving about it as the next SilverBullet. However, proponents cannot produce external, obvious evidence that is convincing, often even to other co-proponents. (Co-proponents may agree with the benefits, but not the example as a demonstration tool.) No obvious improvement in OnceAndOnlyOnce, no dramatic reduction in code size, etc., are produced. Often the benefit is allegedly some kind of hard-to-measure change in mental process. The New Thing makes you "think better", but only if you "get it". The burning question is, "How can something be so great, not just slightly better, without leaving a good trail of evidence"? ---- Beware the LongTitlesSmell. ''Alternative suggestions welcome.'' * "WhatMakesNewThingsSoGreat"? * AssumingRighteousnessWithoutSubstantiation? * PresumingTruthWithoutSubstantiation? * RepudiatingAssumption''''''s? * Can''''''tProveIt''''''sBetter? - ''Nit: Does not convey supporter's enthusiasm'' * SuperGreatWithNoEvidence ''Actually, a discussion on Lisp evangelism in part inspired the topic, and Lisp is older than me. It is the "it is great but I cannot show you why" attitude that this is about. It is that some appear to claim their pet is '''above science'''.'' * Thank God, that's a relief. I thought it was going to be yet another campaign by the RelationalWeenie''''''s against ObjectTechnology. * ''That is next week :-) '' Straw man. That never happens. Lisp fans are always quick to say why. You are thinking of the many, many times (including on this wiki) that a HostileStudent said "prove to me that Lisp is better than all other languages, but don't use any toy examples, because toys prove nothing, and don't give me a big program to look at because I can't read Lisp, and don't talk to me about higher order functions, multimethods, macros, homoiconicity, evaluators, lazy evaluation, etc, because I'm bored with those topics and they don't prove anything. Now come on, hurry it up." -- followed typically by a speechless silence, which '''you''' then take as proof that Lisp is all hot air. Sheesh. * The answer I would use for this would be, "What ''would'' you consider suitable evidence, and what other languages/paradigms/systems fulfill the requirement?" This should draw out the criteria by which the matter is being measured. In my experience, these criteria usually are not particularly objective themselves; this is because, in the current state of the art, '''there are no universally applicable measures of effectiveness in programming.''' The few rigorous measures that exist - AlgorithmicAnalysis, GoalsOperatorsMethodsAndSelectionRulesModel, CorrectnessProving - generally play a little or no role in actual programming practice, and are rarely applied even where they could be of use. - JayOsako ** That's exactly it; there '''are''' objective measures -- which are largely ignored or distorted or otherwise irrationally and subjectively misused by both sides in any debate, even when people have good intentions (which they usually do not). As Heinlein said, "man is not the rational animal, man is the rationalizing animal" ** ''Please list them under ThingsWeAllAgreeOn.'' ''I think that suitable evidence to the greatness of a language (in particular, Lisp, but it can work for any language) is the existence of hot applications made on it, and great availability of libraries and basic programs, which allow you to not start from zero.'' ''Lisp is one of the older languages, and lacks the libraries. Fortran has almost the same age, and has TONS of libraries. Perl is young comparatively and has tons of libraries. PHP is even younger and has lots of libraries. Java too. Something must be bad with Lisp if only now their fans are trying to build a decent library base.'' [The CommonLisp standard is largely about what would be libraries in other languages. One of the reason you don't find many libraries out there for CommonLisp to do mundane tasks is because they ''come standard'' with the language.] ''I can't say I believe you. Yes, there are some libraries that come into CommonLisp, but there are lots of things to do out there. And you can't do it in CommonLisp, or ar least, not in a portable way. Even PaulGraham recognizes this:'' * Libraries are one place Common Lisp falls short. There are only rudimentary libraries for manipulating strings, and almost none for talking to the operating system. For historical reasons, Common Lisp tries to pretend that the OS doesn't exist. And because you can't talk to the OS, you're unlikely to be able to write a serious program using only the built-in operators in Common Lisp. You have to use some implementation-specific hacks as well, and in practice these tend not to give you everything you want. Hackers would think a lot more highly of Lisp if Common Lisp had powerful string libraries and good OS support. (PaulGraham in http://www.paulgraham.com/popular.html) But people are lousy at articulating why X is so great in larger apps that they work with. You can't just say "it is good because it has higher order functions, and higher order functions are better abstraction, and better abstraction is good, therefore higher order functions are good". That is circular reasoning. (Besides, occasional use of them can easily be emulated with an "eval" operation.) When I describe why I like my favorite technologies, I often end up describing the kinds of patterns that my eyes notice (technically, the eye and brain working together). I agree that others may not spot the kind of patterns that my eyes do and ''vice versa'', but at least I narrow it down to the kinds of things that my eyes favor. If your eyes are different, then at least we know where our differences lie. In other cases I find a consistency to my favored techniques that seem to be lacking in alternatives. If there is a consistency in the alternatives, then please point them out. I cannot know that they exist until they are pointed out to me. If there are selling points that compensate for the lack of consistency, then I need to know specifically what they are. I have identified a weakness, consistency, that the other party seems to agree with, but they don't counter it with something equally as specific. These are the kinds of things I hope to get out of others, but I can't. '''They are not doing a good job at psychology dumps.''' [Quite aside from whether Lisp is a good or bad language, higher order functions themselves are so obviously a good thing, at least in some situations, at least in moderation, that there has never been any true counter-argument, to my knowledge, in all seriousness. One might as well demand to hear an argument in favor of floating point versus integer. Integer-only programmers may not grok the point of floating point, but that's their own private self-education problem, not by any means the start of an argument (despite the well-known problems with numerical analysis). Same thing with basic use of higher order functions. There's no debate, there are no sides, there is no subjectivity. There's knowing and there's not knowing, that's all.] [I assume you personally do know higher order functions and you're just playing devil's advocate, but I disagree that that is appropriate on that particular topic.] [Some things are in the "RTFM" category, basically meaning "I would die of shame before flaunting abysmal ignorance of such a basic topic that I could educate myself about so easily, and you should feel the same way, so stop flaunting and start reading." The question of why the entire gestalt of a language, whether Lisp, Haskell, Java, or whatever, is thought to be an effective choice, is not necessarily an RTFM matter. Utility of e.g. floating point or higher order functions '''is'''.] * Actually, floating point is not a good example; some very experienced practitioners in the field, most notably ChuckMoore, ''do'' have a problem with floating point, because it can lose precision without warning. Moore (whose original profession was radio astronomy, where explicitly defined precision is extremely important) steadfastly opposed introducing floating-point into standard Forth, and when popular demand drown him out (in this and other matters), he abandoned the ANS Forth in favor of a new dialect, ColorForth. Similarly, compliant Scheme implementations which implement the full numeric tower generally (AFAICT) use a combination of rational fractions and fixed-point bignums for exact numbers instead of floating point, and often for inexact numbers as well. - JayOsako ** [No, floating point is an excellent example; I am aware of the problems that both experts and non-experts have with it, and I am aware that it should be avoided for some things, yet it is '''still''' indispensable for some other things. Anyone who doesn't understand that is a perfect example of someone in need of further education, which is the point. Yes, floating point has its problems. No, there is no acceptable alternative in many application areas. No, I didn't say it is without problems, nor that it should be used for everything. ChuckMoore is admirable in some ways, but he's enough of an extremist to verge on being a crackpot in other areas (e.g. not believing in software reuse); there is zero reason to bring up his views on this. Floating point is '''necessary''' for '''some''' things, and this is not subjective.][''Name one.''] * ''In the biz world, a "decimal" math library is often preferred. Floating point and currency calculations tend not to get along very well. See FloatingPointCurrency.'' ** Yeah, of course. Not the point. One can have higher-order functions without using Lisp, I would note. Often they can be emulated in dynamic languages that don't directly support HOF with a basic "Evaluate()" function. Although a bit "hacky" in some ways, for occasional use it does the job. The difference is not the "super-great" being sought in this topic. * Many languages support HigherOrderFunctions these days, pick one, use them, for no eval hack will be sufficient, there is no argument, HigherOrderFunctions and FirstClassFunctions are clearly superior features of a language, and languages without them are clearly crippled in comparison. ** Strongly agree. As already stated, their utility transcends language. ** ''How do we measure "crippled" here? More code? OnceAndOnlyOnce violations? I would like to see a demonstration, even if it suffers the problems of "toy" examples.'' *** If you know what those things are, then you don't need examples, they are clearly better, lead to less code, more abstraction, more reuse. If you don't know what they are, it's your job to go learn them, follow the links, there's a wiki page about each one, no need to repeat their benefits here. But here's quick sample in javascript just to prove it: ''[example moved to ArrayDeletionExample]''. ---- I would further invite the proponents of various languages to provide any examples they can find of ObjectiveAdvantagesOfLisp, ObjectiveAdvantagesOfCee, ObjectiveAdvantagesOfOo, ObjectiveAdvantagesOfFp, ObjectiveAdvantagesOfRelational, and so forth. ''If there is no such thing, then can we respect each other's choices without making them feel inferior for not buying into your pet technology?'' This whole page is about pain and pain avoidance. Fear of feeling inferior. Why not simply acquaint yourself with many a tool and transcend them? One has lots of time to slowly get to know many ideas. Defining yourself with respect to a toolset is one of the most self-destructive things one can do. ''That may be so. Then again, it may not. I did not write any of the above, so I do not pretend to know ''exactly'' why it was written. Still, I can imagine reasons for writing it other than "Fear of feeling inferior." Personally, I work primarily with PerlLanguage and a little bit of CeeLanguage most of the time. This does not stop me from recognizing the many advantages of LispLanguage, and it does not keep me from seeing the validity of the points being made by the SmugLispWeenies.'' Question: why have you not abandoned Perl for Lisp? I agree that Lisp is a good language. However, some sell it as a SilverBullet. * PleaseCiteYourSources. I think it leads to much more interesting conversation that way, because some kooks with a webpage doesn't mean the point you're responding to is worth any less. * ''See the area in AreLispersTakingOverThisWiki where someone says "Yes, it's really that great".'' [If you're not quaking in your boots, then you haven't maximized FearOrientedProgramming.] I'm the PerlLanguage user above. I'm not sure which place to put this answer to make the most sense. Refactoring welcome. I have not abandoned Perl for Lisp for lots of reasons. I work at a university. What code I write is usually in the service of some other in-house project. There are several other people in-house who know Perl but do not know Lisp, and do not want to learn. We have lots of custom library code in Perl (much written by yours truly). Perl has higher order functions. It has closures. It has TailCallOptimization (though you need to ask for it with the MagicGoto). It has a decent package system. It has enough ObjectOrientedProgramming capabilities to do what I need. It has garbage collection (although it is just reference counting). It can do some syntactic abstraction via prototypes, if you '''really''' want it to. Much of what I have learned in my independent studies of Lisp has been directly applicable to Perl programming. This is no surprise given that many of Perl's features originated in Lisp! I can do DataDirectedProgramming when I need to. I can do FunctionalProgramming when I need to. I can do ObjectOrientedProgramming when I need to. I can do plain old boring imperative programming when I feel like it. I really like AutoVivification. If I say something like: my(%foo); $foo{'bar'}{'baz'}{'quux'} = 3; The first line declares a local hash named %foo. The second line: Creates a new hash and assigns a reference to it to $foo{'bar'}. Creates another new hash and assigns a reference to it to $foo{'bar'}{'baz'}. Stores the integer 3 into $foo{'bar'}{'baz'}{'quux'}. This is very convenient when I am building a nested data structure and new data comes in. I can just assign it to the correct place on the tree, and if the intermediate nodes don't exist yet, they spring into existence. In most other languages (including, I believe, Lisp) I would need to check for and create each of the intermediate nodes myself. ''Trees? Yuk. Table-time, guys. Nested arrays suck -- top'' When I am talking to a Lisp interpreter, I feel like I really know what is going on in there. Even if the interpreter isn't implemented using my mental model, it still behaves like my mental model. Programming in Perl is more like talking to a person. When I need to do something funky, when I need to nest behaviors, I sometimes guess at the syntax. Usually Perl understands, and sometimes I need to rephrase. LarryWall claims that this is an advantage and that he deliberately made Perl resemble natural language in this way. There's also CPAN versus macros. Frequently I don't actually need to solve my problem in Perl. I can just download someone else's solution, and fill in a few parameters. I know similar things exist for Lisp, but they are smaller and I haven't learned them yet. But with Lisp, I know that I can build '''anything''' I need. There is a nice, liberating, completely in control feeling that I enjoy when working with Lisp. So, that's where I am. Like I said, I still appreciate the truth behind things people say about LispMachine''''''s. Yes, LispMachine''''''s failed for political reasons and not technical ones. The vendors got greedy. The software was proprietary. Sure, technically they may be the best solution for many, if not most computing problems. I know that my tools are in some sense inferior to the best that they could be. That doesn't make '''me''' inferior. It doesn't make me afraid to listen to ways that someone else's tools might be better than mine, or ways that someone else's idioms might be better than mine. ''You seem to agree with me that Lisp is a good language, maybe even the best, but *not significantly* better than other languages, just a little bit at most, especially when compared to other very dynamic languages such as Perl, TCL, etc. I do believe that dynamic languages can run rings around C++ and Java, but those are easy to beat.'' Please don't put words into my mouth. I'll say plenty of dumb things without your help, I promise. ;-) I believe that Lisp is a much better language than Perl, taken language-against-language. The thing is, the real contest isn't just language-against-language. There are also issues of culture, development environment, legacy code, and so on. There is also an issue of need. For my day job, I just don't ''need'' Lisp's power, no matter how convenient it would be, so those other factors tend to come to the front, especially the cultural one (other Perl programmers around) and the legacy code. BUT! None of that is my main point. My main point is in response to the above comment to the effect that this whole page is motivated by fear of being inferior. I believe that it is valuable to discuss the relative merits of different programming languages, tools, and techniques, and I don't think that such discussion must center around fear of being inferior or desire to be superior. I studied Lisp because I wanted to. It has made me a better Perl programmer. Sometimes I resort to a little GreenSpunning, but because I have a strong understanding of what I want to do, and how I would do it if I had the tools available to me, I can do it in a minimal and targeted manner. This doesn't make me feel inferior (because I'm ReinventingTheWheel) or superior (because I know these l33t c0d1ng t3chn1qu3s). It just makes me a better programmer than I was. ------ Re: "There is also an issue of need. For my day job, I just don't ''need'' Lisp's power" I meant "great" from a practical standpoint, not a MentalMasturbation standpoint. ''I guess it's all a matter of perspective. If I were starting from scratch, I think the difference in ease ''would'' be significant. Starting where I am now, I don't know if it would be possible to sell the boss and my coworkers on a change to Lisp, and even if I could, I don't know if the improvement would be "great" enough to offset the effort of the migration. I still maintain hope, though. Frequently, when someone notices an especially clean and good solution in my code, I mention that it is based on a technique I picked up from the Lisp community "...although it would be even easier in Lisp." ;-)'' I HaveThisPattern too, whenever someone compliments something elegant in my code, I almost always credit either Lisp or Smalltalk for the idiom, hoping that someday they'll get the point. * ''While the credit is nice; DoNotWorryAboutTheCredit. The things that originally came from Lisp or Smalltalk, but can be implemented without too much hassle in a different language, aren't going to help you. What will help you is whenever you can show an example of a problem where the Lisp (or Smalltalk) solution is '''significantly''' simpler than the solution in language X, where X is what the PointyHairedBoss has decreed. Unfortunately, most business apps don't need the algorithmic superiority of Lisp (Smalltalk is a better fit - a Smalltalk-like language that wasn't a PinkyAndTheBrainLanguage would be a better fit still). Most business apps need simplistic data processing, the ability to speak numerous protocols ''without'' needing to go find the libs yourself, quick-and-dirty GUI builders, etc. Lisp can do all these things; but none of these play to its strengths.'' Sorry, I disagree, the Lisp and Smalltalk solutions that I credit, are always significantly simpler and less verbose than the hoops I have to jump through to fake them in my language. I write custom business apps too, and I find they do need the algorithmic superiority of Lisp and Smalltalk on a daily basis. I find myself faking features of Lisp and Smalltalk constantly, because it drastically lessens the code I have to write, though it'd be easier in Lisp or Smalltalk. * ''Which features? And what language(s) are you stuck with? Some languages are sufficiently bletcherous that '''anything''' reasonable is better...'' Closures for example... Closure in csharp interface Unary''''''Procedure { void Run(object anArg); } class Some''''''Closure : Unary''''''Procedure { public void Run(object anArg){ some code } } new Some''''''Closure(); Closure in Java interface Unary''''''Procedure { void Run(object anArg); } new Unary''''''Procedure { public void Run(object anArg){ some code } } Closure in Smalltalk [anArg|some code] Closure in Lisp (lambda (anArg)(some code)) If you don't think that's a huge difference, then you don't understand programming with closures. * ''C# is firmly in the aforementioned "sufficiently bletcherous" category. :). Heck, even JavaLanguage can fake closures/lambdas better. But the good thing about DotNet is that lots of languages have been ported to it, so in theory you could try and sneak some Smalltalk in.... :)'' ** 1.0 could be considered "sufficiently bletcherous", from a functional programming standpoint, but 2.0 makes things a significantly nicer: Closure in C#2: // this is actually in the BCL, so you don't need to implement it yourself // along with: bool Predicate(T obj); U Converter(T from); int Comparison(T x, T y); delegate void Action(T obj); delegate(type AnArg){some code} which is almost the same number of characters as the lisp example (discounting the delegate declaration, which written for you and contained in the base class library, the only difference is the required type annotation for the argument). [Further, the justification for closures as "significantly better" than alternatives has not been established. Do you guys use lots of closures, or occasional closures?] * ''Closures are convenient for lots of things, top. Including being useful outside of OO programming. :)'' One need not justify closures, they are quite obviously better, and we use lot's and lot's of them. Objects are build out of closures, and closures are just functions that can maintain state. Closures are core to functional programming, and core to event driven programming. * ''Not only that--if someone were to implement TableOrientedProgramming, for instance, closures are a great way to implement the tons of little functions that would occupy the relevant columns in the various and sundry dispatch-tables that we would need to write.'' ** Fine, then go ahead and '''implement''' it - or ask me or someone else who WritesCompilersAsaHobby to help you do it. Words aren't going to convince us that you're on to something solid, but actions might. ShowMeTheCode! - JayOsako ** ''Note that the "closures" comment did not come from top.'' ** Now that you mention this, isn't programming in a spreadsheet largely TableOrientedProgramming? If so, then perhaps the CommonLisp library Cells, which was inspired by the cells of spreadsheets, is the TableOrientedProgramming language you're looking for, if not a step in the right direction. * I generally use some form of evaluate() for such, but I suppose closures are a bit cleaner. ** ''Huh? While related, the two aren't really comparable. One is a way of creating a FunctionLikeThing without having to name it; the other is a way of parsing and executing code at runtime. I assume you mean by "evaluate", storing program code '''as text''' in some attribute in a record, and using eval--you could (with a SufficientlySmartDatabase) of course store in a StoredProcedure instead--or if you use lightweight tables instead of a RDBMS, you could store a closure.'' * [Actually closures are considered '''sharply''' preferable to eval/uate whenever the choice is feasible, for a whole slew of reasons, potentially including early rather than late language error checks, security, efficiency, and readability/maintainability.] * Um, not to mention that closures carry an execution environment within them, eval is not a comparable replacement for closures. * ''Issue taken up in DynamicStringsVsFunctional.'' Moved discussions on code management/lookup to FileTreesToManageCodeDiscussion ---------------- The benefits of almost every concept that I consider "good" are either explainable with relatively small examples or are something I realize is purely a personal subjective preference. However, some claim that some things don't fall into one of these two categories; that benefits can only be seen after years and years of exposure to a concept, and even then they are still not easily articulatable. Being that I have never encountered this 3rd category in my entire life, I am very skeptical it exists. Either I have reached the limit of my brain or experience that keeps me from seeing the 3rd category anywhere, or claimants of the 3rd category are either deceiving themselves or are shitty articulators. ''Sigh. More exaggerated strawmen. If you're talking about the Lisp discussions, then nobody says it takes years and years to see the benefits. A few weeks of part-time playing around, perhaps. You have to learn enough of the unfamiliar concepts to see how they work together to make programming life more pleasant, and you may have to add some time to get past the unfamiliarity of working with the unfamiliar syntax and some of the unfortunate historical names of basic functions. (I still struggle with the latter, since I don't program in Lisp all that much - yet.) -- DanMuller'' [To put it bluntly, you have to have an open mind and be willing to learn new things on your own. No one will do it for you and you won't ever get it as long as you're waiting for someone else to prove it to you, that's not how programming works. Only those who put forth the effort to "learn" will understand, and top, you aren't in that category, you're a HostileStudent.] I guess what I am trying to say is that in the past, '''benefits of great concepts were not that hard to explain''' (if you know how). I find Lisp concepts good, but not great. I don't see a revolution in there. How can a revolution be obscure? Past revolutions were not obscure, so why has the pattern allegedly changed? ''Great concepts are ''frequently'' difficult to explain, because they are so new and/or different from existing concepts that it is difficult to tie them back to the existing concepts that the listener knows. Consider how much trouble children have with fractions, or how difficult it is for many people to accept that there is no fraction representing the length of a unit square's diagonal. The newer a concept is, the less it has in common with your existing body of knowledge, the more work it will take to assimilate, and the more doing so will broaden your understanding of the world.'' [The pattern hasn't changed, you've just stopped learning. It's not obscure at all, it's blindingly obvious and has been pointed out many times on this Wiki, including on this page. You're mind is so set on tables and databases that you ignore everything else, to your own detriment.] My mind just naturally gravitates toward tables. I cannot stop it without a lobotomy. And, they bring consistency to data structures that you map-pointer-network and tree fans lack. I don't think anyone has challenged the consistency complaint. [Like I said, you've stopped learning, you think tables are the GoldenHammer to solve all problems and you fail to see that they are but one of many many useful data structures. There is no one perfect data structure, certainly not tables, real problem require flexibility and choices, and the willingness to use the appropriate tool for the job. You need to get beyond your table fetish if you ever want to progress as a programmer.] Let's see what happens when you say the same thing about EssExpressions as the one-size-fits-all. Glass-house accusations about my pet technologies are flying all over the place here. [I don't, nor have I ever. I don't believe in GoldenHammer''''''s, that's your bit.] Well, many on wiki do believe in them, just not the same one. If you are not one, then ignore this topic because it is not relevant to you. [ You're stuck in the past, programming wise, and pretty much refuse to learn anything new as far as I can tell. You think people are going to force you to keep up... think again. Yes the relational model is awesome for dealing with data... but it has little effect on most programming tasks and patterns. How many times are you going to write the same loop over that recordset before you realize that's a generic pattern that should be encapsulated into a higher order function so you never have to write it again? Tell you what... paste up some of your common code patterns, and we'll see if we can't package them better using some of these concepts you don't seem to be grasping.] * The sad thing about TopMind is, he often has a point. There are many problems, outside the domain of processing persistent business data, for which use of relational tables would be an elegant solution. The problem with Top's arguments are twofold: ** He routinely confuses relational tables with RDBMS's. While the latter requires the former by definition; the former does not require the latter. Arranging transient data in a relational form is quite frequently a useful thing to do, even when you don't need ACID semantics or transaction semantics. And ACID semantics and transaction semantics are ''expensive'', despite numerous advances in RDBMS technology. *** See MinimalTable. It is not all-or-nothing. ** He sees the database as a GoldenHammer; which ought to replace virtually every other way of structuring data and/or code (excluding a few instances which he erroneously labels as "device drivers"). Granted, lots of other SmugWeenie''''''s have their favorite GoldenHammer as well, but it's well established that GoldenHammer is an AntiPattern. I completely agree with that. If he'd just learn some more, and learn to present his arguments better, and only in proper context, people would listen. But the GoldenHammer comes out on every topic he's involved in, whether the context is appropriate or not. Databases can't replace programming languages, and when you cry wolf so often... well... no one listens anymore. ** ''I don't claim my favorite techniques are objectively better. They are just not objectively worse (except maybe in specific poor implementations or languages) outside of embedded device execution speed.'' ''Let's all agree that all GoldenHammer fans have done a crappy job at articulating their viewpoint, okay? Lisp, OO, relational, etc. Further, I never claimed that tables would "replace programming languages", only reduce the need for them. -- top'' * Oh, I'll agree with that in general. I can't speak for others; but I've never argued for UniformityUberAlles in any technical matter. I think OO is useful, I think functional is useful, I think relational is useful, etc. And the various technologies and paradigms have tremendous areas of overlap in their usefulness. * This overlap may seemingly justify some forms of GoldenHammer thinking - there's the argument that "technology A is the ideal solution to problem W and is a workable solution for X, Y, and Z - so I'll just use A to do the whole thing". Which may be true, but it might be the case that technology B is the ideal solution for Y and Z, and an adequate solution for W and X. Or, by use of C and D, you can have near-BestOfBreed solutions for ''all'' the problems in your problem set. '''Always know your requirements before you settle on your architecture.'''. Keep in mind that the HighlanderPrinciple is often an AntiPattern. * ''This topic generally is geared towards those who think there ''is'' a GoldenHammer. The answer of a "mild-mannered mixer" to the topic title would be "N/A" because there is nothing that is "super great". Further, there is no consensus on what does what best.'' ------------------- RE: ''there's the argument that "technology A is the ideal solution to problem W and is a workable solution for X, Y, and Z - so I'll just use A to do the whole thing". Which may be true, but it might be the case that technology B is the ideal solution for Y and Z, and an adequate solution for W and X. Or, by use of C and D, you can have near-BestOfBreed solutions for all the problems in your problem set. Always know your requirements...'' The idea that programming technologies are tools is problematic in its own way, cf. FallacyOfTheRightTool. One must ask not only whether some technology A supports an ideal or adequate solution for specific problems, but also whether the resulting subprograms can be effectively integrated, configured, reused, extended, deployed, ported, maintained, upgraded, and so on. A requirement to "always know your requirements" is a bad thing because our hindsight is much sharper than our foresight. A more adaptable technology that reduces the need for foresight may be a better one even if it is non-optimal for individual tasks, cf. CodeChangeImpactAnalysis. Focus on individual problems is terribly short-sighted; the bulk of programming effort regards integration anyway, the space between the solutions. As illustrated by Thomas Guest: WRONG http://www.johndcook.com/application.png http://www.johndcook.com/distorted-application.png RIGHT (Full articles: http://wordaligned.org/articles/distorted-software, http://www.johndcook.com/blog/2011/11/15/plumber-programmers/) It isn't GoldenHammer''''''s or SilverBullet''''''s we need. It's MagicWire''''''s, or maybe a broth or putty. And it is developing such where UniformityUberAlles can be a big win, and where small toy-examples can fail to demonstrate much advantage. The world-wide web isn't great because of individual pages, but because (at scale) everything gets connected together. There are many technologies of a similar nature. If you try to measure wires by the same metrics you measure hammers, you're an idiot. If ''every concept that you consider "good" is explainable with relatively small examples'', you have a lot to learn. ------------------ Re: ''How many times are you going to write the same loop over that recordset before you realize that's a generic pattern that should be encapsulated into a higher order function so you never have to write it again?'' I agree that things like closures can reduce loop coding. However, only about 15% of my code is loop setup. ''That's 14% too much'' You need to significantly help the other 85% to move from "good" to "great". ''What's your other 85%, do tell, we'll simplify it.'' Try ChallengeSixVersusFpDiscussion. ''That's not code, it's report writing. That barely requires more than SQL, show me some real code, some application code, crud stuff with business rules and workflow, not reporting.'' * Abandon all hope,ye who enter here. Top has never shown real code. I don't think he believes it exists outside a few dank caverns where RDBMSs are spawned. ** ''Yea, I know, but I still like trying to get something out of him, it's a sick hobby.'' ** Do I smell domain-egotism here? You guys are not exactly sources of "real code" either, at least not outside of systems software. I think you stick to systems software examples so that you can hide behind database execution speed complaints. What is meant by "real code" anyhow? Something from actual production? Challenge-6 is "runnable" (it executes). * Whatever you label it is as, can Lisp do it better, yes or no? '''If no, why not?''' The answer may reveal something. Although it may be not fully representative of any particular niche, data-driven applications tend to have a lot of SQL, for good or bad. And, just because it is a lot of SQL does not mean that all of it is. Can FP simplify the non-SQL parts, yes or no? If no, why not? If you have a better Grand Biz Example to show off Lisp, be my guest in presenting it. Why should I provide a larger example if you won't even bother with a small one? -- top Plus, Lisp is not the only language that can "roll your own loop controls". ''Never said it was'' Besides, many "traditional" loops can often be simplified if one works at it enough. ''One shouldn't have to work at it at all, it should be wrapped, given a name, and used as an abstraction'' * Once you grow used to any technique, you stop having to "work at it". There is a lot of wrapping one can do with functions alone that many never take advantage of. Just because the example in the book has bloated loop setups does not mean you have to copy it, but often people do. ---------------- GoldenHammer'''''s on wiki seem to be based on 3 different data structures as the root: Nested Lists: Lisp Interlinked Maps: OO Tables: T.O.P. ''Just to clarify in case there are misconceptions: Advocating Lisp does not imply advocating nested lists (sexprs) as the GoldenHammer of data structures. They're great for hierarchical data, but CommonLisp has a reasonable set of native data structures, for convenience and efficiency, including hashes, arrays, structs, and classes. A common complaint of Lispers is that many college Lisp courses are still taught as if all data were represented by lists. Even Scheme, with its minimalist orientation, has strings and vectors.'' * More importantly, Lisp itself has had strings and arrays almost since its inception (see e.g. Lisp 1.5 reference manual, available online as I cited I think on LispLanguage page). It has '''always''' been a misconception to think that Lisp supported only lists. I think this is one place where ComputerScience and SoftwareEngineering are easy to tell apart. Universities are not trying to teach you how to use a technology to quickly and easily implement programs. They are trying to teach you how and why the technology works. ''Ideally ComputerScience should actually distance itself from technology (products) and use theoretical pseudolanguages instead of specific on-the-market implementations of a language. The problem with technology and the consumer market, is that it is infected with crap and quackery. One does not need to teach a certain technology or product in order to teach good education about a concept. For imperative programming as an example: you could simply teach in a pseudolanguage that you made up yourself, teaching people about a list of things that happen in the program. Or consider relational: teaching kids SQL in school isn't a good idea, since SQL is a product/technology that has strayed away from relational model. Confusing students isn't a good thing, and products/technologies are often infected with confusing garbage or things that are simply wrong.'' How to use a HashTable in CommonLisp is not an important ComputerScience subject. How to create a HashTable given vectors or arrays ''is'' an important ComputerScience subject. In SoftwareEngineering, the situation is reversed. How to use a HashTable in the language you are working with at the moment is ''very'' important. How to implement a HashTable is completely unimportant if your environment provides one. ''That's not unusual, however. Any engineer should have a good understanding of the science underlying his discipline; even if he seldom employs it directly in practice. A civil engineer should have a good understanding of soil science and other relevant materials science, even though no civil engineer makes his own concrete or forges his own steel. A chemical engineer should have a good understanding of both chemistry and fluid dynamics, even though he won't manufacture pipes.'' Students should also have a good introduction to relational theory and techniques. Some schools skip that, and grads end up using arrays for everything because they don't know anything else. -- top ''Definitely agree; the RelationalModel is a fundamental part of ComputerScience, as is database theory (transaction semantics, etc.)'' Yup, they use arrays and lists and pointers to them, along with structs, when they could be using relational techniques. Problem is, no mainstream product or technology out there actually makes it easy to use relational techniques in our programs. How do you do relational stuff in CeeLanguage for example? Answer: you don't. You call some function like mysql_query() and then you have to work with ugly strings and convert the tables into arrays once you receive the resultset. You do iterative looping and use pointers and such low level garbage. In PredictTheFuture I suppose we should say something about languages of the future providing more relational abilities than our current languages. ----------------- '''One of the best litmus test is a realistic UseCase.''' If one cannot produce a scenario where their pet technique is clearly better (less code, less change-points), then generally I will write them off. * Virtually all of the things under discussion here have "realistic UseCase''''''s". The problem with GoldenHammer and UniformityUberAlles is that someone identifies a UseCase where technology ''X'' is superior; note that ''X'' can do other things adequately, and use that as justification for deployment of ''X'' everywhere (when there may be some ''Y'' that does other things better). It's a questionable argument when it's PaulGraham suggesting that CommonLisp ought to be the dominant language in enterprise software development, and it's a questionable argument when it's you, top, advocating TableOrientedProgramming as general replacement for OO. * ''I never claimed that TOP is best for all domains. In fact, I agree it may be largely subjective, beyond not being objectively worse. As far as Lisp for "enterprise" apps, that word is so overloaded that it has little meaning. DynamicLanguagesAndLargeApps.'' If you have a good excuse why you cannot produce scenarios, then I might be more forgiving. But generally this is how you catch bullshit artists and MentalMasturbation. Sorry Charley, but if you cannot cut it, then '''sayonara'''! It is like central Hollywood: everyone wants to be an actor, but they can't act. * Don't bring ActorsModel into this. :) And, don't give me crap about "not understanding your example". It is either less code and/or less change-points, or it is not. I don't have to understand it to fricken see code size. If your "killer example" is still 90% of my version, you are toast in my book. Give me 50% and maybe I will stay around. You claim "significant", you prove it! * If two competing technologies come in within 10% (which is statistical noise for such a comparison, unless a broad-based study is performed), I'd say they are equivalent (and thus neither should prevail). While you are certainly justified in saying "I'll do it my way" then, so is everybody else. * ''Some of the claims being tossed around do suggest much more than 10%.'' ----- As I see it, the problem is that without any external evicence produced by the current "thing", it is impossible to produce external evidence that the new thing is better. There is no baseline of current software development approaches to compare against, so evaluations must be done based on theory. ''Products and what people are using can act as external evidence, but it is also a TragedyOfTheCommons too. Just because millions of people are using SQL products, doesn't mean SQL is better than some other theoretical language which addresses SQL's problems. If the masses use something, that means there is massive evidence that something is extremely useful. It doesn't mean it is the best solution. OOP is used by the masses for GUI widgets so that people can reuse and inherit the widgets, and it seems that the masses do okay with these techniques. Is there a better way than OOP? possibly, but OOP works for the masses, and SQL works for the masses, so that is evidence for all of us right there that both OOP and databases are useful tools.'' There is indeed something to be said about achieving years of road-testing and being at least "good enough" to get the job done. There are many tools/projects that DON'T get the job done such that getting it done does stand out. However, that doesn't mean we should stop being critical of them and stop testing new ideas. Just don't experiment on critical projects. OOP has worked fairly well for GUI's and SQL RDBMS are a clear improvement over what came before. They are that old pair of shoes that allow you to walk normally and don't hurt your feet, even as they give you that nagging feeling that they are missing newer styles/ideas. ------------------------------------- See BlubParadox, BenefitsAreSubjective, ComparingParadigms, LanguageEvangelism, ObjectiveMeasuresOfEffectiveness, ExampleSizeIssues, IfFooIsSoGreatHowComeYouAreNotRich, GoodMetricsUseNumbers, ExtraordinaryClaimsRequireExtraordinaryEvidence, UniformityUberAlles ------ CategoryEvidence