4 ms·

There are plenty of functional libs in the Nim ecosystem, the prominent ones being: * NimFP[1] * Zero-Functional[2] Disclaimer: my very first language was

There are plenty of functional libs in the Nim ecosystem, the prominent ones being: * NimFP[1] * Zero-Functional[2] Disclaimer: my very first language was Haskell and I'm now a Nim core contributor. Mutability: just like Ocaml, Nim has `let` and `const` and mutable function parameters and mutable variable need `var`. Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). Also many people in Nim community are pushing for more control on mutability, you can see for example the proposition on writetracking[3]. * [1] https://github.com/vegansk/nimfp * [2] https://github.com/zero-functional/zero-functional * [3] https://nim-lang.org/araq/writetracking.html

nudpiedo 8y ago
In my humble opinion on language design, if the main language favours a paradigm or style, the libs will do it even worse although some programming languages gave weird reimplementations of their whole stdlib in a different paradigm it is not the rule. C will be C no matter how much MISRA certifications are sold. For example, kotlin is very promising language on the paper, but in the reality it is being developed by people who kept a Java mindset and way to structure problems and code (and they repeat same concepts and ideas as they do in java, for example calling DSL to every single piece of nested code).
electrograv 8y ago
> Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). “Shallow immutability” is not just a “caveat” — it’s a complete abuse of the word “immutability”. If you can in-place modify the interior of a so-called immutable value in any way (possibly excepting code within some kind of “unsafe” blocks), it is by definition not immutable. Immutability is a pure, all or nothing kind of thing. That you are trying to present immutability as synonymous with C++ style “const”ness perhaps reinforces the parents’ post that Nim is not friendly or even aware of the functional paradigm of programming. But unlike others, I think it’s okay that it doesn’t support immutable variables. It certainly doesn’t outright condemn the language. However, let’s not pretend it’s something that it’s not.
- mratsim 8y ago
  Nim const are compile-time constants, it's completely different from C++ const. I don't agree on immutability, just like you have shallow copy and deep copy, you have shallow immutability and deep immutability. Also functional programming also distinguish pure (Haskell, Idris, ...) and impure functional programming (Ocaml, ...). Allowing side-effect through reference doesn't mean that a language is hostile to functional programming. It just means that it does not enforce purity.

nudpiedo 8y ago

In my humble opinion on language design, if the main language favours a paradigm or style, the libs will do it even worse although some programming languages gave weird reimplementations of their whole stdlib in a different paradigm it is not the rule. C will be C no matter how much MISRA certifications are sold. For example, kotlin is very promising language on the paper, but in the reality it is being developed by people who kept a Java mindset and way to structure problems and code (and they repeat same concepts and ideas as they do in java, for example calling DSL to every single piece of nested code).

electrograv 8y ago

> Caveat: for reference types, immutability is shallow (you cannot change the reference but you can mutate the reference content). “Shallow immutability” is not just a “caveat” — it’s a complete abuse of the word “immutability”. If you can in-place modify the interior of a so-called immutable value in any way (possibly excepting code within some kind of “unsafe” blocks), it is by definition not immutable. Immutability is a pure, all or nothing kind of thing. That you are trying to present immutability as synonymous with C++ style “const”ness perhaps reinforces the parents’ post that Nim is not friendly or even aware of the functional paradigm of programming. But unlike others, I think it’s okay that it doesn’t support immutable variables. It certainly doesn’t outright condemn the language. However, let’s not pretend it’s something that it’s not.

mratsim 8y ago
Nim const are compile-time constants, it's completely different from C++ const. I don't agree on immutability, just like you have shallow copy and deep copy, you have shallow immutability and deep immutability. Also functional programming also distinguish pure (Haskell, Idris, ...) and impure functional programming (Ocaml, ...). Allowing side-effect through reference doesn't mean that a language is hostile to functional programming. It just means that it does not enforce purity.