Code Materials

MATLAB seems like Playdough - easy to mold, flexible, quick to build anything. As malleable as it is non-robust, it is hard to keep anything inside it solid or predictable for long, and the different pieces blend together, so that the boundaries between the different pieces of the program are fuzzy or just plain undefined. A certain level of solidity can be achieved only if programming frameworks and standards are set, and even then only under specific restrictions. Otherwise, MATLAB programs rapidly become a big blob.

Java seems like cast iron. Each of its pieces is well defined and solid, and its templates are the key to the code, which is a blueprint that says how instances of these templates interact with each other. Once a piece begins to interact with many others, it becomes crucial to the system, and the more it is used, the more unchangeable it becomes. If a core piece is changed, all related pieces must also change to adapt to the new core template. Its reusability requires its core pieces to be very well-designed and versatile. Once built and functional, however, a system can remain solid and predictable. What it has in solidity, it lacks in flexibility, and it is not unusual to find multitudes of new pieces designed only as patches to upgrade the core capabilities, at which point the code can become a maze of convoluted logic and obscure exception cases.

C seems like stone. It is not meant to be built upon distinct templates and pieces. A C program is typically a whole - carved for its sole purpose from bottom to top, and each of its parts is unique and solidly bound to each other - a functional collection of one-time usages of logic to solve the specific problem at hand. It is not as common to think of C programs as pieces to place one upon the other, but rather as monoliths of specific functionality to always be used explicitly. If a single program grows too much, it inevitably becomes a mountain of piled-up code that only exceptional documentation, significant logical empathy, and a brave, patient heart can successfully sift through or change. A well-written C program, however, is exceptionally robust and can last for generations to come.

C++, a semantic upgrade over C, is like clay. Pieces and templates can now be designed and molded, though the interaction between them is loose and fragile, and requires good coding practices to keep stable. Changing a crucial piece of the code will also break the designed interactions, although the language is itself malleable enough to allow hacky patches to such changes, like just attaching an additional lump of clay to fit the broken pieces. Clay templates can now be reused in other C++ programs, although the core logic of the code is still, like C, usually monolithic, not open to transfer or reuse.

Visual Basic is like paper. It's not meant to be robust or reusable, but it's pretty quick and easy to produce something "basic". It's versatile - a handy tool for pretty much any task, provided you memorized the techniques for each distinct case. But using it for anything more complicated than quick scripting is not a wise choice. The thing can tear apart at the most unexpected times and cases, and it's only solid enough to support a few layers of logic, before you start using strange hacks just to keep the thing together, but it'll probably still crumble under any fair amount of stress.

PHP, if anything, feels like leather. Both sturdy and flexible, it can be used for a great variety of tasks, while still able to hold ground as a robust platform if designed properly. Once it's well-designed and working fine, it's great and robust. It's not much to look at, however, and its slightly unseemly syntax, combined with its extremely open types and annoyingly global set of API functions, can make it a pain to debug. Though it supports objects, inheritance, and a lot of good stuff, getting the syntax right can be hard for newcomers. Plus, its notorious lack of type-checking and its super-relaxed membership rules can counter many benefits of object-oriented logic. In short, for any simple tasks, it's awesome. For complicated tasks, once it works, it works great, but either making it or changing it can get messy.

Python feels to me like plastic. Not for the hardcore, but rather for those who prefer to just obtain abundant third-party generic pieces with specific purposes, and slap them together to produce a quick solution - a grab-and-use approach. Gets even complicated jobs done quickly if you know what to look for. Very loose interactions, however, and the freedom it gives the coders can be somewhat offset by the often poor allocation of resources caused by the coders' disknowledge of the inner workings of each generic piece.

HTML seems like Lego pieces. All the pieces are already designed by someone else, you just need to attach them in the right order. They don't even have to fit well, the thing will hold as long as it kinda makes sense, even though it mostly ends up looking ugly as heck. Mostly rectangular and predetermined, HTML is simple and serves a specific purpose - show stuff. And as long as it shows what you want, there's really no desire to make it elegant or reusable, as there's not much elegance about the language anyway.

CSS is like fabric. Each description and rendition layers boring HTML with bright colors, it covers up its pieces to soften surfaces and shade corners, it produces gradients, brilliance, and style. A most visual-oriented language, it appeals entirely to presentation, and it contains no substance beyond the cover value.