Forums before death by AOL, social media and spammers... "We can't have nice things"
|    alt.os.development    |    Operating system development chatter    |    4,255 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,050 of 4,255    |
|    mutazilah@gmail.com to Alexei A. Frounze    |
|    Re: subc    |
|    30 Jan 22 20:31:21    |
      From: muta...@gmail.com              On Monday, January 31, 2022 at 6:40:25 AM UTC+11, Alexei A. Frounze wrote:              > I'm not willing to make improvements into Smaller C myself       > because Smaller C suffers from the same design problems that       > SubC and the original Small C (by Hendrix and Cain) do.       > It's hard to modify it in order to extend and improve significantly       > beyond what's already there.              Interesting.              > Yep, there are many different design problems that       > are very limiting further development. It's more fruitful to       > redo the bad design and rewrite the implementation.              Yes, it would be great if someone was willing to sit       down and write the 400,000 lines of GCC 3.2.3 and       release it to the public domain.              It hasn't happened in the last 50 years and I'm not       particularly expecting that to change (although       gcc 3.2.3 will eventually fall into the public domain       if you can figure out who the longest-living author       is, wait for them to die, then wait another 70 years).              We have to work within this natural phenomenon.              There is a small number of people, close to 1, who have the       skills required to write a C compiler and a willingness to       release that unconditionally.              Then there are a small number of people, possibly also       close to 1, who actually appreciate that and are willing to       use that inferior product rather than gcc/Visual C/clang.              So for it "to happen" you can't just choose the perfect       option. You have to make tough decisions within       realistic choices.              I can live with int = long = short = 32-bits. That doesn't       stop it from being C90-compliant. In my natural coding       style I never code "short" anyway.              I also never use floating point and I'm surprised C90       puts a burden to support complicated mathematical       functions. My response to that is to trim C90. I'm doing       something different from "the market" which is racing       ahead with new versions of the C standard, or entirely       new languages.              So what is achievable within the constraints which I may       or may not have sufficiently outlined.              BFN. Paul.              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca