[WIP] Ultimately, this should inspire an article or at least, a rant, about closed source being a lot more insidious than a welded-shut car, but more like a car which has electrical wires of the same colour, no labels, and parts which are surrounded by force fields and electrified to prevent "tampering", or modification of any part of the engine and its support systems.
This article seeks to form an analogy between cars and computers to explain what the real problem with closed-software is, and how pragmatic programmers deal with it.
| Car (commercial automobile) | Computer (PC) | |
| Starting | The car: turn the key | The application: launch the program |
| Initialising | Unlock the car, get into it | Boot the computer, log on |
| Framework | Body of car (external) | Physical PC box (PC case) |
| Projected mindset - primary use | Driver seat, controls, dashboard | User Interface (multimedia) |
| Projected mindset - seconday use | Car interior - decor, comfort | Peripherals (hardware) |
| Primary Utilisation | Driving (personal transport) | Maniupulating datasets (interacting with information) |
| Secondary Utilisation | Various (informal social gatherings) | Web browsing; Games, IM; included as "accessories"; downloadable; (interaction with personal information, social interaction) |
| Implementation details | Electrical, mechanical, fluid systems, all interdependant | Operating system |
| Acess to implementation details | Service manual, clearly labelled parts | OS internals documentation, readable source code; driver source, documentation, and hardware databooks (typically not available). |
| Method of enhancing performance | Enchanging parts for ones which are better, which may actually be from an earlier model design | Wait for an upgrade, which may actually have inferior performance in some areas |
| Informal method of education | Take it apart and re-assemble | None currently existing, was: reimplement a UNIX kernel (current systems to massive for any one individual), or rebuild a microcomputer from parts (current PCs are too compact for hobbyist to build) |
| Formal method of education | Mechanical, Electrical engineering | Computer Science, Software Engineering, Software development (Orthodox), dropout and sell software, letting the market teach by vicious trail and error cycle (Rich - Bill Gates, Paul Allen, Larry Ellison, John Camrack, et cetera), do what you enjoy (demigod-, Tim Sweeney, Linux Torvalds, Alan Cox) |
| Business method of education | Work as a mechanic | none, software as a hobby is expensive but you generally need a degree to get a job, or even to jumpstart a career as a consultant. |
| Kool path | Auto hobbyist | Case modder, Videogame-related |
| Cutting edge | ? Wanker engines? Reprogramming onboard computers? | Realtime Interactive Simulations, including traditional videogames, computer graphics, bio-information, nanotech simulations. |
| Largest unaddressed concern | Safety | Tools [1] and collaboration standards [2] |
[1] Tools: software tools suck. See Tim Sweeny's critical look at programing langugages. Sweeny invented Unrealscript to partially address some of these issues
[2] A way of expressing algorithms such that they are decoupled from the implementation language is not forthcoming. Haskell and other functional lanauges remain obscure. So, code in the form of C, which is as modern as Latin, is used instead. In any case, there is no "code diagram" which is the analogy of the "circuit diagram". They are UML diagrams, but they are rarely used, for good reason: programming languages are developed based on linear parsers which are often one-pass, taking in text and spitting out, ultimately, machine code. There is no storage method to model a programming construct, and then, generate the text or diagram from it... the process is unidirectional, myopic, and insane.
The sustainability of software development is an oxymoron, and this is concealed by creating more and more domanin-specific tools which implement parallel anatagonistic dual unidirectionality to hide true problem of no low-level bidirectionality in the toolchain.
K31. 3 Jan +3.