Showing results for 
Search instead for 
Did you mean: 
Create Post

New Coder: Which Language Is The Right One?

Level 13

To paraphrase a lyric from Hamilton, Deciding to code is easy; choosing a language is harder. There are many programming languages that are good candidates for any would-be programmer, but selecting the one that will be most beneficial to each individual need is a very challenging decision. In this post, I will attempt to give some background on programming languages in general, as well as examine a few of the most popular options and attempt to identify where each one might be the most appropriate choice.

Programming Types and Terminology

Before digging into any specific languages, I'm going to explain some of the properties of programming languages in general, because these will contribute to your decision as well.

Interpreted vs Compiled


An interpreted language is one where the language reads the script and generates machine-level instructions on the fly. When an interpreted program is run, it's actually the language interpreter that is running with the script as an input. Its output is the hardware-specific bytecode (i.e. machine code). The advantages of interpreted languages are that they are typically quick to edit and debug, but they are also slower to run because the conversion to bytecode has to happen in real-time. Distributing a program written in an interpreted language effectively means distributing the source code.



A compiled language is one where the script is processed by the language compiler and turned into an executable file containing the machine-specific bytecode. It is this output file that is run when the script is executed. It isn't necessary to have the language installed on the target machine to execute bytecode, so this is the way most commercial software is created and distributed. Compiled code runs quickly because the hard work of determining the bytecode has already been done, and all the target machine needs to do is execute it.


Strongly Typed vs Weakly Typed

What is Type?

In programming languages, type is the concept that each piece of data is of a particular kind. For example, 17 is an integer. John is a string. 2017-05-07 10:11:17.112 UTC is a time. The reason languages like to keep track of type is to determine how to react when operations are performed on them.

As an example, I have created a simple program where I assign a value of some sort to a variable (a place to store a value), imaginatively called x. My program looks something like this:

x = 6
print x + x

