Why do we need "other" programming languages: maybe I can manage with the framework?
After reading the Hacker News discussion , I again seriously thought about programming languages. Does it matter, you only know one or a few? May I know 5 languages equally well? Or at least so well to say that I "know" them.
If we talk about object-oriented languages with static typing , in fact, the difference is small. The only thing really worth remembering is memory management . If there is a garbage collector , then there is no need to take care of pointers and delete objects. You donate part of the performance and memory (in fact, not always, as the garbage collector helps to avoid fragmentation and segmentation of memory, and you always have a busy part of memory, as well as memory for further distribution, separated by a pointer to the next free memory area ). However, a better understanding of the stack and heap, values, pointers, message between objects, comes from languages where there is no default garbage collector. In fact, you can use the garbage collector (as an example, Boehm GC ), but there are patterns, such as, say, smart pointers and pools that help manage memory, and be sure that objects are released. That is, there are things that can be learned from both "worlds": learn how to manage memory, as well as how to delegate control of memory, and understand what principles are used for garbage collection. It seems to me quite useful.
')
If we talk about dynamic languages , when you cannot be sure of the existence of a method or field before calling a program, it may not be so easy if you are used to compiling and detecting inconsistencies before launch. Dynamic languages allow us to expand objects, making the system more flexible, using impurities and adding functionality to standard classes. Ruby provides the ability to implement impurities through modules, declaring additional methods for a class. All these things are used widely in Rails. Active Record uses method_missing extensively , which in itself is a great idea. Kernel.autoload is also a convenient solution. Objects that are themselves factories in Ruby (the new / initialize method, essentially returning an object instance) also have a certain semantic meaning. It seems to me that all these things are a kind of patterns, and not just methods and features of the language, that is, these things can also be applied in other areas. The same applies to Traits in Scala . Ruby Gems and Packages in Python are also solutions to a specific range of problems (here you can also mention Aptitude , RPM , BSD Ports , with the ability to download source codes and headers for linking). S-expressions from Lisp were also successfully applied in C #, and this changed quite a lot, especially after the appearance of LINQ .
Reading code is one of the fundamental skills for developers. I know a few people who feel quite comfortable using "their" programming language, and do not even want to try to look at the possibilities of the others. But this is not so bad, right? Not certainly in that way. When learning a new language, people often begin to learn a set of libraries, or a framework, instead of learning the language itself. The fact is that if there is a freymork, well-written, and perfectly functioning, open source, you can open the code and look at its implementation, and understand the principles and practices applied there, instead of directly studying the tip of the iceberg - its API and functionality described in the tutorials.
I think everyone heard about the story with alias_method_chain in Rails / Ruby. Apparently, the same thing happened with the .NET model and the ViewState / Postback model, and saving the page state between downloads, when people stopped thinking about how it is better, easier and faster to implement in the world of Web development. The same can be said about models and view in Django (Python): when models and view view are stored by default, in fact, in two files: models.py and views.py, and many developers do not know, or cannot even share them . And great Expressions Trees in C #, which (it seems that) were only used by the LINQ / Enterprise Libraries team.
The next time you look at a new framework, regardless of what you are working on, ask yourself if you can _sami_ implement similar functionality. If not, look at the code, the implementation, try to understand for what reasons everything was done exactly the way it can be done better and more conveniently. I understand that this is not always possible, but Open Source development is becoming increasingly popular every day, and covering more and more tasks. Do not try to learn the framework. Learn the language. The API will change, and over time, you may have to change the code of the framework used to solve your own problems. As an example, what is the first thought that comes to mind when your JS selector is not working? If you google solving a problem, only half of the problem is solved. The second remains in place: the ability to read, understand, debug the code, get to the root of the problem, and implement the solution with your own hands.
New languages are cool and fun. You again think about the syntax, and change your perception. Thinking about how this problem can be solved in another language, you look at your code from a different point of view. It still seems to me that learning any language can help you understand more deeply the set of tools that you use now and find more elegant solutions. Studying the API, however, will allow you to feel comfortable for quite a long time, but will not bring significant benefits, since it is impossible to remember everything. The main thing is to understand how libraries are arranged, and what basic principles are applied in their development.
UPD: sylvio said sensible thing. You can learn a lot:
Not much sense to learn another framework and another method of solving something, you need to learn more general theories, which allow you to deduce these methods yourself, the theory of types, categories , sets, and so on.
However, to solve applied problems of the theory is not always sufficient. It is also required to know the existing solutions, from which you can push off, take as a basis. Applied tasks also require a good theoretical base, but it must be confirmed by experience in use.
What is the difference?
If we talk about object-oriented languages with static typing , in fact, the difference is small. The only thing really worth remembering is memory management . If there is a garbage collector , then there is no need to take care of pointers and delete objects. You donate part of the performance and memory (in fact, not always, as the garbage collector helps to avoid fragmentation and segmentation of memory, and you always have a busy part of memory, as well as memory for further distribution, separated by a pointer to the next free memory area ). However, a better understanding of the stack and heap, values, pointers, message between objects, comes from languages where there is no default garbage collector. In fact, you can use the garbage collector (as an example, Boehm GC ), but there are patterns, such as, say, smart pointers and pools that help manage memory, and be sure that objects are released. That is, there are things that can be learned from both "worlds": learn how to manage memory, as well as how to delegate control of memory, and understand what principles are used for garbage collection. It seems to me quite useful.
')
If we talk about dynamic languages , when you cannot be sure of the existence of a method or field before calling a program, it may not be so easy if you are used to compiling and detecting inconsistencies before launch. Dynamic languages allow us to expand objects, making the system more flexible, using impurities and adding functionality to standard classes. Ruby provides the ability to implement impurities through modules, declaring additional methods for a class. All these things are used widely in Rails. Active Record uses method_missing extensively , which in itself is a great idea. Kernel.autoload is also a convenient solution. Objects that are themselves factories in Ruby (the new / initialize method, essentially returning an object instance) also have a certain semantic meaning. It seems to me that all these things are a kind of patterns, and not just methods and features of the language, that is, these things can also be applied in other areas. The same applies to Traits in Scala . Ruby Gems and Packages in Python are also solutions to a specific range of problems (here you can also mention Aptitude , RPM , BSD Ports , with the ability to download source codes and headers for linking). S-expressions from Lisp were also successfully applied in C #, and this changed quite a lot, especially after the appearance of LINQ .
Reading code and applying practices
Reading code is one of the fundamental skills for developers. I know a few people who feel quite comfortable using "their" programming language, and do not even want to try to look at the possibilities of the others. But this is not so bad, right? Not certainly in that way. When learning a new language, people often begin to learn a set of libraries, or a framework, instead of learning the language itself. The fact is that if there is a freymork, well-written, and perfectly functioning, open source, you can open the code and look at its implementation, and understand the principles and practices applied there, instead of directly studying the tip of the iceberg - its API and functionality described in the tutorials.
I think everyone heard about the story with alias_method_chain in Rails / Ruby. Apparently, the same thing happened with the .NET model and the ViewState / Postback model, and saving the page state between downloads, when people stopped thinking about how it is better, easier and faster to implement in the world of Web development. The same can be said about models and view in Django (Python): when models and view view are stored by default, in fact, in two files: models.py and views.py, and many developers do not know, or cannot even share them . And great Expressions Trees in C #, which (it seems that) were only used by the LINQ / Enterprise Libraries team.
The next time you look at a new framework, regardless of what you are working on, ask yourself if you can _sami_ implement similar functionality. If not, look at the code, the implementation, try to understand for what reasons everything was done exactly the way it can be done better and more conveniently. I understand that this is not always possible, but Open Source development is becoming increasingly popular every day, and covering more and more tasks. Do not try to learn the framework. Learn the language. The API will change, and over time, you may have to change the code of the framework used to solve your own problems. As an example, what is the first thought that comes to mind when your JS selector is not working? If you google solving a problem, only half of the problem is solved. The second remains in place: the ability to read, understand, debug the code, get to the root of the problem, and implement the solution with your own hands.
Findings?
New languages are cool and fun. You again think about the syntax, and change your perception. Thinking about how this problem can be solved in another language, you look at your code from a different point of view. It still seems to me that learning any language can help you understand more deeply the set of tools that you use now and find more elegant solutions. Studying the API, however, will allow you to feel comfortable for quite a long time, but will not bring significant benefits, since it is impossible to remember everything. The main thing is to understand how libraries are arranged, and what basic principles are applied in their development.
UPD: sylvio said sensible thing. You can learn a lot:
Not much sense to learn another framework and another method of solving something, you need to learn more general theories, which allow you to deduce these methods yourself, the theory of types, categories , sets, and so on.
However, to solve applied problems of the theory is not always sufficient. It is also required to know the existing solutions, from which you can push off, take as a basis. Applied tasks also require a good theoretical base, but it must be confirmed by experience in use.
Source: https://habr.com/ru/post/101474/
All Articles