Define popular

To start off on the wrong foot, there isn’t really a consensus on the popularity of programming languages. There are various efforts to rank them based on Google searches, StackOverflow questions, GitHub repositories, and so on.

Depending on which heuristics you consider and how you weigh them in your ranking, you’ll end up being biased in favor or against certain languages.

For example, there is an obvious correlation between the popularity of a programming language and the number of relevant questions on StackOverflow. However, all things being equal, this metric will penalize simpler and better-documented languages.

If you take GitHub repositories as an indicator of popularity, you’ll penalize languages for which code tends to be hosted elsewhere. The same applies for languages that are not widely used in the open source world, of course.

Thankfully, we don’t need exact rankings in order to have a meaningful conversation. Let’s just agree that the ballpark definition of “popular”, as far as this article goes, is making the cut in the top 20 on the TIOBE index or the Redmonk index.[2]

Are popular programming languages better?

Popular languages are not necessarily better than less popular ones.

I would argue that the Lisp family is, in many respects, one of the best family of languages. It is, by our definition above, marginally popular at best.

Without any intent of starting a flame war, I feel obliged to point out that PHP is one of the most popular programming languages in the world.

Technical merit alone doesn’t separate the winners from the losers. Let’s see what does.

Default languages

Several of the most popular languages in the list(s) are what I would define as default languages.

Default languages are the natural go-to language for a given platform.

For example:

• C is the default language for Unix system programming;
• JavaScript is the default language for web browsers;
• SQL is the default query language for relational databases;
• Java is the default language for Android apps;
• Swift (and before that, Objective-C) is the default language for iOS and Mac applications.

Default languages are popular because anyone who is interested in developing in a given ecosystem will simply default to them.

They have a massive advantage over alternative languages.

Using something else requires research and effort. To borrow an example from within the tech world as well, BASH is far more popular than the arguably superior ZSH and FISH shells, simply because it’s the default on so many *nix systems.

Languages backed by tech giants

Another category of popular languages are languages backed by tech giants.

Note that it is not merely sufficient to be backed by a large tech company. Think Google and Dart. No, to make it popular, the company must put their weight behind the language.

Microsoft pushed C# so hard that it virtually become a default language for Windows programming.

Large standard libraries

With the exception of select default languages that rely on their positional advantage, most popular languages have a large standard library.

You need to have one in order to appeal to the initial seed group of developers who will, in turn, help you grow the ecosystem of libraries.

Python is the perfect example of this. Its “batteries included” philosophy made it useful from a very early stage. A great seed for the vast library ecosystem that would develop.

Often new languages that have emerged and become popular in recent years have leveraged existing platforms as a mean to provide a large standard library and a good sized ecosystem of libraries right off the bat.

The most common examples are languages for the JVM, such as Scala, Clojure, and Groovy.

Give it a few more years and Elixir might become an example of a popular language on BEAM (the Erlang Virtual Machine).

Paradigm shifts

Sometimes programming languages become popular because they provided an answer to a particular paradigm shift within the industry.

OOP (e.g., C++, Java), the emergence of the web (e.g., JavaScript, Perl, PHP), mobile programming (e.g., Objective-C, Swift), the emergence of data science (e.g., R), come to mind.

Paradigm shifts don’t occur too often, but when they do, they open the door to new languages.

Right now, functional languages have a  shot at widespread adoption. In part, because they work so well within an increasingly concurrent and parallel world.[3]

Killer apps

Which bring us to another reason why some languages succeed in terms of adoption.

Having an absolute killer application within a given domain.

Ruby is the poster child of this. Outside of Japan, it was a largely ignored language for a decade or so before it started to gain traction elsewhere.

Then Rails came along – and it was a very compelling proposition for web development.[4] People were impressed enough that they were willing to study this little-known language called Ruby, simply because of Rails.

And when they did, they discovered what a nice little language it was. Its technical merits were fundamental to its adoption (and the reason why DHH picked it up for Rails), but not sufficient on their own.[5]

It’s not an overly common scenario, but languages which provide a better answer to a specific problem within a popular domain, can experience huge gains in popularity.

What else helps? Marketing.

Marketing helps. A community that doesn’t shy away from good technical marketing will undoubtedly help the language become more popular.

Note that marketing is a very encompassing term. Great documentation is good marketing. Not having to spend an hour installing things just to get started is arguably part of your approach to marketing.

Being accepting, inclusive, and welcoming to newcomers is good marketing. Blogging, organizing conferences, giving speeches at other conferences, writing great books, are all good examples of things a marketing-oriented community does.

What else? Familiarity.

Familiarity is very important. If your programming language is radically different from anything that the majority of developers are used to, it will struggle to become widely adopted.

So it has to toe the line. It has to be innovative enough to make it worthwhile, but familiar enough that it won’t immediately induce a negative gut reaction the moment a new developer approaches it.

