Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

Post reply on HN
Print view View original

231–240 of 300 posts

Re: Motivation – Keli Language

#231

Post by kingdomcome50 »

ogre_codes wrote: post #194
kingdomcome50 wrote: post #117

Earlier quoted context omitted.

I'm honestly curious what you see as the issue with "getStudentBy"-type function names. Could you expand on that? Of course I understand a name could become rather verbose in your last case, but I'm not satisfied that it would be much of an issue in practice.

See above.

Hmmm... I see where you are going there, but I don't understand how named arguments solve the problem[0] you have outlined. That is, a problem of discoverability.

Like what, precisely, does the autocomplete show in your editor when you type `getStudent` vs `getStudentBy` that makes the former so much better? In either case you are left to disambiguate either the correct overload or the correct method unless... well... you already know there is an overload that accepts the data you happen to be working with. Presumably you would also then know the correct method name.

I suppose it's possible to start typing your named parameters directly and the editor "fills in" name you are going for? But that poses nearly the same problem again: "Wait... is it 'nationality' or 'country'? Did we decide on 'lastname' or 'surname'?"

I agree the `getStudentByCountryAndName` isn't a great signature, and that wrapping all of the args into a single DTO like `StudentInfo` is not so great either. But I can honestly say, I have never once run into a problem of finding a method in the wild! Even if we had numerous `getStudentBy`-type functions all with similar signatures/names it probably wouldn't take more than a few seconds to narrow down to the one of interest.

I also find, from a consumer perspective, named-parameters to be less ergonomic. I like that when I type `getStudentById(` my editor boldens the argument I am meant to pass next. I don't have to decide which parameter I am going to pass next... my editor just walks me through the function (maybe I'm just lazy!)

To be clear, I am not arguing against named-parameters. Though I dislike that they broaden the public surface of functions, I suppose I would rather at least have the option to use them than not at all. I just don't really see, in a practical sense, how they would improve a code-base beyond some fairly niche scenarios that are probably a code smell anyway.

[0] It seems to me your argument is more aimed towards overloading than named-parameters in particular, but I will accept that there is significant overlap in this space.

Re: Motivation – Keli Language

#232

Post by MrPowers »

carlmr wrote: post #31
exclipy wrote: post #18

Anyone else irked by the use of "Intellisense" - a Microsoft brand - when "autocomplete" will do?

Are you irked by Q-tips and Kleenex as well?

These are referred to as "generic trademarks" if you're interested in learning more: https://en.wikipedia.org/wiki/Generic_trademark. Generic trademarks are studied in economics and have legal implications.

Re: Motivation – Keli Language

#233

Post by MrPowers »

adav wrote: post #168
pmarreck wrote: post #52

Earlier quoted context omitted.

Because we're trying to turn people on to functional programming, not off EDIT: Downvotes already? Look, Scala is NOT noob-friendly, and it's a rational argument, not a preference. Here's an example: There are at least 10 (TEN) different uses of the underscore character (_) in Scala. JFC. I can go on, such as the proliferation of bizarre operators everywhere that are impossible to Google (again, not noob-friendly), t…

Nothing’s noob-friendly if you begin with advanced features. Scala is eminently beginner friendly when introduced to developers familiar with OOP. This approach was how I first experienced Scala and it ended up becoming a gateway drug into FP proper. Regarding underscores in Scala, yes there are many technical terms for each thing it has the capability of representing... but in reality, you just use it wherever you w…

I learned Scala a few years ago and have some popular open source Scala libs. I like Scala, but wouldn't call it "eminently beginner friendly". Coming from Ruby, it was hard for me to learn SBT, Maven, Scalatest (much more complicated than Gemfiles, rubygems, and rspec in my opinion). With Ruby, you can easily make an Array.

Scala newbies find it hard to even perform basic Array operations. You need to dig into Array, Seq, and List, figure out the differences, try to see what's accepted by the community, etc.

Re: Motivation – Keli Language

#234

