Choosing the Right Programming Language

When starting a new software project the language chosen can be key to the success or failure of the project. Often times the language that gets chosen gets little to no attention, and the “default” language of the individual or group gets used.

We are not going to look at any specific programming language; we are going to walk through a list of language properties that can inform the choice of a programming language for a specific project.

The goal of this talk is to get you to think of a programming language as a set of features and properties, then match those properties to the task at hand to choose the programming language.

Transcript

1. Lloyd Moore, President Lloyd@CyberData-Robotics.com www.CyberData-Robotics.com Choosing The Right Language (for your project)
2. Introduction: When starting a new software project the language chosen can be key to the success or failure of the project. Often times the language that gets chosen gets little to no attention, and the “default” language of the individual or group gets used. We are not going to look at any specific programming language; we are going to walk through a list of language properties that can inform the choice of a programming language for a specific project. The goal of this talk is to get you to think of a programming language as a set of features and properties, then match those properties to the task at hand to choose the programming language. A bit of background: The idea for this talk came from a “Comparative Languages” class I took in college, found to be VERY helpful in my career, and have heard little mention of in general industry.
3. Language Properties:  General vs Domain Specific  Language Class or Genus  Translation method  Memory safety and management  Thread safety and management  Industry standards and norms  Company familiarity (staff and processes already available)  Community support  Use in “regulated environments” (medical, automotive, aerospace, government)  Portability  Automated tooling  Execution environments (dev, test, production)  Production status
4. General vs Domain Specific: Many languages are “domain specific” and to such a degree that we don’t typically think of them in terms of having much of a “language choice”, ie:  SQL for database access  HTML/CSS for web pages  VHDL/Verilog for circuit design  Cmake for build systems  QML for Qt based forms design For many of these cases the “default” is simply the right way to go as the support and tooling is highly geared to solving a very narrow problem in a very specific way. One question to ask: For the project being built is there value in creating a new domain specific language?
5. Language “Class” or “Genus” The way a language is formed can have a huge impact on how easy it is to solve specific types of problems with that language. In particular: What is known at compile time? What is explicitly stated and what is left to the run time to “figure out”? Does the “form” of the language naturally map to the problem domain?  Procedural – ie: Fortran, C: Simple and have been around for ages  Object Oriented – ie: C++, C#: Map well to modeling complex objects  Declarative – ie: SQL, QML: Specify WHAT to do not HOW to do it  Functional – ie: Haskell, Lisp: Advantages for reliability, scientific apps  Others such as: Logic, Reactive, Aspect Oriented, Dataflow, Stack, Constraint If the problem you are trying to solve “naturally” fits into a specific language “class” or “genus” it is typically best to choose a language from that group.
6. Translation Method The way a language is translated creates constraints:  What must be expressed during development vs run time  Run time performance  Real time limitations  Start up performance  Executable and execution environment size Compiled vs Interpreted:  Trades “work” done during development with “work” done at run time  Trades knowledge specified during development with flexibility at run time  Trades determinism during during development with flexibility at run time  Shifts “environment complexity” between development and run time JIT:  Provides various “best of both worlds” AND “worst of both worlds” scenarios.
7. Memory Safety and Management Programming languages are built upon an “execution model” or “machine model”. A key aspects of the model is how memory is represented and managed. Most use a simple “flat” memory model these days and we’ll stick to that, but do want to note others such as “transactional”, “banked”, “paged”, etc. Manual Memory Management:  Most flexible and required in some areas (low level hardware access)  Most error prone, least safe  Best performing, and most deterministic Reference Counted:  Very flexible can can be used anywhere manual memory management can  Very good safety if actually used  Good performance, determinism can vary based on implementation Garbage Collected:  Worst flexibility as everything is managed for you  Best safety as everything is managed for you  Worst performance and determinism ------ as everything is managed for you
8. Thread Safety and Management Languages vary greatly on support for threads and exactly how those threads are implemented. Question 1: Does your project need to be threaded at all? Sub-question: Maybe you can or want to use an async approach? Question 2: If you need threads how extensive do they need to be? Question 3: What is the communication pattern between the threads? Unlike the memory management topic there really aren’t a handful of common solutions in use. How to manage and communicate between threads is a very active area of development. Some languages have direct support for threads and light weight versions of threads. Some languages have direct support for communication between threads. Others just rely on libraries or the OS for both. The guidance here is to DESIGN your threading and communication architecture BEFORE choosing your implementation!
9. Industry Standards and Norms Some industries have “defacto standards” of what language is used for what. These do change over time but generally DO NOT keep up with advances in language development. A few examples are:  Scientific computing: Fortran, C, C++  Aerospace: Ada (used to be the standard, seems to have faded), C  Finance: C, C++ for high speed trading  Automotive: C – and specifically guided by MISRA-C  Testing: Python Sometimes in these areas the choice will be made for you due to “historical norms” and regulatory requirements. Sometimes you can step outside the norm and establish a new one. Sometimes they are simply out of date!
10. Company Familiarity Just as industries have “defacto standards” companies and departments of companies typically have their own “defacto standards”. The existing support structure for software development needs to be considered when choosing a programming language. If you are planning to deviate from the standard the additional costs need to be weighed against the benefit. In particular:  Training or re-hiring staff?  Company specific libraries?  Company specific tooling (CI and release tools for example)?  Company specific policies?  Ease of getting through formal/external reviews (security reviews)?  Direction the company would like to be moving?  Such as adoption of memory safe programming languages
11. Community Support Community support can be considered an extension of company support (or vice- versa). All of the various items should be thought about, just at a larger scale. In particular:  How easy is it to hire developers for the language?  Do libraries exist to help with the problem being solved?  Do tool exist to support the language, how good are they, how expensive?  Regulatory environment?  Ease of getting through external reviews (FAA for example)?  Direction the industry is moving?  Such as adoption of memory safe programming languages Depending on the business model of the company you are working for; NOT having community support can be an advantage! Missing support should be considered a potential business opportunity and evaluated!
12. Use In Regulated Environments Some areas of development fall into the category of a “regulated environment”. Typically these are: medical, aerospace, automotive, government and finance. Some form of external review or approval of the project is necessary and the needs of that process must be considered when selecting the programming language. One example of many: Aerospace: it is a common requirement that the programming language has a formal specification. Some languages do not have a formal specification, and some only have a specific version or variant that meets this requirement. In this case your language choice will be constrained.
13. Portability How easy is it to port your code from one platform to another? Most languages are quite portable so not as big of an issue as it used to be, but still needs to be considered. Consider:  Operating systems: Windows, Linux, Mac, ChromeOS, QNX, VxWorks, others?  Processors: x86, ARM, RISC-V, PowerPC, MIPS, PIC, others? Library dependencies can also limit language choice.  Can you build and link the library you want to use with the same or compatible compiler?  FFI availability isn’t always enough!
14. Automated Tooling What automated tooling exists to support the language choice?  Build systems  CI systems  Packaging systems  Linters  Style checkers  Revision control systems  Integration with ticket systems  Traceability is common requirement in regulated environments  Editor support  Including auto complete and now AI assistance Text based programming languages generally have a good “common” level of support. Graphical programming languages DO NOT share that “common” level of support. LabView is good example of this.
15. Execution Environments Much of the time the development, test and production execution environments will be the same, however this is not always the case. Embedded systems: Simulation/emulation support is often used to speed development when the hardware is delayed, expensive or exotic. Testing environments: Simulation/emulation is used here as well to allow for fault injection, detailed monitoring, variation in the levels of testing. Large scale development: Development and test environments will typically be some subset of the production environment. The language chosen should also consider not just the needs of the primary project, but also the needs of the support system(s) to develop the primary project.
16. Multiple Languages Depending on the size and nature of the project it is now VERY common for a project to be implemented with multiple programming languages. Each language covers the area where it shines. Generally requires a larger and more diverse team, but allows projects to be completed faster. Language inter-op now becomes a design point, but that is another talk! Example: Even a “trivial” project will typically consist of multiple languages:  C++: Primary language  Cmake: Build system  SQL: Database access
17. Summary Choosing the programming language for a project in isn’t given enough thought or time. This leads to increased development time due to limitations or incompatibilities between the language and project requirements. A spreadsheet is useful to summarize and evaluate the various language properties against the project requirements. Weights can be applied to adjust the relative importance of each property.
18. Questions?