#52WeeksOfCode Week 33 – Groovy

Week: 33

Language: Groovy

IDE(s): Eclipse with Groovy plugins/Groovy Shell


History (official):

(From the Groovy Home Page)


  • is an agile and dynamic language for the Java Virtual Machine
  • builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
  • makes modern programming features available to Java developers with almost-zero learning curve
  • provides the ability to statically type check and statically compile your code for robustness and performance
  • supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
  • makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
  • increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
  • simplifies testing by supporting unit testing and mocking out-of-the-box
  • seamlessly integrates with all existing Java classes and libraries
  • compiles straight to Java bytecode so you can use it anywhere you can use Java

History (real):

Since this is the third or fourth language I’ve encountered that produces code for the Java Virtual Machine (JVM), I decided to search for “java is dead”:

Searching for "java is dead"

Searching for “java is dead”

Apparently the Java Death Watch has been around since 1996. This raises the bigger question “When is a programming language actually dead?”.

According to the Linguistics Society of America, a human language is considered dead when there are no more native speakers.

Computer languages are trickier. Is a programming language dead if no computers are left to run it or is it when there are no programmers who still use it? If we decide to adapt the definition of ‘dead’ from human language (no more native speakers), we need to ask “What is the computer equivalent of a ‘native speaker’?” This puts us back to square one so that’s no help. We should probably just see how good of a case we can make for either choice.

  • Computers as ‘Native Speakers’ – Computers actually ‘speak’ machine language, 1’s and 0’s. This is very hardware and operating system specific, like different dialects of English (same characters different syntaxes). Every programming language command has to eventually end up translated (directly or indirectly) into machine language. For modern coding languages, the underlying hardware doesn’t make that much of a difference. This argument is a non-starter.
  • Programmers as ‘Native Speakers’ – This makes more sense to me. The code is still around and still runs but nobody is writing new programs with the language, then the  language is dead. Or, to use the phrase of art, in ‘maintenance mode’. (see COBOL)

Groovy is another scripting language that produces code that can run on the Java Virtual Machine (JVM). Others include JRuby, Scala, Vala, Fantom and Jython. In effect, they are all dialects of Java, since you can mix Java code with any or all of them and they run just fine.

So is Java dead? Let’s just say that the rumors have been highly exaggerated.


Groovy is cross-platform and there are a number of ways to install it.

  • Download the binary package and unzip it wherever you want
  • Install the Groovy plugin in either Eclipse or NetBeans
  • If you’re on a UNIX-based machine (like Mac OS X or Linux), you can install the GVM (Groovy enVironment Manager).

I already had Eclipse after installing the Scala IDE (i.e. Eclipse with the Scala plugin) so I went with the  Groovy plugins for Eclipse. It was pretty straightforward.

Once I plugged in the location of the Groovy software, I got a nice selection of add-ons. I just selected what I needed:

Minimum Groovy plugin install

Minimum Groovy plugin install

A quick download, install and restart of Eclipse and I was off to the races. When I came back, there were additional choices in my New menu:

Starting a new Groovy Project

Starting a new Groovy Project

I selected Groovy Project, took the defaults and (like the Scala project) opened up with no source code, just project scaffolding. I had to add a Groovy class to the project to get some source I could work with.

There are three ways to run your Groovy code:

  • Run as Java Application – This compiles Groovy into Java bytecode and runs it on the JVM
  • Run as Groovy Script – Don’t compile, just run the script with the Groovy interpreter.
  • Run as Groovy Console – This is the most interesting option to me. When you choose this, your code opens up into a separate window:
Running in the Groovy Console

Running in the Groovy Console

This gives you an interactive console where you can do some quick experimentation with your code. This is a good choice for rapid development, letting you test out chunks of code before rolling them back into your main project.

Since I’m also comfortable with the command line, I installed the GVM for good measure. It’s pretty easy and gives me access to a command-line Groovy interpreter. Like the Groovy Console, this lets me test out chunks of code for rapid development. Once it’s installed you just call it with the command groovysh:

Starting up Groovy Shell

Starting up Groovy Shell

A sample Hello World in groovysh:

Running Hello World in Groovy Shell

Running Hello World in Groovy Shell

This is not the preferred option for Groovy newbies. I would recommend that you stick with Eclipse or Netbeans.

One of the things that interested me about Groovy was the claim that you can drop Java code into a Groovy script and it will just work as Java and Groovy share virtually the same syntax.

I tested this out with Eclipse. I created a quick Java version of “Hello World!”, copied and pasted the code into my Groovy project (commenting out the original code) and it worked!

Java code with Groovy - it works!

Java code with Groovy – it works!

