Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

141–150 of 300 posts

Re: Motivation – Keli Language

#141
post #32

The author lists Ocaml as "non-IDE-friendly." This is not my experience. Ocaml is one of the most IDE friendly languages I have in my toolkit right now -- not just functional languages, but all of them. Ocaml + Emacs + Merlin is stable, accurate, very fast (responsive), and easy to set up and configure. Plus, named and named-optional parameters are supported in the language, and can be used to good effect for disambi…

Compare that to JavaScript where you can literally just install vscode and node and you’re up and running. Not to mention that you could pop open a console in any browser and execute code. I love OCaml as a language but we have to admit that the developer experience just sucks. For something to be simple, a 10 year old kid needs to be able to figure it out. That’s how languages get adopted.

Really? I've had much, much worse developer experiences with other languages. With opam and dune wrapping the default toolchain, honestly it's a pleasure to work with these days.

(I feel obliged to give an example of what I think is a bad developer experience, and I would point at Haskell. There are far too many toolchain variations to choose from, all of which seem to be in active use -- cabal, cabal-v2, stack, cabal-v2+nix, stack+nix; ghcid, ghcide, etc. etc. Once your choices are made and your stack is configured, you'll be okay, except for the inordinately long build times. But in my experience, it can be a real nuisance to come back to a half-finished Haskell project -- say, on a new machine -- unless you've made a singular, personal commitment to a specific technology stack. Leave yourself copious notes, Makefiles, and shell.nixes to remember how to get the thing running! But this is a personal sob-story and a digression.)

My main argument -- which I think is being lost here -- is that Ocaml isn't IDE unfriendly, and especially not so unfriendly that an entirely new language is needed just so that FP and IDEs can happily coexist.

(Well, except for Windows. Ocaml + Windows is more unpleasant than it needs to be.)

Re: Motivation – Keli Language

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

Disagree. Particularly since named arguments are part of the function name and in languages where you use named arguments you will often have very expressive overloaded function names. You might have 3 related functions like so: getStudent(datastore: DS, byId: number) getStudent(datastore: DS, byAssessmentId: number) getStudent(datastore: DS, firstName: string, lastName: string, birthdate: date) Without named paramet…

I get overloading is a popular way of writing DRY code but I’ve never been a fan of overloading either. You might dislike getSomethingBySomething style function names but it’s no different to the examples you’ve given in terms of readability but with the bonus of having fewer surprises.

Re: Motivation – Keli Language

#143

On the topic of language IDE support. One of the things I've noticed from working in a few languages professionally (Python, Ruby, Java, Elixir) is that the level of power required in an IDE seems to be a function of the language. My observation was that to feel comfortable in Java I tended to require a very powerful IDE (Intellej) to deal with refactoring and appeasing the type system. When I write Elixir, I feel co…

The biggest advantage of an IDE for me, in any language, is the ability to rename/move/refactor things across multiple files in a project correctly. I feel notably less capable in this regard when using Vim versus a "full" IDE, no matter what the context or project.

Yeah, this exact flow was a pain for me in switching from vscode to vim full time.

