Blub Paradox (2014) • Hacker News Board

Re: Blub Paradox (2014)

#61

Post by m00natic » Wed, Jan 09, 2019, 2:31 PM UTC

lmm wrote: post #60

m00natic wrote: post #40

Earlier quoted context omitted.

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 somethin…

I'm yet to see a "modern" (statically-typed) language with random syntax whose macro-like facilities are actually usable by mere mortals. My observation is that in practice lisp programmers, even with the good rule of thumb of not using macros when functions suffice, still use way way more macrology. Good macros are just the opposite of reader burden - they tame complexity.

And (compile-time) macros are one thing, but what happens when you need metaprogramming at runtime (for example dynamic code generation)? With the Common Lisp compiler being always present one can easily generate and compile arbitrary code at any point in time. Here's simple real world example (shameless plug):

https://m00natic.github.io/lisp/manual-jit.html

Re: Blub Paradox (2014)

#62

Post by lmm » Wed, Jan 09, 2019, 3:37 PM UTC

m00natic wrote: post #61

lmm wrote: post #60

Earlier quoted context omitted.

> 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 somethin…

I'm yet to see a "modern" (statically-typed) language with random syntax whose macro-like facilities are actually usable by mere mortals. My observation is that in practice lisp programmers, even with the good rule of thumb of not using macros when functions suffice, still use way way more macrology. Good macros are just the opposite of reader burden - they tame complexity. And (compile-time) macros are one thing, bu…

> And (compile-time) macros are one thing, but what happens when you need metaprogramming at runtime (for example dynamic code generation)?

I'd agree that stage polymorphism is rarely used or appreciated in languages that don't have it (though I see no reason it should be incompatible with typing; as far as I can see your example is much the same as e.g. Scala's LMS; as with macros of course it's substantially more cumbersome to do this in a language with much more syntax than lisp[1]). I'm not sure that it qualifies as a "blub paradox" since to my mind it's a performance optimization rather than something that fundamentally changes language expressiveness - having AST-like datastructures that are gradually transformed/interpreted at runtime is very much a standard technique in ML-family languages, wider adoption of stage polymorphism would mostly lead to programming the same way and having it run faster, I think.

[1] I'm not convinced that it would be impossible to make a language with ML-style types but a very lightweight syntax that made metaprogramming easier. Personally even looking at e.g. Haskell I find myself wishing for a more visible syntax more often than I'm wishing for better interpreter tower performance, shrug.

Re: Blub Paradox (2014)

#63

Post by bmn__ » Thu, Jan 10, 2019, 12:19 PM UTC

bjourne wrote: post #58

Jtsummers wrote: post #47

Earlier quoted context omitted.

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.

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

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.