The sources of complexity are not in the programming languages, they come from the nature of problem domains.
That's why domain specific languages shine, they offer few sentences but those are the one needed in the context of that problem domain.
That's also the reason why some languages are better than other for specific tasks and worst for others. For example: perl is very good for text matching and processing, but it might not be so good to build the abstractions needed for a given domain.
Even ASM language is preferred for coding some operations that are near to low level control of external devices (programming drivers for external hardware, controlling microchips) or bit-wise memory operations. And that's because it was designed to that problem domain.
Every programming paradigm has its own set of languages that fit better for the task.
Nevertheless it is true that in the history of programming a lot of unnecessary constructs have been built because the needed programming theory was not available or was not considered. Some examples are the goto sentences, and some people says that abstract clases (some computer scientists argue that abstract clases are not needed if the language has a good support of types, interfaces). Other experts are against of sentences that break the loop, because they say no sentence should contradict a previous one.
If the goal is to find the canonical set of sentences that allows to drive the complexity needed by a general purpose language then I am agree, it is an interesting work.
Nevertheless, if the goal if to go back to old programming paradigms just because the new ones are lacking some features then I am not so happy.
I have programmed the last 30 years, using a lot of this paradigms. There procedural programming paradigm lacked the capacity to easy handle a lot of complexity of the problem domain. I was already programming with structs when the object oriented paradigm came. A lot of people tough at first glance that objects where structs + methods. It took a time to see the additional benefits that OOP has for re-usability and driving the complexity of the problem domain. And that was only possible by mean of reading of the theory.
Per see, javascript is not a danger to the industry. The danger is that newcomers start to learn by javascript, and the past of the programming theory is forgotten.
There is a quotation that says "Those who cannot learn from history are doomed to repeat it".
I would say: If somebody wants to go back to procedural programming paradigm because his tech stack uses it, perfect. But he should be aware that is not the better way to handle the complexity of some problem domains. The complexity would crystallize in form of additional code and new concepts and abstractions. It would eventually precipitate over the solutions whose nature is from that problem domain.
Domain has been always the main the source of complexity, and a new paradigm won't be able to swipe off complexity just because it's more bullet-proof.
Coming from the reverse code engineering field, I would say that the keyword goto has still its use-cases, such as creating code obfuscator / protector (by using JMP in ASM).
But, as you said there are just "off" parts of some paradigms like the keyword goto that causes more harm than good in most scenarios.
I just hope that in the future we won't see developers promoting this paradigm for all kind of scenarios as we saw with TDD and micro-services!
Per see, javascript is not a danger to the industry. The danger is that newcomers start to learn by javascript, and the past of the programming theory is forgotten.
You know what I love about JS and Python?
They give us all the power (allow all different kind of syntax/paradigm in a simple way), then they tell us: "do what you want... however you want" :D
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The sources of complexity are not in the programming languages, they come from the nature of problem domains.
That's why domain specific languages shine, they offer few sentences but those are the one needed in the context of that problem domain.
That's also the reason why some languages are better than other for specific tasks and worst for others. For example: perl is very good for text matching and processing, but it might not be so good to build the abstractions needed for a given domain.
Even ASM language is preferred for coding some operations that are near to low level control of external devices (programming drivers for external hardware, controlling microchips) or bit-wise memory operations. And that's because it was designed to that problem domain.
Every programming paradigm has its own set of languages that fit better for the task.
Nevertheless it is true that in the history of programming a lot of unnecessary constructs have been built because the needed programming theory was not available or was not considered. Some examples are the goto sentences, and some people says that abstract clases (some computer scientists argue that abstract clases are not needed if the language has a good support of types, interfaces). Other experts are against of sentences that break the loop, because they say no sentence should contradict a previous one.
If the goal is to find the canonical set of sentences that allows to drive the complexity needed by a general purpose language then I am agree, it is an interesting work.
Nevertheless, if the goal if to go back to old programming paradigms just because the new ones are lacking some features then I am not so happy.
I have programmed the last 30 years, using a lot of this paradigms. There procedural programming paradigm lacked the capacity to easy handle a lot of complexity of the problem domain. I was already programming with structs when the object oriented paradigm came. A lot of people tough at first glance that objects where structs + methods. It took a time to see the additional benefits that OOP has for re-usability and driving the complexity of the problem domain. And that was only possible by mean of reading of the theory.
Per see, javascript is not a danger to the industry. The danger is that newcomers start to learn by javascript, and the past of the programming theory is forgotten.
There is a quotation that says "Those who cannot learn from history are doomed to repeat it".
I would say: If somebody wants to go back to procedural programming paradigm because his tech stack uses it, perfect. But he should be aware that is not the better way to handle the complexity of some problem domains. The complexity would crystallize in form of additional code and new concepts and abstractions. It would eventually precipitate over the solutions whose nature is from that problem domain.
I totally agree with you.
Domain has been always the main the source of complexity, and a new paradigm won't be able to swipe off complexity just because it's more bullet-proof.
Coming from the reverse code engineering field, I would say that the keyword
gotohas still its use-cases, such as creating code obfuscator / protector (by using JMP in ASM).But, as you said there are just "off" parts of some paradigms like the keyword
gotothat causes more harm than good in most scenarios.I just hope that in the future we won't see developers promoting this paradigm for all kind of scenarios as we saw with TDD and micro-services!
You know what I love about JS and Python?
They give us all the power (allow all different kind of syntax/paradigm in a simple way), then they tell us: "do what you want... however you want" :D