21 ms·

Motivation – Keli Language

285 points by azhenley 6y ago

_raz 6y ago
If great IDE support and ux for developers is the goal wouldn't it be more reasonable to spend the time on IDE support on existing FP languages rather then creating a new one? It seems that Hindley-Milner type system of many existing languages should lend it self well for language servers in general. But what do i know
beders 6y ago
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 to read than: (this Int).square | Int = this.*(this) YMMV you want to define your data shape? use your favorite schema language you want monads? just use a library you want go-routines? just use a library you want compile time types? just use a library
- higerordermap 6y ago
  Except everything is brittle leaky abstraction.
deleted 6y ago
[deleted]
maest 6y ago
The following example is kinda funny: // 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(",") Seeing as Python uses the first version for .join()
- IshKebab 6y ago
  Yeah Python (and I think JavaScript?) pretty clearly have `join` backwards.
  - b34r 6y ago
    JS uses the second example
    - linkdd 6y ago
      It is because in Javascript everything can be translated to a string: 1 + "hello" == "1hello" Therefore, the type Array can have a join method that have predictable results (unlike Python).
      - Zarel 6y ago
        I don't know what that has to do with `join`'s call order. As mentioned above, it's because Python supports `join` on any sequence, not just the array class. Personally, I find JavaScript's solution neater: [..."hello"].join(" ") === "h e l l o"
        linkdd 6y ago
        Because when the Javascript engine will try to concatenate all the strings in the Array (the expected behavior of join), it will first translate every object in the array to a string. Javascript always falls back to string, that is also why we have === and == operators. Python's type system is a bit more strict because it will not attempt to serialize your objet if you haven't explicitly done it yourself. My point is: Python doesn't use this notation because it would not make sense in Python.
        maest 6y ago
        This is also the cause of this lovely bit of JS behaviour: >>> [1,2,10].sort() Array(3) [ 1, 10, 2 ]
rubyist5eva 6y ago
You can achieve this style with Ruby and keyword arguments, no new language required.
- identity0 6y ago
  And you can emulate most of C++ in C with macros. Doesn't mean you should.
  - rubyist5eva 6y ago
    false equivalence, there is no "emulation" of features they are native to the language
enricozb 6y ago
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 than a class. The proposed solution by Keli is to be inspired by the Smalltalk-style message syntax: 'Hello world' replace: 'Hello' with: 'Bye' I think, in general, requiring named arguments is a good thing. Swift does it, and in codebases with a decent amount of TLC, it looks great. Function calls are one of the weird places were the syntax of the language rarely helps you figure out what is going on, and for the most part is just a sequence of human-written names one after another, and in languages with custom operators it could be even terser. In comparison, if-statements, loops, pattern matching, etc. were (hopefully) designed to be expressive. I think by requiring named arguments, function calls will also be much more readable, relying less on an active human effort to do so.
- laumars 6y ago
  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 with hinting then the advantages become moot as the same IDE would hint the order of parameters).
  - m12k 6y ago
    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.
    - implicit 6y ago
dvh 6y ago
Noun verb. Haystack needle.
ollysb 6y ago
While I could get onboard with functional languages being more user friendly I didn't find the motivation to be compelling. > Ambiguous functions argument positions It just seems to be advocating for named arguments, something which the majority of languages (OO or FP) support these days. You could say that requiring named parameters is a feature but it's hard to get excited about. > Not Intellisense friendly I use Elm and Elixir, both of which have decent autocomplete in vscode (and I believe many other editors). Critique aside I definitely applaud more towards increasing FP adoption. I think Elm has brought many good ideas to the table already (though admittedly it's bias is more towards ideal than practical). On the flip side Elixir is very pragmatic and easy to get going with for developers coming from OO languages.
- dnautics 6y ago
  Elixir is very good about function positions, too, by being consistent in it's stdlib, and by pinning structs to modules. Almost all library writers adhere to the convention.
  - dmitriid 6y ago
    People are also consistent because of the pipe operator which was there since the very beginning. So everyone expects functions to work with chaining correctly. That's why you get params that get changed a lot as the first parameter etc.
sfvisser 6y ago
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 method syntax. I assume you get used to that rather quickly.
- pjmlp 6y ago
  Like Leksah.
- dmitriid 6y ago
  > 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.
  - newen 6y ago
    Isn’t that why language server protocol is a thing?
    - dmitriid 6y ago
      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).
  - 6y ago
tobr 6y ago
Great to see the motivation spelled out clearly, but something seems strange. If you read the Quora answer, it just rants about how functional programming is obsessed with big words and esoteric concepts that are hard to grok, and that this constitutes poor UX. But Keli’s interpretation seems to be that the moment-to-moment experience in the IDE is poor, and that that’s what the language wants to address with more explicit syntax and intellisense support. These seem like two very different problems under the umbrella term “UX”.
centimeter 6y ago
I disagree with all points in the article - the user experience with existing FP languages is superior, and the IDE integration for strongly typed languages is generally very impressive. Syntactic window dressing isn’t what makes or breaks a language.
SomeoneFromCA 6y ago
I've almost misread it as "Keil", which brought bad recollections of their IDE C/C++ IDE.
exclipy 6y ago
Anyone else irked by the use of "Intellisense" - a Microsoft brand - when "autocomplete" will do?
- carlmr 6y ago
  Are you irked by Q-tips and Kleenex as well?
  - MrPowers 6y ago
    These are referred to as "generic trademarks" if you're interested in learning more: https://en.wikipedia.org/wiki/Generic_trademark https://en.wikipedia.org/wiki/Generic_trademark. Generic trademarks are studied in economics and have legal implications.
- 52-6F-62 6y ago
  Seems like they're complaining (for lack of a better word) about only having word autocomplete available for most functional languages versus a more refined suggestion tool like Intellisense. But yeah, they don't get that specific about that fact. I guess Intellisense has entered the realm of Kleenex in how it's used.
  - Nullabillity 6y ago
    Mostly in .NET communities though, from what I've seen.
- alkonaut 6y ago
  Code completion (autocomplete) is a subset of intellisense. Intellisense also provides e.g. info tooltips on hover and more. But yes, I agree since the author specifically talks about the way OO languages provide a more easily autocompleted syntax and parameter help doesn't really differ, perhaps the better term to use here would be autocomplete or code completion.
