Professional Development

Learning From Other Languages

Even if you only write code professionally in a single language, learning the concepts and idioms of other languages will make you a better programmer.

Mike Wolfe

Nov 17, 2022 • 4 min read

One of the best ways to grow as a software developer is to learn multiple languages.

The key is to learn not just the syntax of the language, but how to think in that language. Programming languages have certain idioms and best practices that vary from one to another. For example, error handling in VBA is much different than exception handling in .NET which is much different than returning errors in Go. If you understand the pros and cons of each approach, then you can import that thinking into your "native" language in those places where it makes sense.

Here are a few examples from this blog to whet your appetite:

Python-Inspired Doc Tests

[Doc tests] support the concept of verifiable documentation. You write usage examples alongside your function. You can then run tests against those examples to verify they are correct.

Read more here.

LINQ-Inspired Fluent Interfaces

A "fluent interface" is one which uses method-chaining to call multiple object methods on a single line. This can be used to create a very compact syntax.

Say we want to add a label to a form. We want this label to be two inches wide, bold, italicized, with a 14-point Segoe UI font. Here's how we would do this using a With ... End With block:

With CreateControl(CtlName, acLabel)
    .Caption = "My Label"
    .Width = 2 * TwipsPerInch
    .TextAlign = 2 'Center
    .FontSize = 14
    .FontName = "Segoe UI"
    .FontBold = True
    .FontItalic = True
End With

Here's how we might do the same thing using a class that implements a fluent interface:

fb.AddLabel("My Label").Width(2).Center.Size(14).Font("Segoe UI").Bold.Italic

Read more here.

Perl-Inspired Regular Expressions

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Regular expressions are kind of like recursion for most programmers.

Mind-boggling at first.

Then a period of, "I sort of get it, but when would I ever actually use this?"

Followed by the first time you stumble upon an otherwise intractable problem where it offers an elegant solution.

After which, you hoist your shiny new hammer above your head, bellow to the heavens, "THERE CAN BE ONLY ONE!" and stride off in search of more nails (or anything that even vaguely resembles a nail).

Until finally, with a cascade of snapped screws and bent bolts in your wake, you place the now-rusting hammer in your toolbox where it belongs.

Read more here.