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

[Shark8 <onewingedshark@gmail.com>]

On Thursday, March 1, 2018 at 12:09:07 PM UTC-7, Dan'l Miller wrote:
> 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).

But I never said the reason that Turbo Pascal was popular because it was a Pascal; I said that it was successful targeting small-business and hobbyists, which you actually confirm. 

> 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).
 
?? -- I said that there was room enough for support-contracts and/or specialized tools to make a profit. Your supposition [of easily scraping together $500,000] relies on ignoring the implicit prerequisite of having the product (eg compiler).

This isn't to say I'm dismissing the costs of development, but AdaCore operates under the "support contract" model [and already has the compiler] and some of its actions are... puzzling and honestly bad for both Ada and itself. (See, for example, how they quit doing the JVM and DOTNET backends; or how they brand Ada as [almost] an exclusively high-integrity or embedded language.)

I get what you;re saying about "diversity of species", but the flat fact of the matter is that insofar as Ada is concerned GNAT (be it FSF or AdaCore) is the *ONLY* free [and fully-functional] option, the *ONLY* Ada 2012 option, and certainly the most common implementation among hobbyists and small-business. -- For this reason it seems like your argument should be made against GNAT.

> please think of what a drastically-rejiggered GNAT would look like

It would likely suffer from the same architectural and design limitations like GNAT does. Things like the lack of a proper library, using instead the file-system, and being unable to process multiple compilation-units per file, and so on.

Also, there's been some weird regressions/bugs in GNAT that make me think certain things aren't properly handled; example: renaming attributes throws up a bug-box. (The advised solution is to use "NAME : Constant TYPE := Obj'ATTR;")

A further disadvantage to "intensive refactor" is the fact that such efforts are normally directed to "do the same thing" rather than actually evaluate if that thing is the best way of accomplishing the goal -- as a practical example consider Continuous Integration where the typical setup is "(1) pull the current repository, (2) build the entire thing, (3) on errors/bad-build issue an alert [usu. email]" -- the whole thing can be done with far less processing if you were to combine it into the repository function as described here ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf ) using a DB-tree as the repo, so that only consistent/compilable partitions are merged upwards in the DB-tree, resulting in the root-node always being consistent... combine this with existing DB-journaling and now you have a record of *ALL* successful builds.

> 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 ) 

I don't agree; but for the sake of argument I'll allow it.

> 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.

I don't know about this; while it might be theoretically possible, I haven't seen or heard of any ASIS refactoring too being used on this scale to this effect.

I know it's a point of disagreement between myself and several of my friends here on Comp.Lang.Ada, but I'm of the opinion that what we need is a standardized IR in the vein of AIR and/or DIANA -- actually a two-stage set of them -- one wherein the structures align to syntactically & semantically valid Ada, and a 'deeper'/more-general one where things are generalized and abstracted to allow a uniform composition (ie "Subtype Nybble is Integer range 0..15;", "Subtype Nybble is Integer with Static_Predicate => Nybble in 0..15, Predicate_Failure => Raise Constraint_Error;", and "Subtype Nybble is Integer with Static_Predicate => Nybble >= 0 and Nybble <= 15, Predicate_Failure => raise Constraint_Error;" should all be represented as the same thing [perhaps with some flag indicating which style is in source].)

> 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!

Thank you.
Though I'll admit to being stuck/frustrated on part of the parser -- it's *almost* working, and yet so far away...


> 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).

The GPL license is one of the reasons that small-businesses are steered away from Ada -- in short, the viral nature makes them quite leery of using Ada at all because, from their perspective, the license is all legal liability and doesn't protect them. (There've been several instances of this coming up right here on comp.lang.ada, in fact.)

It's one reason I think "major refactor" won't work out the way you're thinking it will -- granted, I certainly could be wrong in my estimation.

> 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.)
 
Perhaps, I know there's at least four or five people here who would love to see an LLVM backend.


> 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.

Allow me to reiterate: I think this wouldn't solve the inherent limitations, nor be conducive to reevaluating "the way we've always done it" for a better approach/process.