GrinningFool 6y ago
Another way to solve the problem the author is looking to fix is by convention: splitStringBy "1,2,3,4,5" "," ^ action ^ Arg1 ^ Arg2
gmfawcett 6y ago
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 disambiguating function parameters of similar type (the split, join problem).
- hashbig 6y ago
  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.
  - carlmr 6y ago
    >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. That's only because VSCode was developed in JavaScript, and JavaScript is used in Browsers anyway. This has nothing to do with Intellisense friendliness.
    - hashbig 6y ago
      No, golang is just as easy to install and work with on vscode. Just install Go and the official Go plugin and you have an IDE experience complete with debugging, formatting, and intelligent autocomplete. It has nothing to do with vscode being written in JS.
      - pjmlp 6y ago
        Same applies to F#, a ML based language.
      - 6y ago
hellofunk 6y ago
We've built our SAAS on Keli for the last six years and have been amazed by the productivity. Each year we are able to make a net reduction in lines of code. We are now down to only 2 lines, and we expect next year to be the most impressive yet for what we will need to maintain.
- azhenley 6y ago
  Any chance you have a write up about your experience with it??
  - bboy13 6y ago
    I'm pretty sure this is a joke. There's no way you can run a SaaS on two lines of code... Unless it's some bizzarely simple calculator or something like that.
    - lostcolony 6y ago
      Of course it's a joke. Sibling comments aside (without comment on my part), it would be hard to have 6 years of production use of a language that has its first git commit 2 years ago.
    - mst 6y ago
      APL programmer bursts through the window "ACTUALLY! ..."
    - linkdd 6y ago
      Do not underestimate oneliners
    - throwaway43234 6y ago
      I agree it's probably a joke, but I'm not so sure that the core idea is actually impossible... I could reasonably see a SaaS that simply provides a quick and dirty key-val store. The code is just a translation from REST to REDIS which could easily be done in 2 lines, the value-add is the hosting. That'd actually be pretty helpful for initial prototyping, where you want to have state shared across devices but don't want to bother with hosting a backend at first, and localhost wont work because the client wants to play with it too.
ciuncan 6y ago
I find the syntax as the author intended it to be: clean. I agree with the ambiguity of positional parameters at first glance. Although named parameters (e.g. in Scala) somewhat solve this, they are optional. Having the parameters with their explicit name makes it quite readable. myList .append(5) .reverse .put(5) atIndex(0) .++(anotherList) .select(x | x.isEven) Edit: The same feature makes it look a little weird when put on a single line, because we mentally parse the whitespace as separator but in this case it is not: $.name("Keli") age(50).isOld It looks like a refreshing addition to function programming languages and I'd like to see where it goes from here, in terms of adoption and features.
- mst 6y ago
  $.name("Keli" :age 50).isOld wold've been nicer to me but ah well.
  - ogre_codes 6y ago
    I agree, having age(50) separate almost looks like a separate function call.
  - lgessler 6y ago
    I can understand $.(:name "Keli" :age 50) but not $.name("Keli" :age 50), why should the age bit go inside the parens? This introduces an asymmetry where the first key appears outside parents and subsequent keys appear inside (and as colon-initialed keywords?!)
hashbig 6y ago
Elm single handedly got me into functional programming. Everything from the syntax to the standard library. I haven’t used a language that was that elegant and delightful to use perhaps since I discovered Ruby. It makes me really sad that Elm turned to this niche language/framework that it is today. I had hoped for it to grow someday to have a mobile target in addition to web, to be able to use it on the server, hell even to be able to use it to build systems. So much wasted potential.
- Kaze404 6y ago
  I also love Elm, but the fact that it is a niche language now doesn't mean it's all it ever will be. There's nothing really stopping anyone from adapting Elm to the server for example, but the reason it hasn't been done yet is because it's best to focus on solving one problem at a time. If Evan just translated the Node standard api 1:1 for example, it wouldn't be Elm or Node and there would be no reason to use it.
  - pcstl 6y ago
    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.
    - lalos 6y ago
      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 contribute but need to get more familiar with FP before contributing to a higher level FP library. I remember one where the proposal could be easily be implemented generically with ports and any other JS library instead of bringing some weird binding logic to A specific JS library. Add the fact that devs from the FP world are concise with their explanations and you have a recipe for miscommunication problems when trying to explain why that idea is DOA to someone not familiar with core FP concepts.
jayp1418 6y ago
Is this being developed? How similar this is to ada ?
- throwaway43234 6y ago
  Hasn't been touched in over a year. https://github.com/KeliLanguage https://github.com/KeliLanguage
  - cridenour 6y ago
    Maybe they broke up.
- hou32hou 6y ago
  Nope because I’m not convinced by this language anymore
misja111 6y ago
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 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. Maybe there should be a new edition of Clean Code written specifically for FP, to address this anti pattern. By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.
- bcrosby95 6y ago
  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.
  - mrkeen 6y ago
    I don't know if this counts as irony, but here goes: The killer feature of programming with pure functions is that you can guarantee the same output for the same input. If I were pushing this idea 5+ years ago, I would have said "Unfortunately you have to give up your comfortable for-loops and mutable variables* and learn about these weird maps and folds instead, but it's well worth the trade!" Fast-forward a few years and now maps and folds are everywhere in the mainstream (it's even recommended to use them over for-loops in many cases.) But we never got the same-input-same-output guarantee which was my reason for switching in the first place! * Even that's being too pessimistic. You can have your mutable cake and keep your guarantees, too: https://wiki.haskell.org/Monad/ST#A_few_simple_examples https://wiki.haskell.org/Monad/ST#A_few_simple_examples
whateveracct 6y ago
Wadler's Law at work
fsloth 6y ago
The author lists F# as not IDE friendly. I find this categorization inaccurate. F# works great with Visual Studio, and especially well with intellisense. F# was designed as industrial language from the beginning, and high quality tooling is a large part of that. It might just be me, though, maybe other people use the language in ways that don't work that well there.
- pjmlp 6y ago
  The only issue with F# is that it is a bit the black swan of Microsoft languages on .NET, so it doesn't get all the toys that C#, VB.NET and even C++/CLI get to play with.
  - deleted 6y ago
    [deleted]
  - fsloth 6y ago
    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.
    - pjmlp 6y ago
      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.
      - Cybiote 6y ago
        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.
