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

261–270 of 300 posts

Re: Motivation – Keli Language

#261

Post by the_af »

lgessler wrote: post #224
the_af wrote: post #217

Earlier quoted context omitted.

> and it's a rational argument, not a preference It might have some justification, but it's just your preference. Scala gained a reputation of being a "difficult" language early on, I suppose mostly by people coming from Java, and it has unfortunately stuck. Singling out underscores in Scala as "difficult" is bizarre. There might be many, but in practice it's very easy to understand what you want, and I've never seen…

> What's wrong with relying on the JVM? It's that the user needs to learn not just Scala but also Java whenever they want to do anything "real". You might say this is a minor hangup, but for learners having to context switch back and forth between Java and Scala and dealing with interop issues can make for much more cognitive load than using a non-hosted language like Python or Go.

That Scala has a vast array of Java libraries is a strength, not a weakness. Interop issues between Java and Scala are not a big deal, anyway. It's mostly seamless.

Re: Motivation – Keli Language

#262

Post by talaketu »

achr2 wrote: post #188
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…

I think the word abstraction here is overloaded. OOP is also fundamentally driven by abstractions. The difference is that FP abstractions are mathematical abstractions, while OOP starts with human-centric conceptual abstractions - the kind every two year old is taught. These are not the same in terms of cognitive understanding. I also use FP approaches all the time in OO languages (like C#), which I believe is more a…

Abstractions are drawn along different axes in both OOP and FP.

The showcase example "Circle, Square, Rectangles are kinds of Shapes that have area" represents an abstraction that is present in the conceptual schema (aka Domain Model, aka Universe of Discourse, aka "problem space"), regardless of implementation style.

Likewise, what you call "mathematical abstraction" (and I'd prefer to call a "implementation model") is present both in OOP (eg "visitor pattern, inheritance, facade") and in FP (eg "fold, pattern match, monad"). I don't really think the difficulty in groking "visitor" is much different from groking "fold".

Re: Motivation – Keli Language

#263

Post by codygman »

dmitriid wrote: post #209
sfvisser wrote: post #13

I really appreciate the effort of designing the syntax to match common IDE expectations. However, I think it shouldn't be too difficult to add intellisense for Haskell-like syntax to IDEs as well. Especially with all the types available! The only unconventional thing is that the function might be put in-front of the value and some parentheses need to be added, instead of just putting it after the cursor like with met…

> I think it shouldn't be too difficult to add intellisense for Haskell-like syntax to IDEs as well. Especially with all the types available! On the contrary, this should give Haskell an advantage because all the types are known and the IDE should be able to autocomplete only the correct parameters. But that requires compiler-as-a-service, and GHC is not. And writing your own analyser for a language is quite a task.

> But that requires compiler-as-a-service, and GHC is not. And writing your own analyser for a language is quite a task.

Yep. Haskell-language-server is very nice, though there are some performance issues I've experienced with a template Haskell heavy large codebase.

For many cases though, the experiences is very smooth after install.

Install issues are close to being sorted out with static binaries being downloaded in the vscode extension for instance.

Re: Motivation – Keli Language

#264

Post by codygman »

bcrosby95 wrote: post #196
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…

I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to. Imperative languages have slowly been adopting some of these. 20 years ago you had people talking about how things like map and filter are confusing but nowadays most imperative languages have a version of it so obviously it isn't that confusing.

> I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to.

What you describe as a problem sounds like a solution to me :)

I'm curious whether you think there are imperative abstractions that could be used over the commonly used FP abstractions.

That avenue of discussion sounds potentially valuable and fun to me :)

Re: Motivation – Keli Language

#265

Post by codygman »

hannofcart wrote: post #175

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.

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

It's still Haskell though, which means it can compose nicely with all that idiomatic Haskell!

Further I'd argue that you typically don't have to go to that level of optimisation.

I'd be very confident in my above statement replacing node or Python REST apis at least, but can imagine that not holding true in other domains.

In that case though, my first point still holds and I find that advantage very powerful.

Re: Motivation – Keli Language

#266

Post by codygman »

1-more wrote: post #163
bauerd wrote: post #131

Earlier quoted context omitted.

>The other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful langua…

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 advantage (or potential problem as you see it) is typeclasses encourage thinking about the meaning and behavior of what you are doing.

For simple cases, the end result of no typeclasses can be compelling sometimes.

For larger cases, taking away that useful tool to wrangle inherent complexity usually results in more complexity taking the form of gobs more simple code that obsfucates the task at hand.

Re: Motivation – Keli Language

#267

Post by galimaufry »

agentultra wrote: post #29
laumars wrote: post #10

Earlier quoted context omitted.

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

Just spitballing, but you could have composition eat the name of an input to the outer function: Given f(x,y) and g(z), write

let q = (f .y g)(z=a) then q(y=b) = f(x=g(z=a), y=b)

let q = (f .x g)(z=a) then q(z=a) = f(y=g(z=a), x=b)

Aesthetically it would be kinda like the notation for fiber product.

Re: Motivation – Keli Language

#268

Post by csirob »

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

Earlier quoted context omitted.

Maybe in the 00s, but these days most languages have collapsed boiler plate down massively. This comes across as an old fashioned view (bordering on extremely old-fashioned).

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.

> If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

I honestly believe we're in a dire need for a more up-to-date metaphor that lets us better express our anger at a computer, due to monitors becoming paper thin and lightweight in the past decade or so.

Re: Motivation – Keli Language

#269

Post by dnautics »

bauerd wrote: post #131
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…

>The other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful langua…

if you don't mind losing static types, there's erlang and elixir.

> I want an FP ecosystem that's not rooted in research

Erlang is rooted in practicality. https://www.youtube.com/watch?v=7AJR66p5E4s&t=180s

Re: Motivation – Keli Language

#270

Post by webmaven »

csirob wrote: post #268
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.

> If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window. I honestly believe we're in a dire need for a more up-to-date metaphor that lets us better express our anger at a computer, due to monitors becoming paper thin and lightweight in the past decade or so.

> > If I see "@returns id integer The ID" one more time I'll be tempted to throw my monitor out the window.

> I honestly believe we're in a dire need for a more up-to-date metaphor that lets us express our anger at a computer, due to monitors becoming paper thin and lightweight in the past decade or so.

My experience may not be representative, but I believe I have encountered variants of "hurl the keyboard at the monitor" more often than "monitor out the window".

OTOH, that phrase doesn't account for laptops.

Post reply on HN