The Tragedy of the Common Lisp: Why Large Languages Explode • Hacker News Board

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#111

Post by sansnomme » Sat, Jun 22, 2019, 3:11 PM UTC

soiheard wrote: post #88

sansnomme wrote: post #8

Earlier quoted context omitted.

Also, Common Lisp's standard library cannot compare to Python, Java etc. They have a lot of language manipulation tools but not actually anything that will help you ship quickly if you are building generic CRUD style applications. CL tends to shine when it comes to extremely domain specific niche stuff where you practically have to write your own tooling from scratch.

Roswell comes to mind for application building and distro management. Add in ningle for web app building and woo for the server (the benchmarks are really good), and you're basically good to go. I think the main problem is there's too many implementations of the same thing in CL, so devs basically have to agree on a very specific subset of tools for every project, which adds a fair bit of overhead. https://roswell.gi…

Last I tried it's not reliable. E.g. generating binaries through VM images is coin toss.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#112

Post by kazinator » Sat, Jun 22, 2019, 5:24 PM UTC

nabla9 wrote: post #31

gnaritas wrote: post #7

Lisp isn't a large language, it's a small language with a large library.

I think comp.lang.lisp had this discussion 10 years ago and the "core language" semantics of Common Lisp is something like 25-30 functions/operators. Rest of the language could be a separated into libraries. But even with the all those 'libraries' COMMON-LISP package has just 978 external symbols.

