Since I’m now an instructor, I thought I would create a repository which demonstrates  code for the many languages out there which could produce a command line tool/interface (CLI).


Currently, there are nine languages represented but I may add more later. Note that everything here is decidedly OSX-specific. Each subsection includes the instructions for running and/or compiling each, noting that some are compiled languages and some are not.

go figure

For years, if I needed to write a computer program, I’d have used one of the following: C, C++ or C#. Those have been the mainstays of programmers who needed an executable program for at least the two decades. Today, though, I’ve just written my first executable in a new language that’s surprisingly easy to work with.


The Go language is like the new kid on the block of compilers. Like the ones mentioned before, it will take text and convert it into instructions the computer can do.

Probably the best thing about the Go language is that it’s entirely open-sourced. If you wanted to work on the compiler itself, you could do so.


The program I’ve just written is technically called a Command Line Interface (CLI) program and will display technical details inside the selected GCODE file for a 3D print job.


Typical session of the program in use:

$ SlicingInfo RC_3DBenchy.gcode
Slicer:          Cura_SteamEngine 2.3.1
Layers:          239
Quality:         low
Profile:         Low Quality Robo C2
Filament size:   1.75
Hotend temp:     190
Bed temp:        0
Supports:        False
Retraction:      True
Jerk:            True
Speed 1st layer: 10
Print speed:     50
Travel speed:    80
Infill pattern:  cubic

why PowerShell sucks so badly

Here, I attempt to answer the rhetoric question, “Why does Microsoft PowerShell suck so badly?” Where to begin…? It has such promise, it’s clear that someone has spent much time coding everything. Ultimately, there appears to be power under that shell and it’s probably truthful to its name. But if you can’t use the tool in the real world, it should be renamed to Microsoft PowerlessShell.

“But if you can’t use the tool in the real world, it should be renamed to Microsoft PowerlessShell.”

It’s almost like a group of scientists in a desert setting somewhere—think “Manhattan Project”—created a collection of methods useful for annihilating the planet and then as almost an afterthought, enough preventive controls were placed upon its use that literally nobody could in fact blow anything up.

Today’s task is to automate the creation of a VPN button for Windows 10—based remote users here at the office. End-users then in theory can just double-click a PowerShell script that I’ve placed on a SharePoint server.  I would then individually share the link with them which would remotely install the new VPN profile. Sounds easy enough.  In fact, it sounds much easier than the two-page long tutorial in a Word document which attempts to educate them how to do all this manually.  Have you ever seen how long an L2TP shared key phase can be?  It’s pretty bad.  Just think of all the support calls I’m going to get if I can’t script this.

Is the PowerShell documentation easy to use? Hell no, it’s not. I’ve just spent a full hour trying to piece together the script required from this hobbled-together documentation on Add-VpnConnection. Does my script work under a test rig? I wish I knew, because at the moment I can’t actually run the script in any form or fashion because Microsoft doesn’t want me to.

“Does my script work under a test rig? I wish I knew, because at the moment I can’t actually run the script in any form or fashion because Microsoft doesn’t want me to.”

Now granted, I’m an Administrative user on my newly-upgraded Windows 10 laptop. The script fails with some terse error message which suggests that I need to run the PowerShell command as Administrator.  Well, that would foil things here in the real world because I’m trying to have the end-users run this script remotely so that I—the administrator—don’t have to be there in the first place.

So I doggedly trudge ahead and end my session and open up PowerShell by right-mouse clicking it and choosing Run As Administrator.  And yet, this still doesn’t work.  This time it fails with another terse error message which suggests that Set-ExecutionPolicy might help.  I then research this to find that “Unrestricted” is the probable attribute but when attempting to run this, I get another terse error message suggesting that I can’t change the policy.  Seriously?

I could now go back to my earlier research and re-learn how to digitally sign a script so that I can run it.  But the process to create and to troubleshoot a script usually requires multiple iterations before the script works perfectly.  And this is especially true since nobody yet on the Internet has provided a good example for creating a VPN tunnel to a SonicWall over L2TP/Ipsec with a pre-shared secret and authenticating to the firewall instead of the domain controller.  Designing a script like this takes trial and error.  Adding a signing phase between each script attempt effectively means:  I’m not going to do this.

“Adding a signing phase between each script attempt effectively means:  I’m not going to do this.”

