"Sick of Ruby, dynamic typing, side effects, and basically object-orientied programming"
He's sick of OOP in Ruby, not of OOP in general. Ruby's dynamic typing means you have one type, "the dynamic type". The compiler leaves you entirely on your own as static analysis is impossible. It means many more tests, assertions, and runtime error conditions. Most OOP techniques have evolved out of, and rely on strong static typing, Ruby isn't that kind of language.
OOP in Ruby is the inevitable result of many Ruby projects growing in scope and size. When you reach that point, a better way is to move part of the project out of Ruby and into a language that can handle that scope and size.
P.S.: Any communication with the outside world is a side effect (ex. network, file, database I/O), so sick of it or not, you better get used to it. Haskell masking side effects as monads through a language loophole isn't making things significantly better.
> Neat article, but I found it surprising that the author didn't go into a bit more detail about why RGB is used and where it's used. Saying that it's just how computers or televisions deal with it because of monitors only offers a bit of information.
It's our eyes. Our eyes are (roughly) RGB, therefore a RGB monitor is a best spectrum match for our eyes, therefore it's how computers and printers deal with it (CMY/K/ is just the inverse of RGB).
For many animals, even our best high end lifelike wide-spectrum display cuts out or inaccurately represents portions of the spectrum they can see.
The headline implies the brain has a global "framerate" implying it's synchronous. That's most definitely not the case. The strobe light and shutter examples are examples of the light and shutter having specific refresh rate, and has nothing at all to do with our brain.
So...
1. We have a study.
2. Then we have a mainstream press (New Yorker) article written by someone barely understanding the study.
3. And then we have this cheap blog post, whose author briefly mentions the New Yorker article, as an excuse to feed us a bunch of contrived nonsense that ties the study (as if) to some random meme GIFs and videos.
But neither this, nor what the author is talking about is "the curse of smart people".
Conspiracy theorists, evolution deniers, religious fundamentalists, alien abductees and so on are examples of people getting together, and successfully rationalizing their belief in some quite twisted ideas. We don't call such groups "smart people", typically. They're not necessarily stupid either. They're just people.
So it's just the "curse" of being a human, I guess.
Whether we use our mind superpowers for good, or in order to fool ourselves and the people around us is completely independent of one's smartness, and has more to do with wisdom.
Many people believe that if you can wrap a convincing narrative around a set of selected facts, the narrative must be truth itself. Stories posing as insight are all around you.
Experience leads to wisdom, and wisdom teaches us to be more open-minded and less sure in the stories we hear or tell ourselves.
It's funny you say that. In many companies you can hear people saying "it's nothing personal, just business" (you also hear the same from movie villains, oh well).
At Apple, for as long as I remember, it's exactly the opposite: it's not just business, it's always personal.
If you hurt Apple, Apple will hurt you back.
You can think of Apple as a smart, powerful, spoiled prince/princess. If you have something the prince(ss) wants, they'll try to be friends with you and shower you with gifts. But if you go this path you better never end up on their bad side.
It may seem childish to some, but as far as game theory goes, this kind if behavior makes one's choices and outcomes very clear when you interact with Apple.
"Sick of Ruby, dynamic typing, side effects, and basically object-orientied programming"
He's sick of OOP in Ruby, not of OOP in general. Ruby's dynamic typing means you have one type, "the dynamic type". The compiler leaves you entirely on your own as static analysis is impossible. It means many more tests, assertions, and runtime error conditions. Most OOP techniques have evolved out of, and rely on strong static typing, Ruby isn't that kind of language.
OOP in Ruby is the inevitable result of many Ruby projects growing in scope and size. When you reach that point, a better way is to move part of the project out of Ruby and into a language that can handle that scope and size.
P.S.: Any communication with the outside world is a side effect (ex. network, file, database I/O), so sick of it or not, you better get used to it. Haskell masking side effects as monads through a language loophole isn't making things significantly better.