I tested my script and changed the value of x to see how each of five languages would process the answer. It should be noted that putting a value in quotes (") implies that the value is a string, i.e. a sequence of characters.John is a string, but there's no reason678" can't be a string too. The values of x are listed at the top, and the table shows the result of adding x to x:


Weakly Typed Languages

Why does this happen? Perl and Bash are weakly (or loosely) typed; that is, while they understand what a string is and what an integer is, they're pretty flexible about how those are used. In this case, Perl and bash made a best effort guess at whether to treat the strings as numbers or strings; although the value 6 was defined in quotes (and quotes mean a string), the determination was that in the context of a plus sign, the program must be trying to add numbers together. Python and Ruby, on the other hand, respected 6 as a string and decided that the intent was to concatenate the strings, hence the answer of 66.

The flexibility of the weak typing offered by a language like Perl is both a blessing and a curse. It's great because the programmer doesn't have to think about what data type each variable represents, and can use them anywhere and let the language determine the right type to use based on context. It's awful because the programmer doesn't have to think about what data type each variable represents, and can use them anywhere. I speak from bitter experience when I say that the ability to (mis)use variables in this way will, eventually, lead to the collapse of civilization. Or worse, unexpected and hard-to-track-down behavior in the code.

That Bash error? Bash for a moment pretends to have strong typing and dislikes being asked to add variables whose value begins with a number but is not a proper integer. It's too little, too late if you ask me.

Strongly Typed Languages

In contrast, Python and Ruby are strongly-typed languages (as are C and Go). In these languages to add two numbers means adding two integers (or floating point numbers, aka floats). Concatenating strings requires two or more strings. Any attempt to mix and match the types will generate an error. For example in Python:

>>> a = 6
>>> b = "6"
>>> print a + b Traceback (most recent call last):   File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Strongly typed languages have the advantage that accidentally adding the wrong variable to an equation, for example, will not be permitted if the type is incorrect. In theory, it reduces errors and encourages a more explicit programming style. It also ensures that the programmer is clear that the value of an int(eger) will never have decimal places. On the other hand, sometimes it's a real pain to have to convert variables from one format to another to use its value in a different context.

PowerShell appears to want to pretend to be strongly typed, but a short test reveals some scary behavior. I've included a brief demonstration at the end in the section titled Addendum: PowerShell Bonus Content.

Dynamic / Statically Typed

There's one more twist to the above definitions. While functionally the language may be strongly typed, for example, it's possible to allow a variable to change its type at any time. For example, it is just fine in Perl to initialize a variable with an integer, then give it a new value which is a string:

$a = 1;
$a = "hello";

Dynamic typing is typically a property of interpreted languages, presumably because they have more flexibility to change memory allocations at runtime. Compiled languages, on the other hand, tend to be statically typed; if a variable is defined as a string, it cannot change later on.

Modules / Includes / Packages / Imports / Libraries

Almost every language has some system whereby the functionality can be expanded by installing and referencing some code written by somebody else. For example, Perl does not have SSH support built in, but there is a Net::SSH module which can be installed and used. Modules are the easiest way to avoid reinventing the wheel and allow us to ride the back of somebody else's hard work. Python has packages, Ruby has modules which are commonly distributed in a format called a "gem," and Go has packages. These expansion systems are critical to writing good code; it's not a failure to use them, it's common sense.

Choosing a Language

With some understanding of type, modules and interpreted/compiled languages, now it's time to figure out how to choose the best language. First, here's a quick summary of the most common scripting languages:

C / ITypeS / DExpansion
PowerShellInterpretedIt's complicatedDynamicModules

I've chosen not to include Bash mainly because I consider it to be more of a wrapper than a fully fledged scripting language suitable for infrastructure tasks. Okay, okay. Put your sandals down. I know how amazing Bash is. You do, too. will



Ten years ago I would have said that Perl (version 5.x, definitely not v6) was the obvious option. Perl is flexible, powerful, has roughly eleventy-billion modules written for it, and there are many training guides available. Perl's regular expression handling is exemplary and it's amazingly simple and fast to use. Perl has been my go-to language since I first started using it around twenty-five years ago, and when I need to code in a hurry, it's the language I use because I'm so familiar with it. With that said, for scripting involving IP communications, I find that Perl can be finicky, inconsistent and slow. Additionally, vendor support for Perl (e.g. providing a module for interfacing with their equipment) has declined significantly in the last 5-10 years, which also makes Perl less desirable. Don't get me wrong; I doubt I will stop writing Perl scripts in the foreseeable future, but I'm not sure that I could, in all honesty, recommend it for somebody looking to control their infrastructure with code.



It probably won't be a surprise to learn that for network automation, Python is probably the best choice of language. I'm not entirely clear why people love Python so much, and why even the people who love Python seem stuck on v2.7 and are avoiding the move to v3.0. Still, Python has established itself as the de facto standard for networking automation. Many vendors provide Python packages, and there is a strong and active community developing and enhancing packages. Personally, I have had problems adjusting to the use of whitespace (indent) to indicate code block hierarchy, and it makes my eyes twitch that a block of code doesn't end with a closing brace of some kind, but I know I'm in the minority here. Python has a rich library of packages to choose from, but just like Perl, it's important to choose carefully and find a modern, actively supported package. If you think that semicolons at the end of lines and braces surrounding code make things look horribly complicated, then you will love Python. A new Python user really should learn version 3, but note that v3 code is not backward compatible with v2.x, and it may be important to check the availability of relevant vendor packages in a Python3-compatible form.



Oh Ruby, how beautiful you are. I look at Ruby as being like Python, but cleaner. Ruby is three or four years younger than Python, and borrows parts of its syntax from languages like Perl, C, Java, Python, and Smalltalk. At first, I think Ruby can seem a little confusing compared to Python, but there's no question that it's a terrifically powerful language. Coupled with Rails (Ruby on Rails) on a web server, Ruby can be used to quickly create database-driven web applications, for example. I think there's almost a kind of snobbery surrounding Ruby, where those who prefer Ruby look down on Python almost like it's something used by amateurs, whereas Ruby is for professionals. I suspect there are many who would disagree with that, but that's the perception I've detected. However, for network automation, Ruby has not got the same momentum as Python and is less well supported by vendors. Consequently, while I think Ruby is a great language, I would not recommend it at the moment as a network automation tool. For a wide range of other purposes though, Ruby would be a good language to learn.



PowerShell – that Microsoft thing – used to be just for Windows, but now it has been ported to Linux and MacOS as well. PowerShell has garnered strong support from many Windows system administrators since its release in 2009 because of the ease with which it can interact with Windows systems. PowerShell excels at automation and configuration management of Windows installations. As a Mac user, my exposure to PowerShell has been limited, and I have not heard about it being much use for network automation purposes. However, if compute is your thing, PowerShell might just be the perfect language to learn, not least because it's native in Windows Server 2008 onwards. Interestingly, Microsoft is trying to offer network switch configuration within PowerShell, and released its Open Management Infrastructure (OMI) specification in 2012, encouraging vendors to use this standard interface to which PowerShell could then interface. As a Windows administrator, I think PowerShell would be an obvious choice.



Go is definitely the baby of the group here, and with its first release in 2012, the only one of the languages here created in this decade! Go is an open source language developed by Google, and is still mutating fairly quickly with each release, as new functionality is being added. This is a good because things that are perceived as missing are frequently added in the next release. It's bad because not all code will be forward compatible (i.e. will run in the next version). As Go is so new, the number of packages available for use is much more limited than for Ruby, Perl, or Python. This is obviously a potential downside because it may mean doing more work for one's self.

Where Go wins, for me, is on speed and portability. Because Go is a compiled language, the machine running the program doesn't need to have Go installed; it just needs the compiled binary. This makes distributing software incredibly simple, and also makes Go pretty much immune to anything else the user might do on their platform with their interpreter (e.g. upgrade modules, upgrade the language version, etc). More to the point, it's trivial to get Go to cross-compile for other platforms; I happen to write my code on a Mac, but I can (and do) compile tools into binaries for Mac, Linux, and Windows and share them with my colleagues. For speed, a compiled language should always beat an interpreted language, and Go delivers that in spades. In particular, I have found that Go's HTTP(S) library is incredibly fast. I've written tools relying on REST API transactions in both Go and Perl, and Go versions blow Perl out of the water. If you can handle a strongly, statically typed language (it means some extra work at times) and need to distribute code, I would strongly recommend Go. The vendor support is almost non-existent, however, so be prepared to do some work on your own.


There is a lot to consider when choosing a language to learn, and I feel that this post may only scrape the surface of all the potential issues to take into account. Unfortunately, sometimes the issues may not be obvious until a program is mostly completed. Nonetheless, my personal recommendations can be summarized thus:

  • For Windows automation: PowerShell
  • For general automation: Python (easier), or Go (harder, but fast!)

If you're a coder/scripter, what would you recommend to others based on your own experience? In the next post in this series, I'll look at ways to learn a language, both in terms of approach and some specific resources.

Addendum: Powershell Bonus Content

In the earlier table where I showed the results from adding x + x, PowerShell behaves perfectly. However, when I started to add int and string variable types, it was not so good:

PS /> $a = 6
PS /> $b = "6"
PS /> $y = $a + $b
PS /> $y 12

In this example, PowerShell just interpreted the string 6 as an integer and added it to 6. What if I do it the other way around and try adding an integer to a string?

PS /> $a = "6"
PS /> $b = 6
PS /> $y = $a + $b
PS /> $y 66

This time, PowerShell treated both variables as strings; whatever type the first variable is, that's what gets applied to the other. In my opinion that is a disaster waiting to happen. I am inexperienced with PowerShell, so perhaps somebody here can explain to me why this might be desirable behavior because I'm just not getting it.


This truly qualifies in the "Geek Speak" realm.

The language you know best is the one to use--except if there's something else you could learn that will do the job better.


Level 13

*grin* True up to a point, so long as the language you know best also supports what you need to do. On the other hand, if you aren't currently familiar with a language and are starting from a clean slate, so to speak, what's the right one to choose? Obviously I have my opinions as stated above, but to echo your sentiment, it doesn't mean I'm *right*, because, well, what's right for me may not be right for somebody else...

I agree, putting the geek in geek speak this week. Really enjoyed, and shared with the team.


Wonderful, good article

I am inexperienced with PowerShell, so perhaps somebody here can explain to me why this might be desirable behavior because I'm just not getting it.

I think they let you treat six as both a string or an integer because you might need to send it to a destination as one or the other. Obviously the integer value of 6 is used anytime you do math, but if you are writing a log entry into a database that likely requires you to pass it a string. If $x =6 and $status = 'Down' you might build your log entry string with $LogLine = "Item "+$x+" is: "+$status Which may work, but may not depending on how you got that $x in teh first place. You could force the $LogLine to convert it by casting like this [string]$logLine or you force the output $x.toString() or take that String you parsed from a text file and force powershell to do math on it as a number$x.ToUInt32($null).

Basically Powershell wants to be able to convert your datatype to what you want when you want it, so it allows you to store it in anyway you set it. It can confuse you, but normally it won't bother you.

As for what language a beginner should start with, I say Powershell for Windows admins in a must, and python for everything else. I learned both.


regardless of how a particular language processes data types, you as the coder must be aware and make sure any conversion is done as required by the application or provide for an exception.


I have more respect for those that do actual coding rather than those that just use a tool to drag a box from one side of the screen to another and let the software build it's "spaghetti code" in the background. Now I know both methods take skill and discipline, but . . .

Level 20

A little flashback to my CIS undergrad!  I would have included C and/or C++.  You're right about compiled languages... in the long run compiling is the best and most efficient but for little short things interpreted can be fine.  In addition to using a compiler you can further improved performance using a profiler.

Level 14

And blogs like this are EXACTLY why I'm sticking to infrastructure!!! 

Level 13

Thank God I took the one less traveled into the infrastructure side.  Giving up programming alone time ago.

Level 13

Thanks for the information, @jm_sysadmin! I know you can force types on the variables and convert them as needed, but your examples and explanation are very much appreciated! Part of the problem - and PS is by no means unique here - is the use by some languages of "+" as a concatenation operator for both strings and numbers. I actually appreciate that Perl for example uses "." for string concatenation, as it makes it explicitly clear what you want to do, e.g.:

$a = 6;

$b = "6";

$y = $a . $b; # gives "66"

$y = $a + $b; # gives "12"

In a statically-typed language, using + doesn't matter, as you can't add an integer to a string, nor concatenate the two without explicitly casting to another type. Ah well. Gotta love decisions about how to best guess the user's intent!

Level 13

This is very true, and I think the more time spent coding in a language, the more we're likely to understand the importance of doing so.

What concerns me I guess is that newer users may not be thinking about data types, and rather than the interpreter saying "Hey, what you've asked me to do is ambiguous; can you clarify?" it plows on regardless. In the example I gave with 12 vs 66, there's no error raised, so that potentially incorrect answer will be used after that point within the program. In my experience, that kind of error (the kind that doesn't raise an error), can be really nasty to track down... Now, if we will all just follow your advice, we can avoid this problem!

