Motivation – Keli Language • Hacker News Board

Re: Motivation – Keli Language

#171

Post by quikoa » Mon, Aug 31, 2020, 6:32 PM UTC

pcstl wrote: post #58

Kaze404 wrote: post #37

Earlier quoted context omitted.

I also love Elm, but the fact that it is a niche language now doesn't mean it's all it ever will be. There's nothing really stopping anyone from adapting Elm to the server for example, but the reason it hasn't been done yet is because it's best to focus on solving one problem at a time. If Evan just translated the Node standard api 1:1 for example, it wouldn't be Elm or Node and there would be no reason to use it.

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.

Yea it's too bad. If the core team was more open and/or communicative I'd use Elm for production. Maybe you've already seen this but there is a pretty solid blog post detailing the state of Elm: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/

Re: Motivation – Keli Language

#172

Post by kitd » Mon, Aug 31, 2020, 6:39 PM UTC

solomonb wrote: post #144

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…

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.

Re: Motivation – Keli Language

#173

Post by DonaldPShimoda » Mon, Aug 31, 2020, 6:40 PM UTC

laumars wrote: post #149

DonaldPShimoda wrote: post #113

Earlier quoted context omitted.

Yes, but this strategy is only suitable for a single developer, or a small group of similarly-experienced-with-that-specific-codebase developers. Onboarding somebody into a world full of single-character variable names and such is a headache. Named parameters are for reading code, and if you're not intimately familiar with the code on your screen right this second, they are helpful. I think what we really need is a s…

> Onboarding somebody into a world full of single-character variable names and such is a headache. The opposite of named arguments isn’t single character variable names. Any organisation with an enforced coding standard would ensure that variables are descriptive irrespective of whether that language uses named arguments or not.

Yes, I agree! I was specifically addressing the parent comment's line about "I use a terse programming style." When it comes to functional programmers, they (more than any other group) will take terseness to the extreme in the form of single-letter variable names in inner functions, match forms, etc.

I didn't mean for my comment to be entirely literal, either. Rather, I just meant to say that terseness can impede readability for those who are not yet familiar with the codebase. (But I have personally been on the receiving end of onboarding into a codebase full of literal single-character names, which I found incredibly frustrating.)

Re: Motivation – Keli Language

#174

Post by pmontra » Mon, Aug 31, 2020, 6:40 PM UTC

linkdd wrote: post #57

pmontra wrote: post #12

Earlier quoted context omitted.

Exactly what I came here to write about: Python 3.8.2 (default, Jul 16 2020, 14:00:26) >>> " ".join(["a", "b"]) 'a b' vs Ruby 2.6.5 :001 > ["a", "b"].join(" ") => "a b" I don't know which one is more natural but I prefer the Ruby version because it's consistent with "a b".split(" ") which works in both languages. One less think to remember.

In Python: ["a", "b"].join(" ") This would mean the type list has a method join, how would it work with the following ? [1.5, "hello", None].join(" ")

Principle of least surprise: make it work like

  >>> f"{1.5} {'hello'} {None}"
  '1.5 hello None'

Ruby does that. From [1] "[Array#join] Returns a string created by converting each element of the array to a string, separated by the given separator."