In TXR Lisp, I seem to have nearly double that in the analogous public library package called usr:

  1> (len (keep-if [orf boundp mboundp fboundp] (package-symbols 'usr)))
  1713

That's just a one-man project coming up to ten years two months hence.

That doesn't count any structure types or their slot names, FFI types, and local macros involved in syntaxes like awk and such.

I would say that Common Lisp shows amazing restraint, given its scope and number of people involved.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#113

Post by wool_gather » Sat, Jun 22, 2019, 6:08 PM UTC

zephyrfalcon wrote: post #93

kerkeslager wrote: post #86

Earlier quoted context omitted.

It took me a bit to understand what you were trying to do. Here's a paste of my Python 3 shell session, showing that Python 3 does indeed return the number of characters. ~$ python3 Python 3.7.3 (default, Mar 27 2019, 09:23:15) [Clang 10.0.1 (clang-1001.0.46.3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> len("ẅ") 1 Python 3 uses UTF 32 internally, so the byte representation y…

So, I see: Python 3.7.3 (default, Mar 27 2019, 09:23:32) [Clang 9.0.0 (clang-900.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> len("ẅ") 2 I wonder why this is? Is the Clang version relevant here? EDIT: Your "ẅ" doesn't seem to be the same as the OP's "ẅ", although they look the same at first glance. >>> "ẅ".encode('utf-8') b'w\xcc\x88' >>> "ẅ".encode('utf-8') b'\xe1\…

Well spotted. It was probably normalized when it was copy-pasted.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#114

Post by dTal » Sat, Jun 22, 2019, 7:15 PM UTC

darkpuma wrote: post #57

gmfawcett wrote: post #44

Earlier quoted context omitted.

Some CL implementations do this ("tree shaking", as it is called). But some of the more popular open-source implementations (SBCL, Clozure CL) do not.

It can also be error prone. Analysising arbitrary lisp code to see which functions could conceivably ever be called isn't as trivial as it might first seems.

Can you elaborate? It seems trivial - just scan every function call. Surely it's not possible to call a function without typing its name somewhere? (Obviously if there's funny business with 'eval' this won't work, but then it reduces to the halting problem in the general case so that's fine. Most programs don't use eval.)

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#115

Post by a1369209993 » Sat, Jun 22, 2019, 7:20 PM UTC

zephyrfalcon wrote: post #93

kerkeslager wrote: post #86

Earlier quoted context omitted.

It took me a bit to understand what you were trying to do. Here's a paste of my Python 3 shell session, showing that Python 3 does indeed return the number of characters. ~$ python3 Python 3.7.3 (default, Mar 27 2019, 09:23:15) [Clang 10.0.1 (clang-1001.0.46.3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> len("ẅ") 1 Python 3 uses UTF 32 internally, so the byte representation y…

So, I see: Python 3.7.3 (default, Mar 27 2019, 09:23:32) [Clang 9.0.0 (clang-900.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> len("ẅ") 2 I wonder why this is? Is the Clang version relevant here? EDIT: Your "ẅ" doesn't seem to be the same as the OP's "ẅ", although they look the same at first glance. >>> "ẅ".encode('utf-8') b'w\xcc\x88' >>> "ẅ".encode('utf-8') b'\xe1\…

Correct, w2 is one character (latin small w with umlaut) represented by two unicode code points. I didn't realize there was a NFC code point for that character; try "\x66\xCC\x88" (f̈) or "\x77\xCC\xBB" (w̻) instead.

> the number of characters should be in a string isn't always clear-cut.

This is why I use examples from latin-with-diacritics, where there is no ambiguity in character segmentation.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#116

Post by a1369209993 » Sat, Jun 22, 2019, 7:34 PM UTC

dodobirdlord wrote: post #89

Smithalicious wrote: post #84

Earlier quoted context omitted.

Are they really doing so "mistakenly"? I feel like there's more to this.

It's not mistakenly. Unicode's complexity is a bit more than trivial, and since much work has gone into abstracting over it many people are surprised when the complexity rears up at them. Consider, for example, the wonderful piece of writing in the answer to this question. https://stackoverflow.com/questions/1732348/regex-match-open... How many characters do you suppose are in this string? . "TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭…

23 if I'm counting correctly (there's a space in "PO NY" for some reason). I would also accept 209 from a language that elected not to deal with large amounts of complexity in string handling. The problem with Unicode is they go to enormous amounts of effort to deliberately give a wrong answer.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#117

Post by nydel » Sun, Jun 23, 2019, 6:40 AM UTC

lerax wrote: post #92

[hyperbolic] Common Lisp deserves more love. People are just too much jealous to admit that CL is one of the best language of the world. How someone can think that JavaScript, PHP, Java and other stuff alike are at least non-miserable in comparison with something so powerful as Common Lisp? [/hyperbolic] Keeping the humor-ish stuff aside, actually taking CL here as example it's someway ignorant. That's doesn't make a…

my neck aches from nods in agreement. i know i’ve written at leeaasst one #’TRAMADOL-SIMULATOR but i’ll likely just lambda the notion, slightly faster &or funner than grepping my filesystem for “\.l*sp$”.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#118

Post by kerkeslager » Sun, Jun 23, 2019, 2:04 PM UTC

a1369209993 wrote: post #115

zephyrfalcon wrote: post #93

Earlier quoted context omitted.

So, I see: Python 3.7.3 (default, Mar 27 2019, 09:23:32) [Clang 9.0.0 (clang-900.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> len("ẅ") 2 I wonder why this is? Is the Clang version relevant here? EDIT: Your "ẅ" doesn't seem to be the same as the OP's "ẅ", although they look the same at first glance. >>> "ẅ".encode('utf-8') b'w\xcc\x88' >>> "ẅ".encode('utf-8') b'\xe1\…

Correct, w2 is one character (latin small w with umlaut) represented by two unicode code points. I didn't realize there was a NFC code point for that character; try "\x66\xCC\x88" (f̈) or "\x77\xCC\xBB" (w̻) instead. > the number of characters should be in a string isn't always clear-cut. This is why I use examples from latin-with-diacritics, where there is no ambiguity in character segmentation.

Interesting, I learned a bit about Unicode here. It looks like copy/pasting combined the two code points into one when I ran my code.

Still, to the original point, I think this is more of a criticism of Unicode than of Python. It seems to me that the answer is to not use combining diacritics, and that Unicode shouldn't include those.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#119

Post by a1369209993 » Sun, Jun 23, 2019, 6:17 PM UTC

kerkeslager wrote: post #118

a1369209993 wrote: post #115

Earlier quoted context omitted.

Correct, w2 is one character (latin small w with umlaut) represented by two unicode code points. I didn't realize there was a NFC code point for that character; try "\x66\xCC\x88" (f̈) or "\x77\xCC\xBB" (w̻) instead. > the number of characters should be in a string isn't always clear-cut. This is why I use examples from latin-with-diacritics, where there is no ambiguity in character segmentation.

Interesting, I learned a bit about Unicode here. It looks like copy/pasting combined the two code points into one when I ran my code. Still, to the original point, I think this is more of a criticism of Unicode than of Python. It seems to me that the answer is to not use combining diacritics, and that Unicode shouldn't include those.

> this is more of a criticism of Unicode than of Python

True, although it's more specifically a criticism of Python for using Unicode, where these kinds of warts are pervasive. See also "\xC7\xB1" (U+01F1 "Ǳ") which is two bytes, one code point, and two characters with no correspondence to those bytes.

> the answer is to not use combining diacritics

This doesn't actually work, sadly, because you can't represent eg "f̈"[0] without some means of composing arbitrary base characters with arbitrary diacritics.

0: If unicode has a added a specific NFC code point for that particular character, then that's bad example but the general point still stands.

Re: The Tragedy of the Common Lisp: Why Large Languages Explode

#120

Post by einpoklum » Sun, Jun 23, 2019, 10:52 PM UTC

btilly wrote: post #32

After programming for 20 years, I've noticed that programmers are aware of the potential benefits of any abstraction that they have internalized, and blithely unaware of the costs. Because, having climbed that learning curve, it is now free to them. The result is that programmers introduce complexity lightly, and when they walk into a new language/organization/etc are inclined to add random abstractions that they are…

That means you have probably not been programming C++.

In C++, the cost of abstraction is a fundamental consideration, and while you can still ignore it - most resources about using C++, and gradually even the language itself, tend to nudge you towards avoiding abstraction costs in various ways (sometimes ugly, sometimes elegant). Plus, core language designers and compiler architects bend over backwards to reduce the cost of various abstractions to nothing or very little.

Plus, it happens that sometimes, you can use stronger abstractions to _reduce_ cost rather than increase it.