A note on diagrams

I’ve been writing object oriented software most of my life. First with C++ and then with Java. You can do OO with other languages of course but these two are compiled. With compiled languages, there’s a tendency to define classes and class relationships quite early in the development. You also tend to refine your OO models in much finer details than with dynamic languages (e.g. Ruby). I’m not saying it’s a good thing, by the way…

I’ve been doing this for close to 25 years. Initially with Booch and Rumbaugh and later on with UML. I’ve done it so much over the years that I tend to disassemble most books (be they science, software and even novels using a bastardized, simplified version of UML). I’ve even done a Game of Thrones taxonomy using UML at the time.

So for the sake people looking at my web site, here is a very VERY small example that gives you an inkling of the diagramming method that may be found here.

In the following diagram:

you’ll find the following relationships and concepts:

  • Any rectangle in a diagram represents a “class”. A class is usually an abstraction of a concept associated with the topic I am talking about. So if I want to talk about the car and the car fabrication process, “Car” would definitively be something that I would want to model.
  • Sometimes (most times?) I will leave the rectangle as is (like the “SUV” or “Sedan” class). Other times, I will model some attributes of the car (for example, its make and model) or some of its operations (“start” and “stop”). When that happens, I will split the rectangle in up to three sections:
    • top: name of the class
    • middle: attributes of the class
    • lower: operations of the class.
  • An arrow linking two classes represent a “generalization” (aka an “is-a” relationship). You can read the relationship following the arrow… so an “SUV is a Car” or a “Sedan is a Car”.
  • Diamonds (empty or full) represent containment. There are two types of containment (aggregation or composition). Composition (full, black) implies that the two classes “life spans” are tied together. The aggregation (empty, white) implies that the two classes’ lifespan are independent. In the diagram, I’ve represented the driver with an aggregation, meaning that their lifespan are not tied while the wheels are tied (basically, they don’t have meaning outside of the concept of a car).
  • Containment relationships may have a multiplicity. For example, a car has 4 wheels.

In any case, UML can get quite complex. What I just showed is a small portion of the class diagramming aspect of UML. It is a much larger spec that also covers sequence and state diagramming. That being said, I find that it’s usually an 80-20 proposition where you can get most of the value of the specification with the first 20% of the language. (Though what I just described is probably less than 2% of the whole thing).

If I write anything that requires more detailed UML or more detail about my “bastardized” version of it, I will attempt to document it in that blog entry or I might just spawn a new page just for notation.

P.S. I’m using a StarUML for the diagram.

2017 is my year of functional languages

It’s a brand new year, time to set some goals!   Software wise, my main goal this year is to get familiar with functional programming.

I want to accomplish by learning two languages that I’ve had on my radar for a while: Elixir and Elm.  Not sure if this is “career advancing”, I doubt it, but from the little that I know from both languages, I’m fairly certain that I will learn something that I can bring back to the Java and Javascript worlds.

So, why Elixir and Elm?

First, Elixir is intriguing.  Elixir runs on top of the Erlang VM.  It uses the same VM that powers WhatsApp…. and WhatsApp is VERY performant.  You can find articles and videos on it here:

There seems to be little doubt that a language built on top of the Erlang VM will be performant.

Now, why not learn Erlang instead of Elixir?  Elixir was created by Jose Valim, a key contributor in the Rails world.  He created the “Devise” library in Rails.  I’ve since looked at the Elixir API and it was definitively heavily influenced by the Ruby and Rails APIs.  I’m just hoping to cut some of the API learning time by leveraging some of my Ruby experience and focus on the new stuff: functional programming proper.

One language should be sufficient to learn how functional programming work but I’ve decided to also dig into Elm.

This is an emotional decision, I think.  I listened to a few podcasts that intrigued me:

I’m not crazy about Javascript and I think that I’m just looking for an alternative that I find more pleasing.  It’s not a dynamic vs compiled language decision, I’m fine with Ruby which is dynamic and I’m fine with C++ and Java, which are compiled.  My problems with Javascript are in some of its details. For example, the equality logic (or rather that weird casting it does).  I’m not crazy about the prototype model stuff either.  It’s pretty far from a what a good OO language should be.  Even frameworks like Angular are a bit annoying because they have to piggyback on some of the idiosyncracies of the JS.  (Though ES6 and Angular2 might make me change my appreciation of Javascript, we’ll see).

Elm is a “transpiled” language (Elm -> JS).  Furthermore, it is typed.  It has meaningful error messages and has an intriguing programming model that looks like it might help out with the asynchronous nature of client application.  Everything in an Elm program is message based.  So really, it’s all asynchronous.

So, there you go.  My plate is full.  It’s going to be interesting.