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…
The Tragedy of the Common Lisp: Why Large Languages Explode
91–100 of 126 posts
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#92Keeping 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
#93Earlier 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…
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
#94Earlier 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
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#95Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#96Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#97Earlier 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?
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
#98Earlier 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?
Re: The Tragedy of the Common Lisp: Why Large Languages Explode
#99Earlier 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 >.>
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
#100Earlier 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)
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.