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

191–200 of 300 posts

Re: Motivation – Keli Language

#191

Post by smabie »

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…

This is true, especially when it comes to array languages. When I was learning kdb+/q, I realized that the language was small enough that I didn't need autocomplete. Also, the language is so powerful that I didn't really even type that much. I would have been perfectly happy writing out the code on a paper napkin it was so terse.

Re: Motivation – Keli Language

#192

Post by smabie »

hashbig wrote: post #140
andrepd wrote: post #112

Earlier quoted context omitted.

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…

> How many 10 year old kids are there working as professional programmers? Many of them in 10 years time, and they will be using concepts they learned when they were 10. And FP enthusiasts would complain why no one uses their favourite language. My point is, if we want to get more people to use FP we have to make it more accessible. Everything from building better tooling, tutorials, environments. Good languages alon…

I actually think it's easier. dune and opam are so much nicer than python/pip/conda or whatever.

Have you used OCaml? Because you can set up a complete environment with IDE support in like 5 minutes flat. It's actually one of the easiest environments to set up of any language. dune, merlin, opam, and utop provide everything you would possibly need.

Re: Motivation – Keli Language

#193

Post by ogre_codes »

laumars wrote: post #142
ogre_codes wrote: post #83

Earlier quoted context omitted.

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 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 figure out which function you need to call.

If you have named parameters, this just works:

  `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane")`
  `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane", middle: "Anne")`
It can call the same function with optional parameters, or 2 different functions and you don't care from the calling side because the syntax is the same and always makes sense.

(slight tangent)

Far better with overloading in general is being able to have 2 methods with the same name which return the same thing but have different types of inputs. Like in Elixir, you can have an API callback be `handle(apiResult)`, then have 2 functions, one which handles the error and one which handles the success. Zero logic written to filter out bad-calls, it's just the same method with different types (the Error result type and the Success result type). Vastly simplifies and cleans up that kind of code.

Re: Motivation – Keli Language

#194

Post by ogre_codes »

kingdomcome50 wrote: post #117
ogre_codes wrote: post #83

Earlier quoted context omitted.

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.

See above.

Re: Motivation – Keli Language

#195

Post by zem »

pmontra wrote: post #12
maest wrote: post #3

The following example is kinda funny: // 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(",") Seeing as Python uses the first version for .join()

Exactly what I came here to write about: Python 3.8.2 (default, Jul 16 2020, 14:00:26) >>> " ".join(["a", "b"]) 'a b' vs Ruby 2.6.5 :001 > ["a", "b"].join(" ") => "a b" I don't know which one is more natural but I prefer the Ruby version because it's consistent with "a b".split(" ") which works in both languages. One less think to remember.

the key difference is that in ruby, `join` is implemented in the `Enumerable` mixin (which provides a whole suite of functionality to any object with an `each` method). if your own class wants to support `join`, it has to both implement `each` and explicitly mix in `Enumerable`.

in python, `join` is implemented in the `string` class, and the argument is an iterable. therefore, if your class wants to support `join`, it needs to implement the `__iter__` method (python's equivalent of ruby's `each`), but it does not need to also mix in an implementation of `join`.

it's mostly a cultural difference between ruby and python - the ruby ecosystem leans more heavily towards mixins and implementing generic functionality by attaching methods to objects, whereas the python ecosystem leans more heavily towards implementing generic functionality by providing functions (or methods on an external class) that accept generic objects.

Re: Motivation – Keli Language

#196

Post by bcrosby95 »

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.

Re: Motivation – Keli Language

#197

Post by adamkl »

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…

> Maybe there should be a new edition of Clean Code written specifically for FP

I’ve posted links to this work-in-progress book a few times in the past, but I’m going to do it again because I think it fits the description perfectly.

Grokking Simplicity by Eric Normand [0] is a great book for introducing the premise behind FP in a pragmatic fashion. It doesn’t get bogged down in monads and type theory, just the benefits of pure functions and modeling applications as flows of data.

