It probably is. Stop making this one crucial mistake to become a 10x developer.
Have you heard of the GOTO statement? It was probably the biggest cause of bugs within the early programming languages. Luckily, it is no longer used in most modern programming languages.
But little do we know that we still use its evil cousin daily in modern programming languages, with the same dire consequences.
C++ and Java probably are some of the worst mistakes of computer science. Both have been heavily criticized by Alan Kay, the creator of OOP himself, and many other prominent computer scientists. Yet C++ and Java paved the way for the most notorious programming paradigm — the modern OOP.
Its popularity is very unfortunate, it has caused tremendous damage to the modern economy, causing indirect losses of trillions upon trillions of dollars. Thousands of human lives have been lost as a result of OOP. …
In this article, I’ll attempt to give an objective and, hopefully, unbiased overview of popular (and not so popular) modern programming languages, ranked from…
Let’s find out why.
Many people swear by type systems. I tend to agree, type systems eliminate a large number of errors in programs, and make refactoring easier. Yet “having” a type system is only one part of the story. There are things that matter far more than static typing, and presence/lack of a type system shouldn’t be the only factor when choosing a language.
Throughout my career, I’ve used a large…
Perhaps you’ve heard of so-called “functional” programming. Maybe you’ve even been wondering whether you should try it next.
The short answer is hell no!
Functional programming is full of flaws, is not suitable for real-world projects, and will make your productivity plummet. Why? Keep reading to find out!
Real-world enterprise software demands a complex set of rigorous and compulsory requirements pertaining to the expected amount of embedded abstractions within the software solution. In other words, object-oriented programming enables the programmer to utilize multiple mechanisms of abstraction that fully satisfy the complex requirements demanded by the enterprise.
That was a mouthful…
OOP is considered by many to be the crown jewel of computer science. The ultimate solution to code organization. The end to all our problems. The only true way to write our programs. Bestowed upon us by the one true God of programming himself…
Until…it’s not, and people start succumbing under the weight of abstractions, and the complex graph of promiscuously shared mutable objects. Precious time and brainpower are being spent thinking about “abstractions” and “design patterns” instead of solving real-world problems.
Many people have criticized Object-Oriented Programming, including very prominent software engineers. …
Unfortunately, most of the React tutorials out there have no consideration for best practices and don’t always teach you the “right” way to do React.
In this tutorial, I will go over the basics of React, and the most common bad practices that you might encounter.
This tutorial is going to be long, so make sure to get yourself some coffee!
Before we get started, let’s stop for a moment and see why React indeed is the best choice.
In React, you describe what to render (instead of telling the browser how…
Disclaimer: this is not an introduction to React, and some familiarity with React is required. For an introduction to React, check my other article: React.js: a better introduction to the most powerful UI library ever created.
Over the years I came to a realization that the only proper way to develop high-quality React applications is by writing stateless functional components.
In this article, I will give a brief introduction of functional components, and of higher-order components. After that, we’ll dive right in into refactoring a bloated React component into a clean and elegant solution consisting of multiple composable higher-order components.
Senior full-stack engineer. Elixir/ReasonML/React.