Language vs tool
The world of software developers is divided into two camps. Language experts 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 utilizing tools for building and debugging, documenting and autocompleting, refactoring, and testing. Language experts tend to use text-based editors like emacs, vim, or the like - they are well suited for almost any language, including new ones. Connoisseurs of tools choose an IDE, such as Visual Studio, Eclipse, or IntelliJ, which include a whole set 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 means of a universal text editor until they receive full support in some kind of IDE. After some time, if the language is really “shot”, this support will undoubtedly appear. This is not because it is too difficult to make the necessary tools. This happens because investing efforts in developing a language and investing efforts in developing tools for it are located in several orthogonal planes and sometimes even crowd out each other. 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 like this:
In this diagram, the initial choice of programming language and its level of proficiency can have a profound effect on your productivity. The choice of IDE is not very important here - basically you will use the IDE as a simple text editor, possibly with rare exceptions. In this case, you will not use all those tools that offer modern IDE.
On the other hand, if you spend most of your time studying development tools, you know what it is like to use the full power of an integrated editor and debugger, autocompletion tools, refactoring, modeling, design, testing, profiling, etc. Your picture of the world looks like this:
Having an IDE gives you significant advantages over a naked text editor. The choice of programming language, on the other hand, is not so important - you will by and large work with all the same classes and methods, variables and expressions, conditions and cycles. But the real strength of your style - in the speed of development, which will give you knowledge of the IDE.
And where should I go if I want to be like that monkey in a joke - and smart and beautiful? Is it possible to be both knowledgeable and used programming language and tools? It's difficult. There are still 24 hours a day, and only 365 days a year. Every free minute can be devoted either to learning the language or tools. Each of these options will ultimately have a positive impact on your skill, but in different ways. These paths of development largely compete - for your attention, for your time, for your programming style. And in the end you get into 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 there is something in it that can help you a lot. To do this, you already have your favorite text editor, and the language has its compiler / interpreter - in fact, nothing more is needed.
Investing time in 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, but since writing them in the style of a classical OOP, is it not easier to do this in the previously used language, with its well-known specifics? Moreover, it seems to give a good development speed and a predictable result.
Thus, by paying more attention to the language, you somehow pay less attention to the tools (and vice versa). And each of these two paths will lead you sooner or later to one of two camps, with all its pluses and minuses.
At any given time, a programmer who has chosen a text editor as the main tool has a wider choice of programming language. All new languages have a compiler / interpreter, but not all of them also have support in some kind of IDE. The diagram below shows what it looks like 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 moment in time, the languages that have passed the “white-red” phase are larger than those who have completed the “red-violet” phase.
One consequence of this larger choice is the fact that this choice gives access to more powerful languages. Thus, a programmer who has staked on a text editor + knowledge of the language plays two factors at once: both the deepening of one’s own knowledge and the benefits of powerful new language features.
The most powerful programming languages often have the weakest tools. The reason for this is still the same - limited resources. The developer of a new language is not a wizard or a billionaire. Every free minute he has to think about where to spend it better - to improve the language, or to improve the tools for working with it.
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 finding balance (middle arrow). The arrows are about the same length (which means the same investment of resources) and therefore they end in completely different places in the diagram. The “language” arrow gives us a super-powerful language with a naked compiler / interpreter. "Instrumental" gives us a good IDE with an average banal language. "Balance" is lost somewhere in the middle.
And here is the fact: a good language will always sooner or later be able to follow this diagram from the “many good features” point to the “many good features and tools” point. So in the end, both language lovers and tool advocates will use good language with decent tools. I hope that the language Laszlo we are developing will also come to this someday.
All 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 a new language earlier, study it 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 will in fact guarantee you a result. The popularity of the tools is known, and their capabilities are also. Learned advanced debugger - get a 5% reduction in product development time. Nasobachilis use refactoring? +5 karma Configure Continous integration - a mountain from the shoulders!
With languages it's not like that. New languages have theoretical power, but it still needs to be justified. You can spend a month learning a new language and face the fact that it turns out to be unsuitable 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 tasks before you - it doesn't matter for 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 - just small pieces of working code are enough, you do not need a large team of specialists who need to be searched and hired somewhere - you are personally enough (well, maybe a couple of enthusiastic colleagues).
Another difference is the team engagement. It may be that someone on your Java project team will use Eclipse, someone will code in IntelliJ IDEA, and someone in a text editor. This is normal as long as the generated code is compiled and executed in the same way. However, if someone alone in your Java team suddenly decides to personally write Haskell, something is definitely going wrong.
Of course, there are also 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 constructions with the tools used, and for programmers who know both of them equally well. But this is about how to meet the glorified 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 means of a universal text editor until they receive full support in some kind of IDE. After some time, if the language is really “shot”, this support will undoubtedly appear. This is not because it is too difficult to make the necessary tools. This happens because investing efforts in developing a language and investing efforts in developing tools for it are located in several orthogonal planes and sometimes even crowd out each other. 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 like this:
In this diagram, the initial choice of programming language and its level of proficiency can have a profound effect on your productivity. The choice of IDE is not very important here - basically you will use the IDE as a simple text editor, possibly with rare exceptions. In this case, you will not use all those tools that offer modern IDE.
Instruments
On the other hand, if you spend most of your time studying development tools, you know what it is like to use the full power of an integrated editor and debugger, autocompletion tools, refactoring, modeling, design, testing, profiling, etc. Your picture of the world looks like this:
Having an IDE gives you significant advantages over a naked text editor. The choice of programming language, on the other hand, is not so important - you will by and large work with all the same classes and methods, variables and expressions, conditions and cycles. But the real strength of your style - in the speed of development, which will give you knowledge of the IDE.
Two camps
And where should I go if I want to be like that monkey in a joke - and smart and beautiful? Is it possible to be both knowledgeable and used programming language and tools? It's difficult. There are still 24 hours a day, and only 365 days a year. Every free minute can be devoted either to learning the language or tools. Each of these options will ultimately have a positive impact on your skill, but in different ways. These paths of development largely compete - for your attention, for your time, for your programming style. And in the end you get into 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 there is something in it that can help you a lot. To do this, you already have your favorite text editor, and the language has its compiler / interpreter - in fact, nothing more is needed.
Investing time in 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, but since writing them in the style of a classical OOP, is it not easier to do this in the previously used language, with its well-known specifics? Moreover, it seems to give a good development speed and a predictable result.
Thus, by paying more attention to the language, you somehow pay less attention to the tools (and vice versa). And each of these two paths will lead you sooner or later to one of two camps, with all its pluses and minuses.
At any given time, a programmer who has chosen a text editor as the main tool has a wider choice of programming language. All new languages have a compiler / interpreter, but not all of them also have support in some kind of IDE. The diagram below shows what it looks like 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 moment in time, the languages that have passed the “white-red” phase are larger than those who have completed the “red-violet” phase.
One consequence of this larger choice is the fact that this choice gives access to more powerful languages. Thus, a programmer who has staked on a text editor + knowledge of the language plays two factors at once: both the deepening of one’s own knowledge and the benefits of powerful new language features.
Dilemma of developers of programming languages
The most powerful programming languages often have the weakest tools. The reason for this is still the same - limited resources. The developer of a new language is not a wizard or a billionaire. Every free minute he has to think about where to spend it better - to improve the language, or to improve the tools for working with it.
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 finding balance (middle arrow). The arrows are about the same length (which means the same investment of resources) and therefore they end in completely different places in the diagram. The “language” arrow gives us a super-powerful language with a naked compiler / interpreter. "Instrumental" gives us a good IDE with an average banal language. "Balance" is lost somewhere in the middle.
And here is the fact: a good language will always sooner or later be able to follow this diagram from the “many good features” point to the “many good features and tools” point. So in the end, both language lovers and tool advocates will use good language with decent tools. I hope that the language Laszlo we are developing will also come to this someday.
The difficulties of the pioneers
All 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 a new language earlier, study it 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 will in fact guarantee you a result. The popularity of the tools is known, and their capabilities are also. Learned advanced debugger - get a 5% reduction in product development time. Nasobachilis use refactoring? +5 karma Configure Continous integration - a mountain from the shoulders!
With languages it's not like that. New languages have theoretical power, but it still needs to be justified. You can spend a month learning a new language and face the fact that it turns out to be unsuitable 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 tasks before you - it doesn't matter for 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 - just small pieces of working code are enough, you do not need a large team of specialists who need to be searched and hired somewhere - you are personally enough (well, maybe a couple of enthusiastic colleagues).
Another difference is the team engagement. It may be that someone on your Java project team will use Eclipse, someone will code in IntelliJ IDEA, and someone in a text editor. This is normal as long as the generated code is compiled and executed in the same way. However, if someone alone in your Java team suddenly decides to personally write Haskell, something is definitely going wrong.
Conclusion
Of course, there are also 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 constructions with the tools used, and for programmers who know both of them equally well. But this is about how to meet the glorified pianist, who is also an international chess grandmaster.
Source: https://habr.com/ru/post/160711/
All Articles