All the code examples are in JavaScript, so it requires no prior knowledge of functional programming, and it does a great job of building things up from first principals while highlighting the benefits vs a more object oriented approach.

It’s only half complete, with a nebulous completion date, but I’ve already purchased a copy, and it would the first book I’d recommend for any newcomer to FP (it’s already worth it just from the first half as far as I’m concerned).

[0] https://www.manning.com/books/grokking-simplicity

Re: Motivation – Keli Language

#198

Post by smabie »

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…

The dominant OO+FP paradigm of Scala code is one of the most powerful, imo. Combining immutable objects with FP constructs is my favorite way of programming and something that only Scala can really do (well OCaml can, but no one uses objects).

Scala is probably the most flexible and powerful statically typed language currently in widespread use and I would probably choose the language for most non-scientific computing greenfield projects.

In my experience of on boarding developers who didn't know Scala or Java into a large Scala project, it's really not that hard to learn. Developers were writing okay code in the first week and completely idiomatic code after the first couple weeks.

The JVM does suffer from non-transparent performance characteristics, but the highly optimized and tested platform makes up for it.

Scala the language is getting better and better and Scala 3 will really be something special, I think.

The worst part of the JVM is dependency management. Upgrading the version of Scala you're using is unbelievably painful and in a lot of cases impossible.

My old Scala shop is still running on 2.10 because no ones bothered to put in the weeks of work to upgrade.

Re: Motivation – Keli Language

#199

Post by eitland »

Joker_vD wrote: post #184
eitland wrote: post #162

Earlier quoted context omitted.

VS Code (which I like and have used extensively for a number of projects) is kind of an IDE, but it doesn't quite compare to full blown Java IDEs IMO.

It's an editor with syntax highlighter, autocompletion, go-to-def, and go-to-uses that also builds the code, runs the code, runs the tests, and also allows you to run them (code & tests) under a debugger. Oh, and it also has projects/solutions/workspaces/whatever they're called. Back in my days™ that's what they used to call an "IDE". But today that's just "glorified Notepad++", I guess? What features does it miss th…

I wrote kind of like an IDE :-)

Maybe I'm just a spoiled brat, but I came to Java from C, PHP, Visual Studio (the old one) and learned how nice programming could be before I left for .Net Core and frontend (with much TypeScript), mostly in VS Code but sometimes in Rider and Webstorm.

To me, to be a real IDE these days you need to have proper refactoring support.

And to a spoiled brat like me that excludes almost everything except Rider, Visual Studio with Resharper, NetBeans, Eclipse and IntelliJ :-)

But yes, I too am old enough to remember back when the C/Assembler program we used to program microcontrollers were considered IDEs.

And technically you are of course correct :-)

I guess a better classification would be: IDE level 1,2,...n where what I call IDEs today are really level 3 IDEs.

Re: Motivation – Keli Language

#200

Post by mrkeen »

rstarast wrote: post #151
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…

Hmm, to me it seems that 'splitBy ","' should be a function that takes a string and returns a list of strings: splitBy "," : String -> List String so it seems "clear" that the separator should be the first argument. But maybe I've just programmed functionally for too long? As an alternative, perhaps there's space to introduce types to make this something like split : Pattern -> String -> List String

I agree with your intuition. I'll try to make my intuition explicit:

The 'splittee' should be the last argument. The last argument is usually what you want to a) elide as part of function composition, or b) loop over (the tightest).

E.g. Splitting a file into lines:

    lines content = splitBy "\n" content
can be:

    lines = splitBy "\n"
If splitBy used the other order, it would be:

    lines = (\c -> splitBy c "\n")
E.g. Splitting a file by lines and tabs:

    entries content = concatMap splitBy "\t" (splitBy "\n" content)
can be:

    entries = concatMap splitBy "\t" . splitBy "\n"
If splitBy used the other order, it would be:

    entries content = concatMap splitBy (splitBy content "\n") "\t"
Post reply on HN