If Shakespeare Were Alive Today

R not Julia the Ruby of the realm?
Go hither and think not upon Ada,
Whose Basic baseness is not worthy a Boo,
C to it sharply and bring Clojure Forth,
Dart away now to her awaiting arms,
As her love for you awaits in the Eiffel tower of her heart,
Like an Elixir to her suffering,
Be not a Hack, a Python in the weeds, but be instead Groovy,
Woo her with Java,
Be Lithe, speak Lucid and without a Lisp,
Utter not a bovine Moo from thy lips,
Instead may an Opal be upon thy tongue,
Your Prolog Swift,
Your Smalltalk small,
Scheme little, for honesty is the Unicorn
upon which no Rust will form.

Spinning 3D Box with BeagleBoneBlack and L3G4200D Gyro

bbbgyro.png

Got a fun little project working this weekend.  I wired up an L3G4200D gyroscope module to a BeagleBoneBlack, wrote the Python code to read the sensor data and send it over using RabbitMQ to a C# app on Windows displaying a 3D box.  Now when I rotate the BeagleBoneBlack, the cube mirrors my movements!

Full article will be posted on Code Project in the next week.

 

The Dangers of Duck-Typed Languages

ducktyped.jpg

Try these examples yourself in repl.it

First, is the ambiguity of what something is.  For example, consider this Python example:

> a=[] 

We have no idea what “a” is an array of.  Now, many people will say, it doesn’t matter, you’re not supposed to know, you just operate on the array.  There is a certain point to that, which however can lead to trouble.

Let’s try this:

> a=[1, 2, 3]

Ah, so you think we have an array of integers?  Think again:

> a.append('4')
> a
[1, 2, 3, '4']

Whoa!  That’s an array of mixed types.  In some ways that’s cool, in other ways, that’s dangerous.  Let’s say we want to add one to each element in the array, and we trust that the programmer that created / modified the array knows that it is supposed to be an array of int’s.  But how would they know?  Someone else can come along and not realize that they’re appending the array with a string.  So now we come along, expecting a happy array of int’s, and do this:

> [x+1 for x in a]
TypeError: cannot concatenate 'str' and 'int' objects

Oops – we get a runtime error!

What happens in Ruby:

> a=[1, 2, 3, '4']
[1, 2, 3, "4"]
> a.map {|x| x+1}
no implicit conversion of Fixnum into String

What happens in Javascript:

> a=[1, 2, 3, '4']
[1, 2, 3, '4']
> a.map(function(x) {return x+1})
[2, 3, 4, '41']

Holy Cow, Batman!  In Javascript, the string element is concatenated!

What does this mean?

It means that, among other things, the programmer must be defensive against, not necessarily the errors (sorry, I meant “usage”) of other programmers, but certainly the lack of strong typing in the language.  Consider these “solutions”:

Python:

> [int(x)+1 for x in a]
[2, 3, 4, 5]

Ruby:

> a.map {|x| x.to_i + 1}
[2, 3, 4, 5]

Javascript:

> a.map(function(x) {return parseInt(x)+1})
[ 2, 3, 4, 5 ]

Of course, if you have a floating point number in the array, it’ll be converted to a integer, possibly an unintended side-effect.

Another “stronger” option is to create a class specifically for integer arrays:

Python:

class IntArray(object):
  def __init__(self, arry = []):
    self._verifyElementsAreInts(arry)
    self.arry = arry

  # support appending to array.
  def __add__(self, n):
    self._verify(n)
    self.arry.append(n)
    return self

  # support removing element from array.
  def __sub__(self, n):
    self._verify(n)
    self.arry.remove(n)
    return self

  def _verifyElementsAreInts(self, arry):
    for e in arry:
      self._verify(e)

  def _verify(self, e):
    if (not isinstance(e, int)):
      raise Exception("Array must contain only integers.")


# good array
a = IntArray([1, 2, 3])
a += 4
print(a.arry)
a -= 4
print(a.arry)

try:
  a += '4'
except Exception as e:
  print(str(e))

# bad array
try:
  IntArray([1, 2, 3, '4'])
except Exception as e:
  print(str(e))

With the results:

[1, 2, 3, 4]
[1, 2, 3]
Array must contain only integers.
Array must contain only integers.

What this accomplishes is:

  1. Creating a type checking system that a strongly typed language does for you at compile-time
  2. Inflicting a specific way for programmers to add and remove items from the array (what about inserting at a specific point?)
  3. Actually doesn’t prevent the programmer from manipulating arry directly.
  4. Javascript? It doesn’t have classes, unless you are using ECMAScript 6, in which case, classes are syntactical sugar over JavaScript’s existing prototype-based inheritance.sed inheritance.

The worst part about a duck-typed language is that the “mistake” can be made but not discovered until the program executes the code that expects certain types.  Would you use a duck-typed language as the programming language for, say, a Mars reconnaissance orbiter?  It’ll be fun (and costly) to discover an error in the type when the code executes that fires up the thrusters to do the orbital insertion!

Which is why developers who promote duck-typed languages also strongly promote unit testing.  Unit testing, particularly in duck-typed languages, is the “fix” for making sure you haven’t screwed up the type.

And of course the irony of it all is that underlying, the interpreter still knows the type.

It’s just that you don’t.

What’s the difference between Junior vs. Senior Developers

no.jpg

Duncan Brown posted a very interesting question on DZone: “Junior vs Senior Developers: What’s the Difference, Anyway?”

It occurred to me that the answer is, the ability to say “no.”  No to additional feature requests, sacrificing personal life, unreasonable deadlines, etc.  I’ve found that junior developers tend to be “yes” oriented (certainly I was) because, after all, one wants to eventually become distinguished as a senior developer.  Enthusiasm is great and needed, but an over-enthusiastic “yes” can often lead the project, the team, and the company, into disaster when the repercussions of saying yes are encountered, often by the now, unhappy, customer.

A senior developer will say “no”, and even better (after some discussion on Code Project that led me to further clarity), will be able to explain why “no” is the appropriate answer, in such a way that management can make intelligent course corrections.  Second, a senior developer will also say “no” and at the same time propose one or more alternatives for consideration.  This facilitates out-of-the-box thinking that, again in my experience, often leads to better solutions that more easily achievable (meaning, less risk.)

Sure, there are lots of technical metrics one might use, but ultimately, I think the difference between junior and senior developers is reflected in their behavior when asked to accomplish something that is demonstrably unreasonable.

The Nuances of Loading and Unloading Assemblies with AppDomain

app.jpg

There’s a lot of posts and articles out there about using AppDomain to load and unload assemblies, but I haven’t found one place that puts it all together into something that makes sense as well as exploring the nuances of working with application domains, hence the reason for this article.

The full article is posted on Code Project, here.

A Lean and Mean Un-opinionated Templating Engine

unittests.png

The article is posted on CodeProject here.

Salient features:

  • Lines of code: 492 (not including unit tests and my extension library)
  • No weird stuff — no temp files generated by the runtime compiler, etc.
  • Assembly caching.
  • Supports multiple models and native types.
  • Support better performing non-dynamic property/method access as well as dynamic objects.