Re: can ada do this?

[Optikos <optikos@verizon.net>]

On Friday, May 17, 2019 at 12:40:00 AM UTC-5, Maciej Sobczak wrote:
> > 1 can you talk to scylla from ada?
> 
> Most likely the easiest path is to bind to the C client API, if the pure-Ada API does not exist.

Rabican, this is the recurring wise advice to you, if you are interested in coding something in Ada up regarding Scyla.  As I mentioned above, the other (nonC++) languages' bindings to Scyla provide a rich amount of tutorials that can be borrowed for Ada too.

> > 2 could u replace scyla with somethign better coded in ada?
> 
> What do you mean by "better coded"?

e.g.,
A) Coded in, e.g., SPARK/Ada to be (mathematically-)provably correct.
B) Coded with resource-pools for embedded systems in mind (à la Multics segmented partitioning) instead of One Big Enormous Heap for general-purpose computing (à la Unix monolith).

> Is this product badly coded, currently? Or, if you think that the product would benefit from better coding
> (presumably in the context of some bug, which is a local problem), would it be possible to code it better
> in the existing language (presumably by fixing the local bug)?

Presumably •not• in the context of local bug as you surmise, but in the context of a systemic widespread architectural flaw or lack that C++ (mis)leads designers into, such as A or B above.

> And, lastly, why would anybody replace an existing (and apparently very good) product with another
> one? It's much better to spend your effort creating something new instead.

Answer:  To achieve quite different architectural or design goals than the Scyla team had in mind.

That all being said, even Ada2020 will lack enough breakthrough differences from C++ at the language level for the language alone to steer an Ada-based Scyla-esque different-thingy to be revolutionarily different.  Mainstream Ada culture does differ markedly from mainstream C++ culture, so the different architectural or design goals would more likely arise from cultural differences at the human-idiom level than at what the piecemeal language feature-set minutia actually permits or prohibits.

Some Adaphiles yearn for a more-pandering-to-popularity AdaNG (Ada next generation) that, say, has braces instead of BEGIN END, and numerous other shallow “features”.  Other Adaphiles like me yearn for a quite different AdaNG that, while remaining true to Ada2020, resurrects the propensity toward begetting something analogous to the breakthroughs of PL/1 and Algol68 in the 1960s and of Ada in the 1970s by setting the bar far far higher regarding what software (and software-engineering and systems engineering) designs, principles, and practices can be achieved easily via expanded expressivity in more (and/or more-flexible) language constructs (instead of contortedly jammed through the backdoor in C++ if even possible at all in C++'s syntax or culture).