While the first step of any new project should be writing out requirements and use cases, we’ll leave that exercise to the reader and get to the fun part. Deciding what language to write your application in. With web development being so hot right now, you certainly have a smorgasboard of languages that can target the web.

Honestly, any Turing complete language would technically do, so what are the concerns one might look for in approaching this? Well, of course we can consider the core concerns when looking at software design in general:

  • flexibility
  • maintainability
  • readability (understandability)
  • paradigm

However, any modern sane language will have been designed with these in mind. Philosophical convictions aside, it’s a fact that even unpopular languages like PHP can produce flexible, maintainable, and readable code when used properly.

Perhaps one can also consider just soft, or human, concerns. Unless of course this is a personal project, in which case, replace these concerns with enjoyment.

  • community
  • prototypability
  • hirability

Let’s break out each of these below.

Software Concerns

Flexibility

In software you see this term thrown around a lot, which I think is because we tend to be a pragmatic industry. Flexibility just means, will this get the job done, but also be able to adapt to other similar jobs without being a pain. It’s the pragmatic acceptance that what you start out building will not necessarily look like what you end up building.

Here, look at languages that have been proven to be flexible for your use cases. Especially for building a UX or complex web application, where building out the Javascript Client is almost a must in this age, is there existing support for compiling to Javascript? Or perhaps a superset of Javascript itself is in order, or Javascript itself?

Flexibility can be where you account for scale, performance, cost, and SLA as well. If you know of any specific bound (CPU, memory, I/O), it may influence your decision. Different languages provide different features, concurrency models, and will have varying levels of community support for common web application components.

Maintainability

Here we must consider the lifecycle of our project. How long will the codebase be active? Who will inherit it, and how many changes and future updates will there be? Maintainability becomes more important as these quantities increase.

Here, look at languages that will lend themselves to stability and future changes. The flexibility of dynamic typing may be a downside, as types provide a more rigorous contract and allow more compile time bugs to be caught. Does the language have good support for building documentation?

Again scale & performance should be a consideration. Using a higher level language may help initial development, but won’t necessarily be as maintainable through larger and larger workloads.

Understandability

This one is quite straightforward, and goes along with flexibility and maintainability. Can a standard software engineer read through and understand this code? Answering this one is tricky, as a more mathematical language may be very expressive and readable to a mathematician. Similarly, modern scripting languages that try to emulate written language more can be overly clever and reliant on knowing small language tricks.

Paradigm

Paradigm is for most intents split between imperative OO and functional programming. While there are many other flavors, these are likely the most talked about.

Personally I am a huge fan of the simplicity of functional programming, but also see the advantages of object oriented design for helping organize your codebase. Also, these are not mutually exclusive, and you will see many existing codebases with both paradigms in use.

Here, I have strong preference toward functional programming. At the very least, I think a language with first class functions as a feature is almost a must, and something I would find it hard to live without. Fortunately, most modern languages support that in one way or another.

Soft Concerns

Community

How “alive” is the language. If you: have bugs in your frameworks to be fixed, have questions that need answering, want real life examples to draw inspiration from, find open discussions helpful to solving problems, etc. Then a lively and active (and preferably open source) community is very helpful.

Take a look at github, blogs, hackernews, and subreddits and see if the community is a right fit for your needs.

Prototypability

Prototyping, rapidly developing a simple version of a product, is an invaluable step in the genesis of large projects. Often businesses and product people don’t know exactly what they want, and being able to iterate quickly on proof of concepts can help weed out requirements that will be nonstarters.

For this, a higher level language can often increase your speed. Shedding static types is often touted to increase development speed as well, though in my experience, your mileage may vary!

Hirability

Finally, if you’re a business that wants to check any of the above boxes, you’ll need an engineer capable of it. Finding a quality software engineer is hard, and I’m definitely a quality over quantity type. Making sure to choose a language that the best programmers want to develop in, and not one that’s a short term fad or an old school nightmare, is a huge concern when starting a project.

And please, don’t let anyone write their own language for a project, unless they’re very very smart.

Home | Next up