patternModerate
What makes a language "optimized" for a specific task?
Viewed 0 times
whatmakesoptimizedlanguageforspecifictask
Problem
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.
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.
Solution
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.
-
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.
Context
StackExchange Computer Science Q#66403, answer score: 19
Revisions (0)
No revisions yet.