
Blub Paradox (2014) - tosh
http://wiki.c2.com/?BlubParadox
======
nestorD
This article discusses the Blub Paradox essay and some of its shortcomings.

The original essay is one of the few texts that stuck with me. I read it not
as an affirmation that some languages are strictly superior to others (in
particular lisp) but as a push to try new paradigms and ideas even if I cannot
see, from my current point of view, how they could improve on my current
practice. It is one of the reasons that had me trying Rust this year.

------
protomyth
If iOS had required Lisp instead of Objective-C, then Lisp would have been
popular right now. Ruby really needed Rails to get people to try it.

I think the killer use problem is more an explanation then anything else. Java
also showed a good marketing, well funded campaign does wonders.

~~~
zzzcpan
> If iOS had required Lisp instead of Objective-C, then Lisp would have been
> popular right now.

It could have dragged iOS popularity with it.

Pushing, promoting or forcing something is not enough for it to become popular
and widely used.

~~~
protomyth
Given the hype and the company, there was no way Lisp would have drug it down.
The only way for it to affect iOS was to provide a worse environment than the
web apps. People would have found a way just as the reluctant found a way with
Objective-C.

Ask Sun about Java and their promotional campaign. When a teacher at a
community college in North Dakota gets a call and sent a book to help him
decide to teach their language, you can be very effective at pushing.

~~~
zimpenfish
> People would have found a way just as the reluctant found a way with
> Objective-C

But the people most likely to develop iOS apps at the start were likely
already familiar with Objective-C, I think, due to it being the favoured app
platform on OSX, no?

~~~
protomyth
I would have thought the same thing, but if you look at a lot of the early app
developers, they did come from other platforms. It was easier for an OS X
developer, but there were a lot of new people who complained about Objective-C
but just got on with it. A lot of early tutorials are really geared to the
bigger group of new developers.

On a side note, I really do believe the people behind Swift hate Objective-C
and a lot of the old complaints are "solved" by Swift.

------
lisper
> 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

This one sentence to me is an indication that the author has completely missed
the point. Templates and macros do the "same thing" only in the sense that all
languages do the "same thing" at some level of abstraction, that is, model
Turing machines. What matters is not what languages "do" when they are
compiled, but in how they bridge the "impedance mismatch" between TM's and
human brains. And in that regard, templates and macros are about as different
as two language constructs can possibly be.

------
AnimalMuppet
I really hate these wiki-articles. (Not Wikipedia, articles like this one.)
The conversational back-and-forth gets confusing when it goes for a while. And
the article goes on long wandering digressions that make it hard to see any
actual points that the article had.

If you want to actually say something, _don 't do it like this_.

------
adontz
Is this some kind of Dunning-Kruger effect?

Anyway, I don't think it's right mental picture, and thus context for paradox.
Language power, I believe, cannot be defined with one dimension. What is more
powerful, Java or SQL? Will SQL benefit from encapsulation or will Java
benefit from window functions?

~~~
nestorD
The linked article is not the original Blub paradox essay and does highlight
this problem (the first element in the "A few problems with the BlubParadox"
list).

------
sandyhatches
The general concept becomes much more interesting when applied to spoken
languages.

------
bjourne
Isn't anyone but me annoyed by the lack of scientific rigor in arguments like
these?

PG: - It is more efficient to write software in Lisp. Others: - Nah, it
doesn't matter.

But no empirical evidence has ever been presented...

~~~
zzzcpan
There is some empirical evidence. I can't find it now but I've seen research
showing Lisp beating all languages in terms of speed of creating some programs
from scratch by both experienced Lisp developers and students new to the
language. Obviously no research for large projects, those can only be
researched through things like github data, etc.

