Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

1–10 of 300 posts

Re: Motivation – Keli Language

#3
The following example is kinda funny:

    // This is obviously not too right
    ",".splitBy("1,2,3,4,5")

    // This should be right, because it reads out more naturally
    "1,2,3,4,5".splitBy(",")
Seeing as Python uses the first version for .join()

Re: Motivation – Keli Language

#5
When giving an example on how infix notation reads better:

    // This is obviously not too right
    ",".splitBy("1,2,3,4,5")

    // This should be right, because it reads out more naturally
    "1,2,3,4,5".splitBy(",")
It's funny that in Python split works this way but join doesn't. This is because in the case of split both arguments are strings, but for join one of the arguments is a Sequence, which is a general protocol rather than a class.

The proposed solution by Keli is to be inspired by the Smalltalk-style message syntax:

    'Hello world' replace: 'Hello' with: 'Bye'
I think, in general, requiring named arguments is a good thing. Swift does it, and in codebases with a decent amount of TLC, it looks great.

Function calls are one of the weird places were the syntax of the language rarely helps you figure out what is going on, and for the most part is just a sequence of human-written names one after another, and in languages with custom operators it could be even terser.

In comparison, if-statements, loops, pattern matching, etc. were (hopefully) designed to be expressive. I think by requiring named arguments, function calls will also be much more readable, relying less on an active human effort to do so.

Re: Motivation – Keli Language

#8
While I could get onboard with functional languages being more user friendly I didn't find the motivation to be compelling.

> Ambiguous functions argument positions

It just seems to be advocating for named arguments, something which the majority of languages (OO or FP) support these days. You could say that requiring named parameters is a feature but it's hard to get excited about.

> Not Intellisense friendly

I use Elm and Elixir, both of which have decent autocomplete in vscode (and I believe many other editors).

Critique aside I definitely applaud more towards increasing FP adoption. I think Elm has brought many good ideas to the table already (though admittedly it's bias is more towards ideal than practical). On the flip side Elixir is very pragmatic and easy to get going with for developers coming from OO languages.

Re: Motivation – Keli Language

#9
post #3

The following example is kinda funny: // This is obviously not too right ",".splitBy("1,2,3,4,5") // This should be right, because it reads out more naturally "1,2,3,4,5".splitBy(",") Seeing as Python uses the first version for .join()

Yeah Python (and I think JavaScript?) pretty clearly have `join` backwards.

Re: Motivation – Keli Language

#10
post #5

When giving an example on how infix notation reads better: // This is obviously not too right ",".splitBy("1,2,3,4,5") // This should be right, because it reads out more naturally "1,2,3,4,5".splitBy(",") It's funny that in Python split works this way but join doesn't. This is because in the case of split both arguments are strings, but for join one of the arguments is a Sequence, which is a general protocol rather t…

I get this might just boil down to preference but I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call.

Plus they don’t always improve writability outside of IDEs because you then have to memorise the parameter names and in some functions there’s several terms that could equally apply (if you’re using an IDE with hinting then the advantages become moot as the same IDE would hint the order of parameters).

Post reply on HN