161–170 of 171 posts
Earlier quoted context omitted.
> What you're referring to is more of what happens when someone is writing functional code in a language that's not functional. And even then, there is the question of whethwr it is a deep or shallow copy on receiving or write.
just pass a const reference. It's immutable anyway.
Earlier quoted context omitted.
Immutable data structures often don’t copy a lot of data around. Immutable linked lists have tail references from each head. If something falls out of scope it gets collected by the garbage collector. Also if you don’t share memory between processes, you can free that memory once a process terminates, which may seem orthogonal but it’s a core principle in Erlang.
Those copy-on-write linked data structures, with the implied pointer chasing, have a cost. That's what the parent is talking about...
Earlier quoted context omitted.
You don't have to do work; at any step you have the functions available that operate on the object returned (whatever it is). On the "Functions and Data" side you are similarly constrained by the possible functions that operate on that data.
What I meant by "work" is, that inside your methods you have to return an object, which has the method, which is the next thing in your a().b().c()... chain. Often in OOP you would not return the object itself, unless you do the builder pattern. Of course you can return other objects, if it is intended, that the chain has a call to a method of another object next. However, you may only call methods of the returned ob…
Immutable objects are a pretty old idea, smalltalk had select (map) methods that returned a whole new collection back in the 80s.
Earlier quoted context omitted.
What I meant by "work" is, that inside your methods you have to return an object, which has the method, which is the next thing in your a().b().c()... chain. Often in OOP you would not return the object itself, unless you do the builder pattern. Of course you can return other objects, if it is intended, that the chain has a call to a method of another object next. However, you may only call methods of the returned ob…
There's no law stopping you returning a new object from a method outside the builder pattern. Immutable objects are a pretty old idea, smalltalk had select (map) methods that returned a whole new collection back in the 80s.
String next = original.substring(2);Earlier quoted context omitted.
There are very successful insects.
No creature is limited to the use of a single programming language, but a lot of programs are. You can learn more than one language and choose one that is appropriate for the task, unlike an insect whose tools are limited so he must have only a few to do everything it needs to. Multi-paradigm is the insectisation here.
> The right approach for the top level rarely matches that for most of its parts, nor each for the others, and likewise down the line. Unless you want to use a different language for each level and subproblem, you will want support for all "orientations" in your language.
It is grossly impractical to use a different language for each fragmentary part of a problem. People do not, as a rule, do that. Trivial exceptions include Python and niche-language programs calling out to C-ABI libraries, programs sending SQL to databases, and web servers sending Javascript to browsers. But those are not about "orientation".
You might use two or more different general-purpose languages for different, independent problems, but that does not contradict my remark about the folly of languages that attempt "purity".
Earlier quoted context omitted.
Aside from being able to prove that the solution halts, you mean? You get a lot of side benefits as well with a halting program, such as provable limits in time and space for the totality of the program instead of just the functional core bits.
Maybe you are unable to prove properties of programs you have coded in Turing-complete languages. Many of us do, though. Routinely. Quick, does this program terminate: int main() {} ? Can't prove it?
Earlier quoted context omitted.
Maybe you are unable to prove properties of programs you have coded in Turing-complete languages. Many of us do, though. Routinely. Quick, does this program terminate: int main() {} ? Can't prove it?
That's not a very useful program.
Add to it, and show that it still terminates, uses finite memory, introduces no data races or undefined behavior, and maybe computes a step toward something useful.
Repeat until done.
Earlier quoted context omitted.
> have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily. How much of that comes from belief rather than reality, and potentially some room to grow on your end? I can debug well written code in any language I jump into, but I've found poorly written and hard to debug morasses can be writ…
> How much of that comes from a belief rather than reality, and potentially some room to grow on your end? You know… suggesting that someone that they’re delusional and uninformed isn’t a very charitable way to discuss anything online. The belief came from personal experience from 2016-2018 while I was much more experienced with JS/TS and relatively new to Elxir. It definitely influenced me to keep exploring and lear…
I think there's no reason to exaggerate what I said just because I don't love your pet principle as much as you do. Here's what I explicitly describe as being part of well-written (or poorly written) code, which has very little to do with FP vs OOP vs procedural:
"Poor naming, branch/loop structuring, scoping, data modeling/normalization, module structuring, logging, and dependency selection/integration"
>The phrase “well-written” may be doing a lot of lifting here
I think if you read the entire comment, you'd see it doing a lot less lifting because I explicitly detail what "well-written" is. And I think it is cross-language.