Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

71–80 of 300 posts

Re: Motivation – Keli Language

#72
If great IDE support and ux for developers is the goal wouldn't it be more reasonable to spend the time on IDE support on existing FP languages rather then creating a new one? It seems that Hindley-Milner type system of many existing languages should lend it self well for language servers in general. But what do i know

Re: Motivation – Keli Language

#73

Off serious topic: Naming it after you girlfriend is a risky move, like getting a tattoo of her. Better get married and stay that way or the next partner is gonna be like: "wtf", you still working on your tribute to your ex programming language!?

I don't know what the problem is. After that you only date people who have the same name as your programming languages.

"Did something happen?"

"Sorry. I just had the wrong idea about you, Kaley."

Re: Motivation – Keli Language

#74
post #30

Earlier quoted context omitted.

Any chance you have a write up about your experience with it??

I'm pretty sure this is a joke. There's no way you can run a SaaS on two lines of code... Unless it's some bizzarely simple calculator or something like that.

APL programmer bursts through the window

"ACTUALLY! ..."

Re: Motivation – Keli Language

#75
post #25

I find the syntax as the author intended it to be: clean. I agree with the ambiguity of positional parameters at first glance. Although named parameters (e.g. in Scala) somewhat solve this, they are optional. Having the parameters with their explicit name makes it quite readable. myList .append(5) .reverse .put(5) atIndex(0) .++(anotherList) .select(x | x.isEven) Edit: The same feature makes it look a little weird wh…

$.name("Keli" :age 50).isOld

wold've been nicer to me but ah well.

Re: Motivation – Keli Language

#77
Unfortunately, no direct comparison to Lisps.

The two downsides mentioned regarding FP are not an issue if you are using a REPL and a Lisp:

- excellent IDE support, since you are working inside your program (which can be inspected)

- paradigm a la carte: you want named arguments? Go for it (split :string "foo,bar" :by ",")

  you want different invocation syntax? (3 + 4) or (3 4 +) is just a macro away
and a bit easier to read than: (this Int).square | Int = this.*(this) YMMV

  you want to define your data shape? use your favorite schema language

  you want monads? just use a library

  you want go-routines? just use a library

  you want compile time types? just use a library

Re: Motivation – Keli Language

#78

Off serious topic: Naming it after you girlfriend is a risky move, like getting a tattoo of her. Better get married and stay that way or the next partner is gonna be like: "wtf", you still working on your tribute to your ex programming language!?

debian says hello

there's also, ALIX[0] more commonly known as HURD

[0] https://biblioweb.sindominio.net/telematica/open-sources-htm...

Re: Motivation – Keli Language

#79
post #62
post #11

Earlier quoted context omitted.

JS uses the second example

It is because in Javascript everything can be translated to a string: 1 + "hello" == "1hello" Therefore, the type Array can have a join method that have predictable results (unlike Python).

I don't know what that has to do with `join`'s call order.

As mentioned above, it's because Python supports `join` on any sequence, not just the array class. Personally, I find JavaScript's solution neater:

    [..."hello"].join(" ") === "h e l l o"

Re: Motivation – Keli Language

#80
post #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…

Advocating for trading away readability in favor of easing the lives of devs who refuse to use an IDE doesn't seem like a win, especially in the context of a team.
Post reply on HN