Comment by mesrik
3 hours ago
Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster.
It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently.
Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.
Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above.
ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.
Yes there were alternatives.
What irks me is this mystical selling point, have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
As you point out, people are not curious enough for what is outside of their bubble and take the marketing message as is.
Even more so, when knowledge was spread via the local library and what magazines one could get their hands on.
>Yes there were alternatives.
Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.
Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.
>...have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.
That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.
But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?
While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.
That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.
But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.
So by that I'm wishing you a nice day, cheers.