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

291–300 of 300 posts

Re: Motivation – Keli Language

#291

Post by specialist »

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…

"... too enthusiastic about creating abstractions."

Like others, I'm eager to hear more of your thoughts.

I also have a theory. A bit of a riff on Rob Pike's observation (IIRC): "Show me your data and I'll understand your code".

Enterprise-y (corp IT) projects are data centric. Functional programming emphasizes flow-of-control over the data flow. Even more so than functional decompensation (imperative programming) and object-oriented.

Donald Norman's notion of "affordances" applies. Any one can certainly "do COBOL" in Scheme, but pushing that rope requires uncommon insight and intention.

Re: Motivation – Keli Language

#292

Post by nybble41 »

nybble41 wrote: post #153
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…

This particular set of examples is especially ambiguous because "splitBy" can be read two different ways: as a description of the result ( noun having been split by a separator) or as an action ( subject split direct object by a separator). Which one you choose will subtly affect the way you group the arguments. Conventions in functional programming tend to prefer the former, whereas imperative (including OOP) langua…

> Functions which are designed to read well as infix operators usually require operator sections or `flip` to adapt them for use as combinators.

It occurs to me that this could have been avoided at the language level by defining infix notation to implicitly flip the arguments. For example,

    x / 3 == (/ 3) x == (/) 3 x

    x ++ "suffix" == (++ "suffix") x == (++) "suffix" x

    x `splitBy` "," == (`splitBy` ",") x == splitBy "," x
(The left and center forms are valid and equivalent Haskell code today; the right form has the arguments flipped.) I think on the whole this would have made it easier to transition between the curried forms and the infix forms, since it's more common to want to bind the RHS of an infix operator than the LHS. I would also say that e.g. `(/) 3` reads more naturally as "divided by three" than its actual definition as "three divided by …". No doubt we could find a few counterexamples where it reads better to have the LHS first, though I can't think of any at the moment.

Of course, it's much too late to be changing something so fundamental at this point. Even as an extension it would cause far too much confusion.

Re: Motivation – Keli Language

#293

Post by pcstl »

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?

On my end, it's mostly lack of time.

Re: Motivation – Keli Language

#294

Post by pcstl »

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…

That's not really what I'm talking about. For instance, a few years ago when I was really into Elm, I wanted to implement a WebAudio library. Back when Elm was an FRP language, I thought it would be a great fit with the language's model.

I even got a proof of concept working and showed it off in the Elm Slack.

And then I got told my library would not get accepted on the official package repository because the core team was developing their own "correct" abstractions for the main Web APIs and they did not want third-party libraries to compete with the core team's libraries, as regular web developers don't know what they're doing and are incapable of choosing the "right" abstractions, which apparently only the Elm core team is capable of doing.

That experience turned me off Elm for good.

Flash forward to 2020: There is still no "official" Web Audio library. (There are a few non-official ones on Elm Packages)

It's your right to side with the core team, but they're the ones pretty much killing the language's chance to see any real usage.

Re: Motivation – Keli Language

#295

Post by Sharlin »

mattmanser wrote: post #279
munk-a wrote: post #251

Earlier quoted context omitted.

I haven't seen evidence of reduced getters & setters in my day to day yet - they still seem pretty prevalent when OOP comes into the picture. I'd even say they got a bit worse because now it's excessive getters and setters with gigantic JavaDoc style comments all around them. If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

What are you talking about? Get setters used to be 10 lines long like: int id; public int Id { get { return id; } set(val) { id = val; } } They're now one liners, and obviously necessary public int Id { get; set; } I don't keep up with Java any more, but C# has super short shortcuts for assignment like: public int Id { get; set; } => generateId(); If you, or your company, are misusing a completely optional documentat…

Your comment is entirely specific to C#. Java has no such shortcuts, its setters and getters look identical to how they looked in 1994:

    private int id;
    public void setId(int id) {
        this.id = id;
    }
    public int getId() {
        return id;
    }

Re: Motivation – Keli Language

#296

Post by shaunxcode »

hou32hou wrote: post #286
shaunxcode wrote: post #179

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

It won’t be delivered because it’s actually my final year project for my software engineering degree, and plus I’m also not convinced by this language anymore, I still think that there’s a better syntax which I can’t think of right now

Keep going!

Re: Motivation – Keli Language

#297

Post by krab »

ghayes wrote: post #189
1-more wrote: post #163

Earlier quoted context omitted.

I started with Elm, then I started working through Learn You a Haskell. At first I thought the lack of typeclasses in Elm was a big missing piece, but now I see the potential for me to turn a programming problem into a little-too-philosophical debate about the nature of truth in the universe or some such. In other words leaving out typeclasses may help but not guarantee that I keep my eyes on the screen and off of my…

The hard part with Elm’s lack of typeclasses is the lack of do notation. It’s pretty easy to end up in Elm’s version of “callback hell” where you’re nested several `andThen`s deep. And that’s for a language that doesn’t have `IO`. That said, I would love to try an “Elm on the backend” that specifically lacks features compared to Haskell.

Scala seems quite close. It has a lot of features. But it's flexible enough that it doesn't "hurt" as much as writing production code in Haskell.

Re: Motivation – Keli Language

#298

Post by cannabis_sam »

scarmig wrote: post #121
cannabis_sam wrote: post #107

Earlier quoted context omitted.

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

Well, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.

Thank you! I’m deeply familiar with the phenomenon!

Re: Motivation – Keli Language

#299

Post by cannabis_sam »

treetide wrote: post #230
cannabis_sam wrote: post #107

Earlier quoted context omitted.

> 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 just wrote about some possible pitfalls down the ADT route: https://treetide.com/posts/domain-model-pitfalls-oop-fp.html > As more operations are demanded, it is more likely that the existing partitioning of the world into the nice distinct cases won’t suit that operation anymore. Then, as a fix, we can introduce more specific cases, or make existing ones more general - leading to ambiguity, bloat and mental load f…

I like it!

It’s the kind of reasonable discussion that I crave in this field.

Re: Motivation – Keli Language

#300

Post by cannabis_sam »

misja111 wrote: post #274
cannabis_sam wrote: post #107

Earlier quoted context omitted.

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

> Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. This was just an example of a behaviour that, if taken too far, could eventually lead to those 'hundreds of lines of abstract code'. Of course a single fold in itself is nothing to be concerned about. But an API that accepts a type 'm a' instead of '[Order]' has lost some of its…

> 'hundreds of lines of abstract code'.

Yeah, I’ve spent way to much time digging into “hundreds of thousands” of lines of abstract OOP code. And it’s sadly, largely ceremonial, mostly due to limitations in the language. The less fanatic about OOP the language is, the more useful it is, is a good rule.

But it’s absolutely not exclusive to either paradigm.

> But an API that accepts a type 'm a' instead of '[Order]' has lost some of its connection with the business domain already.

I completely agree, but I’m also curious how any API interface like that would pass code review. Since it’s so obviously too general.

But I guess the perceived upside is that the equivalent oop-construction would not get caught in code review.

> Yes, this is the same problem which pops up in the OOP world as well.

I know. I’ve spent more time working within oop than without. The type based FP-world just have orders of magnitude better tools.

> I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it.

This is kind of a sad way to dismiss people, as if they’re some kind of ephemeral fireflies...

The reality is that trying to force reality into in an inheritance-based, tree-structured taxonomy, is not only stupid, it also creates endless maintenance headaches.

Some problems fit that model better sure, but most things fit a much simpler ADT-based model since it’s much closer to how we think logically. (In terms of logical primitives and implicit recursion)

Post reply on HN