In short, this is why Microsoft PowerShell sucks.  If you have to sign scripts just to run them while testing then it’s not worth the effort.  Why not include a button in the PowerShell IDE which allows me to “Sign & Execute” my script attempt?  And if I don’t have a digital certificate then open a dialog box to gather the information to magically make this happen.  Or even better, just allow me to create and run scripts without all the nonsense.  How about a big toggle that says “Unsafe Mode” versus “Safe Mode”?

flogging a dead horse

Many times in my career I’ve been at some technical crossroads which demanded a decision on my part:

  1. stay the course with some primary skillset I’d been developing or
  2. branch off on some new expertise.

If you think about it, that’s a pretty big gamble.  What will hiring managers be looking for two or even five years in the future?  What will look better on your résumé, a couple more years of experience in the old skillset or the old skills plus the two years of the new skills?  Is it possible that continuing to work with the old skill will now somehow look bad for your career?  But then, if you include too many skills does it look like you’re not focused enough on anything to actually have expertise?

Recognize Trends

I’d suggest that the following trends are appearing in the development playing space.

  • Java is no longer trusted:  Oracle’s Java was a good idea back in the early ’90s.  It allowed coders to write one set of programming which could be compiled and then distributed and run on a variety of platforms.  Several security-related issues with Java have forced many to outright ban Java from workstations within organizations.  Apple’s Safari browser blocks the plug-in for Java now and Microsoft Internet Explorer in newer versions disables Java by default.
  • Objective-C is a pain:  Apple probably should have replaced this language when it introduced iOS.  Since it only really is used for Mac OS and iOS development, a coder’s skillset in this language limits them to just Macs, iPads, iPhones and the Apple Watch.
  • JavaScript is the new black:  Open source and Node.js have invigorated the JavaScript language.  In the past it was only really used for client-side browser validations and such but today, it’s being used for almost anything on the client or the server.  PhoneGap allows cross-platform phone app development in JavaScript, threatening to destroy all competitors in this space.  In Tolkienian terms, Javascript is the one ring to rule them all.
  • C and even C++ seem dated now:  C (circa 1972) and C++ (circa 1979) are wonderful languages and yet they’re over thirty years old and that makes them seem stale to coders today.  C# (circa 2000) is now over 15 years old and is beginning to feel the same fate.
  • .net is only for Windows:  Even though Microsoft had originally intended .net to compete with Java as a multi-platform coding option, you don’t see this in practice since nobody has worked on a UNIX .net platform to allow this to take place.  The trend would be that single-platform solutions don’t have enough market share to ultimately survive the test of time.
  • Every day there are more coders entering this space:  Schools globally have been pushing technical careers over the last three decades.  Outsourcing websites and better English training and translation software are allowing people in other countries to compete more effectively with U.S.-based coders.
  • It’s not just keyboards and mice anymore:  Hand-held devices, touchscreen monitors and see-through goggles may be the norm soon.
  • Apps and stores (not programs and major versions):  It used to be that a new version of a program was delivered and a major update cost money.  An app now usually comes with unlimited updates and yet “in app purchases” still allow a stream of money for the developer.  In fact, these updates allow the developer another marketing opportunity to up-sell the customer something else.  Apple has made so much money with iTunes that Microsoft has completely re-tooled their own operating system to chase that same business model.  Google has done the same with their Android platform.

See the Future

To me, the future of coding will embrace anything that will allow one set of (familiar) code to be compiled to multiple platforms.

  1. Until the next “new, new thing” comes along, it looks like Javascript (in general) is for now the core language to know.
  2. Some interesting things appear to be coming from the Javascript ECMAScript 6 (ES6) standard.  When a sufficient number of browsers support it, this new standard (specifically) should be another good skillset to have.
  3. Node.js has enjoyed an amazing degree of implementation throughout the world in its short lifespan.  Knowing how to code to this would be in your best interest.
  4. HTML5 has been used in a fair number of high-profile websites, enough to ensure its popularity for a few more years.
  5. The github source code repository has over 30 million individual repositories in place and has built-in support in many other systems which can pull code automatically from it.  It looks like github will be around for a while.
  6. Several popular languages will likely be effectively dead soon for a variety of reasons:  Java, Objective-C, Visual Basic, C, C++, .net and Swift to name a few.

Be the Future

If you want a job as a coder in the future it’s time to start actively steering in the right direction instead of just passively continuing to use the platforms you’re now on.  If you don’t have the skills I’ve listed above then consider taking on a project to learn one or more.

If you’re currently embedded on a team that uses Java, for example, then I’d suggest that it’s going to be increasingly harder to find work elsewhere. Given that it’s becoming harder to find coding work now with all the competition it’s more critical to possess the skills that managers are looking for on a team.