My flow now is to search for a bunch of instances using the fzf plugin (https://github.com/junegunn/fzf.vim) and open them into the quickfix list, then do something like

    :%s/old/new/gce | :w | :bnext

Re: Motivation – Keli Language

#144

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?

Re: Motivation – Keli Language

#145

Earlier quoted context omitted.

What an odd comment. >Compare that to JavaScript where you can literally just install vscode and node and you’re up and running As opposed to OCaml where you... install opam and merlin and you're up and running? >Not to mention that you could pop open a console in any browser and execute code. As opposed to OCaml where you can pop open utop and execute code. >For something to be simple, a 10 year old kid needs to be…

> How many 10 year old kids are there working as professional programmers? Many of them in 10 years time, and they will be using concepts they learned when they were 10. And FP enthusiasts would complain why no one uses their favourite language. My point is, if we want to get more people to use FP we have to make it more accessible. Everything from building better tooling, tutorials, environments. Good languages alon…

It would be nice if 10 year olds can be exposed to functional programming. But it's hardly a necessary prerequisite. There are plenty of technologies that people adopt later in life and which are hugely successful (SQL/RDBMS is a great example).

If you want to expose 10-year olds to functional programming, Logo [1] is a great place to start, and has been for decades. That's where I picked it up (I didn't know it at the time, but looking backwards it's now clear).

[1] https://en.wikipedia.org/wiki/Logo_%28programming_language%2...

Re: Motivation – Keli Language

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

Advocating for trading away readability in favor of easing the lives of devs who refuse to use an IDE doesn't seem like a win, especially in the context of a team.

I’m often writing code into vim (without any fancy plugins installed) and never had an issue. As I stated in my previous comment, I don’t particularly believe named arguments make it any easier to write without an IDE because you’re only trading memorising the order of parameters with the names of those parameters. Either way there’s still a minimum level of memorisation required.

I get each developer is different but personally I remember numbers and orders easier than names.

And frankly, if you have a developer who can’t learn the basics of the language they’re employed to work on yet also refuses to use any developer-friendly tools to assist him, then that’s a failing of the the developer and not the language.

Re: Motivation – Keli Language

#147
post #87

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 don't see a reason why some FP languages (e.g. lisp, or elisp) aren't IDE friendly. It might well be because where there is unpopularity, there is less effort to integrate, promote and maintain. If everything is a function and functions have positional parameters and everything named can be in a symbol table, why can't IDEs support (at least the basics of) FP languages?

I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html

That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But for an IDE's parser, or even for a new coder discovering the codebase, it's pretty tricky to figure out what the code does.

If somebody is ultra-familiar with Common Lisp but for some reason never learned how the loop construct worked they might be stumped when they encounter the following code:

    (loop for x in '(foo 2) 
          thereis (numberp x))
What does that do exactly? What will it evaluate? What will it return? Which one of these symbols are special keywords and which one just refer to variables or functions?

Meanwhile if you code in, say, C, the macro system is so crappy and clunky that you basically avoid it for anything complicated. Writing a similar LOOP macro in C would be an absolute shitshow (not that it prevented people from trying). As such C code tends to be much more verbose, but also much easier to follow if you know the core rules of the language.

Re: Motivation – Keli Language

#148

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…

This is impressively compréhensive and covers everything I thought of while reading the post. I also agree that OCaml needs a one click to opam+dune+utop+batteries+Merlin+editor experience, but new tools like https://www.gitpod.io/ help since your project can just describe everything declaratively and spin up a working environment. I expect this sort of tooling will help with a lot of languages which are not really integrated by default

Re: Motivation – Keli Language

#149

Earlier quoted context omitted.

I understand what you're saying, but something I have noticed over the years is that the amount of code that I can make sense of at any given time is actually proportional to what I can see onscreen at any given moment. I have had pretty good luck cheating this in a bunch of ways: I use a small font, a big display, and I use a terse programming style. Once you internalize a bunch of common higher-order functions, you…

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.

Re: Motivation – Keli Language

#150
post #147
post #87

Earlier quoted context omitted.

I don't see a reason why some FP languages (e.g. lisp, or elisp) aren't IDE friendly. It might well be because where there is unpopularity, there is less effort to integrate, promote and maintain. If everything is a function and functions have positional parameters and everything named can be in a symbol table, why can't IDEs support (at least the basics of) FP languages?

I don't know much about modern IDEs because I don't use them, but I suspect that the very powerful lisp macro system can be an issue for good IDE integration. Think of something like the "loop" construct in Common Lisp: http://cl-cookbook.sourceforge.net/loop.html That's related with the problem the parent is talking about: it's very easy to create DSLs in in languages like Common Lisp, so people use them a lot. But…

Perhaps if Macros where not such a mainstay and powerful element of some FP langs (I am not arguing against them), this argument would not be so strong. Macros in C/C++ are difficult for IDEs to deal with too, save for constants. Seeing though that macros are near fundamental to some FP langs, I understand better the driver for the design of Keli.
Post reply on HN