![]() ![]() Consider this example: class UsersController < ApplicationController And too lazy to even consider alternatives. But in general, I’d say that we’ve grown too fond of our code hanging around in classes without a SOLID ground for it these days. Just like there are justified singletons in game engines, there are convincing class implementations in every Ruby on Rails project. ![]() How many of them make a convincing use of encapsulation? How many have a sense-making behavior? Is the use of polymorphism conscious or is it “just because”? It’s an unhealed scar that I took from my brief adventure with game development, where I witnessed all those C++ game engines in many of which 90% of classes end up as tightly coupled singletons.ĭon’t get me wrong. Looking at Ruby on Rails projects, I often wonder how many of all those classes should really be classes. So, how can Elixir that narrows down Ruby’s basic building blocks ( module, class, inline) to just one ( defmodule) can be perceived as harder? This brings us to the next chapter. For now let’s just stick to the fact that Elixir code may look compact, expressive and beautiful. You may think it’s math so it has a natural advantage over OO whereas a serious problem XYZ can’t be expressed so efficiently without classes. It just can’t get simpler and more expressive. It’s nothing short of beautiful (especially in comparison to others). Phoenix authors surely use the same shameless trick when they describe it as a “productive web framework”.įortunately, you’ll find an Elixir excerpt among those examples on Wikipedia as well. But they’ll instantly think you’re tricking them when you describe Elixir as productive and pleasant. You’ll easily convince your peers that functional programming is cool (pattern matching), powerful (EVM efficiency and scalability), fault-tolerant (OTP) or highly concurrent (cheap and safe processes). ![]() And that’s how Elixir may be perceived too. ![]()
0 Comments
Leave a Reply. |