Bad Code Can Be Written In Any Language
Bad Code Can Be Written In Any LanguageThere are at least 5 types of BadCode:
BadCodeCanBeWrittenInAnyLanguage because we code in our heads, not in our machines - ProgrammingIsInTheMind. Therefore, bad code is caused by bad thinking, and we can think badly regardless of our tools or the means of expression. No language can actually guide the programmer's thinking to the point that only good code can be produced. At best, such a language would lose most of its generality. More likely, restricting the language to eliminate bad code is probably equivalent to (or perhaps even more difficult than) proving a program's correctness. Perhaps it is even equivalent to solving the HaltingProblem. I don't know. I certainly do not expect any such capability to ever be available.
-- RobWilliams
Perhaps "lose most of its generality" is not such a bad thing. There are many LittleLanguages / DomainSpecificLanguages that don't have much generality, yet are seen as quite useful (in their niche).
To take the analogy one step further, it would be like restricting a human, written/spoken language in order to improve text and speeches? Right, bad text can be produced in any language. On the other hand, every human language is somewhat restricted by its grammar and vocabulary. -- FalkBruegmann
Is it true that GoodCodeCanBeWrittenInAnyLanguage? I think not, InterCal and BrainfuckLanguage being two examples of languages that make it difficult to write code that satisfies any accepted "good" quality. But good code can be written in commonly disdained languages like Visual Basic and Fortran, so maybe it is safe to say that GoodCodeCanBeWrittenInAnyGoodLanguage.
Ideally, we always choose the best programming language for the job. But sometimes, we have to use a non-optimal language, or use a language we don't know well. In those situations, we can always fall back on the tried-and-true programming techniques of DoTheSimplestThingThatCouldPossiblyWork, choosing MeaningfulNames, writing MeaningfulComments, and decomposing the solution into a set of small subroutines/functions/definitions/rules.
-- KrisJohnson
BadCodeCanBeWrittenInAnyLanguage, thus, it is unfair to judge a language by its worst practitioners.
In my experience, "BadCodeCanBeWrittenInAnyLanguage" isn't normally used as a response to judging a language by its worst practitioners; it is used to dismiss criticism of a language without having to consider whether that criticism is justified on technical grounds. -- DavidSarahHopwood
It is useless to try to eliminate bad coding by eliminating features of the language. I've seen coding style requirements that rule out most of the useful constructions in the language, and I've seen companies invent languages while deliberately leaving out features, because some programmer didn't understand those features and proceeded to misuse them and write some horrible, unreadable code. Limiting the language is a bad solution to a legitimate problem. In fact, it leads to more unreadable code, since complexities of the problem are forced out of the language and into the programs written in that language. (The good solution is to educate the wayward programmer or fire him.)
For example, take Java's decision to eliminate overloaded operators. Why did they do that? "Well, we'd seen lots of pathological C++ code where people did things like int a; stack s; s+= a; to push onto a stack, and so we wanted to eliminate the possibility of that." Also eliminating perfectly good code like vector3d m; quaternion q; m = q * m * q.inverse();, but that didn't bother them. And that's why JohnCarmack isn't writing Doom III in Java.
That's ridiculous. Are you Carmack? If not, then perhaps you shouldn't be claiming he doesn't use Java because of something silly like operator overloading. Does he even use C++? He certainly used to use C (no idea if this is still the case), which also doesn't support operator overloading.
I interpret this not as "because of something silly like operator overloading", but rather that the point about operator overloading is evidence that Java arbitrarily prevents him from using useful things. Certianly the inverse square root trick often (mistakenly?) attributed to him isn't going to work in Java.
The best language for the job philosophy is discussed in greater depth on HorsesForCourses. But sometimes a problem decomposes into several subproblems, and a different language is "best" for each subproblem, and maybe you can't use CORBA (see e.g. MetaProgramming and LanguageORientedProgramming).
AlternateHardAndSoftLayers perhaps? MultiLanguageRefactoring? SymbioticLanguages?
HelloPolyGlots? I like this suggestion. Bad code can be written in multiple languages at the same time!
Some languages encourage a bad programmer to make bigger messes. For example, in Pascal you are hard-pressed to make a customized IF-statement or loop block, but in languages such as LISP it is a snap. Some languages will herd you toward a certain style (for good or bad). It thus makes it easier to read such programs because you know they won't deviate too much from that style and you are (presumed) used to that style if you are familiar with the language.
EditText of this page
(last edited October 3, 2009)
or FindPage with title or text search