Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, March 20, 2013 6:16:04 PM UTC-6, Randy Brukardt wrote:
> 
> Clearly, the sockets library that never got a real proposal would have 
> helped a bit (mostly for server-side work) on the network end. Having to use 
> some implementation-defined thing (Gnat.Sockets, Claw.Sockets) or 
> off-the-web freebee (like NCSockets) doesn't help anything. Of course, I 
> don't seem much hope for Ada running in a web browser.


Funny you should mention that; there's a site I came across a while back which illustrated using Ruby (and a Java Applet) to run a script-tag w/ Ruby as its language.
   Demo: http://ruby-in-browser.googlecode.com/svn/trunk/evalruby/index.html
   Site: http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby


I'll disagree with your "no hope" on browsers. Ada's tasking/protected-objects is something that I think most web-developers would love (even if they don't know it) because much of what they're doing w/ AJAX is better/more-easily expressed in that manner. -- And it would bring one thing they don't really realize they're missing: type-checking.

> (Personally, I think 
> this is a good thing, I don't think much of anything should be allowed to 
> run in a browser for security reasons. But I'm clearly going to be in a 
> minority on this.)

I rather agree; except that to do what they're doing now HTML/Javascript/HTTP is a bad combination: HTML isn't meant for a page's design/format-layout, HTTP doesn't have a good bidirectional/session mode [like, say, DSA partitions],
Javascript is... LISP ruined by the C-Syntax -- not really suitable for passing typed data in client/server ala AJAX (due to its untyped & EXTREME late-bound nature finding bugs is more difficult).

> I'm not quite sure what you mean by "changes in hardware architecture". The 
> mainstream architechures are well-supported by Ada (there is very little in 
> multi-core that wasn't already anticipated by Ada, as Ada was designed for 
> multi-processor architectures and there isn't much different). Most of the 
> problem areas are less with the language and more with the implementations.

I'm fully agreed w/ you here. I find the current multi-processor hype/concern to be rather amusing in that it's been solved/addressed for over thirty years


> 
> In any case, your overall point is quite correct. To a large extent, this is 
> an implementation problem more than a language problem, but most people 
> can't separate the two and in the final analysis, the distinction doesn't 
> matter much.

Sadly true. Though I would like to see this drive for bare-metal runtimes bear some good fruit. (And hopefully stimulate Adacore to improve GNAT's toolchain.)

> If people want to run their program mostly in a browser, 
> nothing is going to help them much (because they're on the road to hell, 
> they just don't know it yet); certainly, there is no way to bring the 
> advances in static analysis that reenforce Ada to that area (at best we 
> could combine an Ada back-end with a Javascript front-end in some tool, but 
> I really wonder if the result would have many of the advantages of Ada left. 

The Ada-jvm compiler: we could have secure/stable applets, and cause a resurgence there, maybe.

Though maybe an Ada-javascript translator could help, perhaps even turning AJAX into saner PO/tasks.

> 
> It's a project I'd be willing to try if there was a supporter for it.)

Which project?