Level 13

Baby steps perhaps? Have you ever played with Lego Mindstorms? The standard programming interface is exactly as you describe - dragging boxes around and letting the program build the code for you. On the other hand, it's not magic; if you can't figure out the logical steps and conditions in order to decide what action(s) to take, dragging the boxes around won't get you very far. I say Mindstorms is pretty good for teaching basic conditionals and loops and the like, but I do get what you're saying

Level 13

I did debate including C/C++, but the levels of pain that would inflict... I mean, wow. 🙂

Level 13

*lol* It sounds far worse than it really is 😉

Level 13

*lol* Look at it this way: it's just another set of arbitrary things to try and remember. The nice thing is that some of those things are kind of natural; if I were to ask you what the answer was to "6 + cat" you'd stare at me much as some interpreters/compilers would report an error to you. And anybody who specializes in storage, for example, should be looking at this and muttering "meh, trivial" in comparison to the day job 😉

Having never received receiving training for this, I'd much rather be fishing.  It's WAY less complex (after having done it for fifty years), and it can be pretty good for the mental health, too.


I suppose one could say we learn computer programming languages to facilitate our ability to fish when/how/where we'd like.  Program correctly, collect the pay check, get out to the water (or name your favorite hobby) as soon as one can.

Level 13

Live to Work vs Work to Live? I would imagine that both fishing and programming share periods of time spent staring blankly into the distance. Does that count? 😉