~~~
Jtsummers
[http://norvig.com/java-lisp.html](http://norvig.com/java-lisp.html)

Start there, some more links from there to details on the study and follow-
ups.

~~~
bjourne
Thanks for the links! Of those, the only one I can find dealing with
development speed in Lisp vs other languages is
[http://www.flownet.com/gat/papers/lisp-
java.pdf](http://www.flownet.com/gat/papers/lisp-java.pdf) and that study is
flawed due to the self-selection of test subjects. Given 50 years of
[http://wiki.c2.com/?SmugLispWeenie](http://wiki.c2.com/?SmugLispWeenie) the
amount of empirical results is very low.

~~~
bmn__
Ulrich Stärk's empirical research (no Lisp):

[https://web.archive.org/web/2017/https://www.plat-
forms.org/](https://web.archive.org/web/2017/https://www.plat-forms.org/)

It is hard enough to get study participants for the common programming
languages, I deem it nigh impossible for the obscure ones.

------
teekert
It's like... When the aliens in "Arrival" (or Ted Chiang's story of your life)
speak Python but you only speak R. Different languages make you think
differently.

------
tim333
It's kind of interesting in the 2001 essay that invented blub it was suggested
as a hypothesis as to

>And if Lisp is so great, why doesn't everyone use it?

Suggesting programmers in a blub language don't realise it's power. I get the
impression in the 18 or so years subsequently that the main reason for the low
uptake of Lisp is it's power enables people to write clever code that other
programmers have quite a job to understand while languages like Python let you
do much the same stuff while being easier to read.

So it's not that people don't realise the power so much as they don't want it.

~~~
mcv
I'd love to know Lisp, just like I'd love to know Python. I have no experience
in either (I come mostly from Java, javascript with some Ruby and some ancient
C/C++ experience). When I look at Python code, I understand what it does. I
don't think I've ever written any Python, but I think I could sit down and be
productive within a day.

Lisp looks like complete gobbledygook to me. I'd love to be able to understand
it and write it, but the syntax doesn't look like it's meant to be human
readable. It's almost as much work as reading assembly.

I should probably give it another try, though.

~~~
jhbadger
But that's because all the languages you know are basically dialects of each
other because they all descend from ALGOL, not because they are inherently
easier to understand. Similarly, someone trained in Lisp would find things
like Scheme and Clojure easier to understand than something like Python
because those likewise are dialects of Lisp. I'd strongly recommend studying
languages different from ones you know -- they are mind expanding even if you
never use them in practice. Not just Lisp, but things like Haskell, OCAML/F#,
and Prolog will change the way you think.

~~~
wycy
> not because they are inherently easier to understand

I'm honestly not sure that that's true. I would bet money that someone who
primarily works in Lisp would still have an easier time sitting down and
reading Python code than someone who works in Python sitting down and reading
Lisp, because I think it might truly be inherently easier to understand.

There is intrinsic meaning in:

    
    
        x = 5
        let x = 5
    

etc., insofar as these translate character for character, word for word, into
human language, whereas this simply doesn't:

    
    
        (let (x 5))

~~~
kazinator
There is no such thing as "intrinsic meaning", and I think you might be
confusing "human language" and "english-like". There is astonishing variation
in human language.

~~~
rspeele
I really like Lisp and its macros and I don't even mind the sea of
parentheses. But I do think requiring everything to be done in prefix notation
is a weakness. This is an argument I have seen -- it may not be the one you
are trying to make, but your statement reminded me of it:

"No programming language is more or less natural than Lisp. It is merely a
matter of familiarity and the way most programmers were taught."

One obvious problem is that familiarity does matter. Even ignoring all other
programming languages, there is a barrier to climb for the vast numbers of
beginner programmers who know English and common math notation like f(x)
instead of (f x) and x < y instead of (< x y). I've also seen (- x y) be
confusing as one incorrect way to read it as English in your head is "subtract
x from y".

The other is that for some things, it really does seem like infix notation is
inherently preferred by humans. Is there a natural language where conjunctions
_don 't_ go between terms, i.e. one says "und x y z" instead of "x und y und
z"?

~~~
jhbadger
Functions are more like verbs than conjugations. And Verb Subject Object
(which is rather lisp-like) is not uncommon among natural languages. Arabic
and Biblical Hebrew (Modern Hebrew not so much due to influence from Western
languages) use that order a lot.

~~~
rspeele
That's just fine for things that are function calls in any language. I have no
preference between log(x, 10) or (log x 10).

But I do want to read some functions like conjunctions, and in Lisp, I am
forced to call `and`, `or`, `<`, `/`, and pals the same way as log, print,
etc. I just don't think I'll ever find:

    
    
        (and (not (is-blocked door))
             (< (height player) (height door))
             (or (is-unlocked door)
                 (has-key player door)))
    

as readable as:

    
    
        not is_blocked(door)
        and height(player) < height(door)
        and (is_unlocked(door) or has_key(player, door))
    

Edit: to expand, I don't think it's a fundamental flaw of Lisp. There could
easily be some syntax sugar that lets you specify precedence rules for
functions and write them infix, just like Haskell lets you write either `(+) 1
2` or `1 + 2`. It would de-sugar to the same sexpr.

I know this can be done as a macro, in fact I did it for elisp several years
ago (
[https://github.com/rspeele/infix.el](https://github.com/rspeele/infix.el) )
but it is really just a toy for personal use. If an infix operator system came
out of the box and its use was encouraged for certain common operators, I
think that would be a net positive, but most Lispers disagree with me there
(if I had to guess).

~~~
kazinator
The Lisp expression is a nice sideways tree, where we immediately see that
three conditions are joined by _and_. When I look at it, I see this:

    
    
         and --.-- not (is-blocked door)
               :-- < (height player) (height door)
               `-- or --.---(is-unlocked door)
                         `--(has-key player door)
    

The other one looks like a bit of a _lorem ipsum_ paragraph to me.

~~~
rspeele
I guess it comes down to different strokes for different folks. It would be
interesting if there was a website that quizzed you on randomly generated
expressions like these, giving you S-expr forms sometimes and ALGOL/infix
operator forms other times, and asking you whether the expression is true or
false given a set of variable values.

Naively I would guess that I would do best on infix exprs and you would do
best on s-exprs.

But I could imagine other results, like s-exprs giving me a speed disadvantage
but an accuracy advantage (either because I had to read them more carefully or
because they eliminate reliance on precedence rules). Or there may be other
quirks, like maybe S-exprs read better for larger, multiline conditions while
infix reads better on short one-liners with <= 3 operations.

It reeks of effort so I'm not going to make such a site, but I do wonder what
the results would be.

