One of the slides in the quoted post talked about how React.js's supposedly "modern way" is actually 70's style FP programming (or 50's style more accurately given that Lisp, the first Functional Programming language, started in the 50's).
It's not a crime to write simple OOP intuitive code with mutation in Ruby that maps to the real world (which does have mutation, so get over it!). Developers lose half the battle from the get go if they start translating real world concepts to mathematical functions just to do FP as by doing so, they've already distanced themselves so much from the Business Domain and violated Domain Driven Design.
The most hilarious and ironic thing is I run into sometimes is FP liars who claim they are following Domain Driven Design in FP, except their code is nothing but math functions that have nothing to do with the real domain objects. The moment you declare a function instead of an object, you're out of DDD already! If I cannot say turn_right on a car object (like when invoking a method on an object), yet have to translate that to calculate_distance_difference while passing it the direction as an argument, the code is already so far from the domain, it's total trash.
Nowadays, many devs choose comfortable lies over the hard truth, and end up wasting 6 months a year of their client resources at least by over-engineering everything with FP. Yes, FP is over-engineering if used for the wrong problem for it even if it seems "simple". FP was meant to be for mathematical algorithm implementations. As soon as things evolved into simulations and real world modelling, FP was superseded with OOP for those problems while remaining useful for implementing lower-level mathematical logic inside object methods. In fact, OOP is nothing but FP with smart data (objects) that knows its own functions (methods). There are millions of ignorant devs nowadays that repeat lies they heard from other ignorant devs about FP and OOP. They're devs who never thought for themselves and questioned anything, yet just accepted ideas because they're popular. The worst kind of developers.
Of course, we all know that the reality is "modern FPists" are only that way because they have a skill issue with OOP and they're too lazy to overcome it, so they default back to FP out of sheer incompetency. the only reason anyone might avoid the ultra simple OOP is lack of skill in simple abstraction and real world modelling (I mean it doesn't get easier than a car has a move_forward, move_backwards, turn_right and turn_left method, and yet somehow some ignorant devs have a skill issue with that!). Lack of skill in simple code design is a disease. FP is not "simple" compared to OOP. It's just "less sophisticated" in representing real world concepts. I don't care that in the end data is being transformed as if it's in a math function. We don't want to read that when maintaining the code. We want to read business domain knowledge instead. Mutation is OK. OOP is OK. Complicating the code by using a less sophisticated construct like FP for the wrong problem IS NOT OK. I use FP where appropriate only, not all the time like unskilled lazy devs.
The only upside to this is the Software Development world is so uncompetitive nowadays for Master Software Engineers. Job security is easier than ever for those in the know. I thank the ignorant incompetent lazy devs for giving us that easy job security at their expense.
#oop #fp #objectorienteddesign #functionalprogramming #objectorientedprogramming #skill #issue #softwareengineering #programming #software #dev
My talk “Frontend Ruby on Rails with Glimmer DSL for Web” went well at RubyConf Austria 2026. Especially given that after the talk, Chad Fowler (the starter of RubyConf and famous book author) told me “good job” and Obie Fernandez (also a famous book author and entrepreneur) told me he will try Glimmer because he doesn’t like React.js.
In fact, I ran a poll at the beginning of my talk, and everyone agreed that they love Ruby and that Ruby is superior to JavaScript, plus the majority indicated that they’d like to write less JavaScript and more Ruby during their Rails web development work. Several attendees told me my talk was great after the talk.
Charles Nutter had me help him with his JRuby workshop afterwards by showcasing my other Glimmer project, Glimmer DSL for SWT, which runs on JRuby. In about 1 minute, I scaffolded a Hello World desktop app from scratch and then packaged it as a native executable on the Mac. Attendees were impressed.
So, I’ve participated in presenting 2 events at this conference. It was a great experience overall! We’re networking at a Karaoke bar right now.
Talk Slides short link:
bit.ly/glimmer-rubyconf-at-2…
Talk Slides long direct link:
docs.google.com/presentation…
#rubyconf #austria #rubyconfat #rubyconfaustria #ruby #rails #glimmer #dsl #web #opal #frontenddevelopment #webdevelopment #frontend #dev