Attention Lonely Men: The Reason Women Don’t Like You Is You

Along with all of the other nasty reasons for people killing each other, we now have the “Incels” or “Involuntary Celibates”. This is not really a new phenomenon, when I was young we had the “Son of Sam” who made a habit of killing couples who were making out in cars.

There are many young men who gravitate to programming and gaming who have trouble relating to women. I’ve previously written about why this happens. You might see yourself in that essay, or not.

So, as a person of some stature in the computer nerd community, I am embarrassed that I need to explain this to our community, but I do. Here goes. Continue reading “Attention Lonely Men: The Reason Women Don’t Like You Is You”

Companies Just Really Stink at Compliance – Training Is Usually The Problem

HIPAA is a law that is supposed to prevent medical professionals from inappropriately disclosing your medical information to anyone not involved with your treatement and insurance, so that your medical status can not be used against you – for example by an employer who wishes to discriminate against people who are HIV positive. HIPAA compliance is a big deal – it’s likely your personal doctor has given you disclosures related to it, and has had you sign releases regarding your medical data. Penalties for not complying with HIPAA have been as large as 75 Million dollars.

Not too long ago, a major medical manufacturer and their partner, a research hospital, ran a program in which they sent some crucial medical equipment to patients in a large soft rolling padded suitcase. At some point the suitcases became surplus to operations, and they sold them to an online store known for its military surplus. As it happens, I needed a soft padded suitcase to store a ham radio in my trailer, and thus found myself the new owner of one of these cases.

The case came with a patient identification card neatly mounted in an identification window. This gave the patient’s name, birth-date, gender, and the name of a medical device that they were using. A FedEX waybill attached to the case’s handle gave the patient’s home address. Obviously this was a HIPAA violation. I notified the manufacturer and destroyed the patient data.

I’m involved in a different form of corporate compliance: Open Source license compliance by technology companies. But the problems are the same: dumb mistakes like failing to remove patient data before selling suitcases happen because the “little people” in the company – employees who get the assignment of getting the suitcases into a freight container and shipping them out, haven’t been adequately trained to identify a HIPAA issue while it’s happening and protect their employer. Similarly, violation of Open Source licenses happens because engineers and their managers have never had their first class in copyright, licenses, and technology law – it isn’t required for an electrical engineering or computer science degree. When I train such people, I find that they identify problems and bring them to legal when the problems start, rather than letting them happen until there is a development investment and products released to customers, and the intellectual property issues get expensive. Staff who have been properly trained feel in control, and become the first line of defense rather than where the mistakes happen. This saves companies many Millions.

Unfortunately, training people meets strong resistance in every company where I propose it, because the course as it should be taught would take every member of the staff out of production for a whole day. So, I’m always under pressure to cut the entirety of a Compliance 101 class down to two hours.

Somewhere in a medical company, the little people weren’t taught enough about HIPAA to be able to identify an obvious problem, or maybe they were that day’s temps. Managers were tasked to keep this sort of problem from happening. But as always, the managers weren’t the people at the front lines, who really do have brains and can use them if they’re just given some awareness of what’s important.

Someone who isn’t as nice as me could use the information that I saw to bring a class-action suit on behalf of the patients whose information was disclosed, perhaps costing this company tens of Millions. It’s only when that happens that the companies understand the value of training all of their staff.

Learning the Crystal langauge and Lucky web framework

Crystal is a rising programming language with the slogan “Fast as C, Slick as Ruby”.  It has some compelling features that make it more attractive than other modern language attempts like Go. You really can program in a Ruby-like language and achieve software that performs with the speed of a compiled language.

But the greatest advantage of Crystal, that I have experienced so far, is that it provides type-safety without excessive declarations as you would see in Java. It does this through program-wide type inference. So, if you write a function like this:

def add(a, b)
  a + b

add(1, 2) # => 3, and the returned type is Int32
add(1.0, 2) # => 3.0, and the returned type is Float64

You get type-safe duck-typing at compile-time. If a method isn’t available in a type, you’ll find out at compile-time. Similarly, the type of a variable can be inferred from what you assign to it, and does not have to be declared.