This is a struggle numerous Lisp languages have had to face. Most developers are familiar with the C syntax, however, S-Expressions are somewhat scary and foreign to many.[6]

Because of this, although functional languages have a shot, this time around, it won’t be an easy sale.

Anything else? Time.

Programming languages don’t become popular overnight. It takes years, no matter how you slice it.

Most languages take at least 10 years to become widely adopted. Adoption rates are getting faster in recent years, but this process still takes quite a while (several years).

The most obvious exception is Swift, with its meteoric rise over the course of just a couple of years. Not only Swift is backed by Apple, it was also made into a default language for one of the most popular development ecosystems in the world.

So if you’re a programming language developer or an early adopter of a language that you wish to see become more popular, be patient. You’re in this for the long haul.

Popularity ain’t easy

It’s really hard to make a programming language popular.

The competition is fierce, with so many valid options available to developers.

As we asymptomatically approach all that programming languages can be, it is even harder to create something that’s so very much better than it’s worth making the leap to.

Developers need compelling and convincing reasons to jump ship or even just consider investing time in your language and community.

Consider for a moment why a programmer would want to learn a language that is new to them:

• To get or keep a job.
• To become more productive and/or write better software.
• To develop a new category of applications.
• To learn a new paradigm.

If your language can satisfy most of those needs, it will have a chance. But this only buys you admission to the race.

Conclusions

In summary, I believe these are the key factors to consider:

• Being a default language for a popular ecosystem;
• Being backed and promoted by a tech giant;
• Having a large standard library and/or targeting a popular VM (e.g., JVM, unless it’s a system language);
• Fully embodying a new paradigm shift;
• Being very useful in a particular domain, like Ruby did through Rails back in 2005;
• Having great documentation, guidance for newcomers, tools, editor integration, and in general removing any instrumentation obstacle that makes getting started with your language difficult;
• Fostering a welcoming community that encourages sharing, marketing, and evangelism;[7]
• Having a somewhat familiar syntax that is easy to read, write, and teach;
• Being active and developed for several years;
• Providing technical innovations that lead to productivity and more maintainable code;
• Luck.

The first two are out of the question for most languages, and even then, few languages will meet all of the remaining requirements.

Even embracing just a few of these should, however, be enough to grant your language a chance at becoming mainstream.

Failing that, you might still be left with an active, niche language that will survive and be appreciated by many developers for decades to come.

The post So You Want Your Programming Language to Be Popular appeared first on Programming Zen.

During a meeting with a few high-profile engineers, I presented what Ruby brought to the table. An IBM Distinguished Engineer[2] stopped me in my tracks and said, “It sounds slow”.

I love Ruby as much as a programmer can possibly love a programming language, but that engineer’s conjecture was right on the money. Ruby’s emphasis has always been on programmer efficiency, not execution efficiency.

Generally speaking, Ruby programs are significantly slower than equivalent programs in C or Java.

A lot of work has been done to improve Ruby’s performance, with a good degree of success, and that’s terrific – but is it enough in today’s world?

In many ways, yes. You’re not going to employ Ruby to calculate 13 trillion digits of Pi, nor will you use it to power the backend of a messaging app with millions of users.

However, Ruby will suit most scripts just fine. Further, I would argue that Rails still gives you the best bang for your buck in terms of web frameworks, when it comes to a large subset of CRUD-based web applications.

Ruby is lovely and has many uses, however, what Ruby is not, is the language that will define the next ten years. As beautifully designed as it is, it simply isn’t the ideal language to tackle the challenges that an increasingly distributed world throws at us.

Concurrency is the name of the game, and Ruby is, for the most part, limited in its ability to cope with it (despite valuable efforts). It’s not that you can’t do concurrency in Ruby, it’s that there are much better, battle-tested tools to do so.

If you are a fellow Ruby developer who would like to remain relevant in the next decade, I highly suggest that you start looking for something new to pair to Ruby as your main language. (Though, fair warning, you might end up replacing Ruby with it.)

Your main language for the next ten years will be highly dependent on the development context, of course. If you develop iOS apps, Swift is such a language. Android apps? Kotlin is looking good and might have a shot at that. Data Science? Julia, if they can sort out a few performance issues, could get the edge over Python and R. System programming? Rust and Go will be worth a close look, too.[3]

I’m enough of a generalist to dabble in many programming domains, but above all, I’m a web developer, so my main language for the next decade will have to excel in distributed environments where n machines make m requests, for large values of n and m (e.g., IoT alone enables this scenario).

So what comes after Ruby? Some people might argue that it’s Node.js. Not for me personally, though. I’m afraid Ruby has spoiled me. I find Ruby to be a joy to use. JavaScript, not so much.

We are looking for a high-level language that can handle concurrency like a champ, has an elegant, highly readable syntax, provides a great user experience for the developer, and… is functional. In short, fun and functional. 🙂

