Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Motivation – Keli Language

keli-language.gitbook.io

Post reply on HN
Print view View original

201–210 of 300 posts

Re: Motivation – Keli Language

#201

Post by mattmanser »

HelloNurse wrote: post #126
cannabis_sam wrote: post #107

Earlier quoted context omitted.

> An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Do you have a…

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

Maybe in the 00s, but these days most languages have collapsed boiler plate down massively.

This comes across as an old fashioned view (bordering on extremely old-fashioned).

Re: Motivation – Keli Language

#202

Post by robocat »

strbean wrote: post #164
scarmig wrote: post #121

Earlier quoted context omitted.

Well, we're used to the AbstractBeanHandlerFactoryFactories already. A slight discomfort of learning something new can seem much bigger when you're already acclimated to abuse.

Posting to name-drop SimpleBeanFactoryAwareAspectInstanceFactory

For details of the interfaces that the class inherits from, see:

https://docs.spring.io/spring-framework/docs/current/javadoc...

https://docs.spring.io/spring-framework/docs/current/javadoc...

Re: Motivation – Keli Language

#203

Post by mattmanser »

Jaxan wrote: post #181
didibus wrote: post #170

Earlier quoted context omitted.

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

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

Because it's a pain to navigate with the keyboard, plus accidental completion means more deleting, and other little niggles like that.

Re: Motivation – Keli Language

#204

Post by dmitriid »

ogre_codes wrote: post #193
laumars wrote: post #142

Earlier quoted context omitted.

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.

Should I look for the function called: `getStudentByClassRoomFirstNameLastName` or is it `getStudentByClassRoomLastNameFirstName`, or `getStudentByClassRoomFullName` since you sort that way. They you have to deal with optional parameters, do you have an extra argument for that or is there a `getStudentByClassRoomFirstNameLastNameMiddleName` function out there? Now you are scanning the auto-complete code trying to fig…

Even better is Elixir's Ecto or Linq

    Students |> Students.Repo.get_by(first_name: "Ryan")

    from s in Students where firstName = "X" select s
    
    Students.AsEnumerable().Select(s => s).Where(s => s.Name == "X")
etc.

Re: Motivation – Keli Language

#205

Post by mrkeen »

bcrosby95 wrote: post #196
misja111 wrote: post #34

I think it's great that Keli is designed with IDE support in mind. However I believe that this is only half of the reason why FP still doesn't really break through in the corporate world. The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report…

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

I 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

Re: Motivation – Keli Language

#206

Post by dmitriid »

gmfawcett wrote: post #20

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…

Any language is non-IDE-friendly compared to what you have out of the box for languages such as Java, C# and even Python in IntelliJ's IDEs.

Most languages at most have autocomplete and definitions look up (and even those are often very brittle). That is a far cry from what an IDE should be able to provide.

Granted, recently I only tried OCaml via Reason, but I remember that some of the errors the compiler produces are not IDE-friendly either (something like "Type A provided but elsewhere wanted B" with no indication where :) ). But that's mostly due to the age of the language (most "old" languages are very user-hostile and have very terse/cryptic error messages).

Re: Motivation – Keli Language

#207

Post by laumars »

enricozb wrote: post #187
laumars wrote: post #152

Earlier quoted context omitted.

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

I'm talking specifically about the function calls, which are effectively the same in C, Rust, Python, Lisp, Haskell, and many others. No matter how terse, it's always some form of ... The absence/presence of parenthesis and commas don't add anything of semantic value here, so that's not really what I'm referring to. The problem is, is that the values often don't have any meaning attached to them, especially when they…

I agree random boolean arguments are unhelpful. Good software development standards would say any uses of boolean values should be substituted with well named constants if the same value. However the advantage of having that baked into the language rather than forcing developers to via code reviews isn’t lost on me

Re: Motivation – Keli Language

#208

Post by raegis »

robocat wrote: post #202
strbean wrote: post #164

Earlier quoted context omitted.

Posting to name-drop SimpleBeanFactoryAwareAspectInstanceFactory

For details of the interfaces that the class inherits from, see: https://docs.spring.io/spring-framework/docs/current/javadoc... https://docs.spring.io/spring-framework/docs/current/javadoc...

The guy next to me on the bus is asking why I'm laughing so hard. I'm not sure how to respond. "These class names are really funny!"

Re: Motivation – Keli Language

#209

Post by dmitriid »

sfvisser wrote: post #13

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

> I think it shouldn't be too difficult to add intellisense for Haskell-like syntax to IDEs as well. Especially with all the types available!

On the contrary, this should give Haskell an advantage because all the types are known and the IDE should be able to autocomplete only the correct parameters. But that requires compiler-as-a-service, and GHC is not. And writing your own analyser for a language is quite a task.

Re: Motivation – Keli Language

#210

Post by dmitriid »

dnautics wrote: post #17
ollysb wrote: post #8

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

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.

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.
Post reply on HN