theshetty 6y ago
Why is no one talking much about Scala? (https://docs.scala-lang.org/overviews/scala-book/functional-programming.html https://docs.scala-lang.org/overviews/scala-book/functional-...)
- pmarreck 6y ago
  Because we're trying to turn people on to functional programming, not off EDIT: Downvotes already? Look, Scala is NOT noob-friendly, and it's a rational argument, not a preference. Here's an example: There are at least 10 (TEN) different uses of the underscore character (_) in Scala. JFC. I can go on, such as the proliferation of bizarre operators everywhere that are impossible to Google (again, not noob-friendly), the reliance on JVM (ewww... so you end up having to be a Scala expert AND a Java expert... plus deal with JVM windup time and JVM stacktraces... Not noob-friendly), the consistent violation of POLS, etc. etc.
  - haggy 6y ago
    When is the last time you used it? I've been a full time scala developer for over 4 years now spanning versions 2.11, 2.12, and now heading into 2.13. There have been massive improvements across consistency and huge convergences happening across the scala FP community in terms of library usage. > the reliance on JVM (ewww... so you end up having to be a Scala expert AND a Java expert... plus deal with JVM windup time and JVM stacktraces... Not noob-friendly) This is just plain weird. This makes me feel like you spent zero time actually working with the JVM and it's incredible ecosystem. Being fully inter-operable with Java is a huge win for both adoption and usability. Not only that but the JVM is one of the most mature runtimes in existence with massive amounts of documentation and help available.
  - non-entity 6y ago
    Honestly some of the reasons I stay away from learning Scala are the same one that keep me from learning C++
  - adav 6y ago
    Nothing’s noob-friendly if you begin with advanced features. Scala is eminently beginner friendly when introduced to developers familiar with OOP. This approach was how I first experienced Scala and it ended up becoming a gateway drug into FP proper. Regarding underscores in Scala, yes there are many technical terms for each thing it has the capability of representing... but in reality, you just use it wherever you want to ignore a value with a placeholder or pass a provided value through.
pmarreck 6y ago
Elixir already solved that problem tho :)
endergen 6y ago
Off serious topic: Naming it after you girlfriend is a risky move, like getting a tattoo of her. Better get married and stay that way or the next partner is gonna be like: "wtf", you still working on your tribute to your ex programming language!?
- omarhaneef 6y ago
  I don't know what the problem is. After that you only date people who have the same name as your programming languages. "Did something happen?" "Sorry. I just had the wrong idea about you, Kaley."
- Kinrany 6y ago
  Breaking changes after every breakup
- green_apple 6y ago
  debian says hello
  - riffraff 6y ago
    there's also, ALIX[0] more commonly known as HURD [0] https://biblioweb.sindominio.net/telematica/open-sources-html/node62.html https://biblioweb.sindominio.net/telematica/open-sources-htm...
- deweller 6y ago
  But it is too late now. Her: "Why did you change the name?" Him: "Because I'm hedging my bets in case our relationship does not outlast my pet programming project". Her: "..."
- didip 6y ago
  This isn't too bad. We live in Git society now. After the breakup, fork, rename to the new girlfriend name, and put a notice on README.md: "I broke up with Keli but don't worry, I am with Sandra now. Please follow the new language <a href="https://sandralang.org">here</a>" https://sandralang.org">here</a>"
azhenley 6y ago
There was some discussion on Reddit over a year ago that was interesting too: https://www.reddit.com/r/ProgrammingLanguages/comments/acrj9g/request_for_comments_on_my_new_language_keli/ https://www.reddit.com/r/ProgrammingLanguages/comments/acrj9...
ogre_codes 6y ago
This seems like a dead project. It's fairly unknown and hasn't been updated in over a year.
- garmaine 6y ago
  Maybe they broke up?
  - hou32hou 6y ago
    No no we haven’t broke up yet
- hou32hou 6y ago
  Yea it is indeed halted, because I’m still in search of a better syntax.