This gives Groovy an additional advantage, as Java programmers will have a much less steep learning curve when the transition to Groovy.



#52WeeksOfCode Week 32 – Assembly Language

Week: 32

Language: Assembly

IDE(s): SciTe + NASM

History (official):

(There is no one version of Assembly language since it is aimed at specific hardware. However, I did find this in the Forward for The Art of Assembly Language by Randall Hyde which I thought was amusing):

Egads. What kind of book begins this way? What kind of author would begin the book with a forward like this one? Well, the truth is, I considered putting this stuff into the first chapter since most people never bother reading the forward. A discussion of what’s right and what’s wrong with assembly language is very important and sticking it into a chapter might encourage someone to read it. However, I quickly found that university students can skip Chapter One as easily as they can skip a forward, so this stuff wound up in a forward after all.

So why would anyone learn this stuff, anyway? Well, there are several reasons which come to mind:


  • Your major requires a course in assembly language; i.e., you’re here against your will.
  • A programmer where you work quit. Most of the source code left behind was written in assembly language and you were elected to maintain it.
  • Your boss has the audacity to insist that you write your code in assembly against your strongest wishes.
  • Your programs run just a little too slow, or are a little too large and you think assembly language might help you get your project under control.
  • You want to understand how computers actually work.
  • You’re interested in learning how to write efficient code.
  • You want to try something new.



Well, whatever the reason you’re here, welcome aboard. Let’s take a look at the subject you’re about to study.

History (real):

I feel the need to lend some perspective before I dig into Assembly language, otherwise known as Assembler.

This is a picture of the first personal computer ever sold, the MITS Altair (from OldComputers.Net):

MITS Altair image, courtesy of OldComputers.net

The First Personal Computer


The Altair was introduced in January of 1975. It had 256 bytes of RAM (up to a maximum of 64K), a 2.0 MHz Intel 8080 CPU and was available for $395 as a kit. You got a box of parts. You had to make your own circuit boards. If you wanted it pre-assembled, that was an extra $255.

I want to draw your attention to the front panel of this computer. Yes, I mean all of the blinky lights and flippy switches. If you wanted to program this personal computer, you had to flip the switches on the front panel, entering your commands one word at a time in machine language (a series of 1’s and 0’s).

Now because there was no floppy drive, no hard drive, no secondary storage of any kind, if someone happened to trip over the power cord while you were flipping switches, you had to start over from the very beginning.

I mention this to tell you that no matter how arcane and hard to write, maintain, debug, read and understand Assembler is, things could be (and have been) much, much worse.


While Assembler was a step up from machine language, it wasn’t what you would call a giant leap. You still have to shuffles 1’s and 0’s around and have a deep understanding of the underlying hardware of your computer, but at least it took slightly less time to write code.

But if we now have all of these high-level languages, why bother writing code in Assembler?

  • Speed – Assembler programs are extremely efficient and very fast.
  • Size – The efficiency of Assembler also means that programs take up very little space.
  • Power – Since you’re working very close to the hardware, you can do things with Assembler that you can’t do with higher level languages

It’s not as if you have to choose between one or the other. If you have a section of code that needs to run quickly and efficiently you can write it in Assembler and hook it into your higher-level code.

For this exercise I decided to use NASM (The Netwide Assembler), a free, cross-platform assembler for Intel-compatible processors. There doesn’t seem to be a good IDE for Assembler (rumors exist of an Assembler plugin for Eclipse) so I’m going to use a text editor. Though NASM is available for Mac OS X, documentation on how to use it is limited or out-of-date. Linux, on the other hand, is well-documented so I’ll be using Debian 7 for my development platform and SciTe as my text editor. It’s free, cross-platform and does syntax highlighting for a number of common programming languages.

I looked for a “Hello World!” program in Assembler and thanks to a very nice tutorial from Ray Toal at Loyola Marymount University, this is what I found:

Hello World in Assembler

Hello World in Assembler (Using the SciTe text editor)

Compiling and running just involved a bit of typing.

Compiling and running code

Compiling and running our code

Before we look through the source, let’s see what’s happening at the command line.

nasm -felf64 hello.asm

The source code file is called hello.asm. This command tells NASM what format (-f) the output should take. In this case it’s 64-bit ELF (Executable Linkable Format, the standard binary format for Linux executables, object code and software libraries). NASM takes the source code (hello.asm) and compiles it into the object code file hello.o. Object code is machine code, a set of binary instructions.

However, as far as the computer is concerned it’s just a pile of 1’s and 0’s.

ld hello.o && ./a.out

There are actually two commands here.

ld hello.o

