Live data from Hacker News

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

91–100 of 126 posts

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

#91

I kind of wish there was a lisp with the "recompile on error and continue" feature of Common Lisp but without a massive standard library. A standalone SBCL program seems to be around 40MB at minimum. It feels like it would be doable if only CL wasn't designed with the kitchen sink included. Recently I've gotten into Janet[0] and really like the language, although I do miss CL's recompilation magic at times. It feels…

SBCL is so large because it's not particularly optimized for size. A stripped libecl.so is a couple of megabytes.

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

#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 any sense to me. Seems that all that opinion are based in nothing more that nothing when it concerns about Common Lisp literature experience and personal experience with the language.

Some languages are popular, but they being popular doesn't proofs that they are good languages. This is a fact based on the type of problems most of the people are trying to solve.

CL being big it's some way comparable to C++, but for big problems, sometimes we need complex tools. CL is not for kids, neither C++. Common Lisp it's a language for hackers.

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

#93

Earlier quoted context omitted.

> Complain all you want about the 2 to 3 transition Okay. > it's resulted in a simpler, easier-to-use language. Does `print(len("ẅ"))`[0] still produce a value (2) that is neither the number of characters (1) nor the number of bytes (3)? 0: "print\x28len\x28\x22\x77\xCC\x88\x22\x29\x29"

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("ẅ")
    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 "ẅ", although they look the same at first glance.

    >>> "ẅ".encode('utf-8')
    b'w\xcc\x88'
    >>> "ẅ".encode('utf-8')
    b'\xe1\xba\x85'
EDIT 2. More info:

    >>> import unicodedata
    >>> w1 = "ẅ"
    >>> w2 = "ẅ"
    >>> unicodedata.name(w1)
    'LATIN SMALL LETTER W WITH DIAERESIS'
    >>> unicodedata.name(w2)
    Traceback (most recent call last):
      File "", line 1, in 
    TypeError: name() argument 1 must be a unicode character, not str
    >>> unicodedata.name(w2[0])
    'LATIN SMALL LETTER W'
    >>> unicodedata.name(w2[1])
    'COMBINING DIAERESIS'
So the second version (w2) does seem to consist of two separate "characters", LATIN SMALL LETTER W and COMBINING DIAERESIS, which is apparently not the same as the single-character LATIN SMALL LETTER W WITH DIAERESIS. I guess these are actually Unicode code points and not so much "characters" to a human reader, but as another poster pointed out, what the number of characters should be in a string isn't always clear-cut.

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

#94
post #90
post #48

Earlier quoted context omitted.

> Those languages are also not very popular at all today. But yet, C (arguably 'current algol') and Python (arguably 'current scheme' ) are.. yes: python is verry loosely like scheme, this is meant in the sense of a 'dynamic loosely typed language you can interact with in a repl'

the significant difference between python and scheme here is that python is not small. but then, scheme is heading in the same direction if you look at the latest standards development

Depends on what you mean by "latest". R6RS is arguably huge. That's why they decided to split R7RS in two, a small core which is done and a huge version which, ironically, is still in the making.

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

#97
post #76

Earlier quoted context omitted.

Replying to myself as I thought of an example from my own past which is relevant. After discovering the eye-opening expressivity of functional programming years ago with Dylan and Haskell, I had a substantial project in javascript. I found JS supported first class closures and lambdas, which allowed me to make iterators. The novelty was they were iterators not over lists but over trees (DOM trees in this case but of…

haha did your successors think it was worth the cost?

What happened was interesting and unexpected. I was building on top of an application (call it H) which had the DOM trees to manipulate, and JS to manipulate it with. I was reporting new bugs in H continuously, 1 or 2 every day.

Because of the abstractions I'd done (it wasn't only tree iterators) I could largely work around the bugs invisibly - I pushed the bug-special-case-handling code down to make it invisible when using my abstractions.

That made it all too viable to continue using an crappy, flaky product far longer than would have been possible - or sensible - without those abstractions. I'd turned the abstractions' value into a liability!

I finally told them it wasn't worth continuing with H, they junked it AFAIK and I walked away.

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

#98
post #76

Earlier quoted context omitted.

Replying to myself as I thought of an example from my own past which is relevant. After discovering the eye-opening expressivity of functional programming years ago with Dylan and Haskell, I had a substantial project in javascript. I found JS supported first class closures and lambdas, which allowed me to make iterators. The novelty was they were iterators not over lists but over trees (DOM trees in this case but of…

haha did your successors think it was worth the cost?

More importantly, I suppose, did the company?

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

#99
post #58

Earlier quoted context omitted.

I'm not sure too many people could write a test suite for LOOP in his spare time. Never mind the rest of the trickier parts of the language such as MOP, CLOS, packages, conditions, restarts, etc. etc.

https://github.com/pfdietz/ansi-test >.>

> in his spare time

I don't wanna be -that guy- but ... github lists 5 contributors on that repo. "his" is doing a lot of work in your claim there.

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

#100

Earlier quoted context omitted.

> Those languages are also not very popular at all today. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for. Perhaps popularity isn't.

I think that popularity is probably indicative of other qualities of a language, and at the very least, I think being popular is a good feature in itself (in terms of getting support, libraries, documentation etc)

Platforms are products that sell languages, not the other way around.

So being popular just means having the luck to be on a platform that is doing well.

Usually most programming languages fade way when that platform stops being relevant, as history has proven a couple of times.

Post reply on HN