Now, let’s say you never want to see nil as a variable value. If you declare the type of a variable, the compiler will complain at compile-time if anything tries to assign another type to it. So, this catches all of those problems you might have in Ruby or Javascript with nil popping up unexpectedly as a value and your code breaking in production because nil doesn’t have the methods you expect.

There are union types. So, if you want to see nil, you can declare your variable this way:

a : String | Nil

a  : String? # Shorthand for the above.

Crystal handles metaprogramming in several ways. Type inference and duck typing gives functions and class methods parameterized types for free, without any declaration overhead. Then there are generics which allow you to declare a class with parameterized types. And there is an extremely powerful macro system. The macro system gives access to AST nodes in the compiler, type inference, and a very rich set of operators. You can call shell commands at compile-time and incorporate their output into macros. Most of the methods of String are duplicated for macros, so you can do arbitrary textual transformations.

There is an excellent interface to cross-language calls, so you can incorporate C code, etc. There are pointers and structs, so systems programming (like device drivers) is possible. Pointers and cross-language calls are “unsafe” (can cause segmentation faults, buffer overflows, etc.) but most programmers would never go there.

What have I missed so far? Run-time debugging is at a very primitive state. The developers complain that LLVM and LLDB have changed their debugging data format several times recently. There’s no const and no frozen objects. The developers correctly point out that const is propagated through all of your code and doesn’t often result in code optimization. I actually like it from an error-catching perspective, and to store some constant data in a way that’s easily shareable across multiple threads. But Crystal already stores strings and some other data this way. And these are small issues compared to the benefits of the language.


Paul Smith of Thoughtbot (a company well-known for their Ruby on Rails expertise) is creating the Lucky web framework, written in Crystal and inspired by Rails, which has pervasive type-safety – and without the declaration overhead as in Java.

The point of all of this is that you can create a web application as you might using Ruby on Rails, but you won’t have to spend as much time writing tests, because some of the most common problems of Ruby code are taken care of by the type system. And the combination of exceptions and type-safety does an excellent job of getting rid of most of the function return error checking I’d have to write in other languages. When you want to check for a nil rather than catch an exception, there are method versions suffixed with a ? which provide that.

Learning Crystal and Lucky, since I’m already a Rubyist, wasn’t difficult, but I took about two days including finding some bugs in Lucky and learning some non-obvious things about the language. Like it’s better not to declare the types of things a lot of the time. Rather than look up that the type of something was Lucky::AdmittedField, I could just declare the name of an argument that used it and go on with my life, and the compiler would take care of things.

The biggest problem with Lucky right now, in its pre-1.0 state, is that there is no API documentation. There are tutorial guides that tell you how to do most things, but I found myself exploring the Lucky code several times.

I am porting an application I’d written in Ruby for a new startup to Crystal and Lucky, to see if I can have more comfortable development with fewer run-time errors. If this works, I’ll have a large production application to better evaluate the language and framework.

Somewhere in the world there is someone in love with Node who is asking why I don’t use that. Javascript isn’t a particularly elegant language. Attempts to pretty it up like Coffeescript fall short of what you really should see in a modern language.

The advantage of Node is that the native IO framework is non-blocking. Some Node enthusiasts don’t realize that almost every other web framework and server does non-blocking IO to handle the web requests, and you don’t have to concern yourselves with that. But you still have blocking by default for database queries, file I/O, and your calls to other services in the cloud. Crystal library authors could provide non-blocking I/O with promises for this, but the developers haven’t seen a good reason to do so. Crystal uses Fibers for concurrency (and will get multithreading). Fibers start with a 4K stack, and are so inexpensive that a 64-bit processor can realistically provide thousands of them per process. Having a straight-line logical flow through I/O rather than many event-handling blocks (probably nested) means more readable and maintainable code. The overhead of fibers seems a low cost for that.

And finally, one thing I won’t ever miss is a JIT compiler as in Java and Javascript, and its complexity. The architecture portability reasons elucidated when Java was created were never nearly so big an issue as expected – even on Android phones. It works to have it in browsers, but even there the future focus is on Webassembly, a bytecode that runs inside of the Javascript engine, which will be compiled from various other languages.