The Koka programming language (lwn.net)
from cm0002@lemmy.world to programming@programming.dev on 31 Aug 01:43
https://lemmy.world/post/35235530

#programming

threaded - newest

atzanteol@sh.itjust.works on 31 Aug 13:21 next collapse

Functional language developers are obsessed with side effects but I rarely ever see problems with it in real code. Like I can remember once in maybe 10 years setting a developer write a “get” method that also wrote to a file. Caught during code review, rewritten easily.

Also - it’s sad to see languages still using whitespace for code blocks. Respect programmers, use proper start/end symbols for that. It’s not the 80s, development tools can format code now.

Custodian6718@programming.dev on 31 Aug 14:03 next collapse

Still, Not everybody Formats their Code 💀

atzanteol@sh.itjust.works on 31 Aug 14:32 collapse

If I’m viewing poorly formatted code it’s literally one key chord for me to auto-format it. It’s a complete non-issue.

Custodian6718@programming.dev on 31 Aug 15:05 next collapse

Yea until you have to view it outside a code editor

atzanteol@sh.itjust.works on 31 Aug 15:45 collapse

Never a problem.

bitcrafter@programming.dev on 31 Aug 16:06 collapse

Interesting… so in the end, if the whitespace is not telling you what the code is doing, you reformat it so that it does?

Imagine if there were languages that just let you skip that step entirely!

atzanteol@sh.itjust.works on 31 Aug 16:17 collapse

The step I want to skip is having to go back and tab over lines when I’ve moved code or when things don’t paste properly and tabbing gets messed up.

Imagine if there were languages that let you just explicitly state where code blocks start/end and let the IDE handle the formatting for you?

bitcrafter@programming.dev on 31 Aug 16:39 collapse

Saying that the problem of formatting goes away if you have a carefully configured IDE is an excuse, not a reason.

dneaves@lemmy.world on 31 Aug 14:59 collapse

Functional language developers are obsessed with side effects but I rarely ever see problems with it in real code. Like I can remember once in maybe 10 years setting a developer write a “get” method that also wrote to a file. Caught during code review, rewritten easily.

While, sure, get methods writing files could happen in side-effectful code, the side-effect concern is less about that and more of expectations. With OOP languages, class methods can create a dichotomy of expected returns: Using a list reversal as an example, will a list.reverse(some_list) function reverse the list in-place, or return a copy of the reversed list and leave the original in-tact? To know the answer, you have to check the docs or the type signature (which, yes, is easy, but the answer isn’t obvious). Which, the main concern is trying to debug things “magically changing”, since nested function calls and inherited function calls can modify something from layers upon layers of abstraction away.

FP languages tend to not have this dichotomy, with very few exceptions like IO in Haskell, ports in Elm and Gren, external functions in Gleam, or FFI in Haskell, to name some ways from languages I know, all of which usually move the control of the program outside the language’s “default area”, anyway. Outside the exceptions, to reverse a list a reverse function needs to be given that list explicitly, and it also will be returning a copy of the list reversed, only and always

atzanteol@sh.itjust.works on 31 Aug 15:57 collapse

With OOP languages, class methods can create a dichotomy of expected returns: Using a list reversal as an example, will a list.reverse(some_list) function reverse the list in-place, or return a copy of the reversed list and leave the original in-tact?

Mmm - that is an excellent example, though not one specific to OOP… But I see your point. I think Kotlin and other languages have addressed these types of issues with ‘mutability’ as part of the type where it becomes explicit which variables can be modified. Kotlin even has “MutableList” as distinct from “List” which lets you say whether a list’s contents can be modified.

FizzyOrange@programming.dev on 31 Aug 17:44 collapse

Definitely a promising language, and I tried to write something with it a year or so ago. It’s clearly still in the “research language” phase though; “hello world” took about 2 minutes to compile.