A language whose design encourages
UnmaintainableCode, if not out-and-out
IncomprehensibleProgramming.
The
CanonicalExample of this is
PerlLanguage, whose "
ThereIsMoreThanOneWayToDoIt" philosophy has the unfortunate corollary "So to do maintenance, you have to learn
every blasted one!"
Perl as a language has less a design than a thousand special features flying in close formation.
Ever tried writing out a COBOL program with a pencil? That's painful ;-) --
(I threw out my blank COBOL coding sheet pads only 4-5 years ago. But a pencil? Real COBOL coders use pen, and then only when there is no keypunch free!) -- JimRussell
If you have, please add yourself to
HadToUseCobol!
COBOL itself strikes me as only mildly painful within its problem domain (but then, I've never HadToUseCobol, so take that with a GrainOfSalt) - now, socket programming with CobolScript, on the other hand... -- AlistairYoung
There are also deliberately painful languages, like
UnLambdaLanguage,
MalbolgeLanguage,
InterCal, and
BackWardLanguage.
Unlambda is not
deliberately painful. Unlambda is 100% pure combinator graph reductor, so it just isn't readable. Writing Unlambda programs is not that hard: the Unlambda tutorial shows you how to do it. From then on, you just have to think in a tail-recursive way.
Nominations
- SQL*Plus SQL*Plus is an ok language, it's the environment that's painful.
- AbapLanguage - much like CobolLanguage
- Any language besides the one you usually develop in
See, obviously,
LanguagePissingMatch (or possibly
LanguageGriping),
PythonVsPerl,
WriteOnlyLanguage