Merry Christmas, Donald Trump

lumpOfCoal

There’s your Christmas present.

Advertisements

Uninstalling Docker for Windows

docker-for-windows-x

Because of the performance issues with starting up a Docker for Windows container, I decided to uninstall it and go back to the Docker Toolbox and try out .NET Core 2.0.  I’m much more pleased with the experience — Docker is definitely a lot more usable with a Linux OS!  Furthermore, it turns out Hyper-V totally Elephant’ed my video drivers (there’s a lot of posts on the web about that), so NetFlix and “streaming” became a contradiction in terms.

Disabled Hyper-V (a much less painful process than enabling it) and uninstalled Docker. Yet, WTF, there is still 20GB of docker crap left in the ProgramData folder.

And it can’t be deleted — the typical “Administrator access is required” but my user account is an administrator BS in Windows. Find a post on the Docker forum that basically says “yeah, deleting ProgramData\Docker is really hard, we could do a better job of it, you should use docker rmi before uninstalling Docker.” Or something like that. Great, if there’s a command I can run manually, why can’t the uninstaller run it?

So more Googling, trying to take ownership of the file (fail) and I find this post that basically says:

  1. Boot into Safe mode. (Figuring out how to do that in W10 was yet another Google and 5 screens of restart options.)
  2. After reboot, do a “robocopy” of ProgramData\Docker to somewhere else.
  3. After the robocopy finishes, you can remove the directory with rd /S /Q (include subfolders, and don’t prompt for every freaking folder.)

What do you know, that worked. I’ve now reclaimed the 20GB that Docker for Windows failed to install.

Unfortunately, uninstalling Docker for Windows had a few pain points as well.  In my not-so-humble opinion, Microsoft has a ways to go for Docker for Windows to be a viable container development option.

 

 

Static Typing and Broken Software

static_typing_duh.jpg

Granted, I borrowed that image from here, where the author views people like me as “unhappy dogmatists who can’t bring themselves to leave the kiddie pool of strong typing.”  Yes, I am rather dogmatic about strong typing!  But to the point…

David R. Maclver wrote an interesting post “Static typing will not save us from broken software.

Riiight.

davidMacIver = HesGotSomeGoodPoints()
davidMacIver = ButHesAlsoWrong()

Make it more expensive to write broken software – write in a non-static typed language
Make it cheaper to write correct software – write in a static typed language

But because these bugs [those that happen in production] are relatively minor

Now that’s where I totally disagree. If a true static typed language had been used, or had been used properly (ie, semantically, which is the next level of strong typing), this case in point[^]

due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf s) instead of the SI units of newton-seconds (N s) specified in the contract between NASA and Lockheed.

would not have cost the taxpayers $327.6 million

Dealing with type errors in a non-static language is not cheaper. I spend time writing unit tests and verifying the runtime by hand to ensure type correctness that I do NOT spend with static typed languages. Running an app only to discover I’m using a duck-typed variable before I’ve assigned something to it is a time waster. The benefits of static typing far outweigh the benefits of non-static typed languages, and I’m sorry David, that’s not opinion, but measurable fact.

Can duck-typed languages save time? Sure! I can replace a class instance that interfaces with hardware with a class instance that mocks the hardware as simply as the code above. I can add fields to a class outside of the class simply by making an assignment.

All of which are cheats and laziness, break the “code as documentation” fallback, and make duck-typed code more error prone and difficult to maintain.

Most existing static type systems also come with a build time cost that makes testing in general more expensive.

And the unit tests that duck-typed languages require often (in my experience with a small Ruby on Rails web app) take longer to run than compiling much more complex web sites.