Language vs tool
- Transfer
The world of software developers is divided into two camps. Language connoisseurs sing the praises of the power of high-level programming - higher-order functions, metaprogramming, aspect-oriented programming, reflection, etc. Tool connoisseurs have good skills in using utilities for assembling and debugging, documenting and autocompletion, refactoring and testing. Language connoisseurs tend to use text editors like emacs, vim or the like for development - they are well suited for almost any language, including new ones. Tool connoisseurs choose IDEs such as Visual Studio, Eclipse, or IntelliJ, which include entire sets of specialized development tools.
New programming languages, such as, for example, Laszlo or Groovy, and new language extensions, such as AOP, are usually available only for use by a universal text editor, until they receive full support in some kind of IDE. After some time, if the language really "shot", this support will undoubtedly appear. This is not because making the right toolkit is too difficult. This is because investing in developing a language and investing in developing tools for it are in several orthogonal planes and sometimes even squeeze each other out. And that's why.
If you spend most of your time studying the language itself and how to use it, your picture of the world looks something like this:
In this diagram, the initial choice of a programming language and its level of proficiency can greatly affect your productivity. The choice of an IDE is not very important in this case - basically you will use the IDE as just a text editor, possibly with rare exceptions. However, you will not use all of the tools that modern IDEs offer.
On the other hand, if you spend most of your time studying development tools, you know how it feels to use the full power of an integrated editor and debugger, auto-completion, refactoring, modeling, design, testing, profiling, etc. Your picture of the world looks something like this:
Having an IDE gives you serious advantages over a bare text editor. The choice of a programming language, on the other hand, is not so important - you will, by and large, work with the same classes and methods, variables and expressions, conditions and loops. But the real strength of your style lies in the speed of development that the IDE will give you.
But where should I go if I want to be like that monkey in a joke - both smart and beautiful? Is it possible to be an expert on the programming language and tools used at the same time? It's difficult. The day is still 24 hours, and the year is only 365 days. Each free minute can be devoted to either learning a language or a toolbox. Each of these options will ultimately have a positive effect on your skill, but in different ways. These development paths compete in many ways - for your attention, for your time, for your programming style. And in the end, you find yourself in one of two camps.
Investing your time in learning the possibilities of a language makes you appreciate the interesting aspects of new languages. You can immediately afford to start using a new language if it has something that can help you a lot. To do this, you already have your favorite text editor, and the language - its compiler / interpreter - more, in fact, does not need anything.
Investing time in developing tooling skills, on the other hand, does not encourage you to use new languages. After all, the tools do not yet support the most valuable ideas of these languages, and if you write in them in the style of the classical OOP, is it not easier to do this in the previously used language, with its well-known specifics? Moreover, this will give a seemingly good development speed and a predictable result.
Thus, paying more attention to the language, one way or another, you pay less attention to tools (and vice versa). And each of these two paths will lead you sooner or later to one of the two camps, with all its pluses and minuses.
At each point in time, the programmer who chose the text editor as the main tool has a wider choice of programming language. All new languages have a compiler / interpreter, but not all also have support in any IDE. The diagram below shows how it looks for different languages at different points in their evolution.
For each language, the line at the end of the “white-red” phase shows the moment when the language is already suitable not only for academic research, but also for some real use. The line at the end of the “red-violet” phase means that all the tools for this language have become fully suitable for real, useful use. At each time point, there are more languages that have passed the “white-red” phase than those that have completed the “red-violet”.
One consequence of this larger choice is the fact that this choice gives access to more powerful languages. Thus, two factors play the role of a programmer who relies on a text editor + language skills: the deepening of his own knowledge and the benefits of powerful new features of the language.
The most powerful programming languages often have the weakest tools. The reason for this is the same - limited resources. The developer of the new language is neither a wizard nor a billionaire. Every free minute he has to think about where it is better to spend it - on improving the language, or on improving tools for working with him.
Take a look at the following chart. It shows three hypothetical programming languages whose developers decided to focus, respectively, on the development of the language itself (upper arrow), on the development of tools (left arrow) and on the search for balance (middle arrow). The arrows are approximately the same length (which means the same investment of resources) and therefore they end in completely different places on the diagram. The "language" arrow gives us a super-powerful language with a bare compiler / interpreter. "Instrumental" gives us a good IDE with a mediocre commonplace language. The “balance” is lost somewhere in the middle.
And here is the fact: a good language will always be able to go through this diagram sooner or later from the point “many good features” to the point “many good features and tools”. So in the end, both language followers and tool supporters will use good language with decent tools. I hope that the language Laszlo we are developing will also come to this someday.
All of the above, it would seem, leads to the conclusion that the “language” approach is definitely better. Indeed, it is possible to use the power of the new language earlier, to study more deeply, and then the tools will catch up - and we will get profit from them too. So? Not really, there are nuances.
Investing your time in learning a tool is virtually guaranteed to give you results. The popularity of tools is known, their capabilities are also. Learned an advanced debugger - get a 5% reduction in product development time. Have fun using refactoring? +5 to karma. Set up Continous integration - a mountain off your shoulders!
With languages, this is not so. New languages have theoretical power, but it still needs to be justified. You can spend a month learning a new language and find that it turns out that it is not suitable for your subject area. Or does not have badly needed libraries. Or his community is extremely small. Or with his knowledge not to find work.
On the other hand, if you learn languages quickly, apply them in small projects and they solve the problems you are facing, it makes no difference to you whether the further development of this language will be successful. He helped you here and now - great. You do not need thick monographs on it - enough small pieces of working code, you do not need a large team of specialists who need to be sought and hired somewhere - you are enough personally (well, there may be a couple of fellow enthusiasts).
Another difference in approaches is team involvement. It may well be that someone in your Java project team will use Eclipse, someone in IntelliJ IDEA, and someone in a text editor. This is fine as long as the generated code compiles and runs the same way. However, if someone in your Java team suddenly suddenly decides to write in Haskell personally, something definitely goes wrong.
Of course, there are counterexamples of the idea of the “dilemma of language and instrument." For example, Lisp and Smalltalk: both are powerful languages with good tools. Exceptions are possible - both for languages that harmoniously combine the power of internal structures with the tools used, as well as for programmers who are equally well aware of both. But it’s about how to meet a famous pianist, who is also an international chess grandmaster.
New programming languages, such as, for example, Laszlo or Groovy, and new language extensions, such as AOP, are usually available only for use by a universal text editor, until they receive full support in some kind of IDE. After some time, if the language really "shot", this support will undoubtedly appear. This is not because making the right toolkit is too difficult. This is because investing in developing a language and investing in developing tools for it are in several orthogonal planes and sometimes even squeeze each other out. And that's why.
Programming languages
If you spend most of your time studying the language itself and how to use it, your picture of the world looks something like this:
In this diagram, the initial choice of a programming language and its level of proficiency can greatly affect your productivity. The choice of an IDE is not very important in this case - basically you will use the IDE as just a text editor, possibly with rare exceptions. However, you will not use all of the tools that modern IDEs offer.
Instruments
On the other hand, if you spend most of your time studying development tools, you know how it feels to use the full power of an integrated editor and debugger, auto-completion, refactoring, modeling, design, testing, profiling, etc. Your picture of the world looks something like this:
Having an IDE gives you serious advantages over a bare text editor. The choice of a programming language, on the other hand, is not so important - you will, by and large, work with the same classes and methods, variables and expressions, conditions and loops. But the real strength of your style lies in the speed of development that the IDE will give you.
Two camps
But where should I go if I want to be like that monkey in a joke - both smart and beautiful? Is it possible to be an expert on the programming language and tools used at the same time? It's difficult. The day is still 24 hours, and the year is only 365 days. Each free minute can be devoted to either learning a language or a toolbox. Each of these options will ultimately have a positive effect on your skill, but in different ways. These development paths compete in many ways - for your attention, for your time, for your programming style. And in the end, you find yourself in one of two camps.
Investing your time in learning the possibilities of a language makes you appreciate the interesting aspects of new languages. You can immediately afford to start using a new language if it has something that can help you a lot. To do this, you already have your favorite text editor, and the language - its compiler / interpreter - more, in fact, does not need anything.
Investing time in developing tooling skills, on the other hand, does not encourage you to use new languages. After all, the tools do not yet support the most valuable ideas of these languages, and if you write in them in the style of the classical OOP, is it not easier to do this in the previously used language, with its well-known specifics? Moreover, this will give a seemingly good development speed and a predictable result.
Thus, paying more attention to the language, one way or another, you pay less attention to tools (and vice versa). And each of these two paths will lead you sooner or later to one of the two camps, with all its pluses and minuses.
At each point in time, the programmer who chose the text editor as the main tool has a wider choice of programming language. All new languages have a compiler / interpreter, but not all also have support in any IDE. The diagram below shows how it looks for different languages at different points in their evolution.
For each language, the line at the end of the “white-red” phase shows the moment when the language is already suitable not only for academic research, but also for some real use. The line at the end of the “red-violet” phase means that all the tools for this language have become fully suitable for real, useful use. At each time point, there are more languages that have passed the “white-red” phase than those that have completed the “red-violet”.
One consequence of this larger choice is the fact that this choice gives access to more powerful languages. Thus, two factors play the role of a programmer who relies on a text editor + language skills: the deepening of his own knowledge and the benefits of powerful new features of the language.
The programming language dilemma
The most powerful programming languages often have the weakest tools. The reason for this is the same - limited resources. The developer of the new language is neither a wizard nor a billionaire. Every free minute he has to think about where it is better to spend it - on improving the language, or on improving tools for working with him.
Take a look at the following chart. It shows three hypothetical programming languages whose developers decided to focus, respectively, on the development of the language itself (upper arrow), on the development of tools (left arrow) and on the search for balance (middle arrow). The arrows are approximately the same length (which means the same investment of resources) and therefore they end in completely different places on the diagram. The "language" arrow gives us a super-powerful language with a bare compiler / interpreter. "Instrumental" gives us a good IDE with a mediocre commonplace language. The “balance” is lost somewhere in the middle.
And here is the fact: a good language will always be able to go through this diagram sooner or later from the point “many good features” to the point “many good features and tools”. So in the end, both language followers and tool supporters will use good language with decent tools. I hope that the language Laszlo we are developing will also come to this someday.
Pioneer Difficulties
All of the above, it would seem, leads to the conclusion that the “language” approach is definitely better. Indeed, it is possible to use the power of the new language earlier, to study more deeply, and then the tools will catch up - and we will get profit from them too. So? Not really, there are nuances.
Investing your time in learning a tool is virtually guaranteed to give you results. The popularity of tools is known, their capabilities are also. Learned an advanced debugger - get a 5% reduction in product development time. Have fun using refactoring? +5 to karma. Set up Continous integration - a mountain off your shoulders!
With languages, this is not so. New languages have theoretical power, but it still needs to be justified. You can spend a month learning a new language and find that it turns out that it is not suitable for your subject area. Or does not have badly needed libraries. Or his community is extremely small. Or with his knowledge not to find work.
On the other hand, if you learn languages quickly, apply them in small projects and they solve the problems you are facing, it makes no difference to you whether the further development of this language will be successful. He helped you here and now - great. You do not need thick monographs on it - enough small pieces of working code, you do not need a large team of specialists who need to be sought and hired somewhere - you are enough personally (well, there may be a couple of fellow enthusiasts).
Another difference in approaches is team involvement. It may well be that someone in your Java project team will use Eclipse, someone in IntelliJ IDEA, and someone in a text editor. This is fine as long as the generated code compiles and runs the same way. However, if someone in your Java team suddenly suddenly decides to write in Haskell personally, something definitely goes wrong.
Conclusion
Of course, there are counterexamples of the idea of the “dilemma of language and instrument." For example, Lisp and Smalltalk: both are powerful languages with good tools. Exceptions are possible - both for languages that harmoniously combine the power of internal structures with the tools used, as well as for programmers who are equally well aware of both. But it’s about how to meet a famous pianist, who is also an international chess grandmaster.