I find functional programming (with immutable data types) to be a significantly better approach to thinking about most problems, and modeling solutions for them, than Object Oriented programming.[4] I blame my past dabbling with Haskell and Clojure for this.

Speaking of Clojure, on the JVM, both Scala (w/ Akka), and Clojure (w/ STM & Pulsar) are valid options.

Of the two, Clojure is the one that comes closer to a great fit for me. Very close. Unfortunately, I’m somewhat of an aesthete, and coming from Ruby, the Lisp syntax still feels like a downgrade.[5]

Further, the JVM is great, but when it comes to dependable concurrency, you really can’t beat what the Erlang VM (i.e., BEAM) has to offer (ask the team at Whatsapp).

The problem with Erlang is that its Prolog-like syntax feels obsolete. I have never seen an Erlang program and said to myself, “Wow, that was a joy to read”. Or refactor. It’s not the worst, but I personally find it to be a fairly uninspiring language to work with.

Thankfully Erlang is not the only language for its highly fault-tolerant and concurrent VM. There is indeed a language worth getting excited about.

For me, that language is Elixir. Elixir fits all the requirements above and feels like a joy to both read and use.

Like many other Rubyists, when I first found Elixir I thought of it as Ruby for the Erlang VM, due to its largely familiar syntax. But it turns out to be so much more than that. In fact, it’s much more than Erlang as well.

To hastily summarize, we get:

• A highly readable, elegant, concurrent, functional programming language.
• The fantastic Erlang VM (i.e., BEAM) and OTP integration.
• Shared nothing Actor-based concurrency.
• Metaprogramming via macros.
• Polymorphism via protocols.
• A whole host of other nice features (pipeline operator, pattern matching, docstrings, streams, mix, etc).
• An excellent web framework called Phoenix.
• A fast growing supportive community, that it’s reminiscent of Ruby during the early days of Rails.

Ruby’s usage skyrocketed in the past decade and I would argue that Elixir, though not widely adopted as of yet, is well equipped to do the same in the coming ten years.

Give it a try and let me know how you like it.

The post A Language for the Next 10 Years appeared first on Programming Zen.

There are probably a few thousand programming languages out there, some of which are quite esoteric. Yet most developers only end up learning a handful amongst the most common ones that are currently in use within our industry.

I would argue that learning a new language, perhaps even a lesser known one, can be a lot of fun and definitely worth your time. Even if you don’t end up using a given language in production for anything of a serious nature, a good language will offer you a different perspective and let you grow as a programmer in the process.

People who learn, for example, Lisp or Haskell, will end up being better programmers because of it, even when using Ruby, Python, or Java in the course of their day-to-day development.

It’s also worth noting that it pays big dividends to become an early adopter of a programming language that ends up being popular, both in terms of job / consulting opportunities and in regards to the impact you can affect the community. (Though I wouldn’t use this as your main motivation, as your crystal ball might not be as haze-free as you think.)

In this week’s post, I’d like to list (and link to) ten different programming languages that have caught my eye, and which I’ve personally found to be interesting for one reason or another. I invite you to check them out and perhaps spend some time getting more familiar with one that, after a precursory look, appeals in particular to you as well.

Depending on how closely you follow the development world, I expect some people will find this list to be somewhat too mainstream for their tastes. Even then, you may still encounter some languages you are not familiar with. At least I hope you do.

Without further ado, here is my list:

1) Pony is an open-source, object-oriented, actor-model, capabilities-secure, high-performance programming language. (Launched in 2015.)

2) Nim is an imperative, multi-paradigm, compiled programming language. It is designed to be efficient, expressive, and elegant, supporting metaprogramming, functional, message passing, procedural, and object-oriented programming styles by providing several features such as compile-time code generation, algebraic data types, an elegant foreign function interface (FFI) with C and compiling to JavaScript. (Launched in 2008.)

3) Julia is a high-level, high-performance dynamic programming language for technical computing, with syntax that is familiar to users of other technical computing environments. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library. Julia’s Base library, largely written in Julia itself, also integrates mature, best-of-breed open source C and Fortran libraries for linear algebra, random number generation, signal processing, and string processing. (Launched in 2012.)

4) Elixir is a dynamic, functional language designed for building scalable and maintainable applications. Elixir leverages the Erlang VM, known for running low-latency, distributed and fault-tolerant systems, while also being successfully used in web development and the embedded software domain. (Launched in 2012.)

5) Rust is a general-purpose, multi-paradigm, compiled programming language sponsored by Mozilla Research. It is designed to be a safe, concurrent, practical language, supporting pure-functional, imperative-procedural, and object-oriented styles. (Launched in 2010.)

6) Haxe is an open source toolkit based on a modern high level strictly typed programming language, a fast cross-compiler, a complete cross-platform standard library, and ways to access to each platform’s native capabilities. (Launched in 2005.)

