When faced with a new tech project, the choice of programming language always comes into question. What is the best language and why?
All computers run machine language. This is a set of numbers that represent actions, registers, etc. The closest language to this is assembly language. Assembly language is very fast and prone to mistakes that can crash things. New developers make terrible assembly language programmers but experts can work wonders in it. Assembly language represents everything a processor is capable of. Unfortunately each type of chip has its own version. Even when they use the same standard, different manufacturers have custom extensions.
Some projects only run on a single computer or type of computer. These projects can be coded in assembler. It takes about twice as long to write assembly language than a higher level language. Since programming typically involves about half of a software project’s time, this means a project takes 50% longer. You end up with smaller code that runs surprisingly fast. This works great for dedicated machines running a single task, including any embedded processor. For most other projects it fails. Assuming the project is written and has no bugs, one must keep in mind that requirements and people always change. This means the new developers have to update the code. The odds of them being good in assembler are very low. This means they’ll try and probably mess things up. In assembler, it’s easy to mess up royally. Then the next large problem appears. Suppose the hardware becomes obsolete and must be replaced, but the new computer no longer supports the old assembly language. This would require either significant time to update the software or a complete rewrite.
Higher level languages fix the problem of changing chips. (Higher level means looking from a higher altitude. Higher level means more general and less specific.) Higher level languages provide a stable set of instructions that translate into many different kinds of assembly language. It’s also a safer programming environment, so newbies have less chance of producing a catastrophic error. Programmers can produce code faster so projects are less expensive, or at least this is theoretically correct. In reality, the only programmers who enjoy assembler are really good at it. This means they can program in assembler faster than other programmers write in a higher level language. That, and newbies write terrible code regardless of their language. However writing code in a higher level language is theoretically faster. Truthfully, the reason to go with a high level language over assembler is that it’s portable and easier to maintain.
Higher level languages are limited to a set of common hardware features. For example, if you are working in Intel chips then it’s impossible to check the flags in C without using inline assembler. (Flags are a set of bits that are set on or off after many instructions, to note additional information about the last instruction.) Not all chips have flags, so these features just aren’t available in c. This makes it difficult to determine if you have issues like rollover when adding integers. This is the first limit of higher level languages. The next major limit is that every language just converts everything into assembler. This means a high level language adds nothing to what a programmer can achieve. In fact, higher level languages limit rather than expand what’s possible.
Limits are key to higher level languages. Each language makes some things harder and other things easier. Certain tasks are impossible to do in some languages but are exceedingly simple in others. Your first task is to decide what your project requires. If you need low level but portable code then c or c++ is best. If you are building a webpage then JavaScript is your language. If you are building an iPhone app then use Swift.
Next consider the language output. If you need extremely fast code, something that’s really well optimized, you’ll need a language that compiles. For code that’s run infrequently, interpreted is an option. An interpreted language uses an engine that reads through the text of the code. It identifies statements, expressions and functions then executes them. Compiled languages convert programming instructions into assembler and then into machine language. The processor runs these commands natively, making them very fast. Originally these were the only two options. Later, pseudo-compilers were made for interpreted languages, so they are converted into a form that’s faster to execute. Compiled, pseudo-compiled and interpreted are your options.
Most programmers won’t look at requirements, they’ll just tell you to use a language they are familiar with. It’s human nature to stick to what we already know. Experienced programmers will have used so many different languages that learning a new one is easy. Typically though, good languages have been around a long time and are mature. There is rarely a need to venture into newer languages.
If the project uses embedded computers, such as a microwave or stove, assembler is a good option. If the program runs extremely fast and uses little memory then it can use a slower and cheaper processor. Although it costs a little more to program, it costs less to manufacture so it saves money overall. For web server projects it depends on your server OS. If you use Linux, PHP is a good choice. For windows, you can use PHP too or you can use C#. For website projects, JavaScript is a good choice. (Avoid the bloated libraries that run on JavaScript and just use native JavaScript.) C# or VisualBasic used to be common for desktop applications. Unfortunately .net turned desktop applications into an inheritance nightmare. That’s why many desktop applications, such as business software, now use a web server and browser. Phones have their own preferred language and development environment. It typically works best if you use their preferred approach. Everything else needs to be carefully analyzed and an appropriate language selected.
In addition to normal programming languages, sometimes other languages exist. For example, relational databases normally implement an SQL (Structured Query Language) engine. SQL is its own language and it’s geared around querying relational information. It’s a language though, and programmers are reluctant to learn new languages, so they often create libraries to access databases. These libraries are written in a way that more closely resembles a programmer’s mindset. The term ORM (Object-Relational Mapping) is applied to them. They are, at best, a pale imitation of SQL. SQL was designed to work with relational databases, which means it’s very suitable for it. This example brings up the situation of multiple languages within the same project. This is very common and can be very beneficial. A web project, for example, often has code that runs on the server written in one language then code in the webpages written in another language. Each language has its place and use, even if that language is meant to be used to access another application.
New languages constantly appear. Many are horrible and die soon afterwards. Some persist and try to fill a hole that doesn’t exist. If a language doesn’t fill a new hole, but instead tries to do what established languages already do, these languages usually die out. There is a trend towards higher level languages, but these trends ultimately fail. Languages that are too high run into the framework issue. When you use a framework, you’re limited to what the framework does well. Life rarely fits into boxes and there are always situations that fall outside. While working around language/framework limitations is sometimes possible, it often takes far more work than creating the application in a more flexible language. The higher level the language or framework, the less flexible it becomes. Languages are always a balance between flexibility and limitations. Another problem with using a new language is you don’t know how long it will last. A well established language will probably remain for many decades to come while a new language may be abandoned. Applications written in an abandoned language must then be reprogrammed in another language.
When choosing a language, consider the project and its needs. Determine the level of language that fits the project, whether it is compiled or interpreted and select a language or set of languages that fit. Choosing the right languages can simplify a project, make it more supportable and give it longevity.