The first runs the linker (ld) to link the object code with the ABI (Application Binary Interface) for the target platform. It’s like putting a ‘Start’ button on our code so our processor knows how to run it. The default output is an executable called a.out. The line


runs the program to print “Hello World!”. The ‘&&’ between the two commands simply means ‘if the first command succeeds run the second command, otherwise just stop’.

Now let’s go through the source code line-by-line:

# ----------------------------------------------------------------------------------------
# Writes "Hello, World" to the console using only system calls. Runs on 64-bit Linux only.
# To assemble and run:
#     gcc -c hello.s && ld hello.o && ./a.out
# or
#     gcc -nostdlib hello.s && ./a.out
# ----------------------------------------------------------------------------------------


Anything that starts with a pound sign (hashtag for you youngsters) is a comment and is ignored by nasm. This is pretty standard Linux syntax and you may see the semicolon (;) used for a similar purpose on other platforms.

       .global _start

The global keyword marks symbols that need to show up in the output (hello.o). As you might suspect, NASM is showing the linker where the executable starts.


This is just a name for a section of code. Remember, the output is just a string of 1’s and 0’s which could mean anything, depending on where you start reading and how many bits you read at a time. This keyword .text tells us that that the following section is runnable code, not data.


As stated above, here’s where our actual code starts, in case it wasn’t obvious.

       mov     $1, %rax
       mov     $1, %rdi
       mov     $message, %rsi
       mov     $13, %rdx

A machine language instruction consists of two parts, the opcode (what the code should do) and the operand (the data on which the opcode should act). In these four lines, .mov is the opcode for loading data into a register (a small fast chunk of memory used for temporary storage). These four instructions copy data into the registers rax, rdi, rsi and rdx.

The first (rax) holds the location of the system call we’re going to use, which is write ($1).

The second (rdi) is the memory location where we’re going to write our message which is standard output ($1).

The third (rsi) is the string we’re going to write to output. ($message is just a label for the string data, which we’ll find elsewhere in our code. Hang on.)

The fourth (rdx) is how much of our message to print, 13 bytes (or characters).

We’re loading a sequence of commands. Write 13 bytes of our message to standard output. It’s like setting up a series of dominoes, just waiting for that lone finger to start the string of activity.

And here comes the finger:


Since our system already knows how to print strings, why reinvent the wheel? This opcode tells our processor to read the four sections of memory we’ve set up and act accordingly. We still have to tell the processor we’re done so let’s set the dominoes up again.

       mov     $60, %rax
       xor     %rdi, %rdi

The first loads the exit command ($60) into our register rax. The second is the exit code for our program to spit out, in this case 0. Ready for the finger again?


Finally we come to our data section.


       .ascii  "Hello, world\n"

This is labelled with message: so we can refer to it elsewhere in our code, as we saw above. In this case, it contains the string that we want the system to print to standard output. It’s labelled as plain old alphanumeric text, because we have to specify how we want the processor to interpret those 1’s and 0’s.

On the plus side, Assembler is a very powerful way to write fast code that takes up very little memory space. On the minus side, you have to keep track of where your data is at all times and what takes a single line of code in a high-level language takes thirteen in Assembler.

Not that there’s anything wrong with that.

Hyde, Randall. The art of assembly language. No Starch Press, 2003.


#52WeeksOfCode Week 30 – The R Project

Week: 30

Language: The R Project

IDE(s): R

History (official):

(From the R Project “What is R?” page)

R is an integrated suite of software facilities for data manipulation, calculation and graphical display. It includes


  • an effective data handling and storage facility,
  • a suite of operators for calculations on arrays, in particular matrices,
  • a large, coherent, integrated collection of intermediate tools for data analysis,
  • graphical facilities for data analysis and display either on-screen or on hardcopy, and


  • a well-developed, simple and effective programming language which includes conditionals, loops, user-defined recursive functions and input and output facilities.


Once again, this is what you get when programmers write your sales materials – nothing but facts.

Boring, tediously informative facts.

History (real):

In the Olden Days (™), if you wanted a computer to do your math homework, you had to use FORTRAN. It wasn’t what you might call ‘interactive’. You wrote your code, submitted it to the mainframe, which compiled and ran it. Assuming you didn’t have any typos, you got a printout of the results. (FORTRAN was my first programming language back in 1977. We used punch cards.)

This was always annoying and occasionally painful, but there were no good alternatives until the mid-70’s, when researchers at Bell Labs developed the programming language ‘S’. It was standard practice at the time to give programming languages single letter names.

I’m picturing the marketing meetings:

“How about ‘Bell Labs: We Don’t Have Time For This’?”

“Not bad. But I really like ‘Bell Labs: Smart But Terse’.”

