From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Sun, 29 Nov 2015 07:57:58 +0200 From: lucio@proxima.alt.za In-Reply-To: <66535EFF-39F3-4BEE-9913-507DF4E660A7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 796515fc-ead9-11e9-9d60-3106f5b1d025 > I think the issue is trying to fix a broken problem. Perfect > compatibility is pretty much impossible, but most attempts done to fix > it just shift the pain to somewhere else. What's the quote about > complexity not disappearing, just moving around? Basically, increased CPU complexity provides increased performance, which is then used to provide features that only unskilled users could wish for. I once described the syndrome as "I can't figure how this application works, but the next release will be easier to use". I remember using AutoCad 2.6 on an 8086 with a floating point accelerator and being impressed by the speed of its 3D rendering. I have no idea how AutoCad behaves these days, but faster rendering would imply finishing before it even started. So where is the real improvement? Sadly, we developers buy all the hype just like uneducated users. Another example: I switched from XYWrite to Brief 1.something because the latter was as fast, but in addition it handled backspace in replace mode correctly (XYWrite pulled back the remainder of the line, where Brief actually replaced the precedingcharacter with a space and moved the cursor under it). Brief 2.1 was better, with worthwhile improvements, whereas 3.1 was a dog. I never promoted myself to it, No doubt, the developer had made enough money from users like me to afford a 386 PC and forgot that I would not have access to one :-( In summary, we have the resources, we may as well squander them. And those who can't afford them? "Let them eat cake!". Lucio.