Maybe . . .   If staring into the distance while programming enhances one's mental health, the way it does for me while fishing.

As long as that programmer's stare doesn't end up like a Google Images search for "thousand yard stare wwii".

Level 13

Well, if you're going to put all these fancy conditions on it then, um, probably not. *grin*

So here's where this is a bit more interesting.

If you do:

$a = 6

$b = "6"

and then check the types on each variable, $a is an Int32 and $b is a string.

If you then do $a+$b you will get a result of 12 (resulting object is an Int32), and if you do $b+$a you get 66 (resulting object is a string).

So it's not the order that you define the variables in that matters, it's the order you put them in the pipeline.

Level 13

Sorry if I was ambiguous above when talking about the "first" variable, but yes, that's what I was referring to. In the equation $y = $a + $b, $b will be interpreted as the same type as $a. I simply chose to redefine the variables the other way around rather than changing to $y = $b + $a (which may have illustrated my point more clearly!). Thank you for the clarification!

Level 16

I don't know about less complex?.... after 40 years I'm getting worse at tying these. Is it just my eyes or are the hooks shrinking?


Maybe both.  All I know is jigs that used to cost $.15 at the tackle shop now costs $3.95 or more.  Rapala's that were $.95 are now $8.95.  Tiny teardrop ice fishing jigs were $.03 apiece, and now they're a buck ore more. 