“Love it!”

Moving on.

In the early 90’s, researchers at the University of Auckland, New Zealand developed a new version of S that they called R. Currently it’s being maintained by the R Development Core Team, with contributors  from all over the world. The name R is not just a play on the name S, but is also a tribute to the original developers, Robert Gentleman and Ross Ihaka, who were known at university as “R & R”.

R is free and available for Linux, Windows and Mac OS X. The source code is also freely available so you can compile it for any platform you like.


I’ve been looking forward to this for some time. I teach undergraduate math and occasionally blog about math education so math software is a particular interest of mine. I’m a firm believer in letting machines do the grunt work of mathematics. If you understand the problem well enough to explain it to a computer, then by definition you understand the problem.

I downloaded the Mac version of R from the main project site. R is a command line based tool so I wasn’t that surprised when I started up the program and got a window with a command prompt:

R for Mac startup window

R for Mac startup window


The window has a toolbar with easy access to common functions:

  • Load data or a script file
  • Open a new window (for charts and plots)
  • Authorize R to run commands as root (system administrator)
  • Show/hide R command history
  • Set R console colors
  • Open document in editor
  • Create a new empty document
  • Print this document
  • Quit

Most of your work is done at the command line.

Before we get going, I’d like to perform the traditional “Hello World!”:

Hello World! in R

Hello World! in R

This term I’m teaching an introductory statistics course so I’ve got some sample data from classroom exercises to run R through it’s paces. R stores with data tables in variables called data frames. There are pre-loaded data frames available in the software with which to experiment. You can enter data manually or just load the data from an outside source.

My data is in spreadsheet format and there are a number of ways to import spreadsheet files directly into R. Since I use Google Sheets as my primary spreadsheet program, the easiest way for me was to save off my data in CSV format. (Excel files can be imported directly.)

R assumes files are in the current working directory. The default is my home directory so I changed that setting to where I’d saved the files.

Get and set the working directory

Get and set the working directory

My first test data was a simple table comparing car prices to the age of the car. I chose a specific make and model (Toyota Sienna) and pulled these numbers straight from AutoTrader.com. I converted the worksheet and loaded the data table into R:

Car age vs. price data table

Car age vs. price data table

Now I can work with it directly. First let’s give it a once-over using the summary() function:

Summary of data table

Summary of data table

This gives me my central tendency numbers amongst others. Now let’s do a quick plot using using the pairs() function.

Data plot using pairs()

Data plot using pairs()

I got two plots, one with age as the dependent variable and other with price. I didn’t tell R which was which so it did both. I can be more specific using the plot() function:

Plot command syntax

Plot command syntax

This tells R that price is dependent on the age of the car. This gives me a single chart:

Chart using plot()

Chart using plot()

Now I can calculate the correlation coefficient with cor() to see how strongly the two sets of data relate to each other:

Correlation Table

Correlation Table

So price is negatively correlated with the age of the car, which fits what the chart told us. Older cars cost less, in other words. It’s a pretty strong correlation, too, at 85%.

Now we’d like to do some prediction so we’ll perform a linear regression on the data. First create a data structure with the regression data, then pull a summary:

Linear regression

Linear regression

Now you have a processed data set and you can continue working with it.

We can get data in and manipulate it but how do we get it out? For text data, such as the correlation summary, you can just copy and paste it from the R gui window. The plots appear in a separate window. I was able to click on the image, select Copy from the Edit menu and paste directly in a document.

R is a very powerful, interactive language for scientific and math computing. So why would you use it instead of a spreadsheet?

Frankly, if you’re not a full-on numbers nerd, you may just want to stick with spreadsheets. But they’re a general purpose tool and R has more math functionality. You can write your own functions and even groups of functions (called packages) to extend R even further.

Another advantage of R is automation. Anything you can type in at the command prompt can be saved into a file, letting you easily set up long, complex sets of calculations that can be loaded into your workspace with a single command. If you’re doing batch processing of multiple datasets, this can save a lot of time and effort.

The documentation is very good and there are plenty of tutorials and examples available at the project homepage and around the Web.


#52WeeksOfCode Week 29 – Clojure

Week: 29

Language: Clojure

IDE(s): NightCode

History (official):

(From the official Clojure home page)

Clojure is a dynamic programming language that targets the Java Virtual Machine (and the CLR, and JavaScript). It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language – it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

Clojure is a dialect of Lisp, and shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs.

I hope you find Clojure’s combination of facilities elegant, powerful, practical and fun to use.”


History (real):

That was the equivalent of a marketing release for Clojure. In other words, it’s targeted at the ‘suits’. If you want the sales page for the technical crowd, see the Rationale page.

