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

121–126 of 126 posts

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

#121

Post by bluGill »

the_why_of_y wrote: post #104
bluGill wrote: post #54

Earlier quoted context omitted.

C++ is only slightly larger than any other language if you subtract the standard libraries that make a language useful. If you add standard libraries C++ is a tiny language. C++ does have a lot of weird, inconsistent warts that make it tricky to learn/use everything. Which is why most people who advocate to use C++ talk about modern C++ which is C++ where you stay away from those warts.

"C++ a tiny language" - just in case anybody is missing the obvious sarcasm, people who have done it say that implementing a C++ front end takes a decade of effort: https://news.ycombinator.com/item?id=17130870

Those two statements are not incompatible. C++ has a lot of tricky areas that are hard to get right. It is still a tiny language.

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

#122

Post by jrochkind1 »

btilly wrote: post #66
tempguy9999 wrote: post #55

Earlier quoted context omitted.

Your criticism of abstractions is very much in the abstract. What abstractions? What costs of these? In human comprehension, in runtime, in reliability, in mem/cpu? Can you give examples which I can usefully learn so as to avoid? TIA

Any and all abstractions. The cost is usually in all of the above. Examples that I commonly encounter include OO, closures, dependency injection frameworks, complex configuration systems, various code generation systems, and on and on and on. In general the tradeoff is this. For those who have internalized the abstraction, they can think about more complex things. Those who have not internalized the abstraction find…

Which is why what really matters in programming is "communities of shared abstractions."

This is part of what you get with a language, but it depends on the language. (We've seen Javascript users split into several such communities, I'd say).

Or it can be what you get with a framework -- one of the main values of Rails is that people who have learn it's abstractions can look at each other's code and understand it. This applies to third-party extensions to Rails that get especially popular too, like say Devise. (The downside is when those abstractions aren't good, and you want to use something else instead... now everybody finds your code difficult to understand).

When we talk about a language having a good stdlib, a lot of what we're talking about is providing a good set of abstractions that everyone will learn, making their code understandable as well as interoperable with other developers'. JS's lack of much of a stdlib may be not unrelated to JS schism into several communities of shared abstractions...

I don't think it's really about "minimizing abstractions", it's not even possible to do so -- it's about which abstractions how. The important point you make is that abstractions that are understood by a community of programmers, from which those who work on your code are likely to be from -- actually practically have less cost than abstractions that will be unfamiliar with them.

I rememeber when OO was super confusing to me...

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

#123

Post by jrochkind1 »

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̘Ë͖́̉ ͠P̯͍̭…

Yes, what you said. It's not a mistake. It's a... useful abstraction.

Unicode is complicated in some ways because the domain it is dealing with (representing all possible human written communication, basically) is complicated. Unicode is pretty ingenious. It pays to invest in learning about it, rather than assuming your "naive" conclusions are what it "should" do (and unicode's standard docs are pretty readable).

Unicode does offer an algorithm for segmenting text into "grapheme clusters", specifically "user-perceived characters." https://unicode.org/reports/tr29/

It's worth reading that document when deciding what you think the "right" thing to do with "len()" is.

The "user-perceived character segmentation" algorithm is complicated, it has a performance cost... and it's implemented in terms of the lower-level codepoint abstraction.

Dealing with codepoints is the right thing for most platforms to do, as the basic API. Codepoints are the basic API into unicode.

It's true that they ideally ought to also give you access to TR29 character segmentation. And most don't. Cause it's hard and confusing and nobody's done it I guess. It would be nice.

If you want to know "well, howe come codepoints are the basic unicode abstraction/API? Why couldn't user-perceived characters be?" Then start reading other unicode docs too, and eventually you'll understand how we got here. (For starters, a "user-perceived character" can actually be locale-dependent, what's two characters in one language may be one in another).

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

#124

Post by a1369209993 »

jrochkind1 wrote: post #123
dodobirdlord wrote: post #89

Earlier quoted context omitted.

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̯͍̭…

Yes, what you said. It's not a mistake. It's a... useful abstraction. Unicode is complicated in some ways because the domain it is dealing with (representing all possible human written communication, basically) is complicated. Unicode is pretty ingenious. It pays to invest in learning about it, rather than assuming your "naive" conclusions are what it "should" do (and unicode's standard docs are pretty readable). Uni…

> It's not a mistake. It's a... useful abstraction.

It is specifially a abstraction that is not useful.

> It's worth reading that document when deciding what you think the "right" thing to do with "len()" is.

Technically not - the right thing to do is return the number of characters[0] - but the character segmentation parts are worth reading when deciding how to decode UTF-8 bytes into characters in the first place, so the distinction is somewhat academic.

> a [character] can actually be locale-dependent, what's two characters in one language may be one in another

[citation needed]; ch, ij, dz, etc are not examples, but I'm admitted not exhaustively familiar with non-latin scripts[1], so I would be interested to see what other scripts do.

0: or bytes, but that's trivial

1: Which is why I hate Unicode; I'd prefer to pawn that work off on someone else and just import a library, but Unicode has ensured that all available libraries are always unusably broken.

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

#125

Post by joshuamorton »

a1369209993 wrote: post #124
jrochkind1 wrote: post #123

Earlier quoted context omitted.

Yes, what you said. It's not a mistake. It's a... useful abstraction. Unicode is complicated in some ways because the domain it is dealing with (representing all possible human written communication, basically) is complicated. Unicode is pretty ingenious. It pays to invest in learning about it, rather than assuming your "naive" conclusions are what it "should" do (and unicode's standard docs are pretty readable). Uni…

> It's not a mistake. It's a... useful abstraction. It is specifially a abstraction that is not useful. > It's worth reading that document when deciding what you think the "right" thing to do with "len()" is. Technically not - the right thing to do is return the number of characters[0] - but the character segmentation parts are worth reading when deciding how to decode UTF-8 bytes into characters in the first place,…

> Technically not - the right thing to do is return the number of characters[0]

> 0: or bytes, but that's trivial

In what encoding? The utf-8, utf-32, and utf-16 encodings of the same string are different numbers of bytes.

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

#126

Post by a1369209993 »

joshuamorton wrote: post #125
a1369209993 wrote: post #124

Earlier quoted context omitted.

> It's not a mistake. It's a... useful abstraction. It is specifially a abstraction that is not useful. > It's worth reading that document when deciding what you think the "right" thing to do with "len()" is. Technically not - the right thing to do is return the number of characters[0] - but the character segmentation parts are worth reading when deciding how to decode UTF-8 bytes into characters in the first place,…

> Technically not - the right thing to do is return the number of characters[0] > 0: or bytes, but that's trivial In what encoding? The utf-8, utf-32, and utf-16 encodings of the same string are different numbers of bytes.

Number of bytes would apply in cases - like the len() of a python3 bytes or python str object, or something like C's strlen function - where you're not operating on characters in the first place. It's trivial precisely because there is no encoding.

"\xC4\xAC" is two bytes regardless of whether you interpret it as [latin capital i + breve] or [hangul gyeoh] or [latin capital a + umlaut][not sign] ("Ĭ" / "곃" / "Ĭ").

Post reply on HN