Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

21–30 of 300 posts

Re: Motivation – Keli Language

#21
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…

I disagree that named parameters are just biased toward new users. They're also biased toward reading rather than writing. I find that as a code base becomes bigger and more non-trivial, I end up reading code many times, and the more I appreciate named parameters.

Re: Motivation – Keli Language

#22
We've built our SAAS on Keli for the last six years and have been amazed by the productivity. Each year we are able to make a net reduction in lines of code. We are now down to only 2 lines, and we expect next year to be the most impressive yet for what we will need to maintain.

Re: Motivation – Keli Language

#23
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…

They are biased to new readers of a codebase, not of a language, which is really just another way of saying that the code is very readable.

Re: Motivation – Keli Language

#24

We've built our SAAS on Keli for the last six years and have been amazed by the productivity. Each year we are able to make a net reduction in lines of code. We are now down to only 2 lines, and we expect next year to be the most impressive yet for what we will need to maintain.

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

Re: Motivation – Keli Language

#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 when put on a single line, because we mentally parse the whitespace as separator but in this case it is not:

  $.name("Keli") age(50).isOld
It looks like a refreshing addition to function programming languages and I'd like to see where it goes from here, in terms of adoption and features.

Re: Motivation – Keli Language

#26
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…

They are biased towards new users of a codebase, not only the language.

Named arguments improve readability of a code if you are not used to a codebase. By improving readability, you also improve maintanability: you need less experience in a codebase to make a change.

You focus on writability where it's not the biggest issue of the field, it's software debt.

Re: Motivation – Keli Language

#27
Elm single handedly got me into functional programming. Everything from the syntax to the standard library. I haven’t used a language that was that elegant and delightful to use perhaps since I discovered Ruby.

It makes me really sad that Elm turned to this niche language/framework that it is today. I had hoped for it to grow someday to have a mobile target in addition to web, to be able to use it on the server, hell even to be able to use it to build systems. So much wasted potential.

Re: Motivation – Keli Language

#29
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…

How would function composition work without currying? You'd have to name everything, wouldn't you?

I'm thinking of how you could write in point-free style or even have a `(.)` function to begin with if you had the Smalltalk "message passing" style.

Sure the Haskell syntax is a bit much when you're not familiar with it but, like almost any language, it's often the least-interesting part of the language and the most talked about.

Re: Motivation – Keli Language

#30

We've built our SAAS on Keli for the last six years and have been amazed by the productivity. Each year we are able to make a net reduction in lines of code. We are now down to only 2 lines, and we expect next year to be the most impressive yet for what we will need to maintain.

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.
Post reply on HN