Re: Please evaluate tiny binding that does not use Interfaces.C

[patrick@spellingbeewinnars.org]

Hi Per

Thanks for answering my post!

Do you like friendly debates? If we were in the same room you would see that I have a smile on my face and I am not trying to be argumentative or hostile in any way, it's just that I seem to be thinking differently then most Ada people right now and I would love to have my sanity checked. Please don't be offended by this, please help me test my logic......

Here is some background.

I bought/printed 53 lbs of Ada books in 2012. I studied every night. I basically failed. I wanted to use Ada instead of C but every where i turned I needed a binding to C. GTK-Ada was very confusing and I struggled badly with it and eventually gave up on Ada.

I actually went to GnuCOBOL(call open-cobol as the time). I loved it and still do. I learned a lot more about C and I have had a great time mixing GnuCOBOL and C.

I have come back to Ada a few times. I used Interfaces.COBOL. I can use it well but the code required to blend COBOL and Ada is IMHO as gross as the code to mix C and Ada, when using Intefaces.C.

I have read extensively about Interfaces.C and Interfaces.C. Most examples will use some simple C target. In reality people will often want to interface with massive C/C++ libraries.

I know it would be nice if all Ada bindings were thick but is it not in fact fair to say that most are thin, we don't have large communities to support them and to look for bugs, we don't have many bindings relative to let's say Python and writing good Ada bindings is non-trivial to begin with.

My feeling right now is that the expertise needed to use bindings like GTK-Ada is of such a high degree that the programmer might just be better off studying C and writing shim code to that C and binding to it or directly to the C library on an as-needed basis rather then trying to write a whole binding to share with the community.

I am really sorry for writing the above, I know how hard it is to write a binding and I don't want to discourage people but I think it's also important to speak honestly about the language, I think lots of people stop by to see what it's about but move on. I think if it was easier to interface with other languages, Ada could start off as library code to support other languages at first and then could win over people's hearts and become more central or in fact "the" central language of the given application.

With the approach taken above, I am sure I can interface with COBOL without having actually tried this but what about other ELF compatible languages from GCC or elsewhere, this would open the door to interfacing with Java and Objective-C. Lots of languages have C interfaces or compile to intermediate C. Ada could be mixed with Haskell, Vala or dozens more.

I remember back in 2012 being to desperate to have -fdump-ada-spec that I switched distros. I remember using it inn stupid ways, like running it on the whole C library not just the header and trying to bind to internal functions and such.

In almost all cases Interfaces.C isn't doing anything but to someone that was struggling like I was, it adds a layer of magic that hides a much simpler truth.

I also question -fdump's decisions. As per the first post, why recreate a C struct and all of it's nested structs only to create a pointer of the correct type? Yes void pointers are dangerous but mountains of code that do not need to be there is also dangerous.

Simple short code is easier to debug and maintain and a lack of maintenance or worse yet, a poor understanding of code is IMHO worse than the danger of a void pointer.

Why use Interfaces.X if Ada already has the built in types to interface. Having to cast back and forth only makes for more code and less code clarity and at the end of the day, we are still calling into C and more code to check for actual C dangers seems like a better idea to me than using Interfaces.X which offers no protection anyways.

Thanks for reading