[Texmacs-dev] Re: Compiling TexMacs on OSX

[Henri Lesourd]

Abdelrazak Younes wrote:

> Henri Lesourd wrote:
>
> > It's not clever at all to depend on Qt's XML parser,
> > for as soon as you do this, you need the Qt lib
> > installed on your target system *all the time*.
>
>
> So? There's a high probability that this lib will be installed anyway 
> on your system if you already make use of QtGui...
The default version of TeXmacs doesn't depends
on any Qt lib: we don't want to force a dependency
on that.


> If we follow this reasoning, it is not worth using any helper library 
> because it causes bloat... libc is even too much bloat, let's just go 
> back to basics and program in assembler :-)
If you follow this reasoning, you simply avoid introducing
dependencies which are not absolutely necessary.

Except in the case of libraries like the libc, which are
really ubiquitous, the rationale is that you use a helper
lib only if the amount of resources you need for implementing
or maintaining the functionality yourself becomes excessive.


> > In fact, word processing has nothing to do
> > with widgets, for everything occurs inside
> > a specific widget (i.e. the "editor" widget),
> > and the job of the editor is mainly reading
> > keyboard and mouse, and drawing on the canvas.
>
>
> Good (and logical too). So, AFAIU, one has everything in hand if he 
> wants to create a Qt GUI directly on top of this "editor"

The Qt GUI is not "on top" of the editor, rather it
is "around" the editor: the editor is one of the available
components. These components can then be combined together
to assemble the interface.


> (I mean without your glue library). That's good news indeed.
The day you will really want to reuse the TeXmacs
editor without the help of the current glue around
it, you will need to dive into the unencapsulated,
raw jungle of TeXmacs's C++ code. At that time, I'm
not sure you will still consider such a situation as
a "good news" :-)...


> > If C++ were so good, people would use it to write OS
> > code: it turns out that neither UNIX code, neither the
> > windows kernel code is written in C++.
>
>
> So??? A kernel has nothing to do with GUI programming.

Kernel programming is rather like pentathlon, it combines
all the other sports. And as far as the need of defining
clean interfaces is concerned, GUI programming (as any
other kind of programming) has a lot to learn from kernel
programming.

> You want to be close to the hardware

This is an urban legend. In a modern kernel, most of the code
is hardware-independent.


> and be as fast a possible when doing kernel programming, you cannot 
> beat C there, granted.

You cannot beat C there, but it's not because of speed of
driver programming: rather, it's because C doesn't stands
in the way of you having the *control* on what your program
does (e.g.: implementing processes).


> A GUI is user bound and a user triggered action does not have to be 
> fast on all operations.

Again, the problem is a matter of control, not primarily speed. For
example, it can be that you want to implement some code having some
proven real-time properties (i.e.: it is guaranteed to execute below
a given amount of time).

This is in common between GUI programming and real-time kernels. And
in either case, C++ stands in the way, for the specification of the
dispatch machinery of a C++ compiler is not part of the standard. On
the other hand, it is *known* that a C function call is constant time.


> me wonder why so many people uses C++...
Because there are more features. Thus for simple things, there is
less work to do. But as soon as your needs become more sophisticated,
things become more complex.


> You are doing a lot of generalisation here.

Not really: as soon as you become a little bit exigent,
you need a bunch of more sophisticated techniques, which
are only feasible at the C level.

It doesn't means that no compromise is ever possible,
e.g. TeXmacs code is C++, after all.


> And you know what? some people do kernel programming using C++. I did 
> an in-kernel parallel port reading once in C++, I can't remember any 
> problem. IIRC there's even some kernel that were entirely programmed 
> in C++ (BeOS).

Yes there are. But not the mainstream ones, which
means that the people who started the mainstream
projects decided against C++: it cannot be that
there are no real reasons for this.


> > In my opinion, there are well principled reasons to
> > this, these people are not masochists, you know. It
> > only turns out that C++ is not a sufficiently robust
> > language, it is for example notorious that even
> > very well written C++ programs tend to be fragile
> > and hard to debug.
>
>
> Sure, C-style pointers in spaghetti C-code is very easy to debug and 
> is very robust too.
The point is that C-style pointers and spaghetti C-code
is what *you* do: thus you enjoy complete control on
that if you want to do it well.

Mangling method names, or how exactly the dispatch is performed
is hidden inside the compiler, it's blackbox, you cannot change
it, and you cannot gain any reliable (i.e.: platform-independent)
knowledge about that.

Thus you don't enjoy control on these important things.