Blub Paradox
Blub ParadoxAn idea developed in an article BeatingTheAverages by PaulGraham (http://paulgraham.com/avg.html). He argues that some languages are more powerful than others and posits a hypothetical middle of the road language called Blub. He describes the gist of the paradox thus:
See KeyLanguageFeatures for examples of useful features oft subject to the BlubParadox.
I have been accused of being one those. I have asked to see some EmpiricalEvidence to back claims that some of those items "significantly reduce code size". See ChallengeSixVersusFpDiscussion for an example. I agree that some of those may reduce code size by few percentage points, but that is not enough to justify a switch. I want to see significant improvements. I suspect their value is being overhyped by those who mistake MentalMasturbation for productivity. I would rather spend MentalMasturbation on CollectionOrientedProgramming languages.
BlubParadox says that you won't see the improvements as 'significant' even if they are.
A few problems with the BlubParadox:
Of greatest interest are largely domain-independent features that cannot readily be implemented in another language without 'writing an interpreter' or performing the GreenspunsTenthRuleOfProgramming-style informally specified, buggy, slow, 80% solution (leaving 'Lisp' out of it). With sufficient DuctTape, string, and bailing wire; any feature in one reasonable language can be duplicated any any other reasonable language. It may be ugly, full of violations of OnceAndOnlyOnce, and impossible to maintain, but it can be done. And for this argument, for BlubParadox and these 'KeyLanguageFeatures', it really wouldn't count.
The article makes no claim that languages are totally ordered, merely that there is at least a partial order. C++ and Scheme are examples of (near) parity, in Graham's terms, anyway because of C++ templates and Scheme macros doing nearly the same things (albeit different ways and at different times). Now try comparing Scheme, or C++, with Fortran 77.
To expand the Scheme/C++ comparison; let's split C++ into two versions - ANSI C++, and "C++ 2.0", a very early, pre-AnnotatedReferenceManual? dialect of C++ which excludes both templates and exception handling. Clearly, ANSI C++ > pre-ARM C++. (Graham himself compares Perl 4 and Perl 5; so comparing two different versions of the same language is fair). One can fake templates with macros (but it's horrible); one can fake exceptions with setjmp/longjmp (but that's nasty). Yet, no ordering relationship (< or >) can be established between either C++ dialect and Scheme. Both have OO as a core part of the language, neither have lazy evaluation.
And of course, there is the question of what lies at the top. Graham claims it's LispLanguage (and I assume CommonLisp; other Lisp dialects like Scheme lack key things found in other languages). CommonLisp is likely close to the top; and perhaps even shares the top spot with a couple of other languages. I do find the suggestion that for any computer language X, X <= CommonLisp, to be severely lacking in proof. I haven't seen any language X for which X > CommonLisp is clearly true; but I think more than a few which can claim incomparability (in the technical sense of neither greater nor lesser in the PartialOrder). And I know lots of SmugSmalltalkWeenies who would agree with me on this one.
If only Lisp was powerful enough to redefine its syntax and notation to be like infix or Algol languages so I wouldn't have to use Lisp when I need formal Algol style syntax. I guess Lisp just isn't powerful enough. Darn.
So isn't this what ReaderMacro?s are supposed to be for? They allow you to embed other syntaxes within Lisp code by calling a different parser. You could probably even remake Lisp into Algol if you wanted to, but why? Are you just LostInaSeaofParentheses? -- SmugLispWeenie
You might also want to look at SweetExpressions, an effort to add a form of infix compatible with macros (trying to add precedence really makes a mess of things), calling functions as f(x) rather than (f x), providing syntax for arrays of all types (saying *hash*["this"] instead of (gethash *hash* "this"), and providing significant whitespace--and doing all this, in a way compatible with the original s-expression syntax. For most languages, such an effort is impossible--for Lisp languages, like Common Lisp and Scheme, most SmugLispWeenies will merely complain that this effort is very misguided, and a horrible waste of time!
(For the record, I have tried to implement some of these things. Infix notation for Common Lisp is done; I think f(x) notation is done, but I may be wrong; array notation hasn't been done, but I have some ideas on how to do it; I've done *some* work on parsing whitespace, but I don't know how to plug it into Common Lisp's reader for experimentation--the documenation on this is just arcane enough, I haven't been able to figure it out.)
Oh, and if you haven't checked it out already, look at Lisp's LOOP macro. One common complaint about it, is that it's too "Algolish", and not really "Lispy".
So, to answer your question: Lisp *really is* that powerful. --Alpheus
Besides, Racket has a full ALGOL 60 implementation done completely using reader macros. So, yeah, you can have literally Algol style syntax. But why would you use it? --Denommus
Experienced programmers carry quite a number of patterns around in their heads. They may have learned these patterns from books or by hard won experience. The patterns enable a fluid style of programming where attention can be maintained on the unknown parts of the task at hand and work feels productive. Programmers tend to like programming languages that have good support for the patterns they use. Programmers don't like languages that disallow or inconvenience the patterns they use. They are also rarely impressed by language features that support patterns they don't know or use. This much holds whether languages can be ordered or not.
PaulGraham likes the patterns he has now and considers them better than those he sees employed by others. Paul also writes eloquently about his patterns (though he may not use pattern terminology). Thankfully, he avoids many of the affectations that remind us WhyWeHateLisp. Still, I find it far easier to read what Paul writes when I remind myself that there are very fine patterns that he doesn't have or use, and that those patterns will often lead programmers to make language choices unlike his. -- WardCunningham
Ward, I'm curious what "the fine patterns that he doesn't have or use" are? I'm assuming you don't happen to know Mr. Graham personally and that you are working backwards from his language choice (Lisp) to some patterns that he must not have or use since they are ill-supported by Lisp. As a Lisp programmer I'm curious what I'm missing. (Though I'm not really "a Lisp programmer" - I'm a programmer who knows and likes Lisp, among other languages.) -- PeterSeibel
OO is one. There's a discussion in the LL1 archives where he's criticized for "not having done his homework" when deciding not to include objects in Arc. And while he's right in that LexicalClosures provide all the power of C++/Java-style OO with less bloat, he's completely overlooked the more powerful GenericFunction-style OO. BlubParadox applies to programmers as well as languages: if someone makes up their mind that "OO is nothing new under the sun", then they'll look at anything labeled as "OO" as strange and unnecessary without bothering to think of how it can make their job easier. -- JonathanTang
Well, PaulGraham has a very (very) low opinion of OO, mostly because he does a lot of stuff that most people haven't been able to do, and he says he almost never "resorts" to it. However, more recent posts on LL1 suggest PaulGraham is coming around. He's starting to be less derogatory to OO (and seems to have done a 180 on continuations). No one, not even PaulGraham himself, ever said that PaulGraham was immune to the BlubParadox. ;)
Not that I think it matters. If PaulGraham doesn't put OO directly into Arc, then someone else will make a solution like CLOS and that'll be the end of it. :) -- DaveFayram
While I get the gist of the story, I don't get the paradox bit. Where's the paradox in someone seeing something but not seeing something else? -- ClaesWallin
Could it be that one is able to conceive of things of lesser feature/function from where one is, but is unable to conceive of what the greater feature/function might be?
I am reminded of FlatLand, an imaginary space of only two dimensions inhabited by beings that can easily recognize one dimension and two, but can't grasp what a third dimension might be -- can't conceive of "up" -- and when one of their number finds himself "above" the plane, he finds once he returns that it's nearly impossible to explain "up" to the other inhabitants -- they just can't imagine it. -- GarryHamilton
[Us mere mortals not well-versed in modern physics research have similar difficulty groking the additional spatial dimensions that supposedly exist...]
Can some computational psychometrician somewhere use a programming test or a PET-scan to tell us what patterns and understandings we each lack individually? That's got to be the goal for personal improvement. I plowed through a lot of the early Patterns literature only to discover I knew a lot and didn't care for the rest. Joel Spolsky writes that some people never 'Get' C pointers-and-arrays. I'd like to know where my blindness and ignorance is concentrated so I can punch my way out of the paper bag of development (and out of Brooks Law). And where are the proofs that one set of patterns produces more reliable software than the others? -- Warren Seltzer
This doesnt make it a paradox though, there is no apparent contradiction. There is nothing to suggest that looking in both directions should be equal in this case, in fact quite the opposite as you are comparing knowledge of thing you understand to knowledge of things you don't (yet). surely this is similar to knowing the past but not the future, which doesnt appear to be a paradox. it is an interesting observation though. -- JamesKeogh
I think it's fair to say that, just as "Greenspun's Tenth Rule" has no preceding rules, but is just a catchy name, the "Blub Paradox" is a catchy name as well. If there's any paradox involved, it would be this: that a programmer can appreciate power, but unless they understands that power, they're not always going to appreciate it. I remember the first time I encountered C++, and was blown away by the idea of putting things into "if" and "while" blocks, as well as having libraries for I/O rather than a "PRINT" statement--having come from BASIC as my first language. Sometimes it's easy to see when a feature will give you power; sometimes, it's not, until you've done a thing or few with that feature. --Alpheus.
Isn't this the same problem as trying to adopt to a ParadigmShift? People are comfortable with the familiar, others come along and say "here is a better way" but to the person who needs "converting", the new way may seem like a lot of work, on the fringe and actually below his/her current position/process/tools though the proponents of the new (or different) paradigm would claim it is higher.
PaulGraham has the same problem. He never had to face a real business application beyond his E-stores. Thus, he does not have enough experience to know the power of relational databases, which he generally rejects. (I exchanged personal emails with him on this topic.) See WebStoresDiscussion. He extrapolates the experience with one application to assume that EssExpressions can replace a RDBMS. Since we all only live one life, perhaps we are just blinded in different areas. -- top
[Of course, you're also making a false assumption that a database would have been better in that scenario. Paul's a smart guy, and made a fortune off that program, I'm sure he had very good reasons for doing what he did, the way he did it. The entire application was non traditional, that's what made it so cool, and that's what made it work.]
Possibly. I was in fact startled by his attitude, but on the other hand, at least for his particular application, his choice was quite defensible. That's different from rejecting RDBMS altogether, of course, but there are extremists on every topic. Obviously most people believe that relational databases are important for some purposes. Perhaps his secret was finding a niche where his shortcuts could be leveraged.
Some of his works suggest that he has rejected them altogether, although I have never seen a formal rejection from him. But I do agree that for his e-stores project, his approach was an acceptable choice.
Actually, Yahoo! for quite a while, used FlatFiles? itself (PowerOfPlainText in action?). I think a lot more things are understandable when you look at Yahoo! more closely, like when they were trying to rewrite Paul's E-stores. I strongly suspect they were trying to rewrite everything into their target languages, not just E-stores.
I can see how they make sense for lots of small store-lets or portal-lets where Bob's store or portal is not going to interact much with Lisa's store/portal, etc. However, this does not extrapolate into the kinds of apps I see to run a medium-sized or large organization. As described in WebStoresDiscussion, there is not the strong "isolation points" you find in many web gizmos. It is still my opinion that PaulGraham is a bit naive on a wider view of what apps need in the real world when data MUST inter-relate. Or, perhaps he's suggesting that people find areas where they can leverage flat-file short-cuts. At this point, I cannot tell without asking again. He generally rejects OOP, by the way, so if he is a God of Programming, then you cannot pick and choose which doctrines of his you follow. --top
RE: "if he is a God of Programming, then you cannot pick and choose which doctrines of his you follow" -- top
{That seems an irrational sentiment. Even supposing one considered PaulGraham a "God of Programming" (and nobody above is declaring such), in any culture (polytheist or otherwise) one still gets to pick and choose which doctrines to follow.}
Yes, but that opens you up to accusations of cherry-picking evidence. If you like FP and OOP, and Graham dislikes OOP, using his millionare status gained via FP is going hit a sour note because one can use the same anecdote to deflate OOP.
[Paradigms aren't doctrines, or they shouldn't be. They're tools. Replace "[h]e generally rejects OOP [in favour of FP], by the way, so if he is a God of Programming, then you cannot pick and choose which doctrines of his you follow" with "[h]e generally rejects screwdrivers [in favour of hammers], by the way, so if he is a God of Auto Mechanics, then you cannot pick and choose which doctrines of his you follow" to see how ridiculous this sounds.]
I reject that analogy because screwdrivers and hammers tend to be orthogonal in what they are used for. Paradigms are generally not. Chevy's versus Ford's may be more appropriate.
{Well, hammers and screwdrivers do tend to be "orthogonal to what they're used for" (i.e. you put nail orthogonal to board, hammer it in; you place screw orthogonal to board, screw it in) but I think you're equivocating here. Nails and screws are both used for attaching object A to object B via a metal rod. Hammers and screwdrivers are both used to motivate said metal rod into place. As with paradigms, you can make various claims on each of them regarding ease-of-use, energy requirements, and the general rigidity and stability of the final structure. HammerNailAficionados will note that they can simply put in a few extra nails and still get the job done faster. SrewdriverWeenies can fight back, claiming that their tool has less risk of damaging the material... or your thumb. And perhaps they'll note the existence of the automatic screwdriver, claiming that it's as fast as any hammer. HammerNailAficionados will laugh and refer to the nailgun. The SrewdriverWeenies can look appalled, claiming (rightfully) that you really can blow your foot off with that thing. And, if these people get really passionate about it, they can start a HolyWar. (And, into this war can walk the fans of permanent adhesives... the 'new' paradigm for attaching object A to object B about which nobody hears or thinks but that has been working silently and efficiently for many decades, and who now have glues stronger than most welds.)}
{Still think it a bad analogy?}
Yes. Productivity and strength of results can be measured between screws and nails.
{Are you attempting to imply that defect-rates and production speeds can't be similarly measured between paradigms?}
No. They probably can, but I would suggest that such would not be very effective metrics unless we understood why something makes people more productive. Otherwise, one could claim, "but only dumb people use paradigm X to begin with". VisualBasic fights, for example, often led to this kind of issue. Is lots of bad VB code out there due to it not having powerful enough language idioms, or merely that it is one of the first languages that newbies encounter on the job, and is thus "polluted" by newbies? --top
{So you're claiming that metrics of productivity and strength aren't effective unless we understand why they make people more productive? Hmmm. Well, I'm fairly certain that people could provide theories as to why screws or nails are better at productivity or strength, and I'm quite certain that people would do the same for paradigms. And we ARE talking about paradigms, here, not production development environments (e.g. Visual Dot Net vs. EclipseIDE) or particular languages (VisualBasic vs. BrainfuckLanguage). Aren't we?}
I am saying that it is difficult to factor out other issues with such studies without careful control groups, etc. And, its not realistic to expect that on C2. Instead, we should strive for code-to-code comparisons along with mental and physical steps needed to make changes, etc. As far as paradigms versus languages, I do not wish to commit to a hard distinction of categories for language features, I'm not sure there is one. Closures and OOP are features just like nested functions, types, Eval(string), etc.
The bottom line for this topic is that PaulGraham is being like you: lots of claims of superiority of tool with very little inspectable code evidence from real-world-like projects. I label that as elitism. Truly smart people can show, not just talk. Paul is not following HowToSellGoldenHammers.
{Why would you want a golden hammer when you can have a silver screwdriver? ;-) I agree that the focus should be on features, but I'd also note that it is combinations of features that are most relevant, and it is these feature-packages, or 'ways' of writing code, that are most closely associated with the looser understanding of 'paradigm'. No single feature ever solves all the problems. Closures, in a vacuum, have nothing over which to 'close'.}
{And PaulGraham aside, the BlubParadox should stand on its own merits. Judge the idea. Judge the messenger too, if you like, but don't confuse the two judgements.}
If you agree that ParadigmPotpourriMeansDiminishingReturns, then each additional paradigm/idiom creates potential problems.
{That was oddly worded, and I can't agree with it as stated. Reinterpreting the above to a more reasonable: "If you agree that ParadigmPotpourriMeansDiminishingReturns, then [you agree that] each additional paradigm/idiom creates potential problems" - I'll need to disagree with that, too. Creations of problems is different from reduction in returns, so an agreement that returns diminish does not mean agreement that problems are created.}
Agree - the first thing I did when I started reading about how Lisp was so powerful (several years go) - was download some source code from PaulGraham. Unfortunately, my attempt failed. I thought maybe he had to offer some tricks in Lisp that I could see in action.. and some inline source snippets of his web store, and maybe even a web framework from him. After all, we'd like to truly see Lisp in practice by the GoldenHammer owner - just like those late night As Seen On Tv commercials. Maybe even a flash video proving PaulGraham can code the way he does.
One thing we have to consider, is that maybe PaulGraham is not a hero at all. He's just some person who wrote a web store (TheBoyNextDoor). If you think about it - a web store is just a program that totals up t-shirt prices with pants prices. It isn't the most complicated application in the world. He acts, talks, and writes as if he (and Lisp) is some huge hero who has saved the world. Did we need macros, to redefine our shopping carts at run time in order to satisfy our customer who needs a run time definable shopping cart (a customer checking out and using add to cart button, these really should be macros, folks - and a custom Lisp shopping cart language could be handy).
Really, all he did, was write a trivial (but interesting) web store - which probably got torn apart by C++ programmers and put into a typical database application later.
Possible ArgumentByLabToy.
Yeah, right, this reminds me of Linus. He may also be yet another boy next door, who happens to write Linux, thus claims it to be the best OS out there. In the end of the day, you can always use Windows for everything, and Windows will just be as fast, as secure, as insert-in-the-blank. See, Microsoft even publishes papers to prove that.
Give me 100-million dollars and web-celebrity recognition, and then see what I could cook up with my spare time and fame.
[Given what you've produced so far, probably nothing. Productive people are productive without money or celebrity. Indeed, their money and celebrity are usually a result of productivity rather than causes of it.]
Projection. Where's your 100-million? Is this turning into a resume pissing contest?
[I used mine to buy that narcotics addiction I'd always wanted.]
So that's how the GodLanguage idea came about ;-P
[Blub, blub, blub.]
TitanicLanguage? hit an iceberg.
In the book "Founders at Work", Paul attributes much of the success of his store system to both luck (timing) and fancy graphics. He said he found a good web graphics expert that knew how to make good but small graphics, including their own logos & buttons, and customer product images. Not much was said about programming language.
Code Size and Demonstrations
Somewhere on Paul's website (I couldn't re-find it), he stated that the primary advantage of Lisp was brevity: more can be done with less code. He didn't talk about some lofty mathematical elegancy or purity, but pretty much code size. If that's the case, then demonstrating how great Lisp allegedly is, is mostly a matter of demonstrating how it can do the same job with less code. I don't necessarily agree code size (such as LinesOfCode) as a primary metric, but am merely pointing out that demonstrating its benefits according to Paul's description should be straightforward and is NOT a matter of YouJustDontGetIt, as some imply. In other words, show how Lisp can do more (realistic) stuff with less code. -t
I'm just repeating what I read. If you are questioning my interpretation, I'll try harder to find it. My point is that using the stated metric, a demonstration would be rather simple and wouldn't require deep Lisp knowledge. And I'm not even attacking Lisp here. I'm a "conceptual admirer" of Lisp.
Here are some of his articles that reference code size, although they are probably not the same one I remember:
I'm not questioning your interpretation. PaulGraham may well have written it, and he may well believe LOC is a sound rationale for using LISP -- I suppose some example can almost always be found to show language <x> takes fewer lines to do <p> than language <y> -- but I seriously doubt that's why he chose LISP in the first place. LISP programmers choose LISP for the same reason that Smalltalk programmers choose Smalltalk -- all post-hoc rationale aside, programming in these languages simply feels good. They turn coding into something akin to sex.
That may be, but it's not very objective. It doesn't tell us how to distinguish MentalMasturbation from practical productivity and quality improvements. Succinct CollectionOrientedProgramming that can be easily intermixed with imperative "adjustments" without large DiscontinuitySpike penalties for doing such may "feel good" to me, but that by itself is not very convincing. (By the way, Paul doesn't use "lines" so much, but talks about "language elements".) -top
You're right, it's not very objective. So?
Paul implies it is mostly objective. But since he's not here, I cannot ask him why he doesn't create size demos to evangelize Lisp.
I cannot see the value of GarbageCollection (however I'm used to rely on reference counting and automatic destruction for in-core objects). What is wrong with me, or what kind of experience am I lacking? --DexenDeVries
Reference counting GC is still one of two canonical forms of GC (the other being tracing GC; most automatic GC is a hybrid of the two). The primary objection to naive forms of reference counting is high expense for tracking short-lived references (e.g. references on the stack) and limitations for collecting cycles. For manual reference counting, mistakes aren't uncommon. Good programs can be written without GC, but it becomes very difficult to determine when to destroy objects once you start using features such as callback frameworks, plugins, concurrency. Library based smart pointers have a difficult time working across independently developed libraries or frameworks.
See Also: KeyLanguageFeatures, SymmetryOfLanguage, ExpressivePower, HowToSellGoldenHammers, PaulGraham, UnconsciousIncompetence, SocialProblemsOfLisp, GreatLispWar, IfFooIsSoGreatHowComeYouAreNotRich
CategorySkill?
EditText of this page
(last edited November 16, 2014)
or FindPage with title or text search