home bbs files messages ]

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