90% of the time, you could be doing a local function call. Your dozens of containers and multiple repos, all chained together with event queues, hook systems, and standing up async metaphors around fundamentally synchronous behaviours would matter if you scaled to infinity, but the real world business case would fit on a Raspberry Pi 1B if you didn't bloat it with all that IPC overhead in the first place.
All analytics and traffic and usage data are bogus. Either in a underreported (blockers) way, or overreported (bots), and it doesn't matter which to make them all a useless piece of data to use in decision making.
That programming opinions are worthless. The only thing of any real value is discipline. Work, read, study study study, do your best, and don't listen to anyone. Software is art.
AWS, Google Cloud, Azure, makers of OS like Microsoft and Apple should be regulated like other critical infrastructure. Along the lines of the FAA, FTC, & FCC, a new regulatory commission should be created to prevent a cyber meltdown of America.
That computer security is a solved issue. Multilevel secure systems were perfected in the 1970s, but people went with Unix and it's derivatives anyway. So, we'll be stuck having civilizational crisis because of this for a few more decades.
I will not comment on a now-obscure putatively secure system (which presumably has not been battle-tested, at scale, with network cables plugged in, under modern-day conditions) vs UNIX and its derivatives, but I will say that MS Windows has been lacking security considerations right from the outset. Incidentally, the most recent Outage of Global Reach (OGR—there, I coined it) was due to millions of Windows machines infected. So I think the argumentation should be: Corporate cares so little about resilience, diversity of approaches and stability and so much about fast money and good quarterly reports—they tend to just throw millions of identically-configured Windows boxes at a problem instead of even considering some or all could run a different system.
So, if anything, all considered it's really more damning.
I'm sceptical, which proves this is controversial. I've used one of those allegedly ML secure systems (NOS, on a CDC mainframe). The two reasons NOS and other systems of that vintage were considered secure is that nobody of a hackerish nature got to use them, and they were so damn stupid nobody else cared enough to break them.
"Significant whitespace" (e.g. python) is idiotic. Programmers should be free to write their own code in a manner which suits their sense of style (for which there is no accounting).
"Java's Checked Exceptions are the right idea and just need better syntactic sugar."
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.
I don't know what is most controversial, but I have some opinions which seem to be less common such as:
- 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.
