You strictly type your regular return values so that people have to make a clear decision about handling them, and everyone's fine... But do it for predictable categories of error, and some people lose their minds.

- GOTO is good. Structured flow controls can also be useful sometimes, but sometimes GOTO is better.

- Macros is good.

- Pointer arithmetic can be a helpful thing to do.

- Unicode string types is bad. It can result in inefficient code, badly written API interfaces, code that does not work correctly, difficulty in programming it to work well, etc.

- Unicode itself is also bad (independently from the above). There are better ways to handle m17n and i18n, and which character sets/encodings is appropraite would depend on the specific application. (Furthermore, using Unicode to convert between character encodings is not the best way to do it; better would be decode (from the encoding to the code points within the character set that it is an encoding of) -> convert (between the two character sets that the encodings are of; if they are encodings of the same character set then this step can be omitted) -> encode (the reverse of the decode step).)

- Restricting source code to UTF-8 is usually either unnecessary or insufficient depending on your goals. (If you wat security, then restricting it to ASCII might also be insufficient; if you want real security you should restrict it to printable ASCII and a few control characters but not all of them, and tabs and trailing spaces should only be allowed in cases where replacing tabs with spaces or deleting the trailing spaces would not alter the meaning of the program.)

- Object-oriented programming is not good for everything, but sometimes it is useful. (This can also be true of other -oriented programming.)

- Automatic semicolon insertion is a bad feature of JavaScript.

- Indentation-oriented syntax is a bad feature of Python.

- The syntax for types in C is confusing and is not very good.

- Computer software should be designed for advanced users, and should include good quality documentation so that you can learn. The program should not try to believe you know better than the user of that program would know, especially if that program runs on that user's computer.

- You cannot really try to make a program understandable so that it will not need documentation. Documentation is what makes it understandable; otherwise it will not be understandable.

- PostScript is not actually a bad programming language, although some improvements could be made (e.g. writing error messages to stderr instead of stdout by default, adding operators for concatenating strings and for concatenating arrays, allowing auto allocation for some operators if you pass null instead of a string/array/dictionary, and some other improvements).

- It won't help to use one format, one protocol, one programming language, one kind of VM code, etc, for all things.

- Text-based formats, especially just reusing JSON or XML, is not always the best idea. Binary formats can be good, or a custom text-based format. (PostScript text and binary formats can also be used to store data, but unfortunately the binary PostScript format does not support 64-bit numbers; other than that I like them compared with JSON in many ways.)

- Many programs are written in ways that are too inefficient, too much memory and disk space even if a older computer might have a older program that even works faster and even works better, too.