Live data from Hacker News

Ko – A concurrent, immutable, functional language

github.com

61–67 of 67 posts

Re: Ko – A concurrent, immutable, functional language

#61
post #49

I can't be the only one who's annoyed by language writers introducing arbitrary uncommon syntax apparently just for the sake of doing something new? Lua's great little language but writing ~= instead of != is simply annoying. In this "Ko" language, it looks like they do returns with a colon, as in "return: x" -- why??? I won't even go into Rust picking up Perl's bad habit of looking like line noise with all the ASCII…

I wonder why they preferred ~= over =/= ?

I would sympathize with using =/= for "not equal" because it is ASCII art for the traditional mathematical notation of using an equal sign with a line through it. Though it might be better just to permit carefully selected unicode characters such as https://www.fileformat.info/info/unicode/char/2260/index.htm

=/= is disappointing as art because it is too wide, but it has obvious mnemonic power.

Would you object to =/= as "arbitrary uncommon syntax" because it is poor art? Does its mnemonic power save it from the criticism of being "new for the sake of new"

Re: Ko – A concurrent, immutable, functional language

#62
post #21

Earlier quoted context omitted.

> would implement the language in {foo} If that choice becomes perceivable to anyone but the authors and maintainers of the language itself, I'd say that's a first class failing, isn't it? The quality of a language should be a pure function of the language itself; the interpreter doesn't (or rather, shouldn't ) enter into it.

I think the GP has the following causal diagram in mind: +---------------------+ | Author's competence | +-------+-----+-------+ | | | | +--------------+ | | +---------+ |Implementation| |Product | | language | |language | +--------------+ +----+----+ | +----v----+ |Language | |quality | +---------+ So you are both right; language quality is a function of the language itself, but if we don't yet know much about the l…

What does GP stand for? I keep seeing it around HN. I'm assuming it's a variation of OP?

Re: Ko – A concurrent, immutable, functional language

#63
post #23
post #21

Earlier quoted context omitted.

I think the GP has the following causal diagram in mind: +---------------------+ | Author's competence | +-------+-----+-------+ | | | | +--------------+ | | +---------+ |Implementation| |Product | | language | |language | +--------------+ +----+----+ | +----v----+ |Language | |quality | +---------+ So you are both right; language quality is a function of the language itself, but if we don't yet know much about the l…

Except that Haskell and OCaml as implementation languages would signal huge academic bias and therefore likely inability to come up with a usable language or at least there exists a negative correlation with those languages.

That worldview on OCaml and Haskell = academia only is pretty out-of-date these days...

Re: Ko – A concurrent, immutable, functional language

#64
post #57

Earlier quoted context omitted.

I don't agree with "unusable" but "academic" probably has some justification. The fact that it has a "let" keyword does make it "academic" to me. I'm fairly sure we can now have compilers that don't need such hints to be explicitly provided. Rust enjoys its let keyword so much they have a "If let" syntax. Languages that use random punctuation without providing real benefit could also use a cleanup. Lua with ~= is a g…

“let” us a required feature of the Rust grammar; the semantics would be significantly more complex without it, making tooling harder, etc. we didn’t add it for no reason.

Complexity often masks a lack of search for simplicity. Or was "let" the simplest answer?

Re: Ko – A concurrent, immutable, functional language

#65
post #64

Earlier quoted context omitted.

“let” us a required feature of the Rust grammar; the semantics would be significantly more complex without it, making tooling harder, etc. we didn’t add it for no reason.

Complexity often masks a lack of search for simplicity. Or was "let" the simplest answer?

It's not a matter of "search for simplicity"; the grammar is just inherently ambiguous without some sort of token in this position. let was taken from OCaml, where a lot of inspiration from Rust came from.

(As a reader, it's also really nice to be able to see "there's a new variable being created here" at a glance. Ambiguity is a human problem as well as a computer problem.)

Re: Ko – A concurrent, immutable, functional language

#66
post #49

I can't be the only one who's annoyed by language writers introducing arbitrary uncommon syntax apparently just for the sake of doing something new? Lua's great little language but writing ~= instead of != is simply annoying. In this "Ko" language, it looks like they do returns with a colon, as in "return: x" -- why??? I won't even go into Rust picking up Perl's bad habit of looking like line noise with all the ASCII…

I wonder why they preferred ~= over =/= ? I would sympathize with using =/= for "not equal" because it is ASCII art for the traditional mathematical notation of using an equal sign with a line through it. Though it might be better just to permit carefully selected unicode characters such as https://www.fileformat.info/info/unicode/char/2260/index.htm =/= is disappointing as art because it is too wide, but it has obvi…

MATLAB also uses ~= but I am not certain that is where Lua got it from. (The paper on the history of Lua does not say...)
Post reply on HN