pbiggar 6y ago
I'm very sympathetic to the problem. I'm working on Dark (https://darklang.com https://darklang.com) which is a functional language, explicitly because we believe that functional languages are easier to learn, understand and provide great tooling for. It seems to me there's a lot of focus on syntax, and I don't think they've gotten to a great place. For example: (this Int).square | Int = this.*(this) In Rust, they do impl Int { fn square (self) -> Int { self * self } } I can read the Keli version, but I'm note sure that `(this Int)`, `|`, and `.*` are great inventions. You need a good reason to deviate from commonly recognized syntax, and Keli doesn't feel like it's made things simpler with this. In Dark, we use piping heavily to get the benefits of the dot-syntax. In particular, it can be type directed: 8 |> Int::square |> Int::log 2 The autocomplete will only show you integer functions in this case. For the problem of "which parameter" - our IDE shows parameter names when your cursor is in a position to type the next parameter, so you know what you're adding it is. We also show the parameter names when your cursor is in the completed argument so you know what parameter it is. (I couldn't see if Keli did this, it might not be possible in modern editors).
deleted 6y ago
[deleted]
crvdgc 6y ago
Haskell Language Server (https://github.com/haskell/haskell-language-server https://github.com/haskell/haskell-language-server) offers a pretty good IDE experience. It also mitigates the parameter naming problem. With a type hole, the language server will infer the type. But in the case of two parameters having the same type, you have to consult the definition or doc.
grantjpowell 6y ago
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 comfortable using a much less powerful (from a language integration standpoint) Vim, mostly due to the constraints Elixir has in the language. In Elixir, there is no mutable state, I can feel confident that the only things affecting a function are the things in front of my face when reading it. Elixir's alias/import syntax make it pretty easy to jump to the file that has a function definition in. I think FP languages tend to have an edge in how much power an IDE is required to have, because those languages tend to have features like immutability and composable higher order functions)
- nerdponx 6y ago
  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.
  - grantjpowell 6y ago
    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 https://github.com/junegunn/fzf.vim) and open them into the quickfix list, then do something like :%s/old/new/gce | :w | :bnext
    - throwawaw 6y ago
      Is fzf buying you anything over just using :grep? (If speed is the issue, the magic words are `set grepprg='rg --vimgrep'`, after which it's actually usable.)
barrister 6y ago
Can someone point out how Keli implements purity in the documentation? Haskell requires the IO monad to accomplish this, not sure what Keli does. Its feature list claims to implement "pure functional programming" but it seems as though it's just functional, like OCaml or F#.
gdsdfe 6y ago
another terrible programming language website ...
mmphosis 6y ago
reads out more naturally set the delimiter to comma split 1,2,3,4,5 or split 1,2,3,4,5 by comma
leafboi 6y ago
On the post it says Haskell is not IDE friendly. It is really hard to make an IDE around Haskell or does it just that it lacks support?
- whateveracct 6y ago
  It's just a matter of time investment imo. And with the current ghcide effort, that's already happening! The argument that you need method-style syntax to have good IDE support is short-sighted. Haskell has something more powerful (typed holes), so a common thought is Haskell needs a different sort of IDE support and not expect it to feel the same as Java.
nephanth 6y ago
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 intellisense your IDE will tell you which parameter is which (how they are called in doc) — If you have good intellisense, your ide will tell you the type of function, which, with strict typing is sufficient in a lot of cases (think "send : Unix.socket -> string -> unit", the type tells you the order of arguments) — with named parameters, you don’t have to look up the order of parameters… but you have to look up their names, same problem — This last one is pretty subjective, but in a lot of cases you can guess the order of parameters by thinking "on which argument does it make sense to do partial application ?" `splitBy ","` makes sense, `splitBy "a, b, c"` doesn’t really… so "," is the first argument (but that is subjective) For IDE support, with the right tools, in my experience it is pretty good (ocaml-lsp or merlin do the job pretty well, and strict typing often allow for better intellisense than on non-functional languages) Though there we arrive at the real problem I’ve experienced : the tooling. It’s not actually that bad. more like it’s badly explained. how do you know that you are supposed to install — opam for package management (and reinstall ocaml via opam) — dune for building — utop as a REPL, because the basic REPL sucks — batteries or janestreet-core for "standard library" because the standard library sucks (and which one anyway ?) Plus these tools are hard to use at beginning / have a learning curve. (why can’t creating a project be as simple as - type "cargo new project" -> now you automatically have a project dir with a local opam switch, an opam file, a dune file, an example program, and basic utilities installed in that switch ? ) Personally, I think that’s what fp lacks the most right now (though I’m probably influenced a lot by ocaml) : easy to use and flat-learning curve tooling
- marmaduke 6y ago
  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/ 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
daxfohl 6y ago
I like the idea but I think the tactics are wrong. The better approach would try to make the experience as much like OOP as possible. Like the named argument, message passing thing is nice, but it's going to be just one more thing that the 95% is going to have to get used to. If the goal is approachability, then have to get it as close to existing experiences as possible.
yters 6y ago
i do not agree with the implief premise that functional programming is not inherently the act of joy itself
rishav_sharan 6y ago
With every new upcoming language, I always have the same ask; Please add a couple of section on what can we do with the language today. Rust has amazing sites like arewegameyet or arewewebyet. A single paragraph around what users can realistically do with this language and what are the most used packages in the ecosystem will be a great help to anyone curious about it.
- spicybright 6y ago
  Wow, those sites are a really good idea. I wish tech was more honest with it's pro's and con's. Seems like most project maintainers want to be marketers than engineers sometimes...
gridlockd 6y ago
If I want to do functional programming, I can do that just fine in most languages. If I want to do imperative programming, I can do that just fine in most languages, except for functional programming languages.
- spicybright 6y ago
  I think the key with a functional language is given a large codebase, you can reason about it functionally instead of hoping there's no imperative code in there (on purpose or by bug)
  - gridlockd 6y ago
    Kind of like if you're wearing a straitjacket, you don't need to worry about accidentally punching yourself in the face.
fouric 6y ago
I feel like the named reasons, aside from being invalid (it should be really really easy to make a popup that tells you the function parameter names and/or types, like SLIME has been doing for...decades? with Common Lisp), are really bad justifications for creating an entirely new programming language. Surely the effort would be better spent on improving the tooling, because all of their concerns are tooling-related. That also makes the language not about a "good user experience" as given in the docs, but "being compatible with modern IDEs". No thanks, I would rather improve tooling for an existing language that already has a community and ecosystem.
ConanRus 6y ago
>a joy for users But.. we already have H-l for that!
hannofcart 6y ago
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.
- codygman 6y ago
  > 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.
stark3 6y ago
On the AS400 there's a 'command' object type that deals with both issues the Keli language is trying to address. - Argument positions are named, help text, validity checking, special values, etc are defined for each argument. - Command arguments can be prompted within the editor (intellisense). As400 commands can also be prompted and executed by a user, thus providing a common user interface for running jobs as well. I've seen nothing like this in the PC world. The two issues the Keli language is trying to solve were addressed 30 years ago on the as400.
shaunxcode 6y ago
I got excited at the idea of smalltalk syntax in functional clothing but it never seemed to deliver?
- hou32hou 6y ago
  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
  - shaunxcode 6y ago
    Keep going!
didibus 6y ago
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.
adultSwim 6y ago
The F# IDE is really good actually
galaxyLogic 6y ago
>However, OOP languages also suffers the same problem whenever the number of function/method arguments get more than two, for example: Well yes except Smalltalk, the original OOP-language. Smalltalk requires you to use KEYWORD METHOD-NAMES whenever you have > 2 arguments. That makes Smalltalk code highly readable. (I told you so 20 years ago today) :-)
higerordermap 6y ago
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.
- SZJX 6y ago
  Yeah I agree that those two points don't make much sense whatsoever. Though I also don't agree with your point 1. I don't know if you have had much experience writing a functional language professionally. The benefit of immutability is exactly to make reasoning about your program much easier. Of course as you mentioned computers are indeed based on the von Neumann model, so in the end we sometimes have to go into memory usage details. However, unless you're programming some high-performance game, the vast majority of programs run totally fine with mostly immutable data structures. It's also especially suited for distributed computing (e.g. actor model) which is becoming the norm nowadays. In 95% of programming activities, the traditional "real computer science (what is "fake" computer science?), algorithms, data structures, number theory, probability" are used surprisingly rarely, while the elegance of functional/mathematical reasoning really makes the programming experience much more enjoyable and bug-free.
  - 6y ago
SZJX 6y ago
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.

285 points by azhenley 6y ago

_raz 6y ago

If great IDE support and ux for developers is the goal wouldn't it be more reasonable to spend the time on IDE support on existing FP languages rather then creating a new one? It seems that Hindley-Milner type system of many existing languages should lend it self well for language servers in general. But what do i know

beders 6y ago

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 to read than: (this Int).square | Int = this.*(this) YMMV you want to define your data shape? use your favorite schema language you want monads? just use a library you want go-routines? just use a library you want compile time types? just use a library

higerordermap 6y ago
Except everything is brittle leaky abstraction.

deleted 6y ago

[deleted]

maest 6y ago

The following example is kinda funny: // 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(",") Seeing as Python uses the first version for .join()

IshKebab 6y ago
Yeah Python (and I think JavaScript?) pretty clearly have `join` backwards.
- b34r 6y ago
  JS uses the second example
  - linkdd 6y ago
    It is because in Javascript everything can be translated to a string: 1 + "hello" == "1hello" Therefore, the type Array can have a join method that have predictable results (unlike Python).
    - Zarel 6y ago
      I don't know what that has to do with `join`'s call order. As mentioned above, it's because Python supports `join` on any sequence, not just the array class. Personally, I find JavaScript's solution neater: [..."hello"].join(" ") === "h e l l o"
      - linkdd 6y ago
        Because when the Javascript engine will try to concatenate all the strings in the Array (the expected behavior of join), it will first translate every object in the array to a string. Javascript always falls back to string, that is also why we have === and == operators. Python's type system is a bit more strict because it will not attempt to serialize your objet if you haven't explicitly done it yourself. My point is: Python doesn't use this notation because it would not make sense in Python.
        maest 6y ago
        This is also the cause of this lovely bit of JS behaviour: >>> [1,2,10].sort() Array(3) [ 1, 10, 2 ]

rubyist5eva 6y ago

You can achieve this style with Ruby and keyword arguments, no new language required.

identity0 6y ago
And you can emulate most of C++ in C with macros. Doesn't mean you should.
- rubyist5eva 6y ago
  false equivalence, there is no "emulation" of features they are native to the language

enricozb 6y ago

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 than a class. The proposed solution by Keli is to be inspired by the Smalltalk-style message syntax: 'Hello world' replace: 'Hello' with: 'Bye' I think, in general, requiring named arguments is a good thing. Swift does it, and in codebases with a decent amount of TLC, it looks great. Function calls are one of the weird places were the syntax of the language rarely helps you figure out what is going on, and for the most part is just a sequence of human-written names one after another, and in languages with custom operators it could be even terser. In comparison, if-statements, loops, pattern matching, etc. were (hopefully) designed to be expressive. I think by requiring named arguments, function calls will also be much more readable, relying less on an active human effort to do so.

laumars 6y ago
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 with hinting then the advantages become moot as the same IDE would hint the order of parameters).
- m12k 6y ago
  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.
  - implicit 6y ago

dvh 6y ago

Noun verb. Haystack needle.

ollysb 6y ago

While I could get onboard with functional languages being more user friendly I didn't find the motivation to be compelling. > Ambiguous functions argument positions It just seems to be advocating for named arguments, something which the majority of languages (OO or FP) support these days. You could say that requiring named parameters is a feature but it's hard to get excited about. > Not Intellisense friendly I use Elm and Elixir, both of which have decent autocomplete in vscode (and I believe many other editors). Critique aside I definitely applaud more towards increasing FP adoption. I think Elm has brought many good ideas to the table already (though admittedly it's bias is more towards ideal than practical). On the flip side Elixir is very pragmatic and easy to get going with for developers coming from OO languages.

dnautics 6y ago
Elixir is very good about function positions, too, by being consistent in it's stdlib, and by pinning structs to modules. Almost all library writers adhere to the convention.
- dmitriid 6y ago
  People are also consistent because of the pipe operator which was there since the very beginning. So everyone expects functions to work with chaining correctly. That's why you get params that get changed a lot as the first parameter etc.

sfvisser 6y ago

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 method syntax. I assume you get used to that rather quickly.

pjmlp 6y ago
Like Leksah.
dmitriid 6y ago
> 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.
- newen 6y ago
  Isn’t that why language server protocol is a thing?
  - dmitriid 6y ago
    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).
- 6y ago

tobr 6y ago

Great to see the motivation spelled out clearly, but something seems strange. If you read the Quora answer, it just rants about how functional programming is obsessed with big words and esoteric concepts that are hard to grok, and that this constitutes poor UX. But Keli’s interpretation seems to be that the moment-to-moment experience in the IDE is poor, and that that’s what the language wants to address with more explicit syntax and intellisense support. These seem like two very different problems under the umbrella term “UX”.

centimeter 6y ago

I disagree with all points in the article - the user experience with existing FP languages is superior, and the IDE integration for strongly typed languages is generally very impressive. Syntactic window dressing isn’t what makes or breaks a language.

SomeoneFromCA 6y ago

I've almost misread it as "Keil", which brought bad recollections of their IDE C/C++ IDE.

exclipy 6y ago

Anyone else irked by the use of "Intellisense" - a Microsoft brand - when "autocomplete" will do?

carlmr 6y ago
Are you irked by Q-tips and Kleenex as well?
- MrPowers 6y ago
  These are referred to as "generic trademarks" if you're interested in learning more: https://en.wikipedia.org/wiki/Generic_trademark https://en.wikipedia.org/wiki/Generic_trademark. Generic trademarks are studied in economics and have legal implications.
52-6F-62 6y ago
Seems like they're complaining (for lack of a better word) about only having word autocomplete available for most functional languages versus a more refined suggestion tool like Intellisense. But yeah, they don't get that specific about that fact. I guess Intellisense has entered the realm of Kleenex in how it's used.
- Nullabillity 6y ago
  Mostly in .NET communities though, from what I've seen.
alkonaut 6y ago
Code completion (autocomplete) is a subset of intellisense. Intellisense also provides e.g. info tooltips on hover and more. But yes, I agree since the author specifically talks about the way OO languages provide a more easily autocompleted syntax and parameter help doesn't really differ, perhaps the better term to use here would be autocomplete or code completion.

GrinningFool 6y ago

Another way to solve the problem the author is looking to fix is by convention: splitStringBy "1,2,3,4,5" "," ^ action ^ Arg1 ^ Arg2

gmfawcett 6y ago

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 disambiguating function parameters of similar type (the split, join problem).

hashbig 6y ago
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.
- carlmr 6y ago
  >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. That's only because VSCode was developed in JavaScript, and JavaScript is used in Browsers anyway. This has nothing to do with Intellisense friendliness.
  - hashbig 6y ago
    No, golang is just as easy to install and work with on vscode. Just install Go and the official Go plugin and you have an IDE experience complete with debugging, formatting, and intelligent autocomplete. It has nothing to do with vscode being written in JS.
    - pjmlp 6y ago
      Same applies to F#, a ML based language.
    - 6y ago

hellofunk 6y ago

We've built our SAAS on Keli for the last six years and have been amazed by the productivity. Each year we are able to make a net reduction in lines of code. We are now down to only 2 lines, and we expect next year to be the most impressive yet for what we will need to maintain.

azhenley 6y ago
Any chance you have a write up about your experience with it??
- bboy13 6y ago
  I'm pretty sure this is a joke. There's no way you can run a SaaS on two lines of code... Unless it's some bizzarely simple calculator or something like that.
  - lostcolony 6y ago
    Of course it's a joke. Sibling comments aside (without comment on my part), it would be hard to have 6 years of production use of a language that has its first git commit 2 years ago.
  - mst 6y ago
    APL programmer bursts through the window "ACTUALLY! ..."
  - linkdd 6y ago
    Do not underestimate oneliners
  - throwaway43234 6y ago
    I agree it's probably a joke, but I'm not so sure that the core idea is actually impossible... I could reasonably see a SaaS that simply provides a quick and dirty key-val store. The code is just a translation from REST to REDIS which could easily be done in 2 lines, the value-add is the hosting. That'd actually be pretty helpful for initial prototyping, where you want to have state shared across devices but don't want to bother with hosting a backend at first, and localhost wont work because the client wants to play with it too.

ciuncan 6y ago

I find the syntax as the author intended it to be: clean. I agree with the ambiguity of positional parameters at first glance. Although named parameters (e.g. in Scala) somewhat solve this, they are optional. Having the parameters with their explicit name makes it quite readable. myList .append(5) .reverse .put(5) atIndex(0) .++(anotherList) .select(x | x.isEven) Edit: The same feature makes it look a little weird when put on a single line, because we mentally parse the whitespace as separator but in this case it is not: $.name("Keli") age(50).isOld It looks like a refreshing addition to function programming languages and I'd like to see where it goes from here, in terms of adoption and features.

mst 6y ago
$.name("Keli" :age 50).isOld wold've been nicer to me but ah well.
- ogre_codes 6y ago
  I agree, having age(50) separate almost looks like a separate function call.
- lgessler 6y ago
  I can understand $.(:name "Keli" :age 50) but not $.name("Keli" :age 50), why should the age bit go inside the parens? This introduces an asymmetry where the first key appears outside parents and subsequent keys appear inside (and as colon-initialed keywords?!)

hashbig 6y ago

Elm single handedly got me into functional programming. Everything from the syntax to the standard library. I haven’t used a language that was that elegant and delightful to use perhaps since I discovered Ruby. It makes me really sad that Elm turned to this niche language/framework that it is today. I had hoped for it to grow someday to have a mobile target in addition to web, to be able to use it on the server, hell even to be able to use it to build systems. So much wasted potential.

Kaze404 6y ago
I also love Elm, but the fact that it is a niche language now doesn't mean it's all it ever will be. There's nothing really stopping anyone from adapting Elm to the server for example, but the reason it hasn't been done yet is because it's best to focus on solving one problem at a time. If Evan just translated the Node standard api 1:1 for example, it wouldn't be Elm or Node and there would be no reason to use it.
- pcstl 6y ago
  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.
  - lalos 6y ago
    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 contribute but need to get more familiar with FP before contributing to a higher level FP library. I remember one where the proposal could be easily be implemented generically with ports and any other JS library instead of bringing some weird binding logic to A specific JS library. Add the fact that devs from the FP world are concise with their explanations and you have a recipe for miscommunication problems when trying to explain why that idea is DOA to someone not familiar with core FP concepts.

jayp1418 6y ago

Is this being developed? How similar this is to ada ?

throwaway43234 6y ago
Hasn't been touched in over a year. https://github.com/KeliLanguage https://github.com/KeliLanguage
- cridenour 6y ago
  Maybe they broke up.
hou32hou 6y ago
Nope because I’m not convinced by this language anymore

misja111 6y ago

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 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. Maybe there should be a new edition of Clean Code written specifically for FP, to address this anti pattern. By the way this problem is not unique for FP, OOP suffered the same problem in the past. But the OOP community learned from its mistakes and now most developers know to 'prefer composition over inheritance', for instance.

bcrosby95 6y ago
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.
- mrkeen 6y ago
  I don't know if this counts as irony, but here goes: The killer feature of programming with pure functions is that you can guarantee the same output for the same input. If I were pushing this idea 5+ years ago, I would have said "Unfortunately you have to give up your comfortable for-loops and mutable variables* and learn about these weird maps and folds instead, but it's well worth the trade!" Fast-forward a few years and now maps and folds are everywhere in the mainstream (it's even recommended to use them over for-loops in many cases.) But we never got the same-input-same-output guarantee which was my reason for switching in the first place! * Even that's being too pessimistic. You can have your mutable cake and keep your guarantees, too: https://wiki.haskell.org/Monad/ST#A_few_simple_examples https://wiki.haskell.org/Monad/ST#A_few_simple_examples

whateveracct 6y ago

Wadler's Law at work

fsloth 6y ago

The author lists F# as not IDE friendly. I find this categorization inaccurate. F# works great with Visual Studio, and especially well with intellisense. F# was designed as industrial language from the beginning, and high quality tooling is a large part of that. It might just be me, though, maybe other people use the language in ways that don't work that well there.

pjmlp 6y ago
The only issue with F# is that it is a bit the black swan of Microsoft languages on .NET, so it doesn't get all the toys that C#, VB.NET and even C++/CLI get to play with.
- deleted 6y ago
  [deleted]
- fsloth 6y ago
  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.
  - pjmlp 6y ago
    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.
    - Cybiote 6y ago
      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.

theshetty 6y ago

Why is no one talking much about Scala? (https://docs.scala-lang.org/overviews/scala-book/functional-programming.html https://docs.scala-lang.org/overviews/scala-book/functional-...)

pmarreck 6y ago
Because we're trying to turn people on to functional programming, not off EDIT: Downvotes already? Look, Scala is NOT noob-friendly, and it's a rational argument, not a preference. Here's an example: There are at least 10 (TEN) different uses of the underscore character (_) in Scala. JFC. I can go on, such as the proliferation of bizarre operators everywhere that are impossible to Google (again, not noob-friendly), the reliance on JVM (ewww... so you end up having to be a Scala expert AND a Java expert... plus deal with JVM windup time and JVM stacktraces... Not noob-friendly), the consistent violation of POLS, etc. etc.
- haggy 6y ago
  When is the last time you used it? I've been a full time scala developer for over 4 years now spanning versions 2.11, 2.12, and now heading into 2.13. There have been massive improvements across consistency and huge convergences happening across the scala FP community in terms of library usage. > the reliance on JVM (ewww... so you end up having to be a Scala expert AND a Java expert... plus deal with JVM windup time and JVM stacktraces... Not noob-friendly) This is just plain weird. This makes me feel like you spent zero time actually working with the JVM and it's incredible ecosystem. Being fully inter-operable with Java is a huge win for both adoption and usability. Not only that but the JVM is one of the most mature runtimes in existence with massive amounts of documentation and help available.
- non-entity 6y ago
  Honestly some of the reasons I stay away from learning Scala are the same one that keep me from learning C++
- adav 6y ago
  Nothing’s noob-friendly if you begin with advanced features. Scala is eminently beginner friendly when introduced to developers familiar with OOP. This approach was how I first experienced Scala and it ended up becoming a gateway drug into FP proper. Regarding underscores in Scala, yes there are many technical terms for each thing it has the capability of representing... but in reality, you just use it wherever you want to ignore a value with a placeholder or pass a provided value through.

pmarreck 6y ago

Elixir already solved that problem tho :)

endergen 6y ago

Off serious topic: Naming it after you girlfriend is a risky move, like getting a tattoo of her. Better get married and stay that way or the next partner is gonna be like: "wtf", you still working on your tribute to your ex programming language!?

omarhaneef 6y ago
I don't know what the problem is. After that you only date people who have the same name as your programming languages. "Did something happen?" "Sorry. I just had the wrong idea about you, Kaley."
Kinrany 6y ago
Breaking changes after every breakup
green_apple 6y ago
debian says hello
- riffraff 6y ago
  there's also, ALIX[0] more commonly known as HURD [0] https://biblioweb.sindominio.net/telematica/open-sources-html/node62.html https://biblioweb.sindominio.net/telematica/open-sources-htm...
deweller 6y ago
But it is too late now. Her: "Why did you change the name?" Him: "Because I'm hedging my bets in case our relationship does not outlast my pet programming project". Her: "..."
didip 6y ago
This isn't too bad. We live in Git society now. After the breakup, fork, rename to the new girlfriend name, and put a notice on README.md: "I broke up with Keli but don't worry, I am with Sandra now. Please follow the new language <a href="https://sandralang.org">here</a>" https://sandralang.org">here</a>"

azhenley 6y ago

There was some discussion on Reddit over a year ago that was interesting too: https://www.reddit.com/r/ProgrammingLanguages/comments/acrj9g/request_for_comments_on_my_new_language_keli/ https://www.reddit.com/r/ProgrammingLanguages/comments/acrj9...

ogre_codes 6y ago

This seems like a dead project. It's fairly unknown and hasn't been updated in over a year.

garmaine 6y ago
Maybe they broke up?
- hou32hou 6y ago
  No no we haven’t broke up yet
hou32hou 6y ago
Yea it is indeed halted, because I’m still in search of a better syntax.

pbiggar 6y ago

I'm very sympathetic to the problem. I'm working on Dark (https://darklang.com https://darklang.com) which is a functional language, explicitly because we believe that functional languages are easier to learn, understand and provide great tooling for. It seems to me there's a lot of focus on syntax, and I don't think they've gotten to a great place. For example: (this Int).square | Int = this.*(this) In Rust, they do impl Int { fn square (self) -> Int { self * self } } I can read the Keli version, but I'm note sure that `(this Int)`, `|`, and `.*` are great inventions. You need a good reason to deviate from commonly recognized syntax, and Keli doesn't feel like it's made things simpler with this. In Dark, we use piping heavily to get the benefits of the dot-syntax. In particular, it can be type directed: 8 |> Int::square |> Int::log 2 The autocomplete will only show you integer functions in this case. For the problem of "which parameter" - our IDE shows parameter names when your cursor is in a position to type the next parameter, so you know what you're adding it is. We also show the parameter names when your cursor is in the completed argument so you know what parameter it is. (I couldn't see if Keli did this, it might not be possible in modern editors).

deleted 6y ago

[deleted]

crvdgc 6y ago

Haskell Language Server (https://github.com/haskell/haskell-language-server https://github.com/haskell/haskell-language-server) offers a pretty good IDE experience. It also mitigates the parameter naming problem. With a type hole, the language server will infer the type. But in the case of two parameters having the same type, you have to consult the definition or doc.

grantjpowell 6y ago

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 comfortable using a much less powerful (from a language integration standpoint) Vim, mostly due to the constraints Elixir has in the language. In Elixir, there is no mutable state, I can feel confident that the only things affecting a function are the things in front of my face when reading it. Elixir's alias/import syntax make it pretty easy to jump to the file that has a function definition in. I think FP languages tend to have an edge in how much power an IDE is required to have, because those languages tend to have features like immutability and composable higher order functions)

nerdponx 6y ago
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.
- grantjpowell 6y ago
  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 https://github.com/junegunn/fzf.vim) and open them into the quickfix list, then do something like :%s/old/new/gce | :w | :bnext
  - throwawaw 6y ago
    Is fzf buying you anything over just using :grep? (If speed is the issue, the magic words are `set grepprg='rg --vimgrep'`, after which it's actually usable.)

barrister 6y ago

Can someone point out how Keli implements purity in the documentation? Haskell requires the IO monad to accomplish this, not sure what Keli does. Its feature list claims to implement "pure functional programming" but it seems as though it's just functional, like OCaml or F#.

gdsdfe 6y ago

another terrible programming language website ...

mmphosis 6y ago

reads out more naturally set the delimiter to comma split 1,2,3,4,5 or split 1,2,3,4,5 by comma

leafboi 6y ago

On the post it says Haskell is not IDE friendly. It is really hard to make an IDE around Haskell or does it just that it lacks support?

whateveracct 6y ago
It's just a matter of time investment imo. And with the current ghcide effort, that's already happening! The argument that you need method-style syntax to have good IDE support is short-sighted. Haskell has something more powerful (typed holes), so a common thought is Haskell needs a different sort of IDE support and not expect it to feel the same as Java.

nephanth 6y ago

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 intellisense your IDE will tell you which parameter is which (how they are called in doc) — If you have good intellisense, your ide will tell you the type of function, which, with strict typing is sufficient in a lot of cases (think "send : Unix.socket -> string -> unit", the type tells you the order of arguments) — with named parameters, you don’t have to look up the order of parameters… but you have to look up their names, same problem — This last one is pretty subjective, but in a lot of cases you can guess the order of parameters by thinking "on which argument does it make sense to do partial application ?" `splitBy ","` makes sense, `splitBy "a, b, c"` doesn’t really… so "," is the first argument (but that is subjective) For IDE support, with the right tools, in my experience it is pretty good (ocaml-lsp or merlin do the job pretty well, and strict typing often allow for better intellisense than on non-functional languages) Though there we arrive at the real problem I’ve experienced : the tooling. It’s not actually that bad. more like it’s badly explained. how do you know that you are supposed to install — opam for package management (and reinstall ocaml via opam) — dune for building — utop as a REPL, because the basic REPL sucks — batteries or janestreet-core for "standard library" because the standard library sucks (and which one anyway ?) Plus these tools are hard to use at beginning / have a learning curve. (why can’t creating a project be as simple as - type "cargo new project" -> now you automatically have a project dir with a local opam switch, an opam file, a dune file, an example program, and basic utilities installed in that switch ? ) Personally, I think that’s what fp lacks the most right now (though I’m probably influenced a lot by ocaml) : easy to use and flat-learning curve tooling

marmaduke 6y ago
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/ 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

daxfohl 6y ago

I like the idea but I think the tactics are wrong. The better approach would try to make the experience as much like OOP as possible. Like the named argument, message passing thing is nice, but it's going to be just one more thing that the 95% is going to have to get used to. If the goal is approachability, then have to get it as close to existing experiences as possible.

yters 6y ago

i do not agree with the implief premise that functional programming is not inherently the act of joy itself

rishav_sharan 6y ago

With every new upcoming language, I always have the same ask; Please add a couple of section on what can we do with the language today. Rust has amazing sites like arewegameyet or arewewebyet. A single paragraph around what users can realistically do with this language and what are the most used packages in the ecosystem will be a great help to anyone curious about it.

spicybright 6y ago
Wow, those sites are a really good idea. I wish tech was more honest with it's pro's and con's. Seems like most project maintainers want to be marketers than engineers sometimes...

gridlockd 6y ago

If I want to do functional programming, I can do that just fine in most languages. If I want to do imperative programming, I can do that just fine in most languages, except for functional programming languages.

spicybright 6y ago
I think the key with a functional language is given a large codebase, you can reason about it functionally instead of hoping there's no imperative code in there (on purpose or by bug)
- gridlockd 6y ago
  Kind of like if you're wearing a straitjacket, you don't need to worry about accidentally punching yourself in the face.

fouric 6y ago

I feel like the named reasons, aside from being invalid (it should be really really easy to make a popup that tells you the function parameter names and/or types, like SLIME has been doing for...decades? with Common Lisp), are really bad justifications for creating an entirely new programming language. Surely the effort would be better spent on improving the tooling, because all of their concerns are tooling-related. That also makes the language not about a "good user experience" as given in the docs, but "being compatible with modern IDEs". No thanks, I would rather improve tooling for an existing language that already has a community and ecosystem.

ConanRus 6y ago

>a joy for users But.. we already have H-l for that!

hannofcart 6y ago

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.

codygman 6y ago
> 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.

stark3 6y ago

On the AS400 there's a 'command' object type that deals with both issues the Keli language is trying to address. - Argument positions are named, help text, validity checking, special values, etc are defined for each argument. - Command arguments can be prompted within the editor (intellisense). As400 commands can also be prompted and executed by a user, thus providing a common user interface for running jobs as well. I've seen nothing like this in the PC world. The two issues the Keli language is trying to solve were addressed 30 years ago on the as400.

shaunxcode 6y ago

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

hou32hou 6y ago
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
- shaunxcode 6y ago
  Keep going!

didibus 6y ago

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.

adultSwim 6y ago

The F# IDE is really good actually

galaxyLogic 6y ago

>However, OOP languages also suffers the same problem whenever the number of function/method arguments get more than two, for example: Well yes except Smalltalk, the original OOP-language. Smalltalk requires you to use KEYWORD METHOD-NAMES whenever you have > 2 arguments. That makes Smalltalk code highly readable. (I told you so 20 years ago today) :-)

higerordermap 6y ago

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.

SZJX 6y ago
Yeah I agree that those two points don't make much sense whatsoever. Though I also don't agree with your point 1. I don't know if you have had much experience writing a functional language professionally. The benefit of immutability is exactly to make reasoning about your program much easier. Of course as you mentioned computers are indeed based on the von Neumann model, so in the end we sometimes have to go into memory usage details. However, unless you're programming some high-performance game, the vast majority of programs run totally fine with mostly immutable data structures. It's also especially suited for distributed computing (e.g. actor model) which is becoming the norm nowadays. In 95% of programming activities, the traditional "real computer science (what is "fake" computer science?), algorithms, data structures, number theory, probability" are used surprisingly rarely, while the elegance of functional/mathematical reasoning really makes the programming experience much more enjoyable and bug-free.
- 6y ago

SZJX 6y ago

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.