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

The Tragedy of the Common Lisp: Why Large Languages Explode

medium.com

Post reply on HN
Print view View original

81–90 of 126 posts

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

#81

Post by Smithalicious »

mhuffman wrote: post #62
lacker wrote: post #40

The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. Those languages are also not very popular at all today. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for. In many ways, keeping the core JavaScript language small has led to the JavaScript ecosystem being too large and sprawling. For example, look at module importing, someth…

> 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)

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

#82

Post by cat199 »

astrobe_ wrote: post #53
cat199 wrote: 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'

Lua is a far better counter-example as a successful small and (conceptually) beautiful language.

yes, probably so. was going for 'popularity' here

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

#83

Post by cat199 »

darkpuma wrote: post #49
cat199 wrote: 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'

> "dynamic loosely typed" Both Python and Scheme are dynamic but strongly typed.

i'm going to disagree here.

yes, they have strong core types, but there is nothing preventing you calling some function with completely invalid arguments..

even within the 'interpreted fp' world, there are better examples (e.g. ML family)

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

#84

Post by Smithalicious »

a1369209993 wrote: post #77
zephyrfalcon wrote: post #64

Earlier quoted context omitted.

Apparently yes. A quick inspection suggests that this is the same in Ruby, Haskell, SWI-Prolog, Gauche Scheme, SBCL and D. (I might not have the latest version of everything, so maybe this has been fixed in some of them... assuming it needs fixing. Maybe there's a reason for the answer to be 2 if so many language implementations insist on it. Or, they all use the same faulty algorithm. I don't know.)

> they all use the same faulty algorithm Well, yes. To be fair, it's not like any of them make a secret of the fact that they're mistakenly counting unicode code points instead of characters.

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

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

#85

Post by didibus »

I think the word Large is pretty ambiguous. In my opinion, it is more about incoherent, inconsistent, complected, and with no clear way to learn more about things you do not understand. A language which has everything I would need already available and ready to use, in a simple and straightforward way is pretty great otherwise.

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

#86

Post by kerkeslager »

a1369209993 wrote: post #59
kerkeslager wrote: post #39

I feel like this is the real success of Python: the "one and preferably only one obvious way to do it" idea means that new ways of doing something are rarely added, and when new they are added, old ones are likely deprecated. Complain all you want about the 2 to 3 transition, but it's resulted in a simpler, easier-to-use language. If the community really feels a different way is better, they add it in libraries. My o…

> 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 you placed below your post is not how Python 3 represents it. Instead, it looks like this:

    >>> "ẅ".encode('utf32')
    b'\xff\xfe\x00\x00\x85\x1e\x00\x00'
This has disadvantages (memory usage) but for most cases where Python is used, it's an advantage (faster random access, more intuitive for situations like the one you've proposed).

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

#87

Post by dodobirdlord »

cat199 wrote: post #83
darkpuma wrote: post #49

Earlier quoted context omitted.

> "dynamic loosely typed" Both Python and Scheme are dynamic but strongly typed.

i'm going to disagree here. yes, they have strong core types, but there is nothing preventing you calling some function with completely invalid arguments.. even within the 'interpreted fp' world, there are better examples (e.g. ML family)

I think you may be missing some terminology here. Strong typing is about whether entities have definite types and resist type coercion. Ad-hoc typing in dynamic languages can make this hard to see, but it's still there. What would prevent you from calling a function with invalid arguments would be static typing, which Python and Scheme do not have.

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

#88

Post by soiheard »

sansnomme wrote: post #8
lispm wrote: post #5

Earlier quoted context omitted.

SBCL's programs are 40MB because they contain all dev tools and the code is native code, which is also large. There are a bunch of Common Lisp implementations which are smaller (CLISP), can create small applications (Lispworks), can be embedded (ECL) or can compile to smallish C code (mocl).

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.github.io/ https://github.com/fukamachi/woo https://github.com/fukamachi/ningle

p.s. Not the author, but a big fan.

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

#89

Post by dodobirdlord »

Smithalicious wrote: post #84
a1369209993 wrote: post #77

Earlier quoted context omitted.

> they all use the same faulty algorithm Well, yes. To be fair, it's not like any of them make a secret of the fact that they're mistakenly counting unicode code points instead of characters.

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̘Ë͖́̉ ͠P̯͍̭O̚ N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ"

.

And what should Python tell you the length of this string is?

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

#90

Post by em-bee »

cat199 wrote: post #48
lacker wrote: post #40

The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. Those languages are also not very popular at all today. Perhaps "small and beautiful" are not the right metrics to optimize programming languages for. In many ways, keeping the core JavaScript language small has led to the JavaScript ecosystem being too large and sprawling. For example, look at module importing, someth…

> 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

Post reply on HN