The difference is that nil (Ruby's None) disappears

  2.6.5 :001 > [1.5, "hello", nil].join(" ") 
  => "1.5 hello "

That's totally expected because in Ruby the conversion of nil into a string is the empty string. Python converts it into the string "None".

[1] https://ruby-doc.org/core-2.6.5/Array.html#method-i-join

Edit: an example with a type that normally wouldn't meaningfully cast to string

  2.6.5 :001 > class Example
  2.6.5 :002?>   attr_accessor :name
  2.6.5 :003?> end
   => nil 
  2.6.5 :004 > e = Example.new
   => # 
  2.6.5 :005 > e.name = "example"
   => "example" 
  2.6.5 :006 > e.to_s
   => "#" 
  2.6.5 :007 > [1, e].join(" ")
   => "1 #" 
  2.6.5 :008 > class Example
  2.6.5 :009?>   attr_accessor :name
  2.6.5 :010?>   def to_s
  2.6.5 :011?>     "#{name}"
  2.6.5 :012?>   end
  2.6.5 :013?> end
   => :to_s 
  2.6.5 :014 > e = Example.new
   => # 
  2.6.5 :015 > e.name = "example"
   => "example" 
  2.6.5 :016 > e.to_s
   => "example" 
  2.6.5 :017 > [1, e].join(" ")
   => "1 example"

Re: Motivation – Keli Language

#175

Post by hannofcart » Mon, Aug 31, 2020, 6:45 PM UTC

Firstly, kudos to the authors of Keli. Since the primer to the language begins by examining what is preventing FP adoption, I'd like to add another key reason: performance.

Haskell code can be optimised to run very fast indeed, but resulting optimised code does not look much like idiomatic Haskell at all.

Re: Motivation – Keli Language

#176

Post by thefifthsetpin » Mon, Aug 31, 2020, 6:46 PM UTC

maest wrote: 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()

If I were designing a functional language, I'd be thinking about whether data.splitBy or delimiter.split was useful even when not immediately invoked.

Consider this crude csv parser:

using splitBy:

    csv.splitBy("\n").map(csv_row=>csv_row.splitBy(","))

using split:

    "\n".split(csv).map(",".split)

split was the clear winner here. Given splitBy, I basically recreated split as a lambda.

I tried to create an analog to that where splitBy would come out looking better. I figured that if we didn't know the dimensionality of our data, then delimiters becomes an array of arbitrary length and we could pass data.!splitBy into something like delimiters.reduce. When actually writing that, however, I wound up recreating split again:

using splitBy:

    delimiters.reduce((accum,delim)=>accum.deepMap(data=>data.splitBy(delim)),[data])

using split:

    delimiters.reduce((accum,delim)=>accum.deepMap(delim.split),[data])

Re: Motivation – Keli Language

#177

Post by stark3 » Mon, Aug 31, 2020, 6:48 PM UTC

On the AS400 there's a 'command' object type that deals with both issues the Keli language is trying to address.

- Argument positions are named, help text, validity checking, special values, etc are defined for each argument.

- Command arguments can be prompted within the editor (intellisense).

As400 commands can also be prompted and executed by a user, thus providing a common user interface for running jobs as well.

I've seen nothing like this in the PC world. The two issues the Keli language is trying to solve were addressed 30 years ago on the as400.

Re: Motivation – Keli Language

#178

Post by Latty » Mon, Aug 31, 2020, 6:49 PM UTC

lalos wrote: post #114

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.

I'm familiar with those controversies, and most if not all of them I would side with the Elm team. The thing is that, yes it is nice to get user-driven development but they seemed to be proposing to bring back concepts from their OO experience and/or baking in features that should not be part of the core library and are easily implemented if you understand how Elm is wired. Seems like these users are excited to contr…

Eh, it isn't just that though. I recently made a big push to try and get a relatively small change through (setting CSS Custom Properties), which is a big blocker for using a lot of web components (which is officially suggested as a way to deal with interop for the language), and will likely block interaction with future web APIs that use custom properties.

I went through and collected up the reasons to do it, distilled it down and gave examples as requested by the core team and got lots of positive feedback from the community, and just got no response from the core devs and nothing happened.

I agree not all changes people propose are good, I like the fact the language is opinionated and doesn't include half-baked ideas, but there is literally no way to get anything through into Elm core, any attempt to do the legwork is just ignored and thrown away. It is a one-man project and that's it, but they pretend that isn't the case.

Honestly, the answer is probably an unstable fork of the language for more experimentation and development, which to be fair, anyone could do¸ but obviously maintaining that would be a lot of work (I don't want to imply that the core Elm team have some responsibility to do it).

Re: Motivation – Keli Language

#179

Post by shaunxcode » Mon, Aug 31, 2020, 6:50 PM UTC

I got excited at the idea of smalltalk syntax in functional clothing but it never seemed to deliver?

Re: Motivation – Keli Language

#180

Post by implicit » Mon, Aug 31, 2020, 6:54 PM UTC

DonaldPShimoda wrote: post #173

laumars wrote: post #149

Earlier quoted context omitted.

> Onboarding somebody into a world full of single-character variable names and such is a headache. The opposite of named arguments isn’t single character variable names. Any organisation with an enforced coding standard would ensure that variables are descriptive irrespective of whether that language uses named arguments or not.

Yes, I agree! I was specifically addressing the parent comment's line about "I use a terse programming style." When it comes to functional programmers, they (more than any other group) will take terseness to the extreme in the form of single-letter variable names in inner functions, match forms, etc. I didn't mean for my comment to be entirely literal, either. Rather, I just meant to say that terseness can impede rea…

The right balance here can depend on the specific business you're working in.

Some companies earn the privilege of a super tenured core team of engineers who work on their product for an extended period of time. They will choose different tradeoffs from a team that needs to adapt to higher turnover.