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

181–190 of 300 posts

Re: Motivation – Keli Language

#181

Post by Jaxan »

didibus wrote: post #170
m12k wrote: post #21

Earlier quoted context omitted.

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.

For a language that says it'll work hard to be IDE friendly, an IDE can easily show you the argument names and their order for any function. On IntelliJ, it even overlay them. Thus, you can be writer friendly and reader friendly, considering the reader uses an IDE.

But why not turn this around? Let the IDE autocomplete everything, so it’s easy for the writer (or even hide the named arguments). And have the named arguments in the source code, then all readers can read it no matter their IDE!

Re: Motivation – Keli Language

#182

Post by JadeNB »

qppo wrote: post #136
HelloNurse wrote: post #126

Earlier quoted context omitted.

I'd prefer readability to suffer because the fold over a monad needs something clever that requires a bit of reasoning to understand than because vast amounts of "readable" boilerplate (for example, trivial getters and setters) hide a needle in a haystack.

folding over a monad (or any other combinator) doesn't require extra reasoning or anything clever, that's the point.

I think HelloNurse's point was less that a fold is inherently clever or subtle (as you say, it isn't), and more that, if there is something clever or subtle involved, the lesser verbosity of the fold makes it easier to see than would a more familiar, boilerplate-heavy approach in which the clever or subtle point could be lost.

Re: Motivation – Keli Language

#183

Post by sfvisser »

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…

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

This feels backwards to me. If I‘m new and join your team I’m much more likely to understand what a monad and a fold are than to understand your domain specific business objects.

So if we are working for an insurance company and see the ‘Insurance’ type is an instance of Monad I now know a great deal about combing different insurance products into new derived ones. By reading a single word of code!

Re: Motivation – Keli Language

#184

Post by Joker_vD »

eitland wrote: post #162
rightbyte wrote: post #139

Earlier quoted context omitted.

VSCode is an IDE. Otherwise, what is am IDE according to you? Is Emacs an IDE? Eclispe?

VS Code (which I like and have used extensively for a number of projects) is kind of an IDE, but it doesn't quite compare to full blown Java IDEs IMO.

It's an editor with syntax highlighter, autocompletion, go-to-def, and go-to-uses that also builds the code, runs the code, runs the tests, and also allows you to run them (code & tests) under a debugger. Oh, and it also has projects/solutions/workspaces/whatever they're called.

Back in my days™ that's what they used to call an "IDE". But today that's just "glorified Notepad++", I guess? What features does it miss that stop it being a full-blown IDE?

Re: Motivation – Keli Language

#185

Post by smabie »

djhaskin987 wrote: post #42
agentultra wrote: post #29

Earlier quoted context omitted.

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…

That's the whole point of the syntax changes: to make the tradeoff that sacrifices terseness or efficiency or even composability in favor of readability. A lot of functional languages -- Haskell as I understand it is the biggest perpetrator -- optimize for code length and composability, trying to make things as expressive as possible, and decrying those who can't read something that has meaning densely packed into ev…

After learning some array languages, functional languages like Haskell are actually pretty verbose.

Moreover, I believe that in general, shorter code is more readable code. People just like to make excuses in order to avoid learning anything new.

Re: Motivation – Keli Language

#186

Post by Cybiote »

pjmlp wrote: post #86
fsloth wrote: post #69

Earlier quoted context omitted.

I don't think F# needs toys, though. The language is so well put together you don't miss much IDE assist anyway, except to point to you where your code will have problems compiling.

Sure it does, a language alone isn't much help if it only gets a tiny slice of the ecosystem. No .NET Native, GUI designers, WCF/gRPC, EF designers, Blend, WinUI tooling, ASP.NET templates,... hinders adoption at corporate level.

My experience is that, compared to most functional languages, F# has a great IDE experience in Rider, Visual Studio and VS Code. But when compared to big industry focused languages, like C# and Java, tooling is middling at best.

Ironically, despite .NET core being an excellent runtime, it suffers stigma from being assumed to be too tied to Microsoft platforms. This means, depending on your angle, F# lacking specialized ties to the Windows specific tooling you mention need not be considered a disadvantage.

Re: Motivation – Keli Language

#187

Post by enricozb »

laumars wrote: post #152
enricozb wrote: post #23

Earlier quoted context omitted.

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.

I don’t think it’s fair to say what’s readable to new developers is the same as what’s readable to experienced developers nor even every developer. For example the terse style of Sexpressions or C-style braces are off putting to some but after a short while they become second nature to visually parse (not saying all code should follow Those idioms, just using that as an example of how readability changes with experie…

I'm talking specifically about the function calls, which are effectively the same in C, Rust, Python, Lisp, Haskell, and many others. No matter how terse, it's always some form of

...

The absence/presence of parenthesis and commas don't add anything of semantic value here, so that's not really what I'm referring to.

The problem is, is that the values often don't have any meaning attached to them, especially when they are literals. C++ codebases are pretty bad about this with boolean parameters, just having a random `true` at the end of the function call.

Variable names at the call-site are good hints, but we often pass the same variable to different functions, and the name doesn't exactly fit the meaning of each function. This is why I think requiring named parameters, at least by default, is better.

Re: Motivation – Keli Language

#188

Post by achr2 »

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 aligned with where the general purpose language world is moving.

Re: Motivation – Keli Language

#189

Post by ghayes »

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

Re: Motivation – Keli Language

#190

Post by didibus »

I'm not a fan of this:

'Hello world' replaceFromIndex: 0 toIndex: 4 with: 'Bye'

At first sight you might think, oh great don't even need to read the documentation (which is the author argument in favour of this). But, is "toIndex" inclusive or exclusive? Don't know, so now I need to read the documentation anyways and just learn the behavior of the function. And once I did, all those names just become visual noise that my eyes need to skip over when reading and verbosity when writing.

Also, if you're going to go with this style, I'd much rather have function first (as FP should):

replace in: 'Hello world' fromIndex: 0 toIndex: 4 with: 'Bye'

Which brings me to my second point, I prefer languages that just allow both. Some functions are better positional and other named and some a mix of both. Let each function choose the most appropriate one. For example, are we really going to do this?

100 divide with: 5

or

divide theNumber: 100 with: 5

Ya, it reads like an explanation for a 5 year old, but as a professional programmer I'd much rather:

divide 100 5

My point being, certain functions are intuitive even with positional args and others arn't, only the latter should have named args.

Now for the intellisense section I agree, but I think you can solve it with IDE UX. Like just provide a command that lists all locals for you to pick and then lists all functions whose first argument is of that type. Or heck, have it that after you type a var name, it lists functions over it but the list shows to the left and when you pick it autocompletes the function text to the left of it.

Post reply on HN