Are there any reasons to use a statically typed functional programming language?
In fact, in a sense, this question does not make sense in 2010, when most (or most of the most common) languages are languages of many paradigms. Why limit yourself only functional programming? Perhaps someone will find the answer obvious, but if such articles appear as " Ten reasons not to use a statically typed functional programming language, " then you will have to discuss and explain the opposite point of view. "Ten reasons ..." are based on irony and, it seems, the author implies that these shortcomings do not even require discussion, but only ironic remarks. But it is not, let's go for these ten reasons.
The most ridiculous reason. And, strictly speaking, why should I follow the trends? And how? Multithreading for some was a discovery in the 2000s (although the problem itself existed before) and seemed to be a trend. But some people still haven't come across it so far. Not because they are not “fashionable” (ie, in trend) programmers, there were simply no such tasks: either a single-user application, or the container was watching it. And someone did not have time to saddle Web programming, someone did not have time to follow mobile developments. Can you as a developer keep up with all the trends at once? You can, but you have a choice: either pick up on the tops, or delve into one topic. Or be in the middle. But not all at the same time. Perhaps it was meant that the functional approach is so fundamental that any programmer should know about it. This is more like the truth, but there is no need to appeal to trends.
But is this trend so important? And is it possible to convince someone that “a new fashionable language will soon conquer the world”? It may be a revelation to someone, but the syntax or style of the language has rarely been the basis for distribution or popularity. Perhaps in the '60s and' 80s, when various programming styles just appeared, but not now. Let's look at the list of the most common (popular) languages at the moment:
C / C ++ - Although both of their popularity should be grateful to the syntax, but this is a matter of the distant past. Yes, the C syntax allowed us to write more compact code (but unlike the arguments in favor of a functional language, it provided a shorter expression for the same language constructs that existed before, and did not remove them at all). Yes, the C ++ syntax was, in a sense, “syntactic sugar” over C, which resented adherents of C and for a long time there were disputes about performance C against C ++. But, in the end, this pair of languages is still alive, because a lot of compilers have been created for various platforms, and they are a natural choice for anyone who is interested in performance, first of all, since the output is an executable file.
')
Objective-C - Popularity is based on binding to the Apple platform.
Java - Practically at least a new syntax compared to C ++, but “once written, it will start everywhere” (and, yes, it works). Plus applets (which eventually failed, but which were precursors of Flash and HTML5). Plus, mobile development (because I needed a language with portability for very different phones). In addition, I found a niche on the server side and enterprayze.
C # - Another clone of C ++, all the “sugar” appeared later, and the prevalence is based on binding to Windows. Mono? Are you sure that the task of launching absolutely any program written in C # will ever be achieved? And this is taking into account that .Net is developing with its speed, while Mono is trying to keep up. In addition, many libraries are very much tied to Windows.
PHP / Ruby - Two languages that are tied to Web development. Many people do not like the fact that they are in the same pair, but this is the harsh truth of life. And, by the way, dislike for PHP among a certain number of programmers is explained by the “bad” syntax of the language. What does not prevent it from being more popular than any functional language. Although, paradoxically, but PHP became popular precisely because of the “simple” syntax and rapid development of Web applications.
JavaScript - Another language linked to the Web, but on the browser side. And with which, you want - you don't want, almost any Web developer should be familiar. But there are miscalculations in design. And nothing lives. Moreover, in recent years, he even began to live outside the browser and be a separate language. Why? How is it worse Python?
Python / Perl - Two languages that were originally "scripting" (as an alternative to Shell languages) and Web-oriented. But, gradually, Perl began to die off, precisely because of its shorter and sometimes esoteric syntax. Think about it. There is still some sort of syntax brevity.
Visual Basic - Binding to the Windows / Office platform.
Shell - Binding to Unix.
Assembler - Ability to write the most effective code for any device. Again, in many ratings, more popular than any functional language.
The conclusion is obvious: languages have become popular / widespread not through syntax, but through practical application. The current trend of using functional programming is not based on the “unexpected” discovery of the functional style itself, but on the fact that OOP purists did not add functionality to languages, although initially they included elements of OOP and procedural programming.
If you get paid for the lines of code, then you should definitely change jobs, if only because if management incorrectly assesses work efficiency (as in this case), then you may have problems in the future.
Speaking seriously, what are “lines of code”? For example, I have an application with 100 lines of code, I found a library that reduced them to 5. And no functional programming. And maybe I even found 5 more libraries that do the same and reduce the code to 3, 7, 10, 15 and 8 lines of code. Whether to choose the shortest or which has the best support, more options, provides better performance, etc.?
If to speak even more seriously, for some reason, many consider brevity to be an unambiguous advantage of the code. Yes, we have seen odious examples of such “beauty” in C, Pearl and other languages. All this is beautiful for a joke or charade, but not for long-term development. Who can read and understand correctly? Who will support? Why do some people draw an analogy between “short code” and “good code”? Sometimes she is, sometimes she is not.
In many cases, the brevity and clarity of the code are polar concepts. The shorter the code, the more confusing it is, and the more clearly everything is written, the clearer it is. Although it happens the other way around. Is it possible at the same time short and clear code? It depends on what you mean. Look at the natural language. Is it possible to express the meaning of the novel in one phrase? Probably you can, just come out funny. Is it possible to substitute the participle verb or other structure? Of course, it is possible, but this is a matter of style - and you always have a choice in natural language.
And does brevity depend on a programming language? If you have three calls to functions or methods that describe the behavior of the domain, then you cannot simply take and replace them with one if this is not possible. And if possible, it’s not a problem to reduce them in any programming language. And does it really depend a lot on the syntax of a programming language? If you have to write your own algorithm, then either you do not know about the existence of a library that solves this problem, or there is no such library in your programming language, or you have not written your own library that solves this problem. A library call looks the same in almost any language, with the exception of ryushechek in the form of punctuation.
Surprised by this "serious" argument. If you work with the language for quite a long time, then you automatically put all the brackets, and often the editor itself does it for you. So what difference does it make or not? Moreover, many believe that even in a single-line block of code (after a condition or iteration) it is necessary to put curly brackets so that the boundaries of the block are clearly visible and that there are fewer errors when the code is inserted into the wrong block.
I do not like to see explicit types, but I love that the compiler sees explicit types. I don't want him to lose control of the types. It protects me in many situations. But, of course, it's beautiful when the types are implicit and everything somehow works behind the scenes. But the price of beauty: the loss of control over how it all works. And in many cases, the price of beauty is performance and implicit operations. And yes, I want to see that the method will return to me from a library that I did not write, or even say a type of expression that includes variables declared somewhere else in the program. I do not want to guess whether it will be a string or a list of objects.
Perhaps these are the most serious arguments. If this were true, then I think millions of developers would want to immediately switch to functional languages. But let me doubt that this is so. Why adherents of functional languages, believe that they have fewer bugs can be read here and here . Arguments come down to
- no null s (solved by static code analysis)
- immutable data (available in all programming languages, but this approach is not always possible, especially when it comes to performance and memory allocation problems)
- very strict type system (“very” is already a subjective word, therefore we leave this argument on the authors' conscience)
- composition of small functions (lambda functions already exist in C # and other languages, will soon be in Java)
- abstraction of asynchronous programming (this is only a question of abstraction, everything can be done using the library)
- higher order functions for collections (available in C # and other languages, and will be in Java)
- units of measure (valid for F #, not applicable to all tasks)
- the order of operations is clearly expressed in the code (no problem to use in any programming language, but in it we will have the choice to use this approach or not)
For some reason, all the errors here are reduced to more likely code or data errors, although from my experience, most of the errors are related more to behavior, rules, interaction between objects. What is the difference what programming language, if your algorithm turned out in field 5, but should be 3? Such errors are well treated not by “good” syntax, but by unit tests and development through testing. Although for adherents of the functional style, TDD is replaced by the REPL , but it is not clear how the REPL helps when the meaning of the code can change several times after writing?
These arguments are reminiscent of the promises of a “beautiful life” without bugs in tongues with garbage collectors. Yes, there are fewer incomprehensible memory bugs, but, by and large, they simply turned into a zero-point exception. Yes, memory leaks have become much less, but, by and large, they are still in long-lived applications. Of course, you began to think less about the distribution of memory, but you cannot say that you should not think about it at all.
Again an emotional argument. All this depends more on the developer, not on the language.
Very ambiguous argument. Imagine that you have a task to dig a hole, according to an algorithm you have an excavator. Analogue null-a - the absence of a digger. If not, then yes, I want the whole task to be interrupted, this is an exception. I do not want quiet execution, as if there is a digger, but the pit has not been dug. You will say that such situations are also monitored in functional languages. But, excuse me, what difference does it make: do I check null or something else? Good or bad, but checking for null sometimes has semantics, and is not just a check for the presence of an object. Yes, in any programming language, instead of null, you can return a dummy null value (Null object pattern), but think carefully about whether to do it: it's easier to catch an obvious error than an implicit one.
Is it a secret that many design patterns are the result of object-oriented programming features? And aren't closures, monads, or currying, also templates of functional programming only? And it is possible that many templates of functional programming still await us in the future - who knows?
This is also a rather emotional argument. Mathematics is in any programming language. Another thing is that in order to prove the beauty of functional programming, most often examples of pure mathematics are given, or only algorithmic problems (I don’t even know whether the entire sorting algorithm is mathematics or not). But who solves the algorithmic problems in the 2010s? Knuth's book is over 40 years old, and you still write sorting algorithms? Use libraries, do not reinvent the wheel.
I can not assess whether monads and functors are a problem for other people to understand, but if, yes, then functional programming is doomed to remain the lot of the elect. What should rather grieve than to please those chosen ones. The fewer people who can master these concepts, the less likely functional languages are. Lisp is already 50 years old, and he is still waiting for his finest hour. And also has always been the lot of the elect. Think about it.
Of course, the functional style has a bright future. Rather, it is surprising that it did not come even 20 years ago. And it is even more surprising to speak 60 years after the appearance of the first functional language.
Perhaps, designers of programming languages 20 years ago believed that an obvious confusion of concepts was fraught with problems or simply wanted to preserve the “purity” of languages. However, the 2010s are in the courtyard, and the languages of many paradigms run the show. And this is good. Because, by and large, whether to use “nouns” (as in OOP) or “verbs” (as in FP) in the first place is my choice. I do not want to choose between objects and functions, I want to use them, depending on the tasks at hand.
After all, the pure functional programming of many just scares its "beauty". Here it is useful to recall the story of Smalltalk, which is also a “clean” OOP language, unlike C ++, Java, C #. But that never “took off”, unlike languages, which did not reject elements of the procedural approach. Partly, because not all tasks require a “pure” approach, and sometimes it is not applicable at all. In addition, this usually involves the use of abstractions with implicit operations behind the scene, which usually threaten not very good performance. And, if in your practice you met with tasks to implement a GUI in a logical language (like the Prologue) or Web development on Lisp, then you yourself must present the whole complexity of “cramming in”. However, it is worth noting that F #, mentioned in the original article, is also a language of many paradigms, and not a “pure” functional language.
Perhaps you admire another trend: a multitude of programming languages based on JVM or .Net platforms. Of course, this is a plus, that you can write with any syntactic sugar, but receive the same byte-code. However, it all depends on the implementation of the programming language - it can use multi-way combinations for one call or be based on reflection, which is fraught with performance problems. Besides, who needs this variety of languages? Why do we need ten functional programming languages only with different brackets, commas and colons? No, in fact.
You can create a simple program in a new language in 1 day, learn to write more or less in 1 week, master in 1 month, and master well in 1 year. After all, the problem is not only in syntax, but also in numerous nuances, “correct” calls of “correct” functions, and much more. Why, you jump from one language to another? And if in each project? And if every half a year? Of course, this is an intellectual challenge. But whether all employers agree to pay for your internal needs for an intellectual challenge is a question. Although the matter is not even in employers, but even in you - because every time you have to simultaneously solve the problems of the subject area and the problems of entering a new programming language. And in return, you expect a hazy future (maybe you will never need a new language in the future) and the same hazy past (it is possible that you will already forget the experience of working with previous languages). Again, there is the problem of supporting the code - how to find a person who understands the code, or who could learn to understand in minimal time.
However, if you refer to history, then the Babylonian pandemonium of languages was always. Some were born, some were dying. Who remembers Algol or PL / 1 now? But there were still many others. Programming languages have their own evolution, and the strongest among them also survive. And the strongest are not languages with beautiful syntax, but which is necessary. Such a need for functional languages may be associated with reduced development time and fewer bugs, as described here . However, the evidence presented is based on certain projects in a vacuum, so it is absolutely incomprehensible what the numbers of the lines of code mean. Therefore, the answer to the article’s topic is rather “no more than yes, but the future will judge us.”
Reason 1. I do not want to follow the latest trends.
The most ridiculous reason. And, strictly speaking, why should I follow the trends? And how? Multithreading for some was a discovery in the 2000s (although the problem itself existed before) and seemed to be a trend. But some people still haven't come across it so far. Not because they are not “fashionable” (ie, in trend) programmers, there were simply no such tasks: either a single-user application, or the container was watching it. And someone did not have time to saddle Web programming, someone did not have time to follow mobile developments. Can you as a developer keep up with all the trends at once? You can, but you have a choice: either pick up on the tops, or delve into one topic. Or be in the middle. But not all at the same time. Perhaps it was meant that the functional approach is so fundamental that any programmer should know about it. This is more like the truth, but there is no need to appeal to trends.
But is this trend so important? And is it possible to convince someone that “a new fashionable language will soon conquer the world”? It may be a revelation to someone, but the syntax or style of the language has rarely been the basis for distribution or popularity. Perhaps in the '60s and' 80s, when various programming styles just appeared, but not now. Let's look at the list of the most common (popular) languages at the moment:
C / C ++ - Although both of their popularity should be grateful to the syntax, but this is a matter of the distant past. Yes, the C syntax allowed us to write more compact code (but unlike the arguments in favor of a functional language, it provided a shorter expression for the same language constructs that existed before, and did not remove them at all). Yes, the C ++ syntax was, in a sense, “syntactic sugar” over C, which resented adherents of C and for a long time there were disputes about performance C against C ++. But, in the end, this pair of languages is still alive, because a lot of compilers have been created for various platforms, and they are a natural choice for anyone who is interested in performance, first of all, since the output is an executable file.
')
Objective-C - Popularity is based on binding to the Apple platform.
Java - Practically at least a new syntax compared to C ++, but “once written, it will start everywhere” (and, yes, it works). Plus applets (which eventually failed, but which were precursors of Flash and HTML5). Plus, mobile development (because I needed a language with portability for very different phones). In addition, I found a niche on the server side and enterprayze.
C # - Another clone of C ++, all the “sugar” appeared later, and the prevalence is based on binding to Windows. Mono? Are you sure that the task of launching absolutely any program written in C # will ever be achieved? And this is taking into account that .Net is developing with its speed, while Mono is trying to keep up. In addition, many libraries are very much tied to Windows.
PHP / Ruby - Two languages that are tied to Web development. Many people do not like the fact that they are in the same pair, but this is the harsh truth of life. And, by the way, dislike for PHP among a certain number of programmers is explained by the “bad” syntax of the language. What does not prevent it from being more popular than any functional language. Although, paradoxically, but PHP became popular precisely because of the “simple” syntax and rapid development of Web applications.
JavaScript - Another language linked to the Web, but on the browser side. And with which, you want - you don't want, almost any Web developer should be familiar. But there are miscalculations in design. And nothing lives. Moreover, in recent years, he even began to live outside the browser and be a separate language. Why? How is it worse Python?
Python / Perl - Two languages that were originally "scripting" (as an alternative to Shell languages) and Web-oriented. But, gradually, Perl began to die off, precisely because of its shorter and sometimes esoteric syntax. Think about it. There is still some sort of syntax brevity.
Visual Basic - Binding to the Windows / Office platform.
Shell - Binding to Unix.
Assembler - Ability to write the most effective code for any device. Again, in many ratings, more popular than any functional language.
The conclusion is obvious: languages have become popular / widespread not through syntax, but through practical application. The current trend of using functional programming is not based on the “unexpected” discovery of the functional style itself, but on the fact that OOP purists did not add functionality to languages, although initially they included elements of OOP and procedural programming.
Reason 2. I get paid for lines of code.
If you get paid for the lines of code, then you should definitely change jobs, if only because if management incorrectly assesses work efficiency (as in this case), then you may have problems in the future.
Speaking seriously, what are “lines of code”? For example, I have an application with 100 lines of code, I found a library that reduced them to 5. And no functional programming. And maybe I even found 5 more libraries that do the same and reduce the code to 3, 7, 10, 15 and 8 lines of code. Whether to choose the shortest or which has the best support, more options, provides better performance, etc.?
If to speak even more seriously, for some reason, many consider brevity to be an unambiguous advantage of the code. Yes, we have seen odious examples of such “beauty” in C, Pearl and other languages. All this is beautiful for a joke or charade, but not for long-term development. Who can read and understand correctly? Who will support? Why do some people draw an analogy between “short code” and “good code”? Sometimes she is, sometimes she is not.
In many cases, the brevity and clarity of the code are polar concepts. The shorter the code, the more confusing it is, and the more clearly everything is written, the clearer it is. Although it happens the other way around. Is it possible at the same time short and clear code? It depends on what you mean. Look at the natural language. Is it possible to express the meaning of the novel in one phrase? Probably you can, just come out funny. Is it possible to substitute the participle verb or other structure? Of course, it is possible, but this is a matter of style - and you always have a choice in natural language.
And does brevity depend on a programming language? If you have three calls to functions or methods that describe the behavior of the domain, then you cannot simply take and replace them with one if this is not possible. And if possible, it’s not a problem to reduce them in any programming language. And does it really depend a lot on the syntax of a programming language? If you have to write your own algorithm, then either you do not know about the existence of a library that solves this problem, or there is no such library in your programming language, or you have not written your own library that solves this problem. A library call looks the same in almost any language, with the exception of ryushechek in the form of punctuation.
Reason 3. I love braces.
Surprised by this "serious" argument. If you work with the language for quite a long time, then you automatically put all the brackets, and often the editor itself does it for you. So what difference does it make or not? Moreover, many believe that even in a single-line block of code (after a condition or iteration) it is necessary to put curly brackets so that the boundaries of the block are clearly visible and that there are fewer errors when the code is inserted into the wrong block.
Reason 4. I love to see explicit types.
I do not like to see explicit types, but I love that the compiler sees explicit types. I don't want him to lose control of the types. It protects me in many situations. But, of course, it's beautiful when the types are implicit and everything somehow works behind the scenes. But the price of beauty: the loss of control over how it all works. And in many cases, the price of beauty is performance and implicit operations. And yes, I want to see that the method will return to me from a library that I did not write, or even say a type of expression that includes variables declared somewhere else in the program. I do not want to guess whether it will be a string or a list of objects.
Reason 5. I like to fix bugs.
Reason 6. I live in a debugger.
Perhaps these are the most serious arguments. If this were true, then I think millions of developers would want to immediately switch to functional languages. But let me doubt that this is so. Why adherents of functional languages, believe that they have fewer bugs can be read here and here . Arguments come down to
- no null s (solved by static code analysis)
- immutable data (available in all programming languages, but this approach is not always possible, especially when it comes to performance and memory allocation problems)
- very strict type system (“very” is already a subjective word, therefore we leave this argument on the authors' conscience)
- composition of small functions (lambda functions already exist in C # and other languages, will soon be in Java)
- abstraction of asynchronous programming (this is only a question of abstraction, everything can be done using the library)
- higher order functions for collections (available in C # and other languages, and will be in Java)
- units of measure (valid for F #, not applicable to all tasks)
- the order of operations is clearly expressed in the code (no problem to use in any programming language, but in it we will have the choice to use this approach or not)
For some reason, all the errors here are reduced to more likely code or data errors, although from my experience, most of the errors are related more to behavior, rules, interaction between objects. What is the difference what programming language, if your algorithm turned out in field 5, but should be 3? Such errors are well treated not by “good” syntax, but by unit tests and development through testing. Although for adherents of the functional style, TDD is replaced by the REPL , but it is not clear how the REPL helps when the meaning of the code can change several times after writing?
These arguments are reminiscent of the promises of a “beautiful life” without bugs in tongues with garbage collectors. Yes, there are fewer incomprehensible memory bugs, but, by and large, they simply turned into a zero-point exception. Yes, memory leaks have become much less, but, by and large, they are still in long-lived applications. Of course, you began to think less about the distribution of memory, but you cannot say that you should not think about it at all.
Reason 7. I don't want to think about every little thing.
Again an emotional argument. All this depends more on the developer, not on the language.
Reason 8. I like to check for null.
Very ambiguous argument. Imagine that you have a task to dig a hole, according to an algorithm you have an excavator. Analogue null-a - the absence of a digger. If not, then yes, I want the whole task to be interrupted, this is an exception. I do not want quiet execution, as if there is a digger, but the pit has not been dug. You will say that such situations are also monitored in functional languages. But, excuse me, what difference does it make: do I check null or something else? Good or bad, but checking for null sometimes has semantics, and is not just a check for the presence of an object. Yes, in any programming language, instead of null, you can return a dummy null value (Null object pattern), but think carefully about whether to do it: it's easier to catch an obvious error than an implicit one.
Reason 9. I apply design patterns everywhere.
Is it a secret that many design patterns are the result of object-oriented programming features? And aren't closures, monads, or currying, also templates of functional programming only? And it is possible that many templates of functional programming still await us in the future - who knows?
Reason 10. Too much math.
This is also a rather emotional argument. Mathematics is in any programming language. Another thing is that in order to prove the beauty of functional programming, most often examples of pure mathematics are given, or only algorithmic problems (I don’t even know whether the entire sorting algorithm is mathematics or not). But who solves the algorithmic problems in the 2010s? Knuth's book is over 40 years old, and you still write sorting algorithms? Use libraries, do not reinvent the wheel.
I can not assess whether monads and functors are a problem for other people to understand, but if, yes, then functional programming is doomed to remain the lot of the elect. What should rather grieve than to please those chosen ones. The fewer people who can master these concepts, the less likely functional languages are. Lisp is already 50 years old, and he is still waiting for his finest hour. And also has always been the lot of the elect. Think about it.
Conclusion
Of course, the functional style has a bright future. Rather, it is surprising that it did not come even 20 years ago. And it is even more surprising to speak 60 years after the appearance of the first functional language.
Perhaps, designers of programming languages 20 years ago believed that an obvious confusion of concepts was fraught with problems or simply wanted to preserve the “purity” of languages. However, the 2010s are in the courtyard, and the languages of many paradigms run the show. And this is good. Because, by and large, whether to use “nouns” (as in OOP) or “verbs” (as in FP) in the first place is my choice. I do not want to choose between objects and functions, I want to use them, depending on the tasks at hand.
After all, the pure functional programming of many just scares its "beauty". Here it is useful to recall the story of Smalltalk, which is also a “clean” OOP language, unlike C ++, Java, C #. But that never “took off”, unlike languages, which did not reject elements of the procedural approach. Partly, because not all tasks require a “pure” approach, and sometimes it is not applicable at all. In addition, this usually involves the use of abstractions with implicit operations behind the scene, which usually threaten not very good performance. And, if in your practice you met with tasks to implement a GUI in a logical language (like the Prologue) or Web development on Lisp, then you yourself must present the whole complexity of “cramming in”. However, it is worth noting that F #, mentioned in the original article, is also a language of many paradigms, and not a “pure” functional language.
Perhaps you admire another trend: a multitude of programming languages based on JVM or .Net platforms. Of course, this is a plus, that you can write with any syntactic sugar, but receive the same byte-code. However, it all depends on the implementation of the programming language - it can use multi-way combinations for one call or be based on reflection, which is fraught with performance problems. Besides, who needs this variety of languages? Why do we need ten functional programming languages only with different brackets, commas and colons? No, in fact.
You can create a simple program in a new language in 1 day, learn to write more or less in 1 week, master in 1 month, and master well in 1 year. After all, the problem is not only in syntax, but also in numerous nuances, “correct” calls of “correct” functions, and much more. Why, you jump from one language to another? And if in each project? And if every half a year? Of course, this is an intellectual challenge. But whether all employers agree to pay for your internal needs for an intellectual challenge is a question. Although the matter is not even in employers, but even in you - because every time you have to simultaneously solve the problems of the subject area and the problems of entering a new programming language. And in return, you expect a hazy future (maybe you will never need a new language in the future) and the same hazy past (it is possible that you will already forget the experience of working with previous languages). Again, there is the problem of supporting the code - how to find a person who understands the code, or who could learn to understand in minimal time.
However, if you refer to history, then the Babylonian pandemonium of languages was always. Some were born, some were dying. Who remembers Algol or PL / 1 now? But there were still many others. Programming languages have their own evolution, and the strongest among them also survive. And the strongest are not languages with beautiful syntax, but which is necessary. Such a need for functional languages may be associated with reduced development time and fewer bugs, as described here . However, the evidence presented is based on certain projects in a vacuum, so it is absolutely incomprehensible what the numbers of the lines of code mean. Therefore, the answer to the article’s topic is rather “no more than yes, but the future will judge us.”
Source: https://habr.com/ru/post/190838/
All Articles