Re: Cairo

[David Kastrup]

Knut Petersen <knupero@gmail.com> writes:

>> Knut, if you read this message via the mailing list, please try to find
>> out why my messages don't reach you.
>
> T-online.de email addresses seem to become more and more
> obsolete. hotmail.com and outlook.com block t-online, you get blocked
> by t-online. lkml blocked t-online about 8 years ago.
>
> I changed my lilydevel subscription to knupero@gmail.com. AFAICS
> administrators seem to hesitate to block gmail.com as it is big enough
> to be important ;-)
>
> Yes, cairomm was a bad idea. Using cairo directly (and staying with
> c++11) isn't a problem.

The problem with C++ (and also Guile) wrapper libraries is that LilyPond
marries C++ and Guile data structures in a rather special way.  And
pulling more frameworks in can get messy because their design and
assumptions can make their modus operandi a bad fit.

That's particularly a danger when new language features are being used.

The mantra bringing C++ into existence was object orientation and
encapsulation while maintaining C's efficiency.  The proliferation of
the language has clawed onto efficiency, but particularly reuse of code
has not turned out to be much of a thing: perhaps the strongest example
for code in general use is the STL, and its code base is utter
specialist gibberish rather than written in what a standard programmer
would come up with: reusable code bases have turned out opaque in more
than just the CS sense.

In a way that is a reason why after 50+ years numerical libraries in
Fortran still have an impact, partly with C++ and other language
wrappers around them: Fortran has native multidimensional arrays, and so
independent libraries can easily be used, sharing the same data
structures, in user programs.  "If I've been able to reach far, it's
because I've been linking hands with my brethren."  And the rather
highly efficient numerical code of Fortran libraries is readable (if
ugly) and reflects the work of mathematicians rather than code
wranglers.

For better or worse, existing higher language wrappers (C++ or Guile)
tend to result in somewhat awkward fits with the LilyPond code base.

I'd say "something's rotten in the state of Denmark", but then
Stroustrup has not been a principal driving factor of C++ for quite a
while.

-- 
David Kastrup