I have no personal animus against Clojure. Today was the first time I had heard of it. But I have to say that my first thought was “What? You mean I can at last combine the terse, unreadable code of Lisp with the performance hit of running Java? Sign me up!”

Of course, the true story is more complex.

One of the strengths of the Java platform is the Java Virtual Machine (JVM). A Java program compiles to bytecode which runs on the JVM. The JVM gives Jave its portability between operating systems. Microsoft’s .NET language followed suit with the CLR (Common Language Runtime).

Another advantage of the JVM, however, is that Java bytecode is an open, documented standard. That means that you can use any programming language you want to write Java applications, as long as you can compile your language to produce bytecode. Examples include Jython and JRuby that let programmers write Java programs in Python and Ruby, respectively.

Clojure lets programmers write in Lisp and produce code that can easily integrate with Java and code that uses Microsoft’s .NET framework. It can also connect to JavaScript libraries like Node.js for Web applications.

This is a cool idea. Scripting languages do make for faster prototyping and development and bytecode compilation does improve performance a bit (but not as much as going all the way down to machine code).

But why Lisp for scripting? Let’s ask the creator of Clojure, Rich Hickey. From the Clojure Rationale page:

Why did I write yet another programming language? Basically because I wanted:


  • A Lisp
  • for Functional Programming
  • symbiotic with an established Platform
  • designed for Concurrency


I think the third feature is the important one. We already have multiple dialects of Lisp. Erlang is a functional programming language that supports concurrency. But neither of these can integrate so easily with existing code as Clojure.

I think that if I had a complaint, it would be that the scripting language was based on Lisp. But that’s my own personal discomfort and unfamiliarity with functional programming and not meant to diminish Hickey’s accomplishment in any way.


So how do I get started coding in Clojure? After a bit of research, I found that writing the code was easy enough but a real Clojure project involves keeping quite a few metaphorical plates spinning. Managing all of the files, code dependencies and project details can get hairy very quickly, particularly if you work from the command, which is the bare-bones Clojure install default.

There is an existing tool, make, which can handle code projects but it’s finicky to configure. Java has similar project management issues which are handled by a tool called ant. Fortunately some contributors to Clojure created an automation tool named leiningen. It works so well that it’s become the default tool for working with Clojure projects.

I didn’t feel like working from the command line (again) so I searched for a nice IDE for my first Clojure project. There are Clojure plug-ins for popular Java IDEs like Eclipse, NetBeans and Intellij but I wanted a program that was built specifically for Clojure.

Enter NightCode. Not only was it written for Clojure projects, but it was written in Clojure. I felt this showed admirable brand loyalty so I grabbed a copy. The interface is pretty bare-bones:

NightCode on first startup

NightCode on first startup

I only have three options: Create a new project, import an existing project or run code interactively in the little interpreter window on the lower left. This is a pretty neat feature because you can jump out of your current project, quickly test out some scrap of code to make sure it works the way you think it does and then paste it back into your main source file without leaving the IDE. Very nice:

NightCode interactive shell

NightCode interactive shell

I created a new project and after giving my project a name was presented with a list of project templates:

NightCode template selection

NightCode template selection

I like templates. They let me get on with my life.

I picked Console and selected Create Project.  In a few moments my first project was ready to code:

A simple console application project

A simple console application project

I have a few more options now. One thing I noticed were the options Run, Run with REPL, Build and Test. Since Clojure is a scripting language, it’s possible to run code without actually creating an application. Run with REPL runs your code interactively which is useful for debugging. Test checks your code for logic and syntax errors. Build, of course, creates the standalone software application. It’s still a very sparse interface, but it looks like you could do some non-trivial projects in this IDE. Not bad for free software.

On to my trivial project. The console project template is a standard “Hello World” so I use it to take both Clojure and NightCode for a spin.

Here’s the code, in case you’re curious:

Hello World in Clojure

“Hello World!” in Clojure

I’d like to test my code before running it so Test automatically inserts test code into my program, compiles and runs it:

Automatic code testing

Automatic code testing

Selecting Run gives me this:

Running my code

Running my code

Run with REPL loads the code and drops me into an interactive shell:

Running interactively with REPL

Running interactively with REPL

Now I’m ready to create my standalone application with Build:

Building a standalone application

Building a standalone application

Clojure is a unique, versatile language and NightCode gives me enough tools to handle non-trivial projects with confidence.

#Review – The Practice of Programming

In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles— simplicity, clarity, generality— that form the bedrock of good software.

Kernighan, Brian W.; Pike, Rob (1999-02-09). The Practice of Programming (Addison-Wesley Professional Computing Series) (p. ix). Pearson Education. Kindle Edition.


