51–60 of 148 posts
I think anyone who has coded long enough would recognize that OOP, functional, imperative, etc all have their strengths and weaknesses, and all have problem domains they are better suited for. Unfortunately, this sometimes gets lost in the language fan wars - it’s easy to lose nuance when discussing something you are passionate about, I have made this mistake myself.
Earlier quoted context omitted.
I completely agree. Just write pure functions as much as possible and you're good. What goes inside a function doesn't matter so long as the function itself is pure, imo
Do you have any examples of compilers or linters that assist with this? Any kind of error or warning would do.
[1] https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr...
Honestly I think this conclusion comes more from lack of familiarity with how people solve similar problems with FP than anything. For example, in the author’s followup post: All you have to do is pass the world state to each function and return a new state. True, yes, but...yuck. It can be clunky in a language with single-assignment. And what is this really gaining you over C? I mean, if you stop there, sure that’s…
I think it's more accurate to say that it makes you account for the possibility that an object is put into an invalid state at every mutation you do. Which can be good and can be bad. Good being that your code is safer and less likely to have errors. Bad because it's more rigid and trickier to deal with objects containing multiple errors.
Can someone with experience of entity component systems (ECS) please chime in? My understanding is that games are not written in the manner that the author says is so easy, rather they are written as pure functions operating on a big table of world state. The world state happens to be mutable for efficiency, but that's an implementation detail. Then again I've never worked with ECS so perhaps this my misconception.
But in ECS engines you still access a portion of global world state you're interested in, and you mutate some portion of it. The ability to declare what those portions are, when present, allows ECS engines to do stuff like parallel execution of systems, and it also prevents a host of data races, but imho there's nothing really functional / pure / immutable about it.
Honestly I think this conclusion comes more from lack of familiarity with how people solve similar problems with FP than anything. For example, in the author’s followup post: All you have to do is pass the world state to each function and return a new state. True, yes, but...yuck. It can be clunky in a language with single-assignment. And what is this really gaining you over C? I mean, if you stop there, sure that’s…
> admit that functional programming is the wrong paradigm for some types of problems. Absolutely. Some problems are just so much simpler in an imperative style that it's worth the lack of confidence you get with the functional solution in its correctness and robustness. That's why I love languages that have fairly powerful functional features but have an imperative escape hatch. I think more and more languages are be…
IMHO TypeScript is getting really good now, in the 4.1.
I think it's time we stop using the phrase "functional" to describe this paradigm; at this point, every imperative language made in the past 30 years has first-class functions, and there is no other first-class language feature common to all the self-described "functional" languages. IMO, a more accurate term would be stateless programming. This paradigm is about minimizing state. Of course, as the OP mentions, state…
> there is no other first-class language feature common to all the self-described "functional" languages. This line of speech usually serves to corner FP in a self-contradicting definition that can be wrestled with, and it is really aggravating. Functional programming as a concept is well defined, and it's not merely "first-order functions". The reason why many functional languages don't have the same feature set is…
It is really more about controlling state and avoiding it where deemed unnecessary, rather than adherence to a total philosophy. This is done for practical reasons (avoiding pain mostly), not for ideological ones.
Earlier quoted context omitted.
I completely agree. Just write pure functions as much as possible and you're good. What goes inside a function doesn't matter so long as the function itself is pure, imo
Do you have any examples of compilers or linters that assist with this? Any kind of error or warning would do.
In js you can freeze an object to avoid mutation, but there's a performance penalty and a lot of hassle. As for side effects, you have the async keyword which often tells you if a function contains a side effect or not.
In typescript you can use readonly for objects and arrays to avoid mutation, but it becomes a hassle for nested objects, and it doesn't work for local state where it's actually ok to mutate things. There is an issue open for typescript that proposes to add a "pure" keyword, but I think it's quite hard to implement.
What I do instead these days is to separate pure from impure by using separate files, but as you noted in a sibling comment, this can quickly fall apart if people aren't onboard with the idea.
Earlier quoted context omitted.
Functional programming was never about first-class functions. It was always about programming with pure and total functions in their mathematical version.
This may be true in your personal experience but that’s certainly not universal. A key distinction is when you learned this: 2-3 decades ago when most people were using languages without first-class functions, this was very commonly the most important feature mentioned because it was the most pronounced difference. That’s no longer emphasized as much now that this feature and related techniques has become mainstream.
It is not surprising that "what's the difference between your language and mine" will yield an answer that is different than what you'll get if you ask "what is that concept you're trying to build a language after?"
>Sure, there have been games written in Lisp and some games written by language dilettantes fond of Objective Caml, but they never turn out to be programmed in a functional style. You can write imperative code in those languages easily enough. I would like to know more about this. I've written several games in Elm, a js counterpart to Haskell, and I guess foolishly assumed that meant I was writing them in the functio…
My understanding (which there's a good chance is incorrect) is that all code written in Elm has to be in a functional style because the language strictly enforces it; but this enforcement doesn't exist in Lisp and OCaml, so they can be used to write imperative or object-oriented code, as happened in the cases described.
int x = foo();
bar();
char y = baz(x);
do
x