# What makes a language “optimized” for a specific task?

Often there are programming languages that are specialized for specific tasks. Some programming languages are excellent at array arithmetic (such as matrices and the use of multidimensional arrays), yet some are much better at higher-level mathematics that is hard to reproduce in other languages (yet still possible all the same).

What about a language makes it better for a specific task or end-goal than other languages, given that most simply compile down to assembly anyways?

I am talking about Turing complete languages, ones that are Turing equivalent.

• This is an encyclopedic question. I suggest that you break it down in some way, make it more specific. – André Souza Lemos Nov 24 '16 at 17:44
• Would it be wrong to say "marketing"? – corsiKa Nov 24 '16 at 21:05
• @corsiKa Yes, I think it is more than an issue of marketing. – Jeremy West Nov 24 '16 at 22:52

There are a few things to consider:

• Abstraction: what does the language treat as "special"? Are matrices first-class values, like in Matlab, or do you encode them using simpler types like arrays, as in C? C makes you think about how matrices are implemented, Matlab doesn't.

Likewise, if you've got a complicated system of asynchronous communications, you probably want first-class functions so that you can do callbacks.

The more features that are added, the more complex the language gets. So while there are some "multi-paradigm" languages like C++ and D, most languages pick a niche, choose the things that are important to that niche, and prioritize those as their main abstractions.

• Performance: all abstraction comes with a cost, whether it be compile-time or run-time. Some languages limit themselves in a way that makes them less abstract but more performant.

Early Fortran didn't allow for pointers or recursion, so it was great at number crunching, faster than a language like C, where you were running lots of loops. But it was terrible at encoding large data structures, like trees, where you needed pointers for indirection. (Note that I don't know much about modern Fortran.)

Essentially, there are always tradeoffs. More abstract means either slower runtime or more complexity at compile-time. More features means a more complex language. Some features make certain things fast and others slow, like pointers and recursion. There's no perfect language, so each language will reach a sort of local maximum in the space of language qualities.

The constraints of some languages makes it easier to implement faster code (e.g. Fortran vs C and the pointers aliasing) which is a tradeoff between out-of-the-box performance and possibilities).

The language is not "optimized" for specific tasks, but the implementation, compilers and constraints that make it easier to understand the code by compiler makes so. The real deal is about specific libraries, algorithms implemented to speed up the process with switches depending on the problem length makes it optimal.

