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

101–110 of 300 posts

Re: Motivation – Keli Language

#101

Post by Mathnerd314 »

linkdd wrote: post #82
rgoulter wrote: post #68

Earlier quoted context omitted.

>>> " ".join([1.5, "hello", None]) Traceback (most recent call last): File " ", line 1, in TypeError: sequence item 0: expected string, float found Why would `[1.5, "hello", None].join(" ")` be any different?

Because "list of string" is not a type in Python. Why would you put a method on a class if only a small subset of it can use it?

That happens all the time, since Python is dynamically typed. For example a[10] gives an IndexError if a has less than 11 elements. So with static typing, we should restrict indexing to ensure that the number of elements needed are present, and remove indexing from general lists. But you wouldn't remove indexing from lists, that's one of the main functions...

Re: Motivation – Keli Language

#102

Post by skolsuper »

pjmlp wrote: post #59
fsloth wrote: post #41

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.

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.

I think you mean black sheep

Re: Motivation – Keli Language

#103

Post by comboy »

asdfman123 wrote: post #95
didip wrote: post #92

Earlier quoted context omitted.

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 here "" rel="nofollow">https://sandralang.org">here "

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.

Re: Motivation – Keli Language

#105

Post by matt_kantor »

linkdd wrote: post #82
rgoulter wrote: post #68

Earlier quoted context omitted.

>>> " ".join([1.5, "hello", None]) Traceback (most recent call last): File " ", line 1, in TypeError: sequence item 0: expected string, float found Why would `[1.5, "hello", None].join(" ")` be any different?

Because "list of string" is not a type in Python. Why would you put a method on a class if only a small subset of it can use it?

Either way it's a partial function that is not defined for most of its domain. The only difference is how its arguments (including self) get arranged at call sites, right?

Re: Motivation – Keli Language

#106

Post by implicit »

m12k wrote: post #21
laumars wrote: post #10

Earlier quoted context omitted.

I get this might just boil down to preference but I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. Plus they don’t always improve writability outside of IDEs because you then have to memorise the parameter names and in some functions there’s several terms that could equally apply (if you’re using an IDE…

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.

I understand what you're saying, but something I have noticed over the years is that the amount of code that I can make sense of at any given time is actually proportional to what I can see onscreen at any given moment.

I have had pretty good luck cheating this in a bunch of ways: I use a small font, a big display, and I use a terse programming style.

Once you internalize a bunch of common higher-order functions, you learn how to draw a ton of meaning out of a relatively small number of terms.

Re: Motivation – Keli Language

#107

Post by cannabis_sam »

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 code example? It would be interesting to see what this kind of code looks like.

Personally, I find complaining about a ”fold over a monad” to be equivalent to complaining about an ”integer indexed loop over an array”. It’s a pretty straightforward implementation detail that have very little to do with your business logic.

And business logic is far, far easier to model using ADTs (it’s literally just AND and OR, applied to data structures) than confounding object inheritance hierarchies.

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

Re: Motivation – Keli Language

#108

Post by nybble41 »

pgustafs wrote: post #51
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…

The funny thing (that I'm sure you're aware of) is that 'prefer composition over inheritance' is an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing. In OOP, this means that inheritance is bad because it's not always clear what functions are inherited and/or overloaded.

> an instance of 'prefer referential transparency', an idea from FP that you should always know what a variable is referencing.

The idea of "referential transparency" is that you should always be able to substitute a reference for its definition, or vice-versa, without changing the behavior of the program. This implies both immutability (so that duplicating a value doesn't change the result) and purity (so producing the value has no side effects and gives the same result no matter how many times you do it). It has nothing to do with knowing what a variable is referencing. If anything, functional programming encourages the use of generic functions which don't know or care what their variables are referencing (parametric polymorphism).

Re: Motivation – Keli Language

#109

Post by DonaldPShimoda »

pjmlp wrote: post #54
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…

There is plenty of FP in the corporate world, the mistake that many FP advocates make is to make it a war of FP vs anything else. Meanwhile multiple paradigm languages keep getting most of the features that actually matter to Joe/Jane developer.

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

Both solutions are well-suited to certain kinds of problems, and this opposition is well summarized by study of what is called the Expression Problem[0]. A good developer should know both paradigms (in addition to others!) and use each where it is best suited.

[0] There are other issues than those discussed by the EP, but the EP is, I think, the most simple perspective of the distinction between OOP and FP.

Edit: TIL you cannot escape an asterisk on HN. That's a bummer.

Re: Motivation – Keli Language

#110

Post by dkarl »

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…

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

This is a great point. I think there are a lot of open questions about basic questions such as how ergonomic effect systems can become and which functional programming abstractions become intuitive through enough practice versus always feeling confusing. I think that stuff will shake out in a decade or two, and we will end up with much better styles to choose from. Who wants to program in 1990s/early 2000s Java style anymore? (Well, okay, a lot of people, but ignore them.) Nobody would judge OOP negatively based on that mess, because we know it can be done a lot better, and languages have evolved to cater to what we've learned. I think functional programming has a lot of evolution to come that will make it more ergonomic and more practical. It will be especially interesting to see what the cohort of programmers introduced to functional programming via modern front-end Javascript will do as some of them transition to the back end and look for statically typed languages that are better than Typescript.

Post reply on HN