Programming is a craft. Some programmers refuse to acknowledge this, insisting instead that it’s a scientific or engineering discipline. There are certainly elements of that but anything that allows a human to place their own distinctive style on a made thing is a craft.

Bridges look a certain way because that’s how the physics make them look, not because the engineer was feeling whimsical that day. That’s why one bridge looks a lot like another. When a carpenter makes a bookshelf, it shares the same functionality with other bookshelves. However, there are a hundred individual decisions made by the carpenter during the design and creation process. A bookshelf is physics seasoned by art.

Two software applications may have similar functions but the underlying source code tells a different story. Anyone who reads or writes code knows that the programmer imposes their own personal style on the code in hundreds of different ways. From the use of a favorite decision loop to the design and implementation of a particular data structure, programmers have always found a way to express themselves in their work.

The Practice of Programming was written to bring programmers who are swimming in complexity back to their roots and help them regain perspective. Just to be clear, this is not a book that will teach you how to program. However, if you are learning to program or even if you’re a veteran coder, you’ll get something useful out of this text.

Despite this, Kernighan and Pike don’t romanticize the work of programming. Instead they show that by embracing (or re-embracing) the fundamental principles of coding, you can become a better, more productive programmer.

They start with a style guide, because clean, consistent code is easier to read, debug and maintain. Establishing and maintaining a consistent coding style frees up your higher brain functions for more complex decisions and problem solving.

Next we move on to algorithms and data structures. These building blocks of software should be familiar to all coders but the right algorithm choice can make the difference between a program that takes an hour versus one that takes seconds to produce the desired result.

The authors build on this foundational knowledge with discussions on design, interfaces (how to efficiently pass data), debugging, testing (which reduces debugging), performance, portability and end with a chapter on notation which includes a discussion of tools that will help you generate code automatically.

The writing is crisp and direct. Kernighan and Pike speak to you, programmer to programmer. They have decades of combined experience in the coding trenches and understand the problems you face every day, whether you’re doing an assignment for school or creating a business analytics solution for your business.

#52WeeksOfCode Week 18 – VB.NET

Week: 18


Language: VB.NET


IDE(s): MS Visual Basic Express



VB, of course, stands for Visual BASIC and I think it’s worthwhile to review the history of the language and it’s influence in not just the genesis of the commercial software industry but it’s role in the genesis of Microsoft.

First of all, let me give a shout-out to Steven Levy’s wonderful book, Hackers: Heroes of the Computer Revolution. If you want a good, behind-the-scenes look at how the personal computer industry was born and the kinds of people involved in the midwifery, this is the book you want. (I’ll be posting a separate review of it at a later time.) BASIC has several mentions in this book and not always in connection with Bill Gates (but Gates is a key figure in this story).

From the chapter “SpaceWar”, an account of the growing code democratization movement that began at MIT in the 1950’s:


“The planners were also extremely concerned about getting the power of computers into the hands of more researchers, scientists, statisticians, and students. Some planners worked on making computers easier to use; John Kemeny of Dartmouth showed how this could be done by writing an easier-to-use computer language called BASIC. Programs written in BASIC ran much slower than assembly language and took up more memory space, but did not require the almost monastic commitment that machine language demanded.”


Excerpt From: Steven Levy. “Hackers.” iBooks. https://itun.es/us/Em_Px.l


BASIC was at the front of the war against the “mainframe priesthood”, the gatekeepers to the mysterious, room-filling machines that were our only access to computing. It was designed to use English-like commands. For example:


10 PRINT "Hello, World!"
140 END


I took a programming course in 1977 and saw this first-hand. I wrote out my program by hand, typed it into a keypunch machine, took the punched cards to the computer room and handed them to the operator. If I was lucky (i.e. my code worked the first time), several hours later I would come back to pick up a short print-out showing the output of my program. I was unlucky, then I got a much bigger stack of print-out paper which showed me in excruciating detail how badly my program sucked. Much of the paper consisted of a dump of what was in the computer’s memory when my program failed, along with what instructions were running at the time. I then had to grovel through the output, figure out what I had done wrong, fix it and go through the whole process again.

I had heard about these things called personal computers, like the Commodore PET and the Tandy TRS-80 but these seemed expensive and complicated and weren’t really on my radar.

In 1980, Commodore came out with a computer called the VIC-20. It was simple to set up and, more importantly really cheap, so I got one.

Of course, you didn’t get much for the price. It came with 5 kilobytes of RAM (which shrunk to 3.5 kilobytes once you turned it on), had no external storage (but you could buy an external drive that used cassette tapes). It had a cable that you could use to plug it into a television and the display was 22 characters wide and 23 lines tall. It originally sold for $299 but the price eventually dropped to $100.

