Software is so bad these days.
Amen.
There are errors in the math.h that comes with MinGW. I figured that if they are stupid enough to ship their compiler with errors in the standard header files I probably don't want them compiling my code.
I used MinGW for a while. It was pain followed by pain followed by pain. It was awful to work with. I was thrilled to be able to move away from it. Having said that, the goal of the project (at least as I remember it) is basically to create a free Unix-like environment on a operating system whose makers want cross-platform development to be as painful as possible. They're approaching a problem as hard as nailing jelly to a wall during a hurricane and actually *succeeding*. That is quite an accomplishment, and I do admire the effort. During the early days of MinGW there weren't uncrippled free editions of Visual Studio available. I would like to think that MinGW gaining traction may have partially prompted the move to make a free uncrippled express edition of MSVC.
G-SYNC is the worst technology ever created,
Worst technology ever? Sounds like somebody hasn't worked with any of following:
- The ATI/AMD Linux video drivers. How many options can you change in their GUI before it becomes inoperable? My record is three. That's okay, I'll just do it by hand... oh my God what is in this file? Hang on, did you just change two options without rebooting? Don't worry, the driver's got this- time for a hard crash. Now you *have* to reboot. Hope you didn't lose anything important.
- Memory management in OpenSSL- a thin layer in which deallocated memory can be efficiently used.
Go exploits. The API is a bit painful as well, but that's a bit of a side note.
- What would you select as the single C preprocessor define that has caused the most amount of suffering in library building and software development? I offer my candidate: ZLIB_WINAPI. Some of you are nodding right now. I feel your pain.
- Direct3D in DX3, possibly the single worst API of all time. The words "execute buffers" will bring tears to the eyes of anyone who had to use it. Pages and pages of code to... open a single Window and display a single triangle. No diagnostics apart from: "Wrong", "Right" but not actually working, and "Right". Oh, and the textures vanish if you do the wrong thing.
- DirectPlay in DX3. The documentation lied. No, I'm not talking about mistakes. It outright lied.
- PulseAudio, which singlehandedly ushered in the dark ages of Linux audio. Quite an accomplishment, unlikely to be matched by anything else except for systemd.
- SLI-capable development on nVidia cards. A working set of undocumented secret capability bits needed on a per-machine, per-card, per-driver-version, and per-configuration basis? With some combinations experiencing severe graphical corruption after an unspecified time and others running a fraction of the speed of a single video card? Sounds awesome. I'd hate to be the sucker who fires up a developed application over and over for days on end with slightly different options to locate fast and stable configurations on a per-PC basis. Hang on, I *was* that sucker.
- Windows debug/release memory management distinction, with hard crashes on mismatch. Coupled with there being no solid standard for library and DLL naming, and tools that support only a subset of the myriad variations out there, this becomes one of the most destructive design decisions ever made with respect to a health Windows library ecosystem. Building and working with multiple libraries becomes a nightmare. All it would take would be for Microsoft to settle on a single DLL-interface-compatible memory implementation with their next runtime, and all this pain would go away. That's all it would take! Such a simple thing, so much pain.
- The GNU autotools, when used for anything but distribution of a small library with minimal dependencies and simple build structure that runs on multiple Unix-like systems, but only if the developer runs it before making the distribution and the end-user never needs to touch it. automake is a special case. I make the claim that there exists no project, from hello world through to the most complex project, that automake can not make considerably *worse*.
- *singing* Oh, we ain't got a barrel of money; maybe we're ragged and funny; but we travel along, singin' our song; SxS. A technology so bad that it was worse than the problem it tried to solve. It was ultimately shelved. Slotting XML into an executable as an intermediate link step? Sounds awesome.
- UnigineScript, my candidate for the single worst language that has ever or will ever be created. I could have used "designed" rather than "created", but I think "designed" is assuming a lot. A language so bad that I used to joke with a colleague every time I ran into an insane aspect of the language design, but had to stop doing this as I was interrupting him so often that it was interfering with his work. When I realised I had accidentally left it on my CV, I actually deleted it. That's right- the language is so painful to use that I don't want potential employers knowing that I know how to use it.
That was fun.
The alternative is Microsoft Visual C++ which requires me to download 8GB of bloatware just to compile a program. The installer for the 8GB of bloatware bogged down my entire computer and ran at 8fps.
...
Oh yeah, and Microsoft Visual C++ gives me hundreds of error messages about commas that are very difficult to determine the real cause of, probably something to do with the windows.h I now have to include defining every word in the dictionary.
Visual C++ seems the best of the poor options available at the moment. It would be so nice to be able to ignore Windows development entirely, but that really isn't realistic due to its userbase. Realistically, modern development needs a solid CPU and plenty of memory to run development tools and builds efficiently. Just a symptom of the times I guess.
Developer
