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

111–120 of 300 posts

Re: Motivation – Keli Language

#111

Post by jayd16 »

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'm told F# is where the toys come from.

Re: Motivation – Keli Language

#112

Post by andrepd »

hashbig wrote: post #32
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…

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.

What an odd comment.

>Compare that to JavaScript where you can literally just install vscode and node and you’re up and running

As opposed to OCaml where you... install opam and merlin and you're up and running?

>Not to mention that you could pop open a console in any browser and execute code.

As opposed to OCaml where you can pop open utop and execute code.

>For something to be simple, a 10 year old kid needs to be able to figure it out.

How many 10 year old kids are there working as professional programmers? Come on...

Re: Motivation – Keli Language

#113

Post by DonaldPShimoda »

implicit wrote: post #106
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.

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…

Yes, but this strategy is only suitable for a single developer, or a small group of similarly-experienced-with-that-specific-codebase developers. Onboarding somebody into a world full of single-character variable names and such is a headache. Named parameters are for reading code, and if you're not intimately familiar with the code on your screen right this second, they are helpful.

I think what we really need is a sort of "lens" system by which we can modify the syntactic appearance of our code without adjusting the semantics, but do these changes on-the-fly. So say you're doing some debugging or whatever and you're gonna be staring at the same 300 lines of code for a few days — so you switch over to "terse" mode and suddenly the named parameters are gone and the variable names are abbreviated (assume a magic system that picks good terse variable names according to your preference). But then when you're done with that section and ready to venture into the remainder of the codebase (or if you're a new developer who's unused to the team's naming conventions or whatever), you can use "verbose" mode that shows the parameter names and whatnot.

I imagine something like this is not obviously straightforward, but it could be worth investigating!

Re: Motivation – Keli Language

#114

Post by lalos »

pcstl wrote: post #58
Kaze404 wrote: post #37

Earlier quoted context omitted.

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.

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.

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.

Re: Motivation – Keli Language

#115

Post by drdebug »

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 question is should the writer go through the effort of placing the parameter name, or should the reader go through the effort of looking up the function prototype? Since according to Clean Code (https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...) code is more often read than written, it should makes sense for the writer to do it.

Re: Motivation – Keli Language

#116

Post by dashwav »

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…

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 good enough to make the company money"

or

"I love using FP ideas in my code when it makes sense"

I really feel like this is the ideal state for Software Development, as either side "winning" will only hurt the robustness of the environment.

Re: Motivation – Keli Language

#117

Post by kingdomcome50 »

ogre_codes wrote: post #83
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…

Disagree. Particularly since named arguments are part of the function name and in languages where you use named arguments you will often have very expressive overloaded function names. You might have 3 related functions like so: getStudent(datastore: DS, byId: number) getStudent(datastore: DS, byAssessmentId: number) getStudent(datastore: DS, firstName: string, lastName: string, birthdate: date) Without named paramet…

I'm honestly curious what you see as the issue with "getStudentBy"-type function names. Could you expand on that?

Of course I understand a name could become rather verbose in your last case, but I'm not satisfied that it would be much of an issue in practice.

Re: Motivation – Keli Language

#118

Post by elwell »

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…

In Clojure, for functions that will probably have more than a couple args, I like to pass a map, then destructure it by its keys in the function definition. Two benefits are: you don't need to remember the order of args, and it makes refactoring easier in cases where you are simply adding a new optional arg (you don't need to update all the old calls of that function if they aren't using the new option).

Re: Motivation – Keli Language

#119

Post by grantjpowell »

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)

Re: Motivation – Keli Language

#120

Post by haggy »

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…

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.

Post reply on HN