> we can't really measure a new language until its been put to use by a lot people, encouraging an ecosystem of libraries and tools
Programming languages are just a raw material, like wood, or an alloy, or chemical. They have to be applied in a specific way to have a specific result. A "language" on its own doesn't matter. I could write you the same application in 5 different programming languages, just like I could build you the same building with 5 different raw materials.
Once you decide to use wood, you have to figure out how you're going to build with wood.
Again, in the olden days, this was a bespoke process, like it is today with programming. Are you going to timber-frame? Stick-frame? How tall will it be? Will you use wood joinery or metal fasteners? How will you reinforce it? How heavy will it be? Will you need special equipment or teams of people to move materials? Then you have to get your materials prepared; your beams cut to size, your metal fasteners of the right length, your mortises and tenons cut. Then finally you can assemble it all.
Compare that to programming. Again, you have to figure out how you're going to use the language. What modules you will use, what libraries, what software architecture, what APIs, what protocols, etc. Then you collect your materials and fit it all together.
The difference is this: with modern buildings, most of how you put the pieces together is already specified. An architect still needs to draw the plans up, but building it is pre-determined - not by the builders, but by the building code. You know for a wall plate you're going to need 10d nails. You know your floor joists must be 12, 16, or 24 inches on center, and you know how thick your subfloor needs to be for each. You do not deviate. For a given material, in a given place, for a given application, somebody has already determined how you will build it.
Another big problem with software is the lack of specialization. Most often I see teams of random software developers doing all kinds of things they're unqualified for. People who're clueless about system architecture, defining the architecture of the software. People building the applications without knowing what they will end up looking like. This is insane! Imagine if you just sent some random DIYers to build a house, with no plans, with no building code. The result would be an absolute mess. Of course they would need to stay employed for years, constantly fixing and bolting-on things to cover up their mess.
The "software world" has been an asylum run by the inmates for far too long. We don't need to constantly change languages. They're all about the same anyway! Rewrite an application from one language to another, and it just has a different set of bugs. The only reason it's done this way is we allow software developers unnecessary free reign, because we have no other choice, because it's just a guild of craftspeople building things however they want. Standardization should force a set of materials and a way of building, regardless of the personal whims of the programmers. The result may not be "fun" (which seems to be the primary priority of all programmers, over anything else), but it will result in lower cost, faster building, and more reliable results.
Programming languages are just a raw material, like wood, or an alloy, or chemical. They have to be applied in a specific way to have a specific result. A "language" on its own doesn't matter. I could write you the same application in 5 different programming languages, just like I could build you the same building with 5 different raw materials.
Once you decide to use wood, you have to figure out how you're going to build with wood.
Again, in the olden days, this was a bespoke process, like it is today with programming. Are you going to timber-frame? Stick-frame? How tall will it be? Will you use wood joinery or metal fasteners? How will you reinforce it? How heavy will it be? Will you need special equipment or teams of people to move materials? Then you have to get your materials prepared; your beams cut to size, your metal fasteners of the right length, your mortises and tenons cut. Then finally you can assemble it all.
Compare that to programming. Again, you have to figure out how you're going to use the language. What modules you will use, what libraries, what software architecture, what APIs, what protocols, etc. Then you collect your materials and fit it all together.
The difference is this: with modern buildings, most of how you put the pieces together is already specified. An architect still needs to draw the plans up, but building it is pre-determined - not by the builders, but by the building code. You know for a wall plate you're going to need 10d nails. You know your floor joists must be 12, 16, or 24 inches on center, and you know how thick your subfloor needs to be for each. You do not deviate. For a given material, in a given place, for a given application, somebody has already determined how you will build it.
Another big problem with software is the lack of specialization. Most often I see teams of random software developers doing all kinds of things they're unqualified for. People who're clueless about system architecture, defining the architecture of the software. People building the applications without knowing what they will end up looking like. This is insane! Imagine if you just sent some random DIYers to build a house, with no plans, with no building code. The result would be an absolute mess. Of course they would need to stay employed for years, constantly fixing and bolting-on things to cover up their mess.
The "software world" has been an asylum run by the inmates for far too long. We don't need to constantly change languages. They're all about the same anyway! Rewrite an application from one language to another, and it just has a different set of bugs. The only reason it's done this way is we allow software developers unnecessary free reign, because we have no other choice, because it's just a guild of craftspeople building things however they want. Standardization should force a set of materials and a way of building, regardless of the personal whims of the programmers. The result may not be "fun" (which seems to be the primary priority of all programmers, over anything else), but it will result in lower cost, faster building, and more reliable results.