The scientific proof of that OOP is a mass psychosis

Thomas Hansen - May 9 '22 - - Dev Community

Since my previous article generated 100+ comments, 9,500 page views, and some people commenting in anger demanding proof of my statements, I figured I'd prove it. Notice, I tried to explain how the proof of that OOP is a software development mass psychosis by stating "the proof is in your code" - However, nobody apparently believed me, so let me illustrate what I meant by that with two short code snippets doing basically the same.

C++

const auto ret = Tasks::join(
   m_Factories.HTTP->GET("https//gaiasoul.com"),
   m_Factories.HTTP->GET("https://servergardens.com")
).Start();
Enter fullscreen mode Exit fullscreen mode

Hyperlambda

join
   fork
      http.get:"https://gaiasoul.com"
   fork
      http.get:"https://servergardens.com"
Enter fullscreen mode Exit fullscreen mode

For those of us without bias the above should really be self explanatory and enough as proof. However, if you still find it difficult to see the proof, explain the basics of multi threading to a child (who's still not been exposed to OOP), then explain the basics of HTTP and retrieving documents from other servers, and ask the child "which is the easiest to read"?

If you're still in doubt, please realise that the above C++ code was supplied by a commenter as proof of that C++ was "just as good as functional programming languages". Then realise there's no instantiation of the m_Factories variable. Assuming the code is using the accepted coding standards, it's probably safe to assume it's a member variable of some sort, implying the class where it's declared is not shown, the member variable itself is also not shown, so it's probably safe to assume the (complete) code example would probably be at least 3/4 times as large as illustrated in the C++ example above. The C++ example of course also has tons of additional unnecessary constructs, such as classes, types, constructors probably, possibly destructors, maybe even (sigh!) copy constructors, etc, etc, etc - Most of this additional overhead of course being additional unnecessary overhead it shares with all OOP languages out there. However, even ignoring the missing C++ parts, the following is obviously true ...

The Hyperlambda example is obviously 100 times more readable!

Then realise the Hyperlambda code snippet above can literally be pasted into the "Eval" menu item and immediately executed, implying it's a 100% perfectly complete example. Something you can see in the cover image for this article. Then finally, also realise that the Hyperlambda snippet for all practical concerns is just as fast as the C++ version, since 99.999999% of the time is spent waiting for IO, and the Hyperlambda snippet is 100% perfectly async, and hence shares the same traits in regards to CPU and RAM usage as its C++ equivalent. So even though C++ might sometimes be faster than Hyperlambda, the speed performance gains C++ gives you would in 99% of the times be completely irrelevant unless you're developing drivers for hardware or something similar.

Facts are, I can replace 95% of your existing OOP code, with 20% as much Hyperlambda code. If you're using C++ probably as little as 5% as much Hyperlambda code - And it'll for all practical concerns be just as fast, consume the same amount of memory, and no more CPU - Assuming you're creating web apps of course, accessing some sort of database, integrating with other HTTP services. However, the proof of that OOP is a software developer mass psychosis is literally in your code, so let me repeat the code once more for clarity reasons ...

C++

const auto ret = Tasks::join(
   m_Factories.HTTP->GET("https//gaiasoul.com"),
   m_Factories.HTTP->GET("https://servergardens.com")
).Start();
Enter fullscreen mode Exit fullscreen mode

Hyperlambda

join
   fork
      http.get:"https://gaiasoul.com"
   fork
      http.get:"https://servergardens.com"
Enter fullscreen mode Exit fullscreen mode

Really, arguing against the code is literally futile ... :/

BTW, in case you're about to show me Python, Ruby, or PHP code at this point, please realise that Hyperlambda is probably (at least) one order of magnitude faster than all of these languages ...

The explanation of the proof

If you still don't get it, try to imagine a software development noob looking at these two snippets of code, asking questions. How many questions would the noob need to ask before understanding these two code snippets. Well, the Hyperlambda version would be as follows.

  1. What's with the colon :?
  2. What's with the spaces?
  3. What's a fork?
  4. What's a join?
  5. What's a URL?

The C++ equivalent would resemble the following.

  1. What's a const?
  2. What's with the auto thing?
  3. How does assignment work?
  4. What's with the Task?
  5. What's with the double colons ::?
  6. What's a join?
  7. Why the parenthesis?
  8. What's that m_Factories thing?
  9. Why does m_Factories start with m_?
  10. What's with the . after m_factories?
  11. Why can't we use . after HTTP, and what's with the -> part?
  12. What does Start do?
  13. What's with the semicolons?
  14. What's a URL?

And if we saw the complete example, including its class declaration, we'd have an additional.

  1. What's a class?
  2. What's with that private/public/protected thing?
  3. Why does it repeat the class name 3 times? (CTOR, copy CTOR and DTOR)
  4. Etc, etc, etc ...

Facts are, once you break down C++ into questions required to have an answer to before becoming productive in the language, C++ is little more than "glorified regex", with millions of characters, tied together such that changing just a single one of these characters, typically have repercussions to your entire program. The same is also true for most other OOP languages ...

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .