Re: [anjuta-devel] Sharing code between Nemiver and Anjuta

[Dodji Seketeli <dodji seketeli org>]

> GCC is using only libc. Anjuta uses GLib which provide much more
> functions,

Well, GCC also has an extensive "library" functions set that is comparable
to what GLIB offers in terms of containers and things like that.

> including a lots of container objects without the need of STL.

I respectfully disagree here :-) The containers of libstdc++ have
properties like compile-time type checking that GLIB won't have
tomorrow.  And to me, that's a killer feature.  If I have choice, I'll
use the containers of the C++ standard library over GLIB any time.  And
I don't see that as an issue, really.  We (GTKMM and Nemiver) do use
stuff from GLIB too, like the utf8 handling bits among other things.

Similarly, when c++11 support matures in our compilers, I'll use their
feature as I see fit.  I don't see GLIB as the alpha and omega of GNOME
software development, especially when the language you are using
provides you with goodies that are deemed better.  It's no insult to
GLIB.  I think GLIB is truly great when you are doing plain C.

> Yes, I see you use only Gtk+ not the whole GObject platform.  I
> understand your point but, just out of curiosity, why do you use gtkmm
> instead of Qt if you think C++ is much better?

For one thing, because I love GNOME :-) I love it's aesthetics, its user
interaction pattern language, its community, the way it rooted its core
principles into Software Users' Freedom since day one.

And graphically (at least), if I want to be in the GNOME train, I think
there is no good way around siting in a GTK+ wagon.

Technically, Gtkmm was designed since day one to fully interact with the
C++ standard library (instead of, for instance re-code its own
containers and things like that) whereas Qt devised its own container
types, for instance.  The Gtkmm signal/slot mechanism that we use in
Gtkmm takes the compile-time type checking to an extent that was not
(and iirc still is not) present in Qt back then.  Yeah, at the risk of
repeating myself, I guess you must have noticed by now that I really
want that compiler buddy to assist me with this type-checking business
;-)

In short, I'd like to say to the world that there is no real practical
problem with recognizing the strengths of C++ and being a GNOME at heart
at the same time.  :-)

> I have the impression that gtkmm has less maintenance than Gtk+ and
> you need a few additional conversion to pass some data.

Gtk+/Gtkmm might be lacking in some areas.  Granted.  But then I guess
it's up to us, the GNOME community to push it forward and fill its
holes.

In practise, the Gtkmm bugs I have been exposed to have been fixed.  I
have myself made additions to Gtkmm in my time, and I wish I had time
right now to do more.  OK, In these matters, I am not the pessimistic
kind of man ;-)

> Moreover, why do you rely on a library, Gtk+, written using C and so
> having more crashes and leaks?

Why?  Because I take it as my (GNOME) family legacy :-) To some extend,
I am not opposed to making compromises :-) Luckily for me, Gtkmm helps
we in that process of making a compromises.

Ultimately, we all rely on a kernel that is written in C.  I am not
saying that doing C necessarily equals to crashes or that no one should
use libraries written in C.  Far from that.  Heck, Nemiver even directly
uses GDB that is written in C.  I am very well aware of that.  I even
write my share of C code everyday.  :)

I am saying that for application development (at least), there *exists*
a tool that can be better than C today to express your abstractions,
help you make sure the data manipulated by your program respects the
constraints of these abstractions in a tighter way than C can do,
*reuse* C (see, reusing those pesky C code bases is even a feature I
want! (-; ) as no other tool can do, and all that with the same
performance and system control that C can provide you.  Oh, and with a
versatile, mature and maintained toolchain.

Of course, as often, that greater power comes with one main drawback:
you can blow your foot away if you don't take care enough.  But I took
that risk with Nemiver precisely b/c I didn't have much resources to
devote to the task, so I needed a powerful tool to assist me.  And I
guess the result speaks by itself now: I still have my two feet :-)

> Do you think that are much more resource on Gtk+ to do all tests?

Well, testing in Gtk+ is certainly an open issue I'd say.  :-)  Other
than that, I don't really know how to answer that question.

I guess the mitigating effect for Gtk+ testing today is the large
community that uses it and reports the issues.  We substituted
distributed coarse grain testing for unit testing.  And we have this in
place already.  So we can afford taking time to address the greater
testing issue, I guess.  I didn't have that luxury when I started
Nemiver.  :-)

> > For instance, having the compiler tell you straight away that the
> > "data" argument that you passed to your signal handler is of the wrong
> > type (for instance, after you did some refactoring) is a huge
> > improvement over silently overlooking that until you users experiment
> > the inevitable resulting crash down the way is a *huge* selling point
> > in my book.
>
> This is an improvement for sure but I think I spend much more time
> thinking and checking corner cases than fixing type errors. I agree
> that it's difficult to evaluate because it has some additional
> consequences. You need more time to find an error at run time than at
> compile time, refactoring will need a bit more time too.... On the
> other hand, compiling C++ takes more time and GLib is doing quite a
> lots of checks at run time.

Hehe, from a pure system designer point of view, ultimately, I think
that the extra compile time taken by G++ is negligible compared to the
aggregated run time taken by the checks (running on every single device
run by users around the world) that something like GLIB has to make
precisely because of a lacking compiler.  I guess we accept that today
just because we (hackers) are not the one paying for these aggregated
increases of electricity bills :-)

OK, that was an exercise in sophism -- even if I think there is some
amount of truth in it ;-).  I apologize.  My point is that I prefer
doing that check at compile time (at the expense of an extended compile
time -- that toolchain people are working to reduce by the way) rather
than relying on runtime checks.  I want Nemiver users to debug their
programs, not the debugger.

> > And having that, while sitting on the giant shoulders of
> > C, in such a way that you can just copy-paste code from C code bases,
> > compile it and use is w/o *needing* to wrap feels like another silver
> > bullet.  And of course, we can rely on a mature and versatile
> > toolchain these days.
>
> Yes, but C is even better in this regards and the toolchain is more
> mature.

Well, you are omitting forgetting all the other attributes I am
requesting from the compiler that C lacks ;-)

> Another option is vala, the toolchain is no very mature, but I think
> it's easier to write than C++.

Not only is the toolchain not mature at all (the debugging experience
for instance is a joke to me), but the tool falls short in the
reuse-of-C department.  As things stand today, I'd choose C++ over Vala
any day -- if the question is to e.g, progressively convert the C code
base of Anjuta to something else, as this is what I was talking about.

> Then gobject introspection provide this advantage to quite common
> languages like javascript or Python. And if you want to write code
> faster, I think it's a much better option than C++.

I have never said that I wanted to write code *that* faster.  I want to
write code as fast as I can, but not faster.  ;-)

I am more concerned about the maintainability, robustness, speed, and
code size of what I deliver to my users than to the maximization of my
little comfort.  Of course there is a balance to strike there, and I
guess how we strike it is a personal matter.  But hopefully you see
where I put that cursor, as far as I am concerned.


> > Yeah.  Assuming we can devise a library for the stuff you guys find
> > worthwile, if there is value for Nemiver to use that library, I'd be
> > glad to have a library external to Nemiver, that Nemiver depends on.
> > Anjuta could then depend on that same library, too.
>
> Good but it's not very useful for Anjuta unless people from Nemiver
> work on this library which has to be in C. Are you willing to program
> or fix bugs in C for a library used by Nemiver? GDL by example?

We use GDL(mm) in Nemiver already, so yeah I am not opposed to that
chasing and fixing bugs in GDL.  The real prerequisite is to understand
the code somehow ;-)

> Do you agree to add more features in Nemiver code base even if they
> are not really useful for Nemiver itself?

Of course yes.  I guess it'll have to be decided on a case by case
basis.


> > Yes, I am not a fan of GObject at the application development level
> > because the macro soup that comes with it makes it too error prone,
> > leading to a more crashy user experience than I'd like to accommodate.
>
> Obviously there is much less type checks are compile time but there
> are quite a lots of checks are run time, it makes the code a bit
> slower but it allows to detect most issues.

After what I said earlier, I guess you know my point of view on this by
now :-)

> > Nemiver thus defines a lot of ad-hoc types.  It's as easy as doing
> > class foo : some_base class {};  No GObject boilerplate shit.  But we
> > do use a lot of libstdc++ and gtkmm types, too.
>
> Boilerplate code is a bit annoying to write but it could be partially
> generated (Anjuta do it) and it is quite straight forward, I don't
> think it leads to more bugs.

I disagree.  It does lead to more bugs.  If you have to write it, you
can write it wrong.  And having to generate it at Anjuta level while
there are tools to do it generally, support it at the debugger level
etc, is a kind of waste in my book.  *But* you guys have it in place
already so there is no more issue there.  The paragraph you are replying
to was meant as a general statement about GObject boilerplate.  Not
something directed at Anjuta specifically.

>  One advantage is that you can see it, while in C++ this code mostly
> exist but is generated by the compiler directly in assembler.

I disagree again.  Why do you need to see the thing if you never have to
interact with it?  This is a case of abstraction failure to me.  It
usually one of the synonyms of 'boilerplate code'.  I don't see what it
provides my to see the details of the GObject vtable handling, for
instance.  But I can pretty much affirm that precisely (among other
things) because of the way it is done, the GObject vtable makes GObject
instances bigger and slower than e.g, C++ dynamic objects (objects that
have uses vtables) in average.  We can drill into that latter if you
want.

I read once somewhere (and I agree with the fact that), engineering is
about mastering complexity.  And for that we (engineers) have two main
tools: abstraction and modularity.  So generally speaking, I try to use
them as much as I can -- in the size and space constraints of the system
I am designing.

> > As I implied above, what the client consumes is not libgdbmod.  It's
> > rather the interface it exposes, which is nemiver::IDebugger.
>
> Yes, but nemiver::IDebugger is a C++ interface while I need a GObject
> interface currently. So I think one option is to load libgdbmod and
> wrap it inside a GObject. Do you see an issue with that? Do you agree
> to keep a stable ABI for libgdmod?

Generally speaking, the ABI for libgdbmod would be tied to the
nemiver::IDebugger interface (API).  So if you wrap IDebugger into a
GObject thingy, then you wouldn't have to worry about libgdbmod itself.
You'd just use IDebugger.  And tomorrow when there is a new debugger
backend (other than GDB) that we need to support, you'll get its support
'free' when someone write that libnewdebuggermod that exposes the
nemiver::IDebugger interface.

So really, I don't thing it's a good idea to consider libgdbmod itself.

> > I am not interested in consuming GObject at the application level in
> > Nemiver because from where I sit today, and seeing all the advantages
> > we are experiences from using a C++ interface like IDebugger, I hardly
> > see any value in going back to something as low level as GObject.
> > I'd like to hear opinions that would proved me wrong, though.
>
> I see GObject at a higher level that C++ object, it provides much more
> features and is quite close to object in dynamic languages. I think it
> has some advantages compared to C++:
>
> * No need for bindings for using GObject libraries.

Well, with some compiler support to expose the API/ABI of a library
(written C or C++) in a serialized and easily consumable form (maybe
something like XML), you wouldn't need GObject for this, would you?  OK,
granted, you don't have such support today, but you never now.  I am
just asking the question to see if we are on the same page, in theory.

> * Bindings in various language almost for free with GObject
> introspection

This would be addressed by my question above.

> * Very complete set libraries well adapted to our need

Well, this is in the eyes of the beholder :-)

> > Just curious; there are scripts that generate C/GObject wrappers from
> > a C++ interface?
>
> Currently, I think none.

OK.

> On your side, you already have wrappers to use GObject in C++ and you
> use them for GDL and Gtk+

Indeed.  Well, we wrote (OK, Fabien Parent did) gdlmm ;-)

> > But, I tend to think that a C/GObject library that would wrap
> > nemiver::IDebugger would need to be hand crafted.  Automation is not
> > everything; the wrapper's interface will need to be properly designed
> > as well.
>
> I have been really impressed by GObject introspection, you write some
> code in C and you can use directly in Python without writing anything
> else.

I think that can be achieved by something like what I talked about
above.  If I really need that, I'd try to push the support in GCC
directly instead of doing something GObject specific only.

But yes, I agree that GObject instrospection is nice if you are in the
GObject world and really need dynamic languages support.

> By the way, I think std::string is a quite good example. Indeed
> comparing to pure C which has a quite limited support for strings, and
> in particular doesn't take care of allocating the memory, std::string
> is a big improvement. Now comparing to Glib string functions and
> string object, std::string cannot handled UTF8, miss printf format
> string, case insensitive compare, strip spaces, escape
> characters... In fact, std::string is so good that I think every C++
> library has written its own string class. So it's nice to have
> std::string but it's no really comparable to GLib, you need something
> else to compete.

Hehe, we have Glib::ustring in Gtkmm that does pretty much all what you
are saying ;-) Oh, and for the utf8 handling, it uses GLIB.  Sitting on
the shoulders of giants.

> > I am not against using C, mind you.  My willingness to re-use C is
> > what got me in this C++ business in the first place.  :-) But to me,
> > up to a certain point, the more C++ I can use at application level,
> > the better.
>
> I understand your point but it makes the code of Nemiver more
> difficult to share as it forces people to use C++.

Yes.  I guess I get your point too.  But at the risk of repeating
myself, C++ is the closest I want to get to C for this kind of
application development, at least.

Then I guess if this code sharing business is taking place, given that
you want to keep C/GObject for your core and I see that as too expensive
at Nemiver's level the only path left would be to write GObject wrappers
like what the Webkit/GObject folks are doing.  Poor guys.  :-)

I am not opposed to having a joint project for this; we'll sort the
details out later.

> > Emacs is the ILE (integrated Life Environment) where I live so, as a
> > programmer, I am not really interested in hacking on an IDE.  But a
> > graphical debugger (that I launch from within Emacs everyday), I can
> > hack on.  :-)
>
> Ok, personally, I prefer vi:)

There is an Emacs mode for that thing too.  :-)

In the Emacs Environment, we are not against the brothers who lost their
ways at some point; we love them too.  Nobody is perfect.  In the end we
shall be one in the Great Heaven of Hackerdom.  :-)

Until then, happy hacking, brother.  :-)

-- 
                Dodji