Follow

>Mainstream language design is basically living with a flatmate that is slowly succumbing to his hoarding tendencies and simply doesn’t realize it.

via lobste.rs/s/jgxpsm/i_can_t_kee

@sir speaking of which, I'm quite curious to hear more about your own secret project^W^W design opinions.

@sir

>> Mainstream language design is basically living with a flatmate that is slowly succumbing to his hoarding tendencies and simply doesn’t realize it.

Something that gets lost in that analogy is that it equates "change" with "additional features/complexity" – but many language changes are about *removing* special cases and *reducing* complexity.

That quote was in the context of #rust, so that's an especially large oversight: most recent changes have (thankfully) simplified the language

@codesections this is not necessarily true. These "simpliciations" just simplify the language on the surface-level, which generally just means making it more concise. This doesn't actually simplify the underlying language - it does the opposite, complexity still increases.

@sir

> These "simpliciations" just simplify the language on the surface-level, which generally just means making it more concise. This doesn't actually simplify the underlying language

That's true for some changes.

In other cases, special cases in the compiler/standard library have been removed. Or APIs have been made more consistent, again a simplification.

I'm not saying that's true for *every* change; I'm saying it's true for *some*, and that change is a necessary part of simplification

@codesections @sir I don't use Go nor Rust so I don't really have any skin in the game, but with the Go model they maintain simplicity by not changing the language much. With the Rust model they strive for simplicity by removing/changing features they already added.

Rust is never going to be as simple as Go, but the two languages use diametrically opposed methods for developing the language.

Rust definitely uses the hoarder model, even if cleaning crews come by every so often...

@kungtotte @sir

> the Go model they maintain simplicity by not changing the language much. With the Rust model they strive for simplicity by removing/changing features they already added.

That's a good way of looking at it (with the caveat that Rust doesn't break backwards compatibility – code from 1.0.0 runs perfectly on 1.42.0. So it's less about *removing* things than *deprecating* them when there's a simpler way.)

@kungtotte @sir

Also, it sounds like some of Go's superficial simplicity comes at the expense of ignoring significant edge cases, which can ultimately result in more complexity in the end fasterthanli.me/blog/2020/i-wa

But I don't have anywhere near enough first-hand experience with Go to know if that's true and don't have anything at all against it as a language.

(I think Google's motives for creating it are pretty creepy, but that doesn't say anything about the quality of the language itself)

@codesections @kungtotte @sir

>Go says “don't worry about encodings! things are probably utf-8”.

Maybe it does it elsewhere, but from the examples shown it's more like "String is actually a bytestring. If you want sth more fancy, like unicode characters, look elsewhere."

@codesections @kungtotte @sir
The time stuff looks atrocious though.

Hiding real world's quirks behind a layer of abstraction is not simple. It's inherently complex. But if it lifts some complexity off of user's shoulders, that's a trade-off worth considering.

But what they did here, was introducing new quirks, which then need to be worked around by the user.

Complex to use, complex to implement - the worst of both worlds.

@wolf480pl @codesections @kungtotte @sir that applies so much to both strings and time.

Neither one is ever going to be "simple" if you are working beyond the trivial case (designing entirely for people who live where you do and speak the same language).

Even designing for the case of "All US users" you need to worry about encodings and annoyingly complex timezones.

@RandomDamage @codesections @kungtotte @sir

but implementing only bytestrings makes the language/stdlib much simpler, assuming the underlaying OS also uses bytestrings all over the place and knows nothing about unicode (unlike Windows). You're basically pushing all of the encoding handling onto the user, who may decide they don't really need to get into that if all they do is pass strings from one place to another.

@wolf480pl @codesections @kungtotte @sir users need Unicode.

Implementing a language any time in the past 10 years (maybe 20 years) and not having UTF8 as a first-class citizen in your strings is begging for pain when it's obviously a necessity for anything higher level than a keyboard, and probably even then.

@RandomDamage
Imagine you're writing a web service.
You take some strings from a user, put it in a database, then later retrieve them, pass them through HTML escaping, and paste them in the middle of a template from a file.

At which point do you need to interpret those strings as anything more than bytestrings?
@codesections @kungtotte @sir

@wolf480pl @RandomDamage @codesections @kungtotte it depends on the charset your output HTML file is using, probably then or earlier

@wolf480pl @RandomDamage @codesections @kungtotte I don't agree with you on the subject of UTF-8 by the way, strings are strings and should be treated as such

@sir @wolf480pl @codesections @kungtotte if you need a char[] declare it as such. Strings need to be formatted in a way that's useful, and even latin1 is horribly limited when it comes to dealing with user interfaces.

If for no other reason than those damn smartquotes.

@sir @wolf480pl @RandomDamage @codesections @kungtotte So they should alwayws be treated as someting like utf16 or utf32 and never use utf8 as that adds more complexity. Or do you believe that they should be Ascii strings? or EASCII, or even EBCDIC?

@erkol @sir @wolf480pl @codesections @kungtotte heh, UTF8 is brilliant and simple, but if they want the ultimate simplicity then UTF32 is definitely the way to go.

Don't mind the bloat...

@RandomDamage @sir @wolf480pl @codesections @kungtotte If you are really masochistic there is of course also UTF-EBCDIC though even IBM does not use that and mostly use utf-16 for unicode.

@wolf480pl @codesections @kungtotte @sir at the point that you need to interpret their values.

Characters are multi-byte strings, and have been since Microsoft adopted smartquotes. But even before then you were limited by the encoding you chose.

Just use UTF8 it makes sense everywhere but the ivory tower.

@sir that guy also says he avoids slices and prefers to make a new allocation for every because he doesn't like the syntax, even if that is using more ram and not supporting no_std lobste.rs/s/fmcviy/language_de

@yeah super cool how you dig up unrelated comments in other threads to trash someone's opinion

@sir i didn't dig it up, i read it before and remembered his nickname

@sir sorry, i thought he is a troll, but now i see he has a github profile, 900 comments and he also wrote that post

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!