For example the multiplication uses various cases (see GMP multiplication.

When the language specifies the higher level mathematic operations it's implementation is optimal (efficient in this case), but that is not the part of language specification.

Please take a look at matrix rank computation in Matlab, Mathematica and Maple (I cannot perform all the tests myself right now, but these are consistent with my tests). All these languages (environments) implement the same higher level operation but the implementation details differ which gives various times.

When some domain specific task (here also domain specific language) is oriented at particular calculations they get improved and optimized (over the years) for the target audience. But being optimal is not always the case. For example Perl has a long history of handling strings, but the PCRE (here simply Perl's regular expressions) are not the fastest existing ones (and use a lot of memory), but are extremely expressive and powerful.

The constraints of the language makes a difference in the compilation process, the mentioned pointer aliasing prevents the possibility of the code reordering and enforces reloading of variables.

• Most languages are Turing complete by specification, as not all of them specify fixed address sizes in their spec. And it's pretty limiting to lose the distinction between things like C, which are Turing Complete modulo address size, and things like Coq, Agda or System F, which are not Turing Complete at all. – jmite Nov 24 '16 at 18:45
• @jmite thank you. I hope this is no longer shadowing the differences – Evil Nov 24 '16 at 20:07
• @Evil: Well, I think your statement about languages not be optimized for tasks is wrong. you're seeing the word optimize from the point of view of the computer. But some languages are designed to make it easier only for the programmer and let implementors figure out how to make it perform. – theDoctor Nov 28 '16 at 0:51
• This is from efficiency angle, so it is not wrong, I just took this angle, you might consider the other one (optimized meaning it is easier to write some specific tasks in it). "What about a language makes it better for a specific task or end-goal than other languages [...]", I am very confident that: easier to write, faster, cheaper etc. might be included in the "better". The author neither accepted some answer nor included clarifications or comments that any of the answers given are not about what was asked. Besides that, it is one of the factors, for some people more important than to other – Evil Nov 28 '16 at 1:34

In my opinion this can actually be formulated quite precisely: A tool (for example, a programming language together with its standard libraries) is the optimal tool for a particular class of problems when it minimises, over all possible tools that could be employed, the expected cost of getting a sufficiently correct and performant solution, where the expectation is taken over some given probability distribution over all problems in the problem class. Mostly this cost comes in the form of programmer time, and includes expected design time, expected debugging time, expected time needed to educate someone not already familiar with the tool, etc.

In practice, almost none of these quantities can actually be measured. Still, I think it's the right way to think about the problem.

It's an excellent question and not easily answered. Is there anything about the Erlang language that makes it suitable for real-time telecommunications applications? Or is it something about the Erlang compiler? Or is it something about the Erlang community and ecosystem? Perhaps it's that people who know how to write telecomms applications are expert in Erlang, and the people who know Erlang are expert in telecomms applications? I suspect that all these factors play a role.

There are probably two features in Erlang that make it suited to such applications (caveat: I've never used the language myself) - it has good support for concurrency, and support for dynamic software upgrade. Those features would be useful in many other areas too, but telecomms engineers are fanatical about uptime. Perhaps if people building web sites were as concerned about high availability as people building telephone exchanges, Erlang would be popular there too.

The other answers miss the point of optimising a language for a specific task - it isn't just about what makes code run faster on given hardware; it's about how clearly and succinctly a particular language allows you to express the solution to a problem. That very much depends on the problem domain, and (along with marketing hype, ignorance of existing solutions, and the ego trip of writing a new language) is why we have multiple languages - the goal is for the programmer to write less code, which is both less error prone and easier for the next programmer to read/understand/fix/enhance.

For example, both C and C++ can be used for object orientated programming - and indeed, the GObject library is a good example of OO C. A C struct containing function pointers can serve the same purpose as virtual methods on a C++ class, and can perform better; the development penalty is glue code to allocate memory, initialise the function pointers, and choosing a strategy for calling 'parent' methods. Most of the time it's clearer/safer to type Class klass * = new class() than struct class *klass = malloc(sizeof(struct class));klass->fn1 = ...;klass->fnN = ....

• Well, the jmite's answer provides with a bullet points the things you wrote are missing. I wrote about domain specific tasks that are optimized for this matter. I like C, I know things like OCC, but it does not make C Object Oriented (the compiler does not help with this and many optimizations get prevented, there is no garbage collector, etc.). You cannot overload C functions like in C++, but of course you can emulate any behaviour (jmite wrote about this also). I do not see how this answers the question stated. – Evil Nov 24 '16 at 23:25
• @Evil: Object oriented programming and Object oriented programming language are two different concepts. Object oriented programming do not require an object oriented language. Arguably it just requires the existence of paper or whiteboards so you can do your UML design. – slebetman Nov 25 '16 at 3:16
• @slebetman I didn't see that coming. Arguably you do not need the paper and the whiteboard, you can just imagine objects, and according to some people this is how we think, but this doesn't get any closer to the language support of OOP concepts. I am sorry, but this is dispute I do not want to pick. – Evil Nov 25 '16 at 4:56
• @Evil: I'm not so sure about being able to keep track of it all mentally without some abstraction to help you. My first job was being given a large piece of C code that looked like all arrays with function pointers (took me a while to figure what the weird syntax meant - no google back then) and I was struggling with it until I started seeing a pattern and realised that those arrays were objects and those function pointers were methods. Bought myself a small whiteboard and used up a lot of A4 paper but finally I managed to understand the code – slebetman Nov 25 '16 at 5:14
• @slebetman Given that object-oriented programming predates UML by at least 20 years, your claim that UML designs are necessary for object orientation appears to be completely false. – David Richerby Nov 25 '16 at 8:50