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

121–130 of 300 posts

Re: Motivation – Keli Language

#121

Post by scarmig »

cannabis_sam wrote: post #107
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…

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

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.

Re: Motivation – Keli Language

#122

Post by barrister »

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

Re: Motivation – Keli Language

#123

Post by asdfman123 »

comboy wrote: post #103
asdfman123 wrote: post #95

Earlier quoted context omitted.

Relationships are just like new technologies. Sick of all all the hassle you have to deal with regarding ? Use a new, shiny technology! Five years later... Sick of all the hassle you have to deal with regarding ...? The lesson here is ultimately all technologies suck, but you have to find the variety of suck you're willing to live with.

> The lesson here is ultimately all technologies suck, but you have to find the variety of suck you're willing to live with. Alternative view is that they all have their uses and if you choose the right one for the use case, it makes your life easier, not harder, especially once you get to know it well. It helps if you know what do you want. Not a single one is good at everything.

Shop shooting holes through lingering post-adolescent cynicism!

Re: Motivation – Keli Language

#124

Post by non-entity »

pmarreck wrote: post #52
theshetty wrote: post #44

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

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), t…

Honestly some of the reasons I stay away from learning Scala are the same one that keep me from learning C++

Re: Motivation – Keli Language

#125

Post by DonaldPShimoda »

dashwav wrote: post #116
DonaldPShimoda wrote: post #109

Earlier quoted context omitted.

> the mistake that many FP advocates make is to make it a war of FP vs anything else. I don't disagree with this (goodness knows there are plenty of functional purists who come across as religious zealots), but I think it's also worth mentioning that there's an opposing camp of people who are hard-set against ever considering FP for anything at all because they've bought fully into object orientation and stateful com…

In my experience, I have seen much less of the OOP-only group, especially in recent years. The general feel I have seen when communicating with other developers about this is that OOP is a tool and it's probably not the best one, but they are comfortable with it and it's problems. In general it feels like the overall feeling to FP is either "I don't have time to learn a new paradigm when my current one is working goo…

Oh, sure! I didn't mean to suggest that there were as many as the only-pure-FP crowd, though I can see how my phrasing may have suggested as much. I just meant to bring up that there are people like that, who refuse to (consciously) adopt any amount of FP in their development. I have interacted with some myself. Most of them make arguments about, like, "People think in terms of state so FP is inherently a bad user experience" or something to that effect.

Re: Motivation – Keli Language

#126

Post by HelloNurse »

cannabis_sam wrote: post #107
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…

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

Re: Motivation – Keli Language

#127

Post by agumonkey »

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…

FP abuse can lead to abstractitis which is sad but nothing the Corporate World doesn't like ... it was the land of J2EE after all.

Re: Motivation – Keli Language

#129

Post by nerdponx »

grantjpowell wrote: post #119

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

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

Re: Motivation – Keli Language

#130

Post by maest »

linkdd wrote: post #85
Zarel wrote: post #79

Earlier quoted context omitted.

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"

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…

This is also the cause of this lovely bit of JS behaviour:

    >>> [1,2,10].sort()
    Array(3) [ 1, 10, 2 ]
Post reply on HN