Forums
With all the investments that have recently been made in statistical/brute-force methods for simulating machine intelligence, it seems that we may at least at last have achieved the ability to err like a human.
Sometimes bad code arises from incompetence, whether individual, or more usually institutional. Sometimes it's overly tight deadlines, misguided architecture. And sometimes… it's just the easiest way.
Naomi writes in to confess to some bad code.
Unit testing in C offers its own special challenges. Unit testing an application heavily dependent upon threads, written in C, offers even more.
Brian inherited an application where the main loop of the actual application looked something like:
Shipping meaningful data from one company's IT systems to another company's IT systems is one of those problems that's been solved a billion times, with entirely new failure modes each time. EDI alone has a dozen subspecifications and allows data transfer via everything ranging from FTP to email.
When XML made its valiant attempt to take over the world, XML schemas, SOAP and their associated related specifications were going to solve all these problems. If you needed to communicate how to interact with a service, you could publish a WSDL file. Anyone who needed to talk to your service could scrape the WSDL and automatically "learn" how to send properly formatted messages. The WSDL is, in practice, a contract offered by a web service.
Much of the stories and code we see here are objectively bad. Many of them are bad when placed into the proper context. Sometimes we're just opinionated. And sometimes, there's just something weird that treads the line between being an abuse of code, and almost being smart. Almost.
Nic was debugging some Curses-based code, and found this "solution" to handling arrow key inputs:
Apr 21