Post by MrPowers »

theshetty wrote: post #44

Why is no one talking much about Scala? ( https://docs.scala-lang.org/overviews/scala-book/functional-... )

Scala is unfortunately famous for having a toxic community as well. I've emailed with most of the "famous open source" Scala folks and they've all been really nice. But the subreddit seems to have some nasty folks, especially compared with other communities I've been involved with. It's a shame. It's a great language and the people producing the popular libraries are nice.

Re: Motivation – Keli Language

#235

Post by mxz3000 »

elwell wrote: post #118
enricozb wrote: 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…

In Clojure, for functions that will probably have more than a couple args, I like to pass a map, then destructure it by its keys in the function definition. Two benefits are: you don't need to remember the order of args, and it makes refactoring easier in cases where you are simply adding a new optional arg (you don't need to update all the old calls of that function if they aren't using the new option).

That's a pattern I use in a lot of Typescript, it's pretty useful!

Re: Motivation – Keli Language

#236

Post by cuddlybacon »

cannabis_sam wrote: post #107
misja111 wrote: post #34

I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world. The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report…

> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Do you have a…

I think many of the responses to your parent post are focusing too much on `fold` and not the custom monad that is implied to just be a re-implementation of list.

Re: Motivation – Keli Language

#237

Post by gmfawcett »

octachron wrote: post #227
gmfawcett wrote: post #219

Earlier quoted context omitted.

I agree that IntelliJ is excellent for Java, and assume it is for C# (though I haven't used it for that). It's my go-to tool for Java development. In my experience, it's good for Python that doesn't have type annotations -- it's remarkably smart really, considering the challenges of autocomplete for dynamic languages -- but not truly great. Better than nothing, certainly! I can't speak to Ocaml in IDEs other than Ema…

Do you have a recent example of an error of the form "Expected a value of type 'a, but you gave a value of type 'a"? I have hoped to have eliminated all of them in 4.08.

That is great news, and I am probably remembering errors from the olden times. :) Thanks for your work!

Re: Motivation – Keli Language

#238

Post by Kaze404 »

c-cube wrote: post #229
pcstl wrote: post #58

Earlier quoted context omitted.

There's the core team, which is extremely unfriendly to any kind of user-driven development of the language. The whole reason Elm has been stuck in a niche when it had _huge_ hype around 2015 and everyone was sure it would be the "next big thing" on the front-end is that the developers have tried to keep full control of the language and keep shooting down proposals by users. It's either their way or the highway.

Is there any reason why a group of users didn't fork the language? Lack of coordination?

From what I've seen in HN people are more interested in complaining about how Evan handles the language than trying to do something about it or suggest a better approach. Just makes me trust him more, personally.

Re: Motivation – Keli Language

#239

Post by a1369209993 »

kitd wrote: post #172
solomonb wrote: post #144

Earlier quoted context omitted.

Fold Over a Monad? You mean like: ``` ourReportAccumulatorFunc :: Monad m => m a -> m a -> m a ourReportAccumulatorFunc = blah ourFunc :: (Foldable t, Monad m) => t (m a) -> m a ourFunc = foldr ourReportAccumulatorFunc someUnitValue ``` Why do you think a fold would be hundreds of lines outside of the business logic?

Quick tip: indent 4 spaces to get code formatting.

Actually it's only 2 spaces.

  Like this.
    Not this.

Re: Motivation – Keli Language

#240

Post by mikeryan »

laumars wrote: post #10
enricozb wrote: 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…

and quickly become painful to write once you’re familiar with the function call

JavaScript's more recent structuring/desctructuring arguments has made this pretty seamless as long as you name your variables well.

For the most part switching from ordered to named is just func(arg1, arg2, arg3) is just foo({arg1, arg2, arg3})

You may need to rename or pass in the params on the call but it's generally pretty nice. As an above comment says about Clojure - as soon as I need a third argument in a function I switch from ordered to named and its pretty painless.

Post reply on HN