Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blub Paradox (2014)

wiki.c2.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Blub Paradox (2014)

#51

Post by Jtsummers »

mcv wrote: post #46
kazinator wrote: post #37

Earlier quoted context omitted.

But, on the the bright side, that expression gives you a synopsis of all the syntax you will ever have to know. At least the principal organizing syntax for structuring the bulk of the code. What you don't see there are examples of various minor notations, like various kinds of literals and such. The good news is that parentheses disambiguate everything; if we remove some of them, we have to introduce hidden rules th…

This actually sounds far more imperative than I imagined Lisp to be. I thought it was mostly a functional language.

Common Lisp is a very pragmatic language, complete with goto, if you want it. This is for the purposes of efficiency rather than because you should use it yourself.

Suppose you wanted a really efficient numerical library written in Common Lisp, you could do it. But you wouldn't want to use map/reduce/remove/etc which are all linear time on the sequences they operate on (which can be lists or vectors). So clean looking code turns out to have poor performance because you have multiple O(n) operations, introducing large constants or if they're nested turns them into quadratic or worse operations. For instance, if we wanted to compute dot product we could, in CL, do:

  (defun dot-product (v1 v2)
    (reduce #'+ (mapcar #'* v1 v2)))
That's O(n) which is the "best" we can do for dot product. But it actually contains two iterations. In C, you'd have:

  double dotproduct = 0.0;
  for(int i = 0; i
While for this small example the difference in performance is minor, in the case of a library making many calls to these functions that double loop would add up. And for more complex operations you're introducing higher constants (or worse) by using the clean looking Common Lisp code.

Enter something like Series

Series: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html

See here for a demo of how it tranforms functional code to imperative: https://malisper.me/loops-in-lisp-part-4-series/

So you still (as the user) get the illusion of working in a functional language, but under-the-hood it happily transforms itself to an imperative form. And if you wanted to make something like Series, you could present that functional form to your users and hide the imperative, optimized form.

Main takeaway: Common Lisp has high-level functional aspects, OO aspects, but also low-level systems-oriented and imperative aspects. You get to pick and choose which level you want to operate on based on your domain. And with the macro language you can present clean, functional interfaces to the end-user while using the lower-level features to optimize things for them.

Re: Blub Paradox (2014)

#52

Post by marcosdumay »

zeveb wrote: post #48
ainar-g wrote: post #5

Earlier quoted context omitted.

I agree and will also add that pg seems to have missed some other ingredients of a language's power, especially libraries and tools. Python and Ruby (and Perl before them) got big not just as “easy” languages, but as languages that get the job done quickly thanks to the massive amount of libraries. And while Java, C, and C++ may not be the most elegant of languages, the amount of tools to inspect the code, find bugs,…

Libraries & tools are not aspects of a language's power, but rather of an ecosystem's. A language can make it easier or harder to write libraries & tools, but libraries, properly speaking, postdate the language itself.

There is a large correlation between some language and ecosystem features, so you can not separate them that easily.

Re: Blub Paradox (2014)

#53

Post by rspeele »

jhbadger wrote: post #49
rspeele wrote: post #45

Earlier quoted context omitted.

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."…

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.

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 (not (is-blocked door))
         (
as readable as:

    not is_blocked(door)
    and height(player)
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 ) 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).

Re: Blub Paradox (2014)

#54

Post by SketchySeaBeast »

protomyth wrote: post #44
SketchySeaBeast wrote: post #31

Earlier quoted context omitted.

> If iOS had required Lisp instead of Objective-C, then Lisp would have been popular right now. Probably. I wonder if we wouldn't have ended up with more Xamarins instead.

Maybe, but one shouldn't discount the amount of documentation that Apple pushes. Look at Objective-C programmers in the age of Swift. Its rather hard to be on the outside of the preferred language.

Well, I think that's largely due to the ability to use cute emojis as variable names.

Re: Blub Paradox (2014)

#55

Post by kazinator »

rspeele wrote: post #53
jhbadger wrote: post #49

Earlier quoted context omitted.

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.

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 (not (is-blocked door)) ( as readable as: not is_blocked(door) and height(player) Edit: to expand, I don't think it's a fundamental flaw of Lisp. There could easily be some syntax sugar t…

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)
           :--
The other one looks like a bit of a lorem ipsum paragraph to me.

Re: Blub Paradox (2014)

#56

Post by rspeele »

kazinator wrote: post #55
rspeele wrote: post #53

Earlier quoted context omitted.

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 (not (is-blocked door)) ( as readable as: not is_blocked(door) and height(player) Edit: to expand, I don't think it's a fundamental flaw of Lisp. There could easily be some syntax sugar t…

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) :-- The other one looks like a bit of a lorem ipsum paragraph to me.

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 It reeks of effort so I'm not going to make such a site, but I do wonder what the results would be.

Re: Blub Paradox (2014)

#57

Post by fulafel »

protomyth wrote: post #8

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.

I think a more believeable alternative history would have been Dylan, which Apple already created for the Newton and which was a Lisp under a more traditional syntax layer.

Re: Blub Paradox (2014)

#58

Post by bjourne »

Jtsummers wrote: post #47
zzzcpan wrote: post #39

Earlier quoted context omitted.

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.

http://norvig.com/java-lisp.html Start there, some more links from there to details on the study and follow-ups.

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 and that study is flawed due to the self-selection of test subjects. Given 50 years of http://wiki.c2.com/?SmugLispWeenie the amount of empirical results is very low.

Re: Blub Paradox (2014)

#59

Post by mcv »

jhbadger wrote: post #49
rspeele wrote: post #45

Earlier quoted context omitted.

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."…

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.

That may be fine for ancient Jews and Arabs, but it still presents a bit of an obstacle to speakers of Germanic languages, including English. With the exception of Yoda, I suppose. I bet Lisp would be totally natural to him.

Re: Blub Paradox (2014)

#60

Post by lmm »

m00natic wrote: post #40
lmm wrote: post #25

Earlier quoted context omitted.

Lisp isn't really a language so much as a language construction toolkit, because macros are like language features (e.g. any macro you're using needs dedicated support from any tools that you want to use on your codebase). Effective lisp organizations will generally use a small handful of general-purpose macros throughout their codebases - but at that point you might as well standardise that handful of macros as a la…

Static languages are still complete blubs compared to lisps as far as practical metaprogramming goes. And Common Lisp's type system is much less of a blub in that regard.

> Static languages are still complete blubs compared to lisps as far as practical metaprogramming goes.

Not convinced; many modern statically-typed languages offer macros or equivalents (and also offer alternative ways to achieve most or all of the headline use cases). Metaprogramming in those languages is substantially more code-level work than in lisp, certainly, but even lisp users tend to treat macros as something expensive (because even though custom macros are cheap in terms of code cost, they're expensive in terms of reader (and tool) comprehension): the standard advice is not to write a macro unless there is no alternative, and using lots of specific custom macros in each code area is regarded as poor style. So in practice developers in modern static languages use macros in much the same way as lisp users.

> And Common Lisp's type system is much less of a blub in that regard.

Disagree; if you don't have types that are reliably accurate and enforced at compile-time then you gain very few of the advantages, counterintuitive as it is.

Post reply on HN