3 ms·

totally agreed; there is an abundance of research in the academic literature from the past 15 years that still have not been properly commercialized. technolog

totally agreed; there is an abundance of research in the academic literature from the past 15 years that still have not been properly commercialized. technology transfer between academia and industry is often a slow and bumpy process, but eventually the good ideas will find their way into the mainstream, i think (i don't know why you got down-voted for this comment; i just voted you back up)

InclinedPlane 16y ago
Mocking seems to me to be a perfect example. Of how obvious it is that we are fighting against the flow with so many of our tools and we are merely lacking the advances in language design which embrace these use cases at their heart. It seems very similar to the clumsy, piece-meal attempts at procedural programming through the use of various macros and such-like in the early era of programming, and later of the attempts at object orientation through various techniques and conventions. But none of those efforts were able to fully exploit the potential of procedural programming or object orientation. You can't just bolt such fundamental shifts in programming idiom and practice onto existing languages and expect to achieve maximum potency. It often takes new languages, which have internalized the "paradigm shift", to fully achieve the potential of transformative development methodologies. No amount of assembler macros can be as elegant or as effective in facilitating procedural programming as the C language, for example. Similarly, you aren't going to create Python within C unless you already have the idea of Python to work with. I suspect that these aspects (mocking and unit testing especially) will become ingrained in future languages to degrees we can hardly imagine. I suspect that unit testing will be as much a part of many future languages as loops, assertions, and methods are today, and that running unit tests will be such an integral part of the build process that it will take explaining to describe how it's even possible for them to be apart. Unfortunately, I think too many language designers are too satisfied with the current state of affairs and don't see the future in these terms.

InclinedPlane 16y ago

Mocking seems to me to be a perfect example. Of how obvious it is that we are fighting against the flow with so many of our tools and we are merely lacking the advances in language design which embrace these use cases at their heart. It seems very similar to the clumsy, piece-meal attempts at procedural programming through the use of various macros and such-like in the early era of programming, and later of the attempts at object orientation through various techniques and conventions. But none of those efforts were able to fully exploit the potential of procedural programming or object orientation. You can't just bolt such fundamental shifts in programming idiom and practice onto existing languages and expect to achieve maximum potency. It often takes new languages, which have internalized the "paradigm shift", to fully achieve the potential of transformative development methodologies. No amount of assembler macros can be as elegant or as effective in facilitating procedural programming as the C language, for example. Similarly, you aren't going to create Python within C unless you already have the idea of Python to work with. I suspect that these aspects (mocking and unit testing especially) will become ingrained in future languages to degrees we can hardly imagine. I suspect that unit testing will be as much a part of many future languages as loops, assertions, and methods are today, and that running unit tests will be such an integral part of the build process that it will take explaining to describe how it's even possible for them to be apart. Unfortunately, I think too many language designers are too satisfied with the current state of affairs and don't see the future in these terms.