Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

271–280 of 300 posts

Re: Motivation – Keli Language

#271
post #268

Earlier quoted context omitted.

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

> OTOH, that phrase doesn't account for laptops.

It is also not anger-ready for people working on tablets with rubber keyboards attached.

Re: Motivation – Keli Language

#272

I personally don’t think keli is fixing the right problems: I’m personally an ocaml user, and I don’t see what keli adds to ocaml. They cite positional parameters (that they call "prefix notation"… i wonder why ?) but ocaml already has support for named parameters (you can write things like split ~on:"," "a, b, c" for example) Moreover, guessing the order of parameters is generally not that hard : — If you have good…

For writing code with IDE support, your comments about named vs positional parameters are spot on. But when it comes to reading code, an IDE should not be assumed and there is no problem with looking up well-named parameters.

For something Keli has that Ocaml doesn't: it is interesting to see a statically typed FP with multiple dispatch built in from the beginning.

Re: Motivation – Keli Language

#273
post #118

Earlier quoted context omitted.

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!

We’ve got to write argument names twice when we do it in typescript though:

  function foo({ bar }: { bar: string }) {
Still a great pattern, but I’d probably use it a lot more if I only had to write the variable names once.

Re: Motivation – Keli Language

#274

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…

> 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 connection with the business domain already.

Again, this might not be bad, it can even be good, but the problem is that many FP enthusiasts overdo it.

> In fact, I’ve seen a lot more unnecessarily abstracted garbage (usually “design pattern” workarounds to limitations in the object model) in just about every oop based web framework I’ve worked with.

Yes, this is the same problem which pops up in the OOP world as well. I guess it is a human thing to want to use your latest powerful language tool wherever you see a possibility for it.

Re: Motivation – Keli Language

#275
I am going to call bullshit on this:

1) Function argument order is not an issue in practice. Especially Elixir or OCaml providing keyword arguments. Also, there are mostly conventions eg search term comes first in replace function.

Elixir, F# all provide Pipes, while little more verbose than dot notation, more universal than methods on objects.

2) IDE support: above points apply, although pervasive type inference may make few things hard. It is best practice to annotate function signatures.

The real reasons why FP languages are unpopular are:

1. immutability is often a bad abstraction and some FP languages often make performance/memory reasoning harder[0].

2. Your 9-5 engineer doesn't want to learn anything more than what they learned in school or bootcamp.

3. The impression created by some FP language communities. There are some people always talking some complicated category theory stuff that's rarely useful for programming, or propagating zero information statement like "If it compiles it works". [1]

[0] "bUt ItS lIKe gRaDuAtE aBsTrAcT mAThEmAtICs it must be good and elegant even if the machine doesn't work like this". Go and learn some real computer science, algorithms, data structures, number theory, probability, instead of touting your definitions of undergraduate logic and set theory.

[1] There is more chance it works, sure. But "If it compiles, it works" is dishonest statements.

Re: Motivation – Keli Language

#276
post #77

Unfortunately, no direct comparison to Lisps. The two downsides mentioned regarding FP are not an issue if you are using a REPL and a Lisp: - excellent IDE support, since you are working inside your program (which can be inspected) - paradigm a la carte: you want named arguments? Go for it (split :string "foo,bar" :by ",") you want different invocation syntax? (3 + 4) or (3 4 +) is just a macro away and a bit easier…

Except everything is brittle leaky abstraction.

Re: Motivation – Keli Language

#277
post #268
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.

Putting fist through the monitor?

Re: Motivation – Keli Language

#278
post #259

Earlier quoted context omitted.

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

Isn’t that why language server protocol is a thing?

Yup, kudos to MS for coming up with it and standardizing it.

(the following is just what I think, I have no hard knowledge on the matter)

Language server still limits what an IDE can do. E.g., IDEA can do complex large scale refactoring and analysis over a codebase. If you're brave enough, you can write your own language analyzer that converts your language into structures IDEA understands, and you can get (some) of the same benefits. But it's a lot of work.

IIRC, language server can only provide rather superficial type information and autocompletion (which is still way more than many languages had before).

Re: Motivation – Keli Language

#279
post #251

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.

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 documentation feature, which you definitely should not be using to annote obvious stuff like IDs, that's your problem, not OOPs.

Switching to a functional language won't save your monitor, you'll still be forced to write bad code if doing stupid things like that are in your style guide.

Re: Motivation – Keli Language

#280
I'm not sure those are the things holding FP back. The statement "The user experiences of functional programming languages sucks." sounds really weird and is the exact opposite of my experience. I write Elixir professionally. The developer experience is unparalleled and I definitely wouldn't trade it for a job writing Java 9 to 5.

Maybe it's trying to refer to stuffs such as existing libraries and package management etc. when you want to quickly boot up a real-world project. I once tried to write some web app in Haskell and that experience definitely was anything but smooth. Fortunately Elixir has a really vibrant community and libraries for the majority of common tasks (plus 20+ years of Erlang ecosystem). It's also really easy to roll your own solutions.

I don't think the issues of IDE support and parameter ordering mentioned in this article are problems to FP programmers at all. Powerful language servers exist nowadays for all major functional languages and they're not that different from language servers for OO languages. So yeah I tend to agree with a lot of commentators that this article doesn't seem to make much sense unfortunately.

Post reply on HN