One thing that developers love to argue about is which languages are the best, and the one thing that they love to argue about more than which language is the best is which *kind* of language is the best.
Take, for example, dynamically typed languages versus languages that are statically typed at compile time. With the former, the interpreter or OS infers the type of a variable at run time, while with the latter the developer explicitly states the type (or supertype) of an object in the code itself. Developers will argue for hours over which is better, and for good reason; this distinction has big implications for how a system will be developed, maintained and integrated.
But of course, the correct answer to ‘which is best’ is whatever language lends itself to the task at hand.
Consider a piece paper (and yes, this is going to be an analogy, how could you tell?). Is there anything so full of promise, so resplendent in untapped possibilities as a blank sheet with a pen next to it? Even in an office, where bits of paper rule supreme (as it’s inexplicably still the 70’s in this scenario), a blank sheet of paper lends itself to new, dynamic and quickly evolving ways of working. Need a specific and novel memo to send to Janice in accounts? Just write down what you’re thinking, send it over and so long as she can read your writing it’s all good. Need to add some contextual information to a quote? The quote’s a letter to the client’s CEO; just get your secretary to include the info in write up. As long as there is a shared understanding between members of the team and everyone gets the gist of how it all hangs together, the office can work and evolve without having to get bogged down in its own workings.
Things start to unravel, though, when the office grows out of its little niche. Maybe it expands in size, maybe it fragments into smaller offices each with their own teams, maybe it has consultants in, or has to start producing paperwork that needs to be circulated around the wider company. In this scenario hand written notes or letters, without any agreed formal structure between the parts of the office, are going to be difficult to work with. The receiver of a memo might not know if it’s a quote, invoice or receipt; that note that made sense to Janice in accounts, with whom you have a close working relationship, might not make so much sense to the contractor brought in three years later to do an audit.
So you start to introduce forms; structured documents or templates. The invoice is marked as such; memos to accounts, inventory etc have tick boxes, places to write context etc. Everything is ordered by design, and the decision about what each document is and how it should work within the context of the wider office is detailed upfront by the people designing the system (which is what an office is). This makes it easier for, say, the office to on-board new people, for the paperwork to be shared with other offices (especially if you are all working from the same set of templates) and for new workflows between offices to be specified and designed (including new templates!). What’s there not to love?
But, of course, it all starts to go wrong. Structural complexity tends to beget more structural complexity; as the office grows in scope, new types or sub-types of templates need to be created, the formalism (in particular the need to declare up-front the exact kind of document is going to be used in each case) begins to weigh down the evolution of the office and the development of the wider workflow across the company. Soon you’re going to be holding three hour meetings to agree on a hierarchical naming scheme for templates with the same base template, rather than actually building something new.
So either way has its own benefits and drawbacks. The ‘blank paper’ office can develop new ways of working quicker, and is generally more free flowing and fun to work in. The more ‘form based, structured’ office can work better within wider scopes and across contexts that have other offices or teams that the first office might not even know exist.
Conversely, a blank paper office requires a shared understanding between those who are working in it as they develop the business, and can get very messy without that, thus limiting its scope, while a more form based, defined office system can start to collapse under its own structure.
So the question is, what kind of office are you creating? Is it limited in scope? Is it ‘try something out and see if it fails’? Is it part of a bigger enterprise? How many external parties are going to be participating in it? And so on…
You’ve probably guessed that the blank paper office is represents dynamically typed languages, while the ‘formal, template based’ approach is for statically typed languages (not perfectly in either case, I may add; dynamic languages are still formal, and there’s a lot of liquidity in all languages including statically typed ones).
I think dynamically typed languages excel in developing quick, highly iterative applications of limited scope with a small team of developers with a shared understanding of what is being passed where. I could not imagine writing a large enterprise size system with Python or Ruby (not without an existing ‘on rails’ framework, which kind of proves my point anyway).
The main benefit to statically typed languages for developers that I can see is that it takes a lot of the knowledge of ‘what goes where’ out of the developers head and puts it in the code. It also helps with the enforcement of what can go where, and the communication of what a class is for and how it works. This is critical if you are working on enterprise scale software that may encompass many teams across several years; indeed, I believe that is why languages such as Java were developed to allow developers be so specific (I’m looking at you, ‘checked/unchecked exception’ distinction*), to facilitate the development of the enterprise grade monoliths we were building twenty years ago.
(The fact that we have now shifted towards micro-services and serverless code is telling in itself, and should also be a factor in language selection; when the ins-and-outs of a unit of business logic are defined in terms of JSON messages rather than objects, the benefits of a statically typed language are less).
Anyway, opinions aside, it’s very important to think about what you are building and how you are building it before choosing a language; nobody likes having to trace through dozens of python files to figure out what’s being passed into a method, and nobody likes going through a code review argument about exactly how a Java generic is defined.
Until next time, stay safe!
Javantis 