7 ms·
It is quite obvious to me that the author is ignorant on the history of computing. The reason of the popularity of OOP is way longer than java, Xerox invented
by hevi_jos 8y ago
It is quite obvious to me that the author is ignorant on the history of computing.
The reason of the popularity of OOP is way longer than java, Xerox invented the graphical desktop and ALSO OOP.
When Steve Jobs was ousted from Apple he created NEXT because he believed OOP was the next big thing. It was, and it became the foundation of MacOS X. Microsoft copied Steve Jobs in Windows with MFC. Java copied all of them.
In the words of Steve Jobs, developing in OOP is not faster than not using it. The big difference was once it had been created, it can be reused easily. That was essential for complex systems. It became obvious for companies.
There is this religion today of functional programing, people come to me and say, look how great this is, without state parallel programming is so easy, now you can use 32 processors at the same time. Great!!, until we measure performance and the thing goes 50 times slower. So now you can use 32 processors for what used to take one.
Don't get me wrong, we use functional programming when it is the best tool for the job(it removes lots of bugs), but it is not panacea.
- adamnemecek 8y agoFunctional programming has little impact on performance.
- zaphirplane 8y agoProbably talking about Java’s implementation which takes a while to warm up
- pjmlp 8y agoOnly when proper use of memory isn't part of performance.
- goalieca 8y agoOop is slower than functional in many cases. The highly optimized java stack isn’t that fast and still uses oodles of memory. And then there’s languages like ruby which are practically slower than writing shell scripts.
- pjmlp 8y agoFunctional generates tons of garbage and requires a very good concurrent generational tracing GC, more so than OOP languages. Only thanks to researchers like Simon Peyton Jones[1], did functional language compilers improved their code quality. [1] - https://www.microsoft.com/en-us/research/publication/the-implementation-of-functional-programming-languages/ https://www.microsoft.com/en-us/research/publication/the-imp...
- willtim 8y agoIt's actually harder to write a GC for a language like Java with both rampant mutation and plenty of garbage!
- pjmlp 8y agoI only accept CS papers about it, do you have one at hand against Java favouring some random FP language instead? Something of this level of quality, not random assertions on online forums. http://kcsrk.info/multicore/gc/2017/07/06/multicore-ocaml-gc/ http://kcsrk.info/multicore/gc/2017/07/06/multicore-ocaml-gc...
- willtim 8y agoThere are a few papers about Haskell's GC by Simon Marlow where this is discussed. The absence of mutable references is a big win for writing a concurrent collector.
- pjmlp 8y agoI don't recall any of Marlow's papers having a table comparing performance of Haskell tracing GC implementations versus the tracing GC implementations available across several JVM implementations.
- willtim 8y agoYou never defined what you meant by a "good concurrent GC", only now are you asking for "performance" numbers. My point is that writing a GC for Java has in fact proved very difficult. It took Sun and Oracle many man years and different GC designs to get where they are today. So it seems Java also needs a "good" concurrent GC. With both functional and OOP languages generating a lot of garbage and sharing language features, I don't see a big difference in requirements in practice. And sure enough, Clojure/Scala seems to work well using the JVM GC and F# seems to work well with the .NET GC too. I think the burden of proof rests with you and your statement that the concurrent GC situation is somehow more challenging for an FP language. > I only accept CS papers about it Me too
- deleted 8y ago[deleted]