6 Ways to Determine a New Programming Language is a Turkey
People invent new programming languages all of the time. Some languages look terrible from the outset and you know to avoid them. Quite a few languages look like good (or at least usable) ideas but don’t work out later — often after you invested a lot of time in them. Only a few become great computer languages that perform useful tasks, from which you can also earn a living. This article tells how to choose the cream of the crop, as soon as possible.
Judging the value of a programming language requires a moment in which to review the basics: The purpose of a computer language is to provide a means for humans to communicate instructions to a computer system, which the computer then follows to perform a given task. As part of that communication, the human-readable language is translated into machine code.
Even if you use a Java Virtual Machine (JVM), Common Language Runtime (CLR), or a browser-based language, the tenets for languages are the same. Since the computer’s underlying language doesn’t change over time, the whole purpose of creating new languages is to enhance the human side of the equation. That is, programming languages exist to aid the wetware (the biological hardware and software used to create the application). Amidst discussions of semantics, features, libraries, and complex formulations, it’s easy to forget that the whole purpose behind a computer language is to make things simple, fast, and easy.
As a result of forgetting these simple principles, a few developers create languages that feed egos, rather than help other developers create good code. The result is a turkey language that really doesn’t help anyone do anything well. In this article I don’t point fingers at any specific language, nor do I suggest the language you’re using today is a turkey. I provide six questions you should ask yourself before you grab the latest language from the shelf and invest your time in learning it.
How does this language help me communicate?
I’m dating myself here, but my first computer application writing experiences involved a light panel into which I input individual bits that included instructions, memory locations, and data in machine code. It was a grueling way to write code. In fact, when I first saw Macro Assembler (MASM), I thought it was a gift from heaven because I could use it to communicate my ideas so much more quickly. Of course, MASM is considered archaic, difficult, and time consuming to use today; computer languages have taken a huge leap forward in usability and understandability.
The computer has no concept of language. All it understands is machine code (or hex, for hexadecimal). The purpose of using a computer language is to help you communicate ideas and concepts to the computer, ideally in a fast, easy, and simple manner. If you find yourself struggling to communicate with the computer, you’re using the wrong tool for the job. When someone suggests using a language because “the computer understands it better,” start looking anywhere else. A computer language is for humans, not for computers.
Does this language turn abstractions into concrete principles?
The reason that developers no longer write applications using machine code is that machine code is extremely abstract. Computers speak the language of math, they know nothing about data except numbers, and they understand very little about the data except its location in memory. (Also, they don’t like being anthropomorphized.)
A computer language should make it possible for you to express your ideas in a way that makes sense to you. This is why most languages today rely on object orientation: It turns abstractions into concrete concepts that humans readily understand. The better a new language performs this task, the easier it is for you to express your thoughts in a way that the language can translate into terms the computer understands.
The concepts of concrete and abstract are somewhat fluid, which is why a “one size fits all approach” doesn’t work for computer languages. Someone who writes database applications for a living has a different perspective of abstraction than someone who writes video games. Work through the ideas of “abstract” and “concrete” in light of the tasks you think you might perform using the proposed new-to-you language. For example, when working with browser-based applications, the idea of a canvas you use to draw on is quite inviting. Adding the concept of a canvas to a database management language would be fluff that could actually end up getting in the developer’s way; database management relies largely on form-based applications where a canvas isn’t needed.
Will this language be around tomorrow?
Human languages evolve to meet the needs of the community they support. Likewise, computer languages evolve to meet the needs of the application development community. Changes in usage, user expectations, hardware, and environment make changes necessary, so developers can better express how to handle each of these needs.
Many languages look great at the outset, but eventually die due to lack of support from the vendor who originated it or from the community that supports it. When a vendor (or sometimes a community—read, open source) orphans a computer language, it becomes much like Latin: a great idea that doesn’t evolve to meet the needs of its users. Even though many of Latin’s principles, concepts, and constructions are still around in the form of other languages, Latin itself is considered a dead language. You don’t want to base your business on a language that could be dead tomorrow due to a lack of support.
When selecting a new language created by a vendor, consider the vendor who supports that language. A strong vendor often translates into a strong language. Of course, there are exceptions to the rule, most of which are the language’s technical issues or due to lack of community support. However, without good vendor support, languages simply can’t succeed in many cases. Orphaned languages are like that roast turkey on the dining room table—possibly nice looking, but dead just the same.
Even though communities that support languages through the open source mechanism seldom orphan a language, it does happen. The language doesn’t quite go away completely, but it also doesn’t grow. Anything that doesn’t grow is dead, despite the fact that it hasn’t realized it has died. For example, despite the fact that I really like IronPython, I haven’t seen anything new for it in almost a year now. IronPython isn’t dead, but it isn’t breathing hard either.
Does the language have strong community support?
When choosing a new language, look around to see who’s talking about it. A computer language is only viable as long as people are discussing it, using it, and improving it. You should see new books written about the language and developers should create libraries for it as the language becomes accepted. (But don’t necessarily reject a new language because it lacks these things. Some things do take time.)
Vendors can try to push a computer language, but until the community supports the language, it won’t go anywhere. Developer communities use the language to create applications and to build relationships based on the tasks that it is best at performing.
Beyond identifying who’s talking about the language and how much help you can get from other developers, see what they’re saying and what sorts of questions other developers are asking. Look for potential problems from the outset, such as a perceived lack of vendor support or poor documentation. It’s also important to determine how the language is being used. If everyone’s saying what a great idea that language is, yet no one’s using it to create meaningful applications, you’re probably looking at a turkey.
How well is this language documented?
Many human languages ceased to exist because they lacked a written representation. People may enjoy using the language, but get frustrated without a way to record their thoughts.
Likewise, computer languages require good documentation. You can’t accurately record your thoughts in a coherent manner if you don’t understand the language or if its grammar is vague. Ideally, the language should have the backing of a standards organization that supports it and helps the language to grow in a community-based setting. However, even vendor-specific languages require great documentation to succeed.
When viewing documentation for a new computer language, look for these kinds of entries:
- Language Overview: The documentation should provide an overview of the language and its constituent parts so you can see how the language functions as a unit.
- Syntax: Each language element should provide a synopsis of its use, preferably in Backus–Naur Form (BNF), which is a precise method of describing syntax.
- Overall Description: Every language element should provide an overall description that tells you how that element is used and what purpose it serves.
- Argument Description: Each of the arguments, both required and optional, should have a complete description including any data type requirements for the argument.
- Example Code: The best documentation provides a simple, concise example as an overview. It then provides more detailed examples showing how to use various arguments and the data returned as a result of making a call.
- Feedback Options: The language owner (vendor, standards committee, etc.) needs to provide some means for allowing feedback. It’s nearly impossible to create perfect documentation without the help of the community.
When will I use this language to perform useful work?
If a language doesn’t meet your needs, it doesn’t matter how well the language is designed or how elegantly it’s presented; you simply can’t use it. A computer language should translate your ideas—not someone else’s.
It’s at this point where your turkey language may be someone else’s gem. Answering this particular question is incredibly hard because it’s difficult to know just how you’ll use a language when you first start using it. A good place to start is by creating simplified versions of applications you already created in an older, more-familiar language, using the new language. You don’t want to create a full application until you know a little more about the language, but you also want to make your test as real world as possible. If you rewrite an older application in a new language, you should gain a sense of what might have been easier – or harder.
As your understanding of computer science grows and the kinds of applications you create changes, you need to explore new languages as well. New languages help you communicate your thoughts in concrete terms and in an efficient manner, ultimately saving you time and resources.
When you find a new language that meets your needs, it can feel like pure heaven creating applications with it. Avoid computer language turkeys that slow you down and make it frustrating to create useful applications.