7) Agda is a dependently typed functional programming language. It has inductive families (i.e., dependent types), parameterised modules, mixfix operators, Unicode characters, and an interactive Emacs interface. Agda is a proof assistant. It is an interactive system for writing and checking proofs. It has many similarities with other proof assistants based on dependent types, such as Coq, (Launched in 2007.)

8) Idris is a general-purpose purely functional programming language with dependent types. The type system is similar to the one used by Agda. The language supports interactive theorem-proving comparable to Coq, including tactics, while the focus remains on general-purpose programming even before theorem-proving. Other goals of Idris are “sufficient” performance, easy management of side-effects and support for implementing embedded domain specific languages. (Launched in 2011.)

9) Gosu is a general-purpose programming language built on top of the JVM. It is object-oriented, statically typed (with type inference), imperative, Java-compatible, and it offers simplified generics. It’s a “simple and pragmatic” language for the JVM. (Launched in 2010.)

10) Kotlin is a statically typed programming language for the JVM, Android, and the browser. It is entirely interoperable with Java. Kotlin is developed by JetBrains. (Launched in 2011.)

(Most descriptions are from Wikipedia and/or the homepage of each project.)

Have you found a lesser known programming language that intrigues you? What do you like and dislike about it? Feel free to share in the comments below.

The post 10 Lesser-Known Programming Languages Worth Exploring appeared first on Programming Zen.

The method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.

The second definition is more interesting because it allows me to make a point about programming languages. It goes like this:

The system of communication used by a particular community or country.

Look at that. Isn’t that beautiful? Let’s cut the country stuff, and shorten it to, “The system of communication used by a particular community”. Tell me that it’s not a spectacular definition of programming languages as well.

We can look at programming languages in two possible ways. They can be a means for us to instruct the computer, and incidentally communicate with fellow programmers, or they can allow us to communicate with other programmers in specific terms that are ultimately executable.

The first interpretation is technically more accurate. Or, more specifically, the worst kind of accurate.

I like to think of programming languages as languages because, outside of trivial programs, above all else they enable programmers to communicate with one another when it comes to resolving a problem or completing a particular task, while incidentally producing code that is also understood by computers via “translators” (e.g., compilers and interpreters).

There are plenty of benefits that can be derived from thinking about programming in terms of the second interpretation.

When you view programming in this light, you start considering the value of comments expressing the “why” and code expressing the “how”. Tests become a way to communicate to a fellow programmer [1] that a change to the codebase has violated a given requirement. Above all, writing idiomatic code becomes important.

Remember the Google Dictionary definition. “The system of communication of a particular community”. It is in fact the community, for better or for worse, that sets the guidelines and de facto style of a particular programming language.

Since we are operating in a system of communication, programming is a bit like driving: predictability is important. That’s why in the Ruby community we have the principle of least surprise [2] and in the Python community one finds the “There should be one – and preferably only one – obvious way to do it” mantra. [3]

When you think of programming languages as a series of conventions adopted by a community, and incidentally understood by the computer, you avoid recklessly monkey patching classes just because you can. You know that doing so leads to unexpected results and miscommunications with other programmers.

You also avoid features which are technically legal in the language, but rare and confusing to fellow experienced developers in that particular language. For an example of this, take a look a the Flip-Flop operator in Ruby (a reminiscence of its Perl heritage). Technically legal Ruby, even useful at times, however you shouldn’t use it because only a handful of fellow Rubyists will understand what you’re doing. [4] Worse yet, it will be hard to Google for an answer unless you are familiar with its name already.

When you’re first picking up a human language, you learn the meaning of common words. Then you use simple sentences that you memorize from books, people around you, songs, movies, and TV shows. Then you try to mimic the idioms you see used by mother tongue speakers. Often you won’t get them right at first, resulting in comical variations that are close, but not quite right, to those of native speakers.

When it comes to programming languages things really aren’t all that different. That’s why it’s critically important to read other people’s code, write code and receive feedback in code reviews, do peer programming, take part in open source contribution, and engage in other forms of social interaction pertaining to code. Doing so is immensely important when it comes to truly mastering a programming language.

Another consequence of this emphasis on communication among programmers through a common, precise, language whose style, conventions, and idioms are defined by the community is that you should choose your communities carefully. What are the community’s priorities? If there is no love for beautiful, clear, elegant, easy to understand code, tread very carefully. [5]

As someone who had to learn English as an adult, pretty much from scratch, I can tell you that I find many parallels between the experience of learning a new language and that of a new programming language.

Even if the two are not a perfect match – and seeing a programming language as a human language is an imperfect metaphor – I feel that thinking of it in these terms has allowed me to quickly acquire key skills in the programming languages that I needed or wanted to learn.

The post On Programming Languages as Languages appeared first on Programming Zen.