Posted on

Some Thoughts on Bad Programming Practices

I recently read an article about the worst kind of programmer. I agree with the basic idea, but I wanted to add my thoughts on it.

I have seen, over time, that developers seem invested in learning new things for the sake of new things, rather than getting better at existing approaches. Programming is like everything else — new is not always better. I have a Honda CRV that is not as easy to use as some cars I used to own before touch interfaces became popular. The touch screen sometimes acts like I'm pressing various places on the screen when I'm not, making beeping noises and flipping screens randomly. I have to stop and turn the car off and on to stop it. It has a config screen with every option disabled. It has bizarre logic about locking and unlocking the doors, that I have never fully figured out. I often wonder if devs who make car software have a driver's license.

Posted on

SQL Has Always Been a Good Solution

I recently read an article at 9 Reasons SQL has Got to Go suggesting that SQL has "got to go". This article is misguided, and the claims are patently false. I'll discuss the points the original author made, and why I believe they are off the mark.

Tables Do Scale

I live in Canada. The Bank of Canada estimates there are approximately 30 million financial transactions per day in this country. We have what we call the "Big 5" banks. If we assume they get the brunt of these transactions (let's say two-thirds), that would be 20 million transactions. If we assume an even distribution, that means they each handle about 4 million transactions per day. Banks have been handling this kind of load every day for years, and use SQL.

Posted on

Multiple Inheritance in Java

Ever since Java 8 introduced default interface methods, I felt there had to be a way to use it for multiple inheritance. I have never needed it, but I was bored for a bit today, so decided to try the following idea:

  • Create a non-public class XData to hold the fields the interface needs to work with, and a public interface X in the same X.java source file
  • The interface has one virtual method getXData() that returns the XData instance
  • The remaining interface methods are default methods that call getXData() to read and write the fields as necessary to perform some useful operations.
  • Create another interface Y and class YDatain the same pattern
  • Create a class XY that implements both interfaces X and Y
  • The class XY has XData and YData fields, which are returned by getXData() and getYData(). These are the only two interface methods XY is required to implement.
  • I didn't bother in my example, but XY would have to decide how to implement the Object methods hashCode, equals, and toString. These methods cannot be implemented by interfaces (but they could be implemented in XData and YData classes if desired)

The end result is the XY class is an instance of both X and Y interfaces, and inherits the encapsulated behaviors of both X and Y default methods - multiple inheritance by any reasonable measure.

Posted on

Cross-compiling a C++ CLI Application

Github project containing details of every Makefile variable and target, as well as how to configure FreeBSD 13.0 to mount an SSH filesystem at boot.

Prepare for Disappointment

You'd think as you're reading that somebody, somewhere is busy cross-compiling GCC, or building the latest LLVM with all the backends. You'd think by now, after all these years, it would be an easy process. You'd think that after using Go, there would be a simple command in LLVM to tell you what all targets are available.