That's a hard pill to swallow.  It's also one of the drawbacks of living a long time and remembering what prices used to be when I was a little kid.

On the other hand, I can afford a lovely Walleye / Ski boat now, where I couldn't afford a Bass-Buster Beetle-Spin back in the '60's without having to save my pennies.  Maybe the problem with remembering is not keeping ALL current conditions in mind--like the change in income between a grade school kid's allowance and an I.T. person's salary (who's married to another I.T. person).

Level 16

Back in the day all I could afford was a pair of waders and a cheap flyrod. I still have both of them. The waders have several patches of goop on them but still stay dry and the flyrod is still in service with the 1911 Fluger reel that one of my friend gave me 30 years ago. SInce that time I also was able to own a lot of boats and high end fishing toys but I still get the most fun out of hitting a stream and hooking into a steelhead or salmon with my old tackle




I used to buy packets of the beetle spins and sassy shads back in high entertainment at the local small lake.

Couple that with a cheap light action rod and spinning reel made for hours of fun.  Used to go fishing almost everyday after school except for rainy days and most of winter although the best catch was in January one year.

Level 13

So, speaking of putting the geek in geek speak... I understand about 1 in 3 words of the above comments, but it sounds pretty cool 😉

Level 14

Terrific article jgherbert​.

I am a Powershell user ... (basic), but after reading this I might take a look at GO...

Thanks for sharing!

Level 14

Ok, so I mentioned above I'm glad to be an infrastructure nerd, so I don't have to worry about my eyes crossing from looking at code all day. HOWEVER, all things evolve, and I was forced to evolve after attending a local "Cisco Connect" event yesterday. Best thing outside of CiscoLive! I was told by several engineers that the integrated APIs Cisco is putting in all the OSs will be best automated by learning Python.

So, for all the old school CLIs folks and for SolarWinds Dev...we need to be learning and using Python to get MAXIMUM benefits from tools and integrations. UGH! just when I thought it was safe to go back in the water!


Level 16

Here are some fishing terms for you:

This is a JitterBug


This is a BitterJug


Both are used for fishing! Both end up in the lake eventually.

Level 13

It's over my head...what happened to C+, C++, C# and VB?

Very impressive article. This is very useful even for non-coders like myself. I hear Python, Go, Powershell, and have a vague understanding of what their sweetspot is. This article has educated me. Thanks.

Great question. My IT techy heyday was during these languages. What happened?