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

241–250 of 300 posts

Re: Motivation – Keli Language

#241

Post by shallowthought »

gmfawcett wrote: post #141
hashbig wrote: post #32

Earlier quoted context omitted.

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

Really? I've had much, much worse developer experiences with other languages. With opam and dune wrapping the default toolchain, honestly it's a pleasure to work with these days. (I feel obliged to give an example of what I think is a bad developer experience, and I would point at Haskell. There are far too many toolchain variations to choose from, all of which seem to be in active use -- cabal, cabal-v2, stack, caba…

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

Right, and I guess my counterargument would be that, yes it is, and you don't need to resort to logic to see it - just do a little googling about its poor adoption.

Re: Motivation – Keli Language

#242

Post by a1369209993 »

enricozb wrote: post #5

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

> The proposed solution by Keli is to be inspired by the Smalltalk-style message syntax

But that doesn't actually solve the problem.

  "Hello world".replace("Hello","Bye") // works fine
  but
  somesequence join: "," // still doesn't work
  // unless every $Sequence implements join explictly

Re: Motivation – Keli Language

#243

Post by a1369209993 »

DonaldPShimoda wrote: post #173
laumars wrote: post #149

Earlier quoted context omitted.

> Onboarding somebody into a world full of single-character variable names and such is a headache. The opposite of named arguments isn’t single character variable names. Any organisation with an enforced coding standard would ensure that variables are descriptive irrespective of whether that language uses named arguments or not.

Yes, I agree! I was specifically addressing the parent comment's line about "I use a terse programming style." When it comes to functional programmers, they (more than any other group) will take terseness to the extreme in the form of single-letter variable names in inner functions, match forms, etc. I didn't mean for my comment to be entirely literal, either. Rather, I just meant to say that terseness can impede rea…

> When it comes to functional programmers, they (more than any other group) will take terseness to the extreme

You should really read about APL and other array languages then. (I don't have a good starting point, but they tend to come up on HN periodically such as [0] [1]).

0: https://news.ycombinator.com/item?id=23055793

1: https://news.ycombinator.com/item?id=16847641

Re: Motivation – Keli Language

#244

Post by hinkley »

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

They're talking about Existential Crises in another post today.

I think I still have a copy of the book that Johnson wrote to accompany the creation of Spring (which someone wants $300 bucks for on Amazon, I didn't know it was a collector's item). The last time I used Spring, I had the distinct thought that I should go through his book as if it were a bingo card, comparing it with the latest version. It seems like it has reacquired all of the bits of J2EE that it set out to avoid.

If, outside of Spring, there is anything in the Java world that more perfectly embodies Nietzsche's warning about fighting with monsters, I don't know what it is.

Re: Motivation – Keli Language

#245

Post by throwawaw »

grantjpowell wrote: post #143
nerdponx wrote: post #129

Earlier quoted context omitted.

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

Yeah, this exact flow was a pain for me in switching from vscode to vim full time. My flow now is to search for a bunch of instances using the fzf plugin ( https://github.com/junegunn/fzf.vim ) and open them into the quickfix list, then do something like :%s/old/new/gce | :w | :bnext

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

Re: Motivation – Keli Language

#246

Post by structural »

didibus wrote: post #170
m12k wrote: post #21

Earlier quoted context omitted.

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.

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.

I can't disagree more strongly about this. Many, many times I'm trying to understand a codebase, and what I have is that codebase, not the dozens of dependencies involved, and not a full development/build environment. I may not even know what, if any, IDE the original developers used.

There's also very common sources of bugs when functions take multiple arguments of same (or sadly in some languages, implicitly convertible) types. With named arguments in complex functions, you can sit down, read the code, and spot the bugs. Happens frequently enough in code review that we have a category for it. Without named parameters here, every single function call becomes a game of "mouse over the parameter in the IDE". Moreover, "you can just read the docs inline in the IDE" also causes people to not think much about naming things, which also harms maintainability.

It's a real issue in large, long-lived codebases that may not seem like much in smaller projects.

Re: Motivation – Keli Language

#247

Post by galaxyLogic »

bauerd wrote: post #131
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 other reason is that many FP users are too enthusiastic about creating abstractions. Elm lacks typeclasses, yet I've found this lack is what keeps a lot of libraries at bay that would have otherwise turned out overly abstract (see any mainstream Haskell library, really). It's the same reasoning behind Go: With great power comes great responsibility. At large, programmers shoot their own feet with powerful langua…

Overuse of abstraction is penny-wise and pound-foolish.

It is penny-wise in that it saves some code, but pound-foolish in that it makes maintenance harder.

Why? Because when you have an abstraction, your code, possibly in many places, depends on it. Now if you need to make a change, you will need to understand both the abstraction, and your "instance" of it.

Well no rather you need to understand ALL instances of that abstraction, to know that if you change the abstraction you are not breaking ANY of its uses.

Penny-wise and pound-foolish in many cases.

Re: Motivation – Keli Language

#248

Post by AmpsterMan »

DonaldPShimoda wrote: post #109
pjmlp wrote: post #54

Earlier quoted context omitted.

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

I've had people chew me out for using function objects in Java, saying it's too complicated and the newest thing isn't always great. I wanted to point out that Java 8 is 6 years old now, and qsort() has been a thing for a while.

Re: Motivation – Keli Language

#249

Post by galaxyLogic »

>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) :-)

Re: Motivation – Keli Language

#250

Post by ogre_codes »

kingdomcome50 wrote: post #231
ogre_codes wrote: post #194

Earlier quoted context omitted.

See above.

Hmmm... I see where you are going there, but I don't understand how named arguments solve the problem[0] you have outlined. That is, a problem of discoverability. Like what, precisely, does the autocomplete show in your editor when you type `getStudent` vs `getStudentBy` that makes the former so much better? In either case you are left to disambiguate either the correct overload or the correct method unless... well..…

I think a better question is:

Why would you want a function that gets students to be called anything other than `getStudent`? Fundamentally, the simpler, easier to parse your function name is, the more readable and editable your code is.

I definitely think overloading functions is more interesting/ important than named parameters. But named parameters are useful both for overloaded functions and for optional parameters where you might not know what the 3rd/ 4th parameter might be.

One pattern I see frequently in languages which lack named parameters is instead of using optional parameters, people pass objects with optional properties. This is used a ton in Javascript/ Typescript. If the language supported proper named & optional parameters, it wouldn't be an issue.

Post reply on HN