Of course we should focus more on the processes that create software than on alleged metrics for evaluating a project and abstract absolute values that are not tangible. This is a general problem in software development: at universities, the process of creating software itself is presented as unimportant, and only the results of analysis and design are considered important. As if analysis or design were independent of the implementation process, as if they could be directly derived from the former two. In some cases, programming itself is even separated from the normal realm of software development and packed into courses that are required as mandatory credits - but in actual teaching, it is pointed out that analysis and design predetermine the software solution, and you can do the programming in any language anyway. Absurd.
Software creation is accompanied by many components. Of course, analysis and design are among them - and not entirely unimportant ones. Preferably, these two components stand at the beginning of development. But they also accompany development during the process. But just as naturally, the actual implementation - often dismissively portrayed as mere coding, as if you were just converting one formal language into another and could hand it over to some trained monkeys - is an essential aspect that is crucially responsible for success and failure. The tools also play a role, specifically the degrees of freedom they offer, but also the degrees of freedom that programmers actively use in realization, are an essential aspect. This is not about my language being better than your language - that is banal and boring. No, it's about the fact that languages provide means of expression, just as natural languages do. Languages offer models of thinking - with 40 words for snow and ice, you can discuss snow and ice far better, but in the desert, you run out of conversation. The same is true in programming languages - they offer models of thinking that you can use. Or you can rape the language and discuss the meaning of desert with 2 words for sand.
In my opinion, it is infinitely sad that especially in the software engineering movement and in modern software development strategies (perhaps with the exception of the XP movement and the Pragmatic Programmer - but they are also often regarded as outsiders), the programming language is often dismissed as mere tool. My creed: the programming language is more than a tool. It is a way to communicate with the machine. And this communication is certainly not dry or banal or primitive. It is an intellectual challenge and a creative activity. The activity is not coding - it is communicating. The language used reveals the focus that a community has - this also applies to programming language. Its abstraction mechanisms, its degrees of freedom and expressive variety show what directions were envisioned, how the developers who designed this language see the software world. These directions and idea spaces in which a language moves are important - if I go against them in communication, I lack the words. I have to resort to circumlocutions - ugly, inelegant code is often the result.
In my now almost 20 years of programming, 16 of them professionally, I have read a lot of old code. This is essential when you spend 10 years of your working time working on an old inventory management system. And what always struck me was that inelegant code - in the sense mentioned above, but also in its most mundane form as incorrectly structured and formatted code - was almost always the code with the most bugs.
It is often a very clear sign that the failure to understand the culture of a programming language and its ethos is reflected in programming through a failure to understand complex processes - and that leads to bugs.
Ugly language designs then contribute to the fact that programs actually remind one more of curses at the machine than of what they should be (and in my opinion, are): Programs are poems for the computer!
Many programs in this context, however, remind one more of failed limericks with incorrect meter and non-rhyming lines, to which the poet has written 5 pages of explanations on how the discerning reader is supposed to interpret the poem...
At PragDave there is the original article.
Hah! If I had had that earlier, I could have written the whole Python Desktop Server in Common Lisp together with the portable allegro store and maybe a port of Woods
I found the original article at CLiki Recent Changes.
