Re: Embeddinator-4000 begetting an Ada-cross-platform future?

["Dan'l Miller" <optikos@verizon.net>]

Dan'l Miller wrote:
> > Anyone can have another open-source Ada compiler whenever so desire: 
> > 1) Fork the FSF copy, so as to (apparently?) have the proper license. 
Shark8 wrote:
> Why? This will inherit *ALL* of GNAT's flaws and limitations.

Hence the aforementioned ASIS automation-assisted accumulation of refactorings.  Grind the concrete up into powder again; shape that soft clay quite differently.

Dan'l Miller wrote:
> > 2) Put an LLVM backend on it.  Either modernize Dragon Egg itself or conceptually repeat the entirety of Dragon Egg's old work differently in a more-modern release of GNAT and GCC. 
Shark8 wrote:
> You could do that with a non-GCC compiler. 

Of course.  For example, one of today's proprietary Ada compilers could do that.  (And if, for some reason, they wanted to change their business model, they could optionally open-source their new LLVM-backended Ada compiler.)

Dan'l Miller wrote:
> > 3) Indeed, even ASIS it to semi-automatedly drastically refactor/overhaul the Ada code in which GNAT is written.  Even do this gratuitously for no reason to inhibit merging it back into FSF easily (unless someone else develops the anti-refactorer to recursively unwind the deeply-accumulated divergent ASIS-assisted refactorings). 
Shark8 wrote:
> This seems a bit convoluted; I'm not sure I get your meaning, or purpose here.

Instead of starting from a blank text editor like you apparently did, one could start with GNAT and then drastically drastically overhaul it top to bottom.  The biggest downside would be the derivative-work result couldn't be any license other than GMGPL (or worse GPL).

Dan'l Miller wrote:
> > 4) Always contribute all such evolution in GPL-compliant ways, such as on GitHub. 
Shark8 wrote:
> *SIGH* -- There's the start of a MIT-licensed compiler, Byron, I have on GitHub. -- https://github.com/OneWingedShark/Byron -- but there's only one contributor. 

My step 4 was predicated on the prior steps.  Of course, if you start with a blank text editor instead of GNAT, then yes, you can contribute the open-source Ada compiler under some other license than GMGPL (or GPL).  Btw, awesome initiative & effort!  There was a time 3 decades ago where Andrew Tannenbaum was at the same point with Minix, which Linus Torvalds then extended into Linux.  Big things can start with a single passionate individual acting alone (assuming the Andrew Tannenbaum didn't have all his grad students helping him out immensely).

> > 5) Go merrily on your way, never looking back at FSF (or at AdaCore). 
> Why even look to them to begin with? 

When starting with a blank text editor as you apparently have, then correct, you want to clean-room your design so that you don't (even subconsciously) mimic anything in GNAT, so that you don't create a (GMGPLed or GPLed) derivative work.  But for the technique that I enumerated in this thread, one would intimately critique each and every design decision in GNAT to perhaps drastically alter it via the aforementioned ASIS-assisted refactorings.

Dan'l Miller wrote:
> > The big problem is never begetting the open-source repository itself for a 2nd open-source Ada compiler. 
Shark8 wrote:
> Objectively false; see above. 
> The big problem is that there's only one contributor, and he's disgusted with his lack of progress. 

False in the world in which your logic is operating, but true outside of your start-from-a-blank-text-editor world.  (I am using modal logic's definition of possible-world logic there.  https://en.wikipedia.org/wiki/Possible_world )  Using the technique that I enumerated, a quite-different-than(-except-for-license)-GNAT Ada open-source compiler can be squirted out as the numerous accumulations of the ASIS-assisted refactoring in probably less than one person-year effort.  Perhaps 2 person-year effort to radically set a GNAT-derivative-work on an entirely different foundation of aggressive redesign.

Dan'l Miller wrote:
> > The big problem is how to fund an open-source business model.  (Hence, why closed-source business models arise for entirely-different not-GPLed source-code bases.) 
Shark8 wrote:
> Not really -- there's plenty that can be done with (a) support contracts, and/or (b) specialized/additional tooling. 

If scraping up sufficient funding is so easy, then scrape up $500,000 to hire 5 more developers for your OneWingedShark Ada compiler so that you aren't the lone contributor.  Or likewise, if wooing corporate subsidization is so easy, then go beg at one or more Fortune 1000 corporations who frequently contribute staff time to open-source repositories that are not their own (e.g., IBM).  Yes, once you own the means of production so to speak, then, yes, you can milk & milk & milk that cash cow.  The problem is scraping up enough hundreds of thousands or millions of dollars to write the cash cow in the first place, when starting from a blank text-editor.  Hence, my point of don't limit ourselves as a community to only fresh starts with a blank text editor, such as your own laudable effort.  You are one genome.  My aforementioned list of steps are another genome.  Survival of the species is best via diverse genomes, so that at least one survives the rigors of natural selection.  To everyone other than you & your fellow contributors, please think of what a drastically-rejiggered GNAT would look like (other than the one immutable chiseled-in-stone part:  GMGPL or GPL).

Dan'l Miller wrote:
> Conversely, I would pay relatively-small-but-still-substantial amounts of money (less than $1000 per year per seat) for a proprietary closed-source Ada toolchain so that I could write both nonportable/SDK-specific UI/UX and portable backend-processing libraries all in Ada on iOS, MacOS, and Android.   
Shark8 wrote:
> Turbo Pascal proved that a company could thrive by targeting small-businesses and hobbyists with relatively cheap compilers. 

Well, yes, but back in 1983 the bar was set very low though.  Philipe Kahn's TurboPascal only needed to be better than Microsoft's BASICA or GWBASIC •interpreters• (and better than Waterloo BASIC •interpreters• largely only on fellow-Canadian Commodore) and better than UCSD p-System Pascal's p-code •virtual machine•.  All existing (incongruent-)competitors were sitting-duck targets.  Had Waterloo/WATCOM released a far-more-expensive set of impressively-optimizing compilers corresponding to their interpreters a few years sooner (or had Microsoft bought the rights to Lattice Semiconductor's C compiler a few years sooner), Philipe Kahn's TurboPascal marketspace would have been shriveled to the size of a raisin.  People didn't buy TurboPascal because it was Pascal; they (and I) bought it because it was a •compiler-to-machine-code• of any language above assembly language and we couldn't afford Digital Research's/Intel's PL/M compiler.  We didn't buy TurboPascal because it was Pascal; we bought it because it was Turbo (and cheap).