From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, LOTS_OF_MONEY autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.36.86.4 with SMTP id o4mr2577873itb.55.1519943131527; Thu, 01 Mar 2018 14:25:31 -0800 (PST) X-Received: by 10.157.32.3 with SMTP id n3mr163336ota.12.1519943131401; Thu, 01 Mar 2018 14:25:31 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!e10no55717itf.0!news-out.google.com!a25ni94itj.0!nntp.google.com!w142no54534ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 1 Mar 2018 14:25:31 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.113.16.86; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.113.16.86 References: <5a8e17dc-1d52-4393-be58-8881e741c3a4@googlegroups.com> <1190543753.541369961.154390.laguest-archeia.com@nntp.aioe.org> <6700ecea-cdfe-4c73-88ec-d98bafd9151b@googlegroups.com> <1288175616.541375784.664064.laguest-archeia.com@nntp.aioe.org> <2babf92b-161e-4e59-9877-6de5466a6683@googlegroups.com> <95718cf6-c89c-4fb9-bd6a-5abb1146124e@googlegroups.com> <11be6e36-7041-4346-859e-876f0a19ee6b@googlegroups.com> <5b6d496b-a375-41c7-bac6-01a1b20c3137@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6a1818f1-71c2-463d-baa6-0bbe12c88d42@googlegroups.com> Subject: Re: Embeddinator-4000 begetting an Ada-cross-platform future? From: Shark8 Injection-Date: Thu, 01 Mar 2018 22:25:31 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 13294 X-Received-Body-CRC: 1477681781 Xref: reader02.eternal-september.org comp.lang.ada:50775 Date: 2018-03-01T14:25:31-08:00 List-Id: 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-sourc= e Ada toolchain so that I could write both nonportable/SDK-specific UI/UX a= nd portable backend-processing libraries all in Ada on iOS, MacOS, and Andr= oid. =20 > Shark8 wrote: > > Turbo Pascal proved that a company could thrive by targeting small-busi= nesses and hobbyists with relatively cheap compilers.=20 >=20 > Well, yes, but back in 1983 the bar was set very low though. Philipe Kah= n's TurboPascal only needed to be better than Microsoft's BASICA or GWBASIC= =E2=80=A2interpreters=E2=80=A2 (and better than Waterloo BASIC =E2=80=A2in= terpreters=E2=80=A2 largely only on fellow-Canadian Commodore) and better t= han UCSD p-System Pascal's p-code =E2=80=A2virtual machine=E2=80=A2. All e= xisting (incongruent-)competitors were sitting-duck targets. Had Waterloo/= WATCOM released a far-more-expensive set of impressively-optimizing compile= rs 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; the= y (and I) bought it because it was a =E2=80=A2compiler-to-machine-code=E2= =80=A2 of any language above assembly language and we couldn't afford Digit= al 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 hobbyist= s, which you actually confirm.=20 > 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.)=20 > Shark8 wrote: > > Not really -- there's plenty that can be done with (a) support contract= s, and/or (b) specialized/additional tooling.=20 >=20 > 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 are= n't the lone contributor. Or likewise, if wooing corporate subsidization i= s so easy, then go beg at one or more Fortune 1000 corporations who frequen= tly contribute staff time to open-source repositories that are not their ow= n (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 u= p 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 poi= nt of don't limit ourselves as a community to only fresh starts with a blan= k text editor, such as your own laudable effort. You are one genome. My a= forementioned list of steps are another genome. Survival of the species is= best via diverse genomes, so that at least one survives the rigors of natu= ral selection. To everyone other than you & your fellow contributors, plea= se think of what a drastically-rejiggered GNAT would look like (other than = the one immutable chiseled-in-stone part: GMGPL or GPL). =20 ?? -- I said that there was room enough for support-contracts and/or specia= lized tools to make a profit. Your supposition [of easily scraping together= $500,000] relies on ignoring the implicit prerequisite of having the produ= ct (eg compiler). This isn't to say I'm dismissing the costs of development, but AdaCore oper= ates under the "support contract" model [and already has the compiler] and = some of its actions are... puzzling and honestly bad for both Ada and itsel= f. (See, for example, how they quit doing the JVM and DOTNET backends; or h= ow they brand Ada as [almost] an exclusively high-integrity or embedded lan= guage.) 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 opti= on, and certainly the most common implementation among hobbyists and small-= business. -- For this reason it seems like your argument should be made aga= inst GNAT. > please think of what a drastically-rejiggered GNAT would look like It would likely suffer from the same architectural and design limitations l= ike GNAT does. Things like the lack of a proper library, using instead the = file-system, and being unable to process multiple compilation-units per fil= e, and so on. Also, there's been some weird regressions/bugs in GNAT that make me think c= ertain things aren't properly handled; example: renaming attributes throws = up a bug-box. (The advised solution is to use "NAME : Constant TYPE :=3D Ob= j'ATTR;") A further disadvantage to "intensive refactor" is the fact that such effort= s are normally directed to "do the same thing" rather than actually evaluat= e if that thing is the best way of accomplishing the goal -- as a practical= example consider Continuous Integration where the typical setup is "(1) pu= ll the current repository, (2) build the entire thing, (3) on errors/bad-bu= ild issue an alert [usu. email]" -- the whole thing can be done with far le= ss processing if you were to combine it into the repository function as des= cribed here ( http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.26= .2533&rep=3Drep1&type=3Dpdf ) using a DB-tree as the repo, so that only con= sistent/compilable partitions are merged upwards in the DB-tree, resulting = in the root-node always being consistent... combine this with existing DB-j= ournaling 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.=20 > Shark8 wrote: > > Objectively false; see above.=20 > > The big problem is that there's only one contributor, and he's disguste= d with his lack of progress.=20 >=20 > 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 defin= ition of possible-world logic there. https://en.wikipedia.org/wiki/Possibl= e_world )=20 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 p= erson-year effort. Perhaps 2 person-year effort to radically set a GNAT-de= rivative-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 thi= s effect. I know it's a point of disagreement between myself and several of my friend= s here on Comp.Lang.Ada, but I'm of the opinion that what we need is a stan= dardized IR in the vein of AIR and/or DIANA -- actually a two-stage set of = them -- one wherein the structures align to syntactically & semantically va= lid Ada, and a 'deeper'/more-general one where things are generalized and a= bstracted to allow a uniform composition (ie "Subtype Nybble is Integer ran= ge 0..15;", "Subtype Nybble is Integer with Static_Predicate =3D> Nybble in= 0..15, Predicate_Failure =3D> Raise Constraint_Error;", and "Subtype Nybbl= e is Integer with Static_Predicate =3D> Nybble >=3D 0 and Nybble <=3D 15, P= redicate_Failure =3D> 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 a= s on GitHub.=20 > Shark8 wrote: > > *SIGH* -- There's the start of a MIT-licensed compiler, Byron, I have o= n GitHub. -- https://github.com/OneWingedShark/Byron -- but there's only on= e contributor.=20 >=20 > My step 4 was predicated on the prior steps. Of course, if you start wit= h a blank text editor instead of GNAT, then yes, you can contribute the ope= n-source Ada compiler under some other license than GMGPL (or GPL). Btw, a= wesome 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/over= haul 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 d= evelops the anti-refactorer to recursively unwind the deeply-accumulated di= vergent ASIS-assisted refactorings).=20 > Shark8 wrote: > > This seems a bit convoluted; I'm not sure I get your meaning, or purpos= e here. >=20 > 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 awa= y from Ada -- in short, the viral nature makes them quite leery of using Ad= a at all because, from their perspective, the license is all legal liabilit= y 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 thin= king 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.=20 > Shark8 wrote: > > You could do that with a non-GCC compiler.=20 >=20 > Of course. For example, one of today's proprietary Ada compilers could d= o that. (And if, for some reason, they wanted to change their business mod= el, they could optionally open-source their new LLVM-backended Ada compiler= .) =20 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:= =20 > > > 1) Fork the FSF copy, so as to (apparently?) have the proper license.= =20 > Shark8 wrote: > > Why? This will inherit *ALL* of GNAT's flaws and limitations. >=20 > Hence the aforementioned ASIS automation-assisted accumulation of refacto= rings. 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 bet= ter approach/process.