A word on languages
Every language is born from the fundamental need to communicate informations between humans. Now when it comes to computers, a third party’s involved: the computer. But the machine doesn’t communicate, it performs tasks. Complex series of tasks though, cannot be communicated to a machine as it is to another person, it’s pure numbers, a language that may have written the universe but which we still don’t speak fluently.
As a consequence, a fault seems to appear in every human-machine language: the language design in itself is nice but frustrating. It always brings technical limitations, it creates a restricted field of semantics and rules, acting as much as an intellectual guide than a grumpy warden. Exactly like a spoken language, every computer language is a product of a culture, a set of mind, a set of goals.
The funny part here, is how born object-oriented languages benefit from a greater credibility against any other language. Do object-oriented languages bring more satisfaction at usage than others ? I believe their credit comes more from their suitability to a majority of contemporary development problems. English became the international language when english speaking countries became the cultural, economical and intellectual model, just as French previously did in Europe before the conquest of America.
But yes, suitability to a majority of problems obviously brings great satisfaction to the problem-solver: the coder.
The myth of mystic CSS
I’m going to be a cold-hearted technician here, but CSS doesn’t contain any mystery or hidden misconception; it doesn’t obey any mystic law nor fate or luck. It’s a common experience for developers to stumble upon an unpredictable, inapprehensible behaviour, that may also disappear as it appeared: without a clue left for the coder. But that’s often the result of projects with an unhealthy but necessary weight: multiple languages, dependencies, content managers mixed with task runners and workflow handlers etc. The environment development is intelligent, but complex, and sometimes simply outmatches our own ability to handle complexity.
The way CSS is treated and learned by developers grown in these big scale environments, is so much blurred by their specific culture and experience, that it always make for a funny moment when they’re sitting in front of a simple, blank text editor and expect everything to be very simple. Then, after learning a couple of property-value pairs and some basic selectors that only match their specific, supposedly “easy” goal, they go straight into coding CSS until something “mystic” happens. And this is how the gap between expectations of simplicity and the sudden experience of inapprehensible complexity turns into a totally irrational : “CSS can’t be taken seriously, it’s language design is so much burried in faults it feels mystic when it works as well as when it doesn’t.”
The benefit of theory before practice
The CSS language, like any other one, has been born thanks to specifications. And this is the very reason it cannot be mystic or shallow, because it obeys logic and patterns designed to suit its purpose : styling an HTML page. Any logic or pattern is open for improvement, but closed to fortuity.
If you experienced any frustration with CSS or another language, consider reading about the language’s core specifications before giving up. You may end up realizing you chose a language unfitting your problem, or you may end up demystifying many things, but in both cases you’re moving forward as a developer.
(A future article will come about CSS language’s design and logic.)