News for hackers. Stuff that matters.
Re:Grain: A strongly-typed functional programming language f... by pyrale on Sunday April 25, 2021 @12:54PM (#26934215)
You seem to believe that, because tuples are available in a language, they will be used everywhere. And indeed, that wouldn't be great.

From my mileage in this industry, though, the cases you describe simply don't happen. As you said, tuples aren't used in interfaces, because developers know better than to do that.

> which is more often than not the issue of functional programming and why it can't scale well

I don't know what you've done with FP, but in your last few posts, you've been making claims about it that simply don't match my experience. There's not much to discuss without specifics, though, so maybe you could expand about the cases where you had issues with it?

Re:Grain: A strongly-typed functional programming language f... by slver on Sunday April 25, 2021 @01:03PM (#26934312)
I wish tuples didn't exist in interfaces, unfortunately every function and method argument list is one. /s

I appreciate your point that people try and avoid tuples where not appropriate, but the question is why even have that opportunity, when we can nudge the community to use equivalent "named attribute tuples".

Regarding scale, FP scales great for certain types of problems. But it's not great at modeling or encouraging boundaries. Imagine doing FP where all your types cease to exist for part of your codebase, but also you need to interact with the code where the types are. Even more, imagine if those two modules may fail independently (i.e. so you lose one of them). Anyway I think I'm becoming too abstract.

Basically the FP world needs to be more like Erlang. Erlang is functional but keeps units bounded (in processes).

Re:Grain: A strongly-typed functional programming language f... by pyrale on Sunday April 25, 2021 @01:47PM (#26934744)
> but the question is why even have that opportunity

I have provided a valuable use case above, and creating a structure allowing convenient use cases while preventing inconvenient ones would be extremely costly.

> But it's not great at modeling or encouraging boundaries.

What features are you missing specifically? You cited the need to "keep units bounded", but most FP langs provide the ability to contain implementation details within modules, by not exporting them.

> Imagine doing FP where all your types cease to exist for part of your codebase, but also you need to interact with the code where the types are. Even more, imagine if those two modules may fail independently (i.e. so you lose one of them).

I've had to deal with antiquated DBs containing unreliable data using flaky drivers, and while working with legacy can be painful sometimes, the FP paradigm caused no specific trouble.