It’s interesting, and also somewhat shocking, to hear that the largest part of programmers did not feel that programming in machine language was something that they should improve upon.
I feel very much the same way with respect to hardware design languages. I find VHDL (and Verilog, for that matter) to be insanely limited and have been looking for an alternative. Recently, I started using SpinalHDL for work purposes and cannot possibly imagine going back to the old ways. By my own estimates I am between 2-5 x more productive, depending on type of work. Some logic I would have never started writing in VHDL because opportunity cost is just too high. Most seasoned HDL engineers I tell about the language are, however, totally unimpressed. To them it seems like a risk that, even if taken, will not gain them much.
It’s interesting, and also somewhat shocking, to hear that the largest part of programmers did not feel that programming in machine language was something that they should improve upon.
Here is Edsger W. Dijkstra, in his 1972 ACM Turing Award lecture, illustrating your observation. (Emphasis added.)
Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque. I have run a a little programming experiment with really experienced volunteers, but something quite unintended and quite unexpected turned up. None of my volunteers found the obvious and most elegant solution. Upon closer analysis this turned out to have a common source: their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious. Their solutions were less efficient, needlessly hard to understand, and it took them a very long time to find them. It was a revealing, but also shocking experience for me.
This sort of thing is a good reminder that tech-savvy people are just as prone to conservatism as anybody else. We are all in favor of disrupting existing systems, as long as they aren’t the ones we have grown accustomed to.
It’s interesting, and also somewhat shocking, to hear that the largest part of programmers did not feel that programming in machine language was something that they should improve upon.
I feel very much the same way with respect to hardware design languages. I find VHDL (and Verilog, for that matter) to be insanely limited and have been looking for an alternative. Recently, I started using SpinalHDL for work purposes and cannot possibly imagine going back to the old ways. By my own estimates I am between 2-5 x more productive, depending on type of work. Some logic I would have never started writing in VHDL because opportunity cost is just too high. Most seasoned HDL engineers I tell about the language are, however, totally unimpressed. To them it seems like a risk that, even if taken, will not gain them much.
It also reminds me of the blub paradox: https://wiki.c2.com/?BlubParadox
Here is Edsger W. Dijkstra, in his 1972 ACM Turing Award lecture, illustrating your observation. (Emphasis added.)
Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque. I have run a a little programming experiment with really experienced volunteers, but something quite unintended and quite unexpected turned up. None of my volunteers found the obvious and most elegant solution. Upon closer analysis this turned out to have a common source: their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious. Their solutions were less efficient, needlessly hard to understand, and it took them a very long time to find them. It was a revealing, but also shocking experience for me.
This sort of thing is a good reminder that tech-savvy people are just as prone to conservatism as anybody else. We are all in favor of disrupting existing systems, as long as they aren’t the ones we have grown accustomed to.
Since people in the early days were so opposed to high level languages I wonder if Forth would have taken off if it were available a decade earlier…