91–100 of 417 posts
Earlier quoted context omitted.
Jane Street wrote a compiler that converts Ocaml to Verilog which they run on FPGAs. The OCaml you write in that case is pretty different than what you write for CPUs.
"A FORTRAN programmer can write FORTRAN in any language"
JavaScript isn't a functional language itself, but you can use a functional library like lodash/fp ( https://github.com/lodash/lodash/wiki/FP-Guide ) on top of it to get all that lovely functional goodness in your frontend and node code. Using lodash/fp has made my frontend state management code a lot nicer, and I'm really only just starting out with it.
Personally, I think JS is a fine functional language. Like you say, it doesn't have a good FP style system library, but it doesn't have a good anything style system library ;-) My main complaint is that currying is awkward. One thing I have discovered, though, is that closures are relatively slow (that is, unoptimised) in most implementations. In several implementations, they can also leak memory in certain circumsta…
But most importantly, prototypal inheritance, in other words invoking the object's own methods as if they were pure functions is what really puts me off.
Earlier quoted context omitted.
I’m all for mechanical sympathy, and I’m sure that some programmers legitimately need their language to map neatly to assembly, but that isn’t the norm as evidenced by the overwhelming popularity of interpreted and VM languages. Lots of companies are making money hand over fist with Python, which is probably 3 orders of magnitude (or more) slower than the optimized C or C++ that this real-time graphics engineer is wr…
we users pay a price for this trend though :( Those python users could switch to F#/OCaml/Clojure and get a big speed boost too!
Simple as that.
I am a functional and OOP programmer myself. I find functional way more elegant for modeling most mathematical problems, but OOP way better at modeling real life things with states.
OOP and states introduce lots of problems and complexity, but the solution is not removing states, or a series of complex mathematical entelechies.
In fact "removing states" is not really removing them. It is creating new objects with static states on it. It makes it super hard to model real life.
(dynamic)States exist in real life. Temperature, pressure, height, volume, brightness, weight...
There are programmers that understand programs as a religion, they only program in one system ans believe it is the best thing in the world and everybody should be forced to use it. I feels sorry for them and the people that depend on them.
The solution will be new paradigms that are neither OOP nor FP.
OO is the norm because it is has immediate business value and is easier to teach to young people. Most programmers in the work place are produced from educational institutions. Educational institutions has competitive quantifiable
FP requires thinking in terms of calculus. This isn't hard, personally I find it much faster and easier. Thinking in calculus does require some maturity, and possibly some analytical experience, young students may not find comfortable.
---
This question can also be answered in terms of scale.
FP reinforces simplicity. Simplicity requires extra effort, often through refactoring, in order to scale or allow extension for future requirements. This is a mature approach that allows a clearer path forward during maintenance and enhancements, but it isn't free.
OO scales immediately with minimal effort. OO, particularly inheritance, strongly reinforces complexity, but scale is easily and immediately available. This is great until it isn't.
The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…
Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.
Yes, OCaml has garbage collection. It's a very efficient GC, and it is only ever called when you try to allocate something and the system determines that it's time for cleanup (https://ocaml.org/learn/tutorials/garbage_collection.html, though this might change if/when Multicore OCaml ever happens?). So if you write an innermost function that does arithmetic on stuff but never allocates data structures, you will not have GC problems because you will not have GC during that time, period.
Also, there are cases where destructive mutation of things is more efficient than making pure copies. OCaml allows you to do that, you don't need to fiddle with monads to simulate state.
There really isn't that much black magic there. Just don't believe everything that is said about "FP".
The top comment on YouTube raises a valid point: > I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage col…
I regularly read the assembly output of the OCaml compiler I'm using and there are very few surprises. The mapping from source to generated assembly is quite straightforward. You couldn't say the same for Haskell, though. So it depends on which FP language you're using.
Earlier quoted context omitted.
Even in maths, I find a solution in terms of the problem easier to understand than one in terms of the previous step. Even when the recursive form is a more natural representation, like arithmetic sequences: start at s , increase by d with each step: a(0) = s, a(n) = a(n-1)+d a(n) = s + n*d The analytical form seems simpler, neater, more "right" and more efficient to me - even though, if you want the whole sequence,…
Lately I’ve been thinking that a lot of code style debates center around an explicit versus implicit axis. Imperative is more explicit, and, in one sense, easier to see what’s going on since it lays everything out step by step. On the other hand, those same steps are a mix of essential steps (that deal with the problem being solved) and accidental steps (that deal with computer and code in order to get the job done.)…
I've been trying to think of a totally clean functional abstraction, i.e. that's functional under the hood, but there's no way to tell. Perhaps in a compiler?
Richard Gabriel’s famous essay “Worse is better” ( https://www.jwz.org/doc/worse-is-better.html ) is an interesting perspective on why Lisp lost to C. In a way, the same arguments (simplicity vs consistency vs correctness vs completeness) can be made for why functional programming lost to OOP. But those philosophical perspectives aside, personally I find my brain works very much like a Turing Machine, when dealing wi…
> personally I find my brain works very much like a Turing Machine Exactly this. How baking a cake in FP looks like: * A cake is a hot cake that has been cooled on a damp tea towel, where a hot cake is a prepared cake that has been baked in a preheated oven for 30 minutes. * A preheated oven is an oven that has been heated to 175 degrees C. * A prepared cake is batter that has been poured into prepared pans, where ba…
And then, when someone returns to that code, they have no idea that these steps are unnecessary and why each step was taken. (Or maybe they are necessary, because cloud counting ensures there is time for ingredients to permeate?). So probably these steps will be left and more mess and jungle will accumulate.
Earlier quoted context omitted.
might be interesting for you, Lips in production: https://tech.grammarly.com/blog/running-lisp-in-production
Notice that they are using Common Lisp, which is a multi-paradigm language, rather than a more functional lisp like Clojure.