Better or worse
Translation of the article "For Better or For Worse" by a developer from DataDog Inc. The article is devoted to the question of the design of programming languages ​​and the connection of design with attempts to assess the quality of languages. This is in part a response to this article recently translated here .
In the programmer get-together, a meme appears about the “objective quality” of the Go design. Just the other day I met him in an article about the choice of languages ​​from Honza , where he was very clearly visible:
I think this is a very interesting set of contradictions , and the author agrees.
It would be hard to argue so confidently and confidently that Go is poorly designed if this opinion were not so common. Last year, a number of articles and blog posts laid the foundation for this opinion. Among them were the articles of people who do not love Go, because he does not allow them to feel smart or because there is nothing fundamentally new in it . They are sure that Go, deliberately ignoring certain advances in the design of programming languages, is in the past, from which the best languages ​​have gone far ahead. And they claim it very insistently .
')
When people with this vision try to explain Go's popularity, they inevitably come to a paradox. If Go is so bad, why is it so popular?
And in this case it is very difficult to fight with cognitive dissonance. Unlike other ridiculed but popular languages , Go was not imposed. He did not gain a critical mass in spite of his shortcomings , on a new platform, occupied mainly by amateurs and inexperienced developers. It was developed by the largest Internet company in the world , one of the most experienced programmers in history, and received its first turn of adoption in distributed infrastructure projects.
To get around this paradox, people usually either conclude that all fools (which, unfortunately, in programmer communities, it seems, are not uncommon), or that there were other factors contributing to Go adaptation. But the option that it may actually be good, if you look at this definition from a different angle, is usually not even considered.
This is a modern manifestation of what Richard P. Gabriel described in his classic essay “The Worse, the Better” . In it, Gabriel voiced 4 main values ​​of the system design, which may be in conflict: simplicity , correctness , consistency and completeness . He further describes two competing philosophies: the MIT approach, putting higher accuracy and consistency, and the New Jersey approach, putting simplicity above.
Even if it is possible to argue whether the post-factum approach of New Jersey is a description of Unix-philosophy, then you can definitely be sure that the creators of Go have clearly promoted simplicity as the leading element of their philosophy . The simplicity of implementation is a clearly formulated position both in the language itself and in the libraries , and this clear priority of simplicity over logic is sewn into the language.
Simplicity has probably become an even more recognized priority since writing an essay in 1990, as the computer world has changed dramatically .
To cope with growing volumes of data, computing and storage began to scale horizontally, and the logical result to cope with this was the trend toward simpler things. Systems praised in the old literature, like CORBA or ironically called SOAP , were eventually buried many times by simpler systems, whose failure modes were much less elegant, but the implementation was an order of magnitude simpler.
The way in which software is developed has also changed. A huge number of companies are built mostly on open source products, and they, in response, contribute to them. Because simple code is easier to write, read, debug, and maintain, simple languages ​​take advantage of being simpler to learn, which leads to more use, more libraries and contributors , increasing resilience in the short run and quality in the long run.
All this does not mean that simplicity necessarily implies a departure from the academic sphere into primitivism. Just complex things like Paxos are ultimately inferior to simpler things like Raft .
Despite the trend towards simplicity, discussions of programming languages ​​usually take place in the frame of the MIT approach. It was so successful and popular that it is imperceptible and even not obvious.
Complex type systems , in which the absence of the possibility of certain classes of errors has been formally proved, are praised, despite the resulting implementation complexity or cognitive load on the programmer. Consciously simplifying these systems is always viewed as a disadvantage, and not as a conscious compromise.
The problem is that this topic of assessing the quality of programming languages ​​has no obvious links with their effectiveness in writing real code.
Go's approach was to start with C, then throw out things that were difficult to use correctly, and fill in the gaps until there was nothing simple enough or enough orthogonal to add. Take the famous set of compromises, the known point on the continuum between simple and complicated, and make small changes based on dozens of accumulated years of practical development experience in the real world. This is an unforgivable straightforward engineering approach to building systems.
Of course, you can not put everything on the altar of simplicity. Many low-level bytecode and assembler languages ​​are easy to write and port, but their interfaces are too complex for programmers to use. It is necessary to achieve a balance between the number of features and the simplicity of the language.
And we have seen, and more than once, that systems that did not try to do this correctly, have interfaces that are too complicated to use, and systems that have sacrificed simplicity for the sake of completeness are too complicated to be properly used. Systems on the complex side of the spectrum often achieve the “right” through undesirable approaches for practical reasons, or just pretend to do what is “right” . Enough useful abstractions will flow away , so it's best that their behavior is simple enough so that their consequences can be understood in advance. Errors have complexity commensurate with the complexity of the implementation of their systems.
It may take years to find out what the jury decides about Go. There are no simple and clear ways to measure how “good” a language is, so this is ultimately determined by how popular systems thrive, and not popular ones wither and die. Contrary to his detractors, Go’s popularity continues to grow thanks to its strengths, which means that it deserves more time to evaluate. If his apparent weaknesses are real, we will certainly see them in the real world, as the systems created on it reach maturity, but so far the prospects are very good.
But what we see is that Go choose projects that even 5 years ago were not even possible because of the terrible situation with the tools in their niche. Even if Go ultimately fails, the longer it grows, the more likely it is that the next generation of languages ​​will start with Go, just like Go started with C, and given the family lineage and remaining strength, I would say that it will be a huge success.
In the programmer get-together, a meme appears about the “objective quality” of the Go design. Just the other day I met him in an article about the choice of languages ​​from Honza , where he was very clearly visible:
Consider, the language is objectively very poorly designed. [...] And, at the same time, Go is much more popular than Haskell, according to GitHub. At the same time, there are already so many great projects written on Go, like Docker, InfluxDB, etcd, Consul, Prometheus, packer and others.
I think this is a very interesting set of contradictions , and the author agrees.
It would be hard to argue so confidently and confidently that Go is poorly designed if this opinion were not so common. Last year, a number of articles and blog posts laid the foundation for this opinion. Among them were the articles of people who do not love Go, because he does not allow them to feel smart or because there is nothing fundamentally new in it . They are sure that Go, deliberately ignoring certain advances in the design of programming languages, is in the past, from which the best languages ​​have gone far ahead. And they claim it very insistently .
')
When people with this vision try to explain Go's popularity, they inevitably come to a paradox. If Go is so bad, why is it so popular?
And in this case it is very difficult to fight with cognitive dissonance. Unlike other ridiculed but popular languages , Go was not imposed. He did not gain a critical mass in spite of his shortcomings , on a new platform, occupied mainly by amateurs and inexperienced developers. It was developed by the largest Internet company in the world , one of the most experienced programmers in history, and received its first turn of adoption in distributed infrastructure projects.
To get around this paradox, people usually either conclude that all fools (which, unfortunately, in programmer communities, it seems, are not uncommon), or that there were other factors contributing to Go adaptation. But the option that it may actually be good, if you look at this definition from a different angle, is usually not even considered.
The worse the better
This is a modern manifestation of what Richard P. Gabriel described in his classic essay “The Worse, the Better” . In it, Gabriel voiced 4 main values ​​of the system design, which may be in conflict: simplicity , correctness , consistency and completeness . He further describes two competing philosophies: the MIT approach, putting higher accuracy and consistency, and the New Jersey approach, putting simplicity above.
Even if it is possible to argue whether the post-factum approach of New Jersey is a description of Unix-philosophy, then you can definitely be sure that the creators of Go have clearly promoted simplicity as the leading element of their philosophy . The simplicity of implementation is a clearly formulated position both in the language itself and in the libraries , and this clear priority of simplicity over logic is sewn into the language.
Simplicity has probably become an even more recognized priority since writing an essay in 1990, as the computer world has changed dramatically .
To cope with growing volumes of data, computing and storage began to scale horizontally, and the logical result to cope with this was the trend toward simpler things. Systems praised in the old literature, like CORBA or ironically called SOAP , were eventually buried many times by simpler systems, whose failure modes were much less elegant, but the implementation was an order of magnitude simpler.
The way in which software is developed has also changed. A huge number of companies are built mostly on open source products, and they, in response, contribute to them. Because simple code is easier to write, read, debug, and maintain, simple languages ​​take advantage of being simpler to learn, which leads to more use, more libraries and contributors , increasing resilience in the short run and quality in the long run.
All this does not mean that simplicity necessarily implies a departure from the academic sphere into primitivism. Just complex things like Paxos are ultimately inferior to simpler things like Raft .
Nature of quality
Despite the trend towards simplicity, discussions of programming languages ​​usually take place in the frame of the MIT approach. It was so successful and popular that it is imperceptible and even not obvious.
Complex type systems , in which the absence of the possibility of certain classes of errors has been formally proved, are praised, despite the resulting implementation complexity or cognitive load on the programmer. Consciously simplifying these systems is always viewed as a disadvantage, and not as a conscious compromise.
The problem is that this topic of assessing the quality of programming languages ​​has no obvious links with their effectiveness in writing real code.
Go's approach was to start with C, then throw out things that were difficult to use correctly, and fill in the gaps until there was nothing simple enough or enough orthogonal to add. Take the famous set of compromises, the known point on the continuum between simple and complicated, and make small changes based on dozens of accumulated years of practical development experience in the real world. This is an unforgivable straightforward engineering approach to building systems.
Of course, you can not put everything on the altar of simplicity. Many low-level bytecode and assembler languages ​​are easy to write and port, but their interfaces are too complex for programmers to use. It is necessary to achieve a balance between the number of features and the simplicity of the language.
And we have seen, and more than once, that systems that did not try to do this correctly, have interfaces that are too complicated to use, and systems that have sacrificed simplicity for the sake of completeness are too complicated to be properly used. Systems on the complex side of the spectrum often achieve the “right” through undesirable approaches for practical reasons, or just pretend to do what is “right” . Enough useful abstractions will flow away , so it's best that their behavior is simple enough so that their consequences can be understood in advance. Errors have complexity commensurate with the complexity of the implementation of their systems.
It may take years to find out what the jury decides about Go. There are no simple and clear ways to measure how “good” a language is, so this is ultimately determined by how popular systems thrive, and not popular ones wither and die. Contrary to his detractors, Go’s popularity continues to grow thanks to its strengths, which means that it deserves more time to evaluate. If his apparent weaknesses are real, we will certainly see them in the real world, as the systems created on it reach maturity, but so far the prospects are very good.
But what we see is that Go choose projects that even 5 years ago were not even possible because of the terrible situation with the tools in their niche. Even if Go ultimately fails, the longer it grows, the more likely it is that the next generation of languages ​​will start with Go, just like Go started with C, and given the family lineage and remaining strength, I would say that it will be a huge success.
Source: https://habr.com/ru/post/270981/
All Articles