But that wasn’t what made it magic for me. I remember unpacking the box, scrambling to get the cables connected just so I could turn it on and see this:


It wasn’t as powerful as the mainframe I used in school but it was MINE.

The VIC-20 booted directly into a BASIC interpreter and you interacted with it using BASIC commands. CBM stood for Commodore Business Machines and they used a dialect of BASIC called Commodore BASIC. But they didn’t develop their own version, they bought it from someone else. Someone whose entire business model initially consisted of providing BASIC interpreters for different computers.

It’s hard to imagine that before Bill Gates came along, the idea of selling computer software was unthinkable. Not in a bad way, but in that it just didn’t make any sense. After all, the computer business model was: you buy (or lease) the computer and the company gave you software for free (because the computer wouldn’t run without it). They even gave you the tools to build your own software because this added value to their hardware and encouraged more people to use it. So programmers got into the habit of not only getting their software for free but also giving away the software they wrote.

So when Bill Gates and Paul Allen wrote a BASIC interpreter for a new computer called the MITS Altair, someone snagged a copy of the paper tape containing Altair BASIC and ran off a bunch of copies, then handed them out to their friends, asking them to each make two copies and hand copies to their friends.

Of course, when Gates and Allen found out about it, this resulted the infamous Open Letter to Hobbyists. It’s hard to understate the huge rift this incident created in the nascent personal computer industry. (Seriously, read Hackers. It’s great.)

Microsoft, of course, went on to dominate the commercial software world far beyond their initial humble beginnings, but BASIC came along with them. It was even included in early versions of DOS and Windows. It kept evolving adding features and functionality that let it be deeply embedded into the Microsoft software ecosystem. It became tremendously popular in business software because it was an easy way to hook into your software (assuming you ran MS Office, MS Exchange, MS SQL Server, etc.) and let you quickly put together a GUI front-end for your server systems.

To give you a sense of how much the language has changed, here is the standard Hello World program written in VB.NET:


Module Module1

    Sub Main()
        Console.WriteLine("Hello, world!")
    End Sub

End Module


Frankly, this looks a lot more like Java:


public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello, World");



Can we still call VB a dialect of BASIC? More importantly, with the introduction of cleaner, more modern languages like Ruby, is there still any need for VB, with or without .NET?

I’m going to get some crap for this, but I have to say, “No”. Unless you have an all-Microsoft shop with a substantial investment in legacy Visual BASIC code, there is little reason to use VB.NET.

That being said, let’s fire up Visual BASIC Express and see how it runs.



The first thing that shows up:


Just to be clear, if you want to use someone’s product then you implicitly agree to whatever conditions they require before you can start using it. However, crap like this is why I actively seek alternatives to Microsoft software. Other commercial software developers make you jump through hoops, but nobody does it with such bloody-minded verve like Microsoft. Fortunately I have a Windows Live account for just such a contingency.

After completing a survey and politely declining membership on several email lists, I finally get a registration key, enter the key, click on Register Now and:


Yes, Microsoft, I’m aware that you have me by the short and curlies. Don’t rub it in.

Once past all that, I was presented with the usual friendly interface. I give Microsoft a lot of crap, but it’s clear that they work very hard making the front-ends to even quite complex software pretty friendly. I selected New Project… and opened the default application template and got this:


Now I appreciate secure computing as much as the next man, but this file was installed on my computer by Microsoft. By. Microsoft. Okay, that’s all I wanted to say about that.

I located a very sketchy tutorial on Udemy, a popular online course site. After a bit of fussing with variable names, I got a simple Windows Forms application:

If you’re familiar with Windows Forms, it doesn’t take too much extra work to get up to speed on VB.NET. The IDE looks and works the same as it does in Visual C# Express, with drag and drop of form elements and easily edited property lists.

I still stand by my opinion that Visual BASIC is essentially a dead-end platform. I thank Gates and Allen for their hard work in bringing programming to a greater audience and doing their part to free us from the grip of the mainframe priesthood.


#Coding4Humans #DIYMath FreeMat

(Cross-posted at We Hate Math)

Today in DIY Math we’re looking at  FreeMat. As the name suggests It’s modeled after MatLab. FreeMat has been in development for over a decade by a group of volunteers

System Requirements – Specific hardware requirements were not available but the pre-built packages I tested all run on 32 or 64-bit Intel-compatible CPUs. The application itself doesn’t seem to use much memory. As an example, the Mac version uses about 85 MB of real memory on my system. Since Windows XP is supported, we can assume that XP-compatible hardware constitutes the base system.

