so our computers are not suited for FP languages right?
The machines we know actually are based on Alan Turingās work.
FP is based on Alonzo Church lambda calculusā¦
They were trying to solve the same problem, by different means.
Actually itās quite easy, there is even a kernel called mirage built in OCaml that is blazing fast, very safe, and fantastic for embedded usages.
These are the big things, yet OCaml works around it by allowing you to add safe mutability when necessary, and if even further needed you can do entiirely unsafe code (in the Rust sense) via Obj.magic (which honestly you should never need to touch unless doing systems programming. The last bit is the GC, but that is fairly controllable in OCaml when necessary unlike most other languages.
āIn Generalā OCaml and C will compile to very similar machine code (Excepting GC and such) and using the same algorithms in both you will achieve almost identical speed. This cannot be said of something like Haskell for example.
Correct, recursion is just a loop in another form, if it compiles slower then thatās an issue of the compiler and/or the programmer, not the fact that it is recursion. OCaml, for example, compiles recursion into assembly jumps, which is what loops do as well.
Rust is very nice, sadly it has a lot of Haskellāisms that I wish it really really did not have that is contributing to some syntax woes, but it is very nice overall. OCaml with a borrow system to get rid of itās GC would be even better though. ^.^;
Uh, algorithm or not Ruby is SLOW, on the order of hundreds of times slower than something like C/Rust/OCaml, that is the difference of processing data between, oh, 5 seconds or 5 hoursā¦
You can add attributes to functions that specify that they fail to compile if TCO cannot be performed as well in most compilers (clang can and I think gcc can too) too. 
In python you can fake it via generators to an extent. Go is just garbage. The JVM and .NET both donāt like that TCO removes stack frames (while they completely ignore the fact that loops have no stack frames at all so why does that even matter?!).
That is also garbage, detecting TC is trivial in every compiler Iāve ever looked at. You literally just look at the last expression and see if it is a function call and if it returns the same type as āthisā function itselfā¦
Yeah they complain that TCO/Recursion removes stack frames which makes debugging harder, and yet they completely ignore the fact that the loop has no stack frames at all, so I donāt know what they are thinking thereā¦ ^.^;
Plus the average programmers are not that stupid, like reallyā¦ And if they want to fix debugging stack frames then just with a flag have it store the āstack framesā to a shadow stack, which is another popular pattern. The JVM/.NET/Go/Javascript authors bug the crap out of meā¦ >.>
That is only if you donāt have TCO.
Whoooo that site takes a long time to start returning data!
As we can clearly see, the recursive is a lot slower than the iterative (considerably) and limiting (stackoverflow).
The reason for the poor performance is heavy push-pop of the registers in the ill level of each recursive call.
Yeah this author seems to be lacking knowledge on this subject, these costs donāt exist with TCOā¦
too long/stack overflow
This also does not exist with TCOā¦
Yeah this article isā¦ not well reasonedā¦
Haskell has a lot of overhead compared to OCaml because it LOVES thunks, it allocates thunks EVERYWHERE it seems, consequently it is always slower in comparison.
Theyād be similarā¦
Iād say on average it would be C++ at 1x, C at 1.5x, OCaml at 1.5x, and Haskell at 3x for well written readable programs in each. C++'s metaprogramming can create pure magic with assembly so itās hard to beat it when you are tryingā¦
GC can be tuned in both GHC/Haskell and OCaml, and with the proper constructs in OCaml then you can run pretty well GC-less, though code starts looking more like C then. ^.^;
OCaml is the fastest optimizing compiler of any language out. ^.^
C++ can get scary because templates (though it is SO MUCH better than it was 10 years ago).
Haskell gets scary because it uses an HKT typing system, which requires program flow analysis, compared to OCaml that uses HPTās, which are scope contained, significant differences (and HPTās are overall more powerful than HKTās too, though slightly more verbose, but not by much).
Mmmmm, tasty LISP Machines, I so wish they become commonā¦ ^.^
Oooo a new language to look at that Iāve not seen yet! Thanks!
(EDIT: Ah, itās basically an MLāy dialect of OpenCL, not bad though.)
They are suited fine. ARM and x86 are so crazy-optimized that they do everything āwellā (not perfectly in all cases, but far far better than any average on about everything).
@OvermindDL1 these days i see alot Ocaml(reasonMl, bucklescript, forumā¦). First i thought it is a new language but not. Why everyone is rediscovering Ocaml after longtime ?
Iāve used it for ~15 years so Iām unsure about this whole rediscovering thing (I so love the 'newāish GADTās and PPXās though, whooo!)ā¦ ^.^;
In the context of elixirforum:
- Primarily: You keep bringing it up.
- Connected with that BuckleScript is usually next thing to come up.
- ā¦ which these days usually has ReasonML on itās heels.
- Forum members looking for JavaScript alternatives that arenāt like JavaScript (e.g. TypeScript) while at the same time not feeling like a straitjacket like Elm or possibly PureScript.
- And then of course there is the whole F# ā OCaml thing. While F# may be somewhat niche on the .NET platform, I wouldnāt be surprised if itās one of the most active ML versions.
- I keep bringing up F# because of Scott Wlaschinās DDD/FP work.
Outside of elixirforum
- OCaml being used by Facebook with Flow.
- OCaml is the template for Facebookās ReasonML (almost suggesting that in some cases Flow doesnāt go far enough, in which case itās worth it to go further than TypeScript).
- Facebook using OCaml is calling attention to Jane Street having used it for years.
So around these parts the OCaml awareness is unusually high - to the point of being a false positive.
Haskell is much easier for people to find because of itās notoriety and proclaimed purity. Iām also given the impression that for the time being Haskellās concurrency story is better than OCamlās. Personally I also found that ways to get started with OCaml as a āself-learnerā are pretty limited if you arenāt into reading documentation. In my opinion the tutorials and Real World OCaml largely require that you have already acquired the āfunctional mindsetā and most beginners never find the much more basic ocaml-book (or dismiss them as too basic).
(Also apart from F#, I donāt think that OCaml was problem free on MS Windows for the longest time.)
Somehow Pythonās āaccessibilityā got the Machine-Learning community stuck to it. I see OCamlās apparent lack of a good beginnerās path as a huge missed opportunity because from what I can see OCaml would have been a much better fit for Machine Learning.
Anecdote:
Q: Why are we using OCaml in this class?
A: To make it harder to find/understand answers on StackOverflow.
Yep, still not getting on why itās such a problem to implement. Well, I remember that Scala compiler does such optimization, but itās quite trivial, i.e. turns recursion into a loop, also requires user to provide annotation on such a method
This works only if the last call of the method is calling recursion.
Also it is not trivial if you use two recursive function calling each other ā¦
Then you must use trampoline.
damn JVM ā¦
Yeah it only recently started working well on windows. ^.^;
Hmm, true, Iāve not actually got around to checking its machine learning libs, thatās an interesting ideaā¦
Hahaha, Iāve gotta remember that! Thatāll be awesome at where I work. ^.^
That only works on local recursion, not unbounded recursion, I.E. it is not actually perfect TCO, it is local only.
Thatās TCO in general.
Indeedā¦
Two videos explaining why Jane Street adopted OCaml over more mainstream choices (and still considered it performant enough).
.NET IL has TCO. F# compiler generates proper TC but C# does not (at least it didnāt last time I used it). No idea about VB thought.
The guy that wrote the article knows very little about programming.
If one rewrites the recursive versions to be tail recursive, they are very READABLE, are very fast and MAY even be faster than the iterative variant. Please donāt believe everything you read own the Internet.
If you donāt run yourself the benchmarks, you are in the dark.
I also find it worrying that the article says that an Ackermann function can not be transformed into an iterative versionā¦
Some links:
https://www.sciencedirect.com/science/article/pii/0304397588900461