Installation – The latest version is 4.2 and is available for Windows (XP and up), Linux (various) and Mac OS X. In addition to pre-built packages for the above platforms, the source code is also available and is released under the GPL license. All versions of FreeMat are kept at the same version level and functionality.

Windows: Simply download the 52.5 MB setup file and double-click it. (NOTE: A portable version of Freemat is also available so you can run it from a thumb drive without installation.)

Linux – I installed FreeMat on Debian Linux using APT and on my system it was a 12 MB download, using an additional 22 MB of disk space.

Mac OS X – The installer is a 79.5 MB compressed disk image (DMG) file. Double-click the file to mount it, then drag the program and documentation to your Applications folder. The two files together take up about 250 MB of disk space.

Documentation – The Mac download comes with a PDF manual detailing all of the functions available in FreeMat. (For Windows or Linux, you can download the manual here.) The manual is automatically generated using Doxygen, which scans specially marked comments in the source code and outputs documentation in a variety of file formats.

This is both a good thing and a bad thing. It’s good in that it makes it easy for developers to actually maintain their documentation, assuming they remember to update the comments. It’s a bad thing because there’s no guarantee that the resulting document will be well-written. In fact, the included manual is very sparsely written, despite the 162 page (!) table of contents. It is less a manual than simply an API reference. Each function or class is briefly described and includes one or two usage examples. The target audience for this manual are those who don’t need a manual. It’s comprehensive but very terse.

A much better option to start with is the FreeMat Primer. Who’s the audience? Let the authors (Gary Schafer and Timothy Cyders) tell you:

We assume that you have Freemat properly installed and working. If you have any issues, direct them to the online Freemat group, http://groups.google.com/group/freemat.

This book was originally written for the Windows version. The book now covers more of the Linux and Mac versions, as well. In those cases where there are differences, we’ll point them out.

It’s a much friendlier introduction to the software. It’s very readable, with plenty of screenshots, little tutorials and code examples. With this and the official function reference you have a very good documentation base. In addition, there is also a Google group available for more interactive support. There is another Google community intended to host FreeMat tutorials. (At this time the content is a bit sparse.) You can also type helpwin at the command prompt from within FreeMat.

Compatibility – Based on the scripts I tested, MatLab support is somewhat hit-or-miss. I’ve been able to run scripts with no modifications, minor modifications or not at all. I would suggest that you test your Matlab scripts on a case-by-case basis and then decide whether you want to make the changes or just re-write from scratch. The scripting syntax is similar enough that most of your work will be figuring out equivalent function calls.  (A MatLab to FreeMat translation guide would be a really good project. Better yet, some kind of conversion tool.)

Command Line vs. GUI – The Windows and Mac versions of FreeMat are targeted at a graphical interface so accessing the tool from the command line is at best a non-trivial . The Linux version can be launched from the CLI. With no parameters, the graphical client starts up by default. To use the CLI version only, start the tool with the option -noX or -nogui to suppress the graphical subsystem This will give you a FreeMat command prompt in your terminal window. If you simply wish to run a Freemat command and then exit, use the option -f to run the tool in command mode. (NOTE: if you want to see the output of your command, make sure to specify that as FreeMat will not show any output.)

Integrating FreeMat with your native scripting environment is problematic (okay, just about impossible),as FreeMat scripts are meant to be run from within the FreeMat interface. You can edit them inside FreeMat or using your favorite text editor but make sure that they are saved to FreeMat’s working directory. (You can set this up by running pathtool from within FreeMat.)


The GUI for each version is comparable in look and feel.

FreeMat Interface

FreeMat GUI

This is from the Mac version of the tool. In addition to the main terminal window, FreeMat also tracks your command history (allowing you to invoke a previous command simply by double-clicking on it), tracks what variables are currently in memory, along with their data types and values if applicable. The Debug window is supposed to show any error or warning messages but on all three platforms I tested, the messages showed up in the main terminal window and the Debug window remained blank.


Pros: Easy installation, all supported platforms are kept current with a common codebase, decent documentation and online support.

Cons: Development progress is a bit slow. The latest release (4.2) was posted in June of 2013 and that was two years after the previous release. CLI support is limited or non-existent in the Windows and Mac versions and all scripts are restricted to running within the FreeMat environment. Third party support is a bit anemic.

Would I use this in my class? – I would feel confident recommending this to my students. The ease of installation and minimal setup are a definite plus, you don’t need the latest hardware to run it and the price fits everyone’s budget. It supports nearly everything we might do in 100- and 200-level math classes with enough overhead room for more advanced work.