Re: [DNG] GTK (was Will there be a MirDevuan \"WTF\"?)

[T.J. Duchene]

Roger, 

I haven't had a chance, but I wanted to thank you for your insights regarding 
C++ last month.  I've not used it as a "main language" in some time.  
I was coding in C++ long before smart pointers were introduced.  Old habits 
die hard I suppose.

Your comments made me reconsider many things, and encouraged me to review what 
I knew on the subject.  While I still think that C++ has some design flaws, and 
smart pointers are not a perfect solution, you are right - they do mitigate a 
number of problems. 

Anyway, I just wanted to say "thank you" and I hope we have many more useful 
discussions in the future.  


T.J.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Jaromil]

On Sun, 26 Jul 2015, Didier Kryn wrote:
> >I encountered this principle long ago when I got involved in the
> >design and implementation of Algol 68 -- they deliberately violated it
> >with one feature -- they decided that everyone would pay the price of
> >a procedure calling mechanism that supported recursion.
 
yes, after this post I definitely feel like a youngster.

> Le 25/07/2015 20:55, Hendrik Boom a écrit :
> So you were involved in the design of Algol68! This was the first
> language I learned, in 1972-1973. The second of a great lineage
> which comprises Pascal and Ada. Kudos Hendrik! That's a pretty
> long carreer.

if one is able to look beyond the decreasing hate rethoric, in this list
there are real pearls of wisdom being shared by a rather unique and
diverse set of generations. its quite breath taking sometimes :^)

this is also very attuned to one of the oldest among dyne.org's
missions: that of supporting the creation of a working computer museum
in Sicily http://museum.dyne.org/en/ where we gathered many rare pieces
already.

I hope soon there will be the possibility to organize a gathering of
sorts, perhaps in the near of our museum, which can be about Devuan as
a main topic, but it should certainly leave space to this very community
and the importance of historical memory when designing new systems.

ciao


-- 
Denis "Jaromil" Roio, Dyne.org Think (& Do) Tank
We are free to share code and we code to share freedom
Web: https://j.dyne.org Contact: https://j.dyne.org/c.vcf
GPG: 6113 D89C A825 C5CE DD02  C872 73B3 5DA5 4ACB 7D10
Confidential communications: https://keybase.io/jaromil



signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Didier Kryn]

Le 25/07/2015 20:55, Hendrik Boom a écrit :

...

>This really
>violates the standing principle of "paying for only what you use."

I encountered this principle long ago when I got involved in the
design and implementation of Algol 68 -- they deliberately violated it
with one feature -- they decided that everyone would pay the price of
a procedure calling mechanism that supported recursion.

Sometimes it is the right thing to do.  The same decision was made by
practically eveery language designed afterward.

Not to say they didn't accidentally violate it a few times, of course.
I'm talking five decades ago, back when people were inventing the
language design principles we now take for granted.


So you were involved in the design of Algol68! This was the first 
language I learned, in 1972-1973. The second of a great lineage which 
comprises Pascal and Ada. Kudos Hendrik! That's a pretty long carreer.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

Oh I agree Henrik, but like all things, there is a time and place for it.
It is a good principle to keep in mind even when you break it when
designing a language because it avoids "feature creep" which is something
that has become far too prevalent in software, especially today.  I
consider OOP to be the worst example of feature creep.

I'm not all for or against OOP, but I do not think that it should be the
solution automatically pulled out in the majority of cases. While I agree
that some of the principles of OOP are worth having, I just think that it
is prudent to question the value of the rest, especially now that battery
life is a concern.  I often ask myself if you can really do an really do an
algorithmic N-operations analysis anymore, and when dealing with OOP I
don't even bother to try.  I fully expect to waste 30%  (perhaps more) of
execution time on overhead compared to procedural programming.  At that
point, anyone wanting efficiency really starts questioning the value of OOP.




On Sat, Jul 25, 2015 at 1:55 PM, Hendrik Boom 
wrote:

> On Sat, Jul 25, 2015 at 12:36:47PM -0500, T.J. Duchene wrote:
> >
> >
> > On 7/25/2015 5:26 AM, Roger Leigh wrote:
> ...
> ...
> > This really
> > violates the standing principle of "paying for only what you use."
>
> I encountered this principle long ago when I got involved in the
> design and implementation of Algol 68 -- they deliberately violated it
> with one feature -- they decided that everyone would pay the price of
> a procedure calling mechanism that supported recursion.
>
> Sometimes it is the right thing to do.  The same decision was made by
> practically eveery language designed afterward.
>
> Not to say they didn't accidentally violate it a few times, of course.
> I'm talking five decades ago, back when people were inventing the
> language design principles we now take for granted.
>
> -- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Hendrik Boom]

On Sat, Jul 25, 2015 at 12:36:47PM -0500, T.J. Duchene wrote:
> 
> 
> On 7/25/2015 5:26 AM, Roger Leigh wrote:
...
...
> This really
> violates the standing principle of "paying for only what you use."

I encountered this principle long ago when I got involved in the 
design and implementation of Algol 68 -- they deliberately violated it 
with one feature -- they decided that everyone would pay the price of 
a procedure calling mechanism that supported recursion.

Sometimes it is the right thing to do.  The same decision was made by 
practically eveery language designed afterward.

Not to say they didn't accidentally violate it a few times, of course.  
I'm talking five decades ago, back when people were inventing the 
language design principles we now take for granted.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On 7/25/2015 5:26 AM, Roger Leigh wrote:


  In C++ this simply doesn't happen; upcasting is completely 
transparent, downcasting with dynamic_cast is completely safe. This 
can lead to long standing latent bugs in the codebase that are well 
hidden.


What you describe is the result of poor design and bad casting, not a 
failing of the C language, in my opinion.  I agree with you that C has 
faults, it is hardly a perfect language.  There aren't any perfect 
languages.  My main distaste for C++ comes from the fact that like most 
OOP languages, you are saddled with embedded language features, like 
exceptions, even if you do not use them.  This really violates the 
standing principle of "paying for only what you use." Dynamic 
casting/RTTI comes with a cost and is not without its critics. Even 
Bjorne Stroustrup did not include it in the original C++ spec because he 
felt it could be misused.   I think mainly though that those problems 
with GTK  can be solved with better programming practices and compiler 
warnings, rather than resorting to RTTI.


We could discuss the virtues or lack of virtue for RTTI and not get 
anywhere, so I think it will be best to simply agree that GTK has sloppy 
code that needs improvement.  That we can both agree on without complaint.




  OOP can certainly be overused where other approaches would be more 
appropriate, but in the general case it provides many concrete 
benefits, so long as you don't try to do polymorphism in C.
I think we can agree to disagree.  =)  Before C11, I would have agreed 
with you that the  "polymorphism argument"  was valid, but I think that 
C11 renders a most of that advantage a moot point.In my opinion, C11 
_Generics wipes most of that advantage out.
On the whole, I consider the industry wide "love affair" with OOP to be 
a mistake, but a mistake we can learn from.  Much of what you describe 
as liking - polymorphism and cast checking can be done outside of OOP.   
I  consider OOP  massively overused and the costs have to be weighed 
against the benefits.


Absolutely not.  All the code is completely exception safe and will 
not leak if exceptions are thrown.  That's what RAII and smartpointers 
take care of.  Running under valgrind shows zero leaks with exceptions 
being thrown all over the place.  Exception handling can be 
*completely robust* when you use modern C++ techniques.




Another point where we must depart in agreement, I'm afraid.

To be clear, I'm not doubting your skills, or that you can write 
reasonable code that does not leak under foreseeable conditions. I am 
criticizing OOP in general.  In theory, all OOP code is exception safe.  
In practice, they are not.


Setting aside everything else, we all work in the real world. In the 
real world code, exceptions *can* cause leaks because you suddenly have 
unpredictable exit points at runtime once you get the code out in the 
world.  What I am saying is that the mechanism itself generates 
uncertainty.  Unless you catch all exceptions, you cannot possibly 
predict every exception that might be thrown.  You can certainly try, 
but 100% exception safe code is not an easy task. The cost of exceptions 
outweighs the benefits in my opinion.  You are depending on everyone 
else to be as studious as you, and as we both know, that is not the 
case.  I feel it is a bad programming model.


I have nothing personally against smartpointers other than the 
performance hit you inevitably take, and that it gives the luxury of 
lazy.  So it becomes a question of can I clean up my own pointers or 
not?  Usually, the answer is yes.







___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Steve Litt]

On Sat, 25 Jul 2015 12:23:49 +0200
Jaromil  wrote:


> personally a fan of FLTK which I really recommend, worthed mentioning
> in this thread I guess.

Thank's for reminding me about FLTK. I learned about FLTK a year ago
from a Debian-User inhabitant who had used it to create an exhibition
no-dbus notification system with about 20 lines of code. Then I forgot
the name of the library, and have been looking for it ever since.

SteveT

Steve Litt 
July 2015 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Hendrik Boom]

On Fri, Jul 24, 2015 at 06:58:04PM -0500, T.J. Duchene wrote:
> 
> Yes, I figured it was something along those lines.  As I mentioned
> in a previous email, my experience with GTK has been mercifully
> small.  I can certainly understand why you would get annoyed.  I'm
> something of a C aficionado so using pointers to do this does not
> bother me, but that said, it is very to make a mistake.
> 
> >This is work which the C++ compiler would have done for me, with
> >no added complexity, and no chance for me to introduce bugs into
> >the overly complex mess.  On top of that, the C++ class would be
> >completely type-safe in all respects where the GType system
> >requires allmost all type safety to be discarded to implement
> >polymorphism.
> >
> I apologize for the confusion on my part.  I see what you meant.
> When people say the phrase "type-safe" in relation to C/C++ I'm left
> to wonder.

Suggesting that GTK would be easy to handle via a binding to a truly 
strongly-typed language, where the binding provides the static typing 
and careful memory management that's hard to see in the C version of 
GTK.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Jaromil]

On Sat, 25 Jul 2015, Roger Leigh wrote:

> And later they made an incompatible break with GtkBuilder with then
> with GTK+3, which was the final straw in dropping GTK+ for good.

the glitches you mention and some others were coming up in my experience
and this nonchalance in breaking backward compatibility and dropping old
standards (sounds familiar eh) made me also orientate in other
directions when coding. Even the JVM is better in these regards,
especially if Java resources are used via Clojure, one of the Lisp
dialects I love the most.

GTK's final straw for me has been the Unity desktop dropping support for
gtk-tray applications: they went making yet another "standard" for it...

ciao


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Roger Leigh]

On 25/07/2015 10:23, Jaromil wrote:

On Fri, 24 Jul 2015, Roger Leigh wrote:


I imagine the reason why Glib was written in C is because binding to
other languages is easier with C than C++.


I expect so. C is fairly straightforward.


This was certainly the original intent.  But having used the bindings,
my experience was that they were of wildly variable quality, had
varying degrees of wrapper coverage, and some were not exactly usable.
All in all, the number of production quality bindings could be counted
on one hand with some fingers to spare.  Maybe it's improved since I
last looked.


I share most of the criticism to GTK in this thread. I think the best
thing it really produced was glade/libglade, but then is it worthed?


Glade and libglade were very nice, and I used to use these extensively. 
 However, I still ran into nasty bugs here.  For example, if you load a 
glade widget tree and reparent into a custom widget, it loses all the 
accelerators (keyboard bindings).  And there were issues with the 
libglade bindings as well, both bugs and defects such as not being able 
to use signal autoconnection.  And later they made an incompatible break 
with GtkBuilder with then with GTK+3, which was the final straw in 
dropping GTK+ for good.



Regards,
Roger
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Roger Leigh]

On 24/07/2015 23:58, T.J. Duchene wrote:



On 7/24/2015 3:57 AM, Roger Leigh wrote:

First, thank you for the reply, Roger. I supremely appreciate it.


The C++ compiler objectively does a better job here.  It's simpler,
quicker to write, safer, easier to refactor.  And when I've done a
full conversion of GObject-based C code to C++, the C++ compiler has
picked up on real bugs which the C compiler hadn't picked up on
(because the type information had been deliberately cast away).  GTK+
programs can be riddled with bugs, without the developer being any the
wiser in the absence of compiler diagnostics.


That is true to some degree. I don't agree entirely.  It really depends
on the compiler and what settings are being used.  GCC is not the
world's greatest compiler by any stretch of the imagination, and there
are a lot of extraordinarily lazy FOSS programmers who ignore warnings,
and do not initialize variables before using them.


It's worse than this, and is nothing to do with the compiler and 
everything to do with unsafe practices in the libraries.  With 
GTK/GObject, suppose I use one of the macro casts for polymorphism such 
as GTK_WIDGET().  This cast casts a pointer to a (GtkWidget*) with a 
little checking.  But it's essentially just the same as (GtkWidget*).
This "works" if you use the correct cast macro with a variable of the 
correct type.  BUT.  What if you get it wrong?  You have explicitly cast 
away the real type and told the compiler to use a completely different 
type.  There is *no way* the compiler can issue a diagnostic if you got 
it wrong.  In C++ this simply doesn't happen; upcasting is completely 
transparent, downcasting with dynamic_cast is completely safe.  This can 
lead to long standing latent bugs in the codebase that are well hidden.


That's the start.  Now consider stuff like signals and closures, 
g_signal_connect, g_cclosure_invoke etc.  What happens to type-safety 
here?  Again, it's almost always completely lost.  What happens if you 
screw up?  Nothing.  You would get no diagnostic from the compiler, and 
this would result in bad things at runtime.  In C++ with libsigc++, 
Boost.Signals etc. the signals and handlers are templated and specific 
for the signal and handler types, even going so far as to be able to 
rebind and elide arguments.  If you get it wrong it will fail to 
compile, not crash and burn at runtime.  And with the gpointer (void) 
data pointer in the signal, used to pass arbitrary data or object to the 
handler, that's completely unsafe--the handler has no guarantee it's 
going to get what it expected.  Again, the C++ handlers don't do 
that--it's completely safe and checked at compile time.


This is not about "programmer laziness"--they were not in a position to 
be notified of any mistakes they made, at all.



No one can blame you
for disliking the fact that GTK tends to leak references  (at least from
warnings I seen on the console) when using Linux.  That's entirely out
of your hands.


No.  It means the programmer screwed up the reference counting.  *Every* 
instance is programmer error.  Since different object types handle 
reference counting differently and inconsistently, this is a very 
difficult thing to get right.  Do you get a newly-created object with a 
refcounf of 1?  With a floating reference?  Do you need to sink it? 
It's a nightmare.  This is one reason the GTKmm bindings are nicer--they 
handle it correctly for you and give you a consistent and transparent 
way to handle it (GLib::RefPtr).  No more manual refcounting, and no 
inconsistency makes it impossible to screw up.



If I had to critique GTK based on what little you have
told me, I'd say it was probably a bad design, trying to force OOP in C.


It's definitely both of these things.  C is entirely unsuited to OOP if 
you care about the result being correct and robust.



That is not to say that OOP cannot be done in C, but as a programming
paradigm, I personally feel that OOP is a very flawed idea.  I've been
programming for a long time, and to be perfectly honest, I have seen
very few cases where OOP methodology actually makes things "better".
There are some nice features, but I don't buy the whole idea as actually
making software development easier. I'd sacrifice most of those features
in a heartbeat not to have to deal with exceptions.


I think this is at odds with general consensus to be honest.  OOP can 
certainly be overused where other approaches would be more appropriate, 
but in the general case it provides many concrete benefits, so long as 
you don't try to do polymorphism in C.



This too also has its limits, but put it this way: I haven't had a
memory leak in C++ code in a decade due to the use of shared_ptr, and
this isn't something I can say for my GTK+ C code, or GTK+ C code in
general.


I would  qualify that statement by saying you have not had a leak as
long as an exception was not generated.


Absolutely not.  All the code is completely exception safe 

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Jaromil]

On Fri, 24 Jul 2015, Roger Leigh wrote:

> >>I imagine the reason why Glib was written in C is because binding to
> >>other languages is easier with C than C++.
> >>
> >I expect so. C is fairly straightforward.
> 
> This was certainly the original intent.  But having used the bindings,
> my experience was that they were of wildly variable quality, had
> varying degrees of wrapper coverage, and some were not exactly usable.
> All in all, the number of production quality bindings could be counted
> on one hand with some fingers to spare.  Maybe it's improved since I
> last looked.

I share most of the criticism to GTK in this thread. I think the best
thing it really produced was glade/libglade, but then is it worthed?

personally a fan of FLTK which I really recommend, worthed mentioning in
this thread I guess.

ciao


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Didier Kryn]

Le 25/07/2015 03:38, Joel Roth a écrit :

Constructors and destructors are a helpful convention to
ensure objects get initialized and cleaned up properly.


For me this is the major utility of objects.

Anyway encapsulation and generics do not belong to OOP. In the Ada 
programs I have written, I often had the choice between two designs: 
generics of OOP. Generic is very often simpler and better fitted.


The problem, in C++ is that all that is confused; generic 
programming is only possible with objects.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Didier Kryn]

Le 25/07/2015 09:18, Didier Kryn a écrit :

Le 25/07/2015 01:57, Roger Leigh a écrit :
This really only applies to the grandfathered-in C numeric types 
subset of C++.  As soon as you use or own types (or wrap the 
primitives), you have control over the conversions and can define 
your own policies.


Roger,

This is true for the user of the class, not for the author. I mean 
the methods operating on the private part. This is typical of the C++ 
philosophy: make everything possible but by hand crafting and at the 
cost of possible errors an/or unreadable source.


Imagine you want to implement an integer with an allowed range [7, 
107], you will need to embed it inside a class and provide a setter 
which  raises an exception if the argument is not within the range. In 
Ada, you declare your type with its range and the compiler does the 
check for you: everywhere it cannot determine at compile-time if the 
value is in the range, it will silently insert the necessary 
instructions to verify.


Didier




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On 7/24/2015 8:38 PM, Joel Roth wrote:


Hi T.J. and others,

I've been following this thread with some interest.

T.J., it seems most of  your objections to OOP are not
strictly against the principles and advantages of OOP in
abstract, but against the way OOP is implemented in C and
C++.

With respect, I disagree.

My problems with OOP pretty much apply to every single OOP language I 
have ever used, because 90% of the OOP paradigm is flawed.   I have no 
problem with certain things.  Some examples would namespaces or 
polymorphism if they are handled sanely.  Much of OOP - things like duck 
typing, exceptions and inheritance are actually moving backward. They 
obfuscate code and introduce points of failure that cannot possibly be 
detected or tested for.   The whole point of programming is to produce 
reliable code.  There is precisely zero evidence that OOP has produced 
code that is actually any more reliable than previous methods.


In fact, some of OOP's usual features produce code that is less 
reliable, more resource intensive, or both.  Companies like Google 
specifically ban their programmers from using certain things, like 
exceptions, even if they are programming in C++.  The Clang Project does 
not accept contributions that use exceptions or RTTI - even though it is 
primarily a C++ compiler.






As a programmer in a dynamic garbage-collected language,
I find most of these objections don't apply.
I have a special dislike reserved for those languages that force you to 
use a garbage collector.  I can tolerate them if I can override it.






Constructors and destructors are a helpful convention to
ensure objects get initialized and cleaned up properly.
Constructors (and destructors) in most OOP languages are a bloody 
disaster.  Because most constructors cannot return values, you can't 
exit cleanly without throwing an exception.  Throwing an exception means 
that unless you catch it inside of the constructor. If you don't, any 
resources you allocated for your object are not guaranteed to be 
released cleanly.  This is especially important in OOP languages with GC 
where you are probably accessing libraries that have unmanaged code.  
Then you have to throw it again in order to tell the calling class it 
failed.  Catching it and then throwing it again means that you lose 
vital debugging data on the stack trace.


Either way, you lose.

I never use constructors or destructors in my code, and I find that I am 
better off in all cases.




Working on an application that has grown to about 20k lines,
OOP is the only way I've been able to manage.
Try that when it gets to 2 million, including dependencies.  When you 
reach that point, I will agree OOP can be somewhat helpful.  I don't 
hate OOP entirely, but I do NOT believe that what we presently use makes 
for better code.  Features even if they are part of the language 
standard should be evaluated for real world usefulness.




Perhaps I misunderstand your complaints, or perhaps I'm
fortunate to be using a language where those complaints
are less applicable.


That's okay.  Everyone is entitled to their views.  Just because I've 
been kicking this around a long time does not make me right. Use what 
you think best.


Take care!

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Joel Roth]

T.J. Duchene wrote:
> Didier Kryn wrote:
> >
> >What are your preventions against OOP for graphics? Is it against OOP
> >in general?
> Mostly against OOP in general.  It wasn't a bad idea to start with, but OOP
> started out with good intentions and blossomed more into a movement.  The
> question really is has OOP made code easier to maintain and less complex.
> Generally speaking, the answer is not really. The primary reasons for using
> OOP are encapsulation, polymorphism and inheritance.
> 
> Yes, encapsulation in scope is a good thing, but much of that can be
> achieved in other ways without using objects. When you take languages like
> C++, while the language itself is standardized, the name mangling that the
> compilers introduce is not standardized at all.  That makes prepackaged
> libraries and sometimes linking questionable unless you are using the same
> version and compiler.  It is enough of a problem every version of Linux
> recommends not updating your installation piecemeal  (eg if I update XFCE, I
> better recompile everything that is linked to XFCE - even if everything is
> backward compatible).  Microsoft got around it somewhat by using their COM
> specification.
> 
> Polymorphism?  Yes, I will agree that polymorphism is helpful.  That can be
> achieved with things like pointers,  void arrays, and in the case of C11,
> the use of _Generics.
> 
> So that leaves inheritance as the last real standing benefit of OOP, and
> that is really the one everyone hates.  Most OOP languages limit inheritance
> to single instance in order to avoid some very bad problems.   Realistically
> 90% of the time, it is better to not inherit at all, but simply instantiate
> what you would have used as a base class as a variable class inside of your
> class, and then dispose of it when you are finished.  You have no problems
> with multiple inheritance, calling base functions, and overall you are
> wasting less of the stack and memory.
> 
> The major reason I object to OOP is exceptions.  They make it impossible to
> write code with 100% predictable exit points.   When code can exit at any
> point above and below your own, that means that things can leak.  "Add a
> garbage collector," you might say.  What happens when the collector has a
> flaw and you do not know about it? Leak again.

Hi T.J. and others,

I've been following this thread with some interest. 

T.J., it seems most of  your objections to OOP are not
strictly against the principles and advantages of OOP in
abstract, but against the way OOP is implemented in C and
C++.

As a programmer in a dynamic garbage-collected language,
I find most of these objections don't apply.

I have experience writing and then refactoring a medium-size
application in Perl to OO. It was quite a long process, to
be honest. If I did it again, I would have spent more time
developing tests. Fixing and breaking and fixing again based
on user bug reports has been somewhat tedious, ameliorated
to some extent by good logging facilites and stack
backtraces on fatal errors.

While I might be able to develop similar code without 
objects now that I understand OO ways of thinking, I feel
no reason *not* to enjoy the syntactical, organizational
and cultural advantages of OO coding.

Constructors and destructors are a helpful convention to
ensure objects get initialized and cleaned up properly.  The
$object->method() syntax is a great organizing principle. I
know where to look for methods, usually in the same file as
the constructor/destructor and other aspects of the class
definition. Code related to each class goes into separate
namespaces.

At the risk of sounding like an enthusiastic newbie, it is
so awesome!

Working on an application that has grown to about 20k lines,
OOP is the only way I've been able to manage.

I've followed the debates about inheritance, and used
inheritance a lot. I haven't had a chance to try out the
major alternative to inheritance in OOP: roles. 

However, I have read blog posts of a programmer working for
the BBC who managed to flatten a huge codebase with hundreds
of classes and an incredibly complex inheritance tree, into
fewer classes that consume roles. 

In my case, inheritance means that, in the DAW application
I've been developing, I can have audio Track objects,
and I can easily modify them for a special case where I 
need to override some behaviors. 

I even have separate user interface classes, so that 
users can have a GUI, a terminal interface or both
together.

Each time I introduced a class, I got rid of numerous
if statements that had been sprinkled around.

So for me, with my limited experience, OOP is the greatest
thing since sliced bread. There are many situations where I 
don't use OOP, but where I need it, the advantages are
immense.

I'll take any computer science innovations that can help me,
whether its objects, grammars, exception handling, testing
or version control.  Each brings new possibilities for bugs,
and overhead to deve

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On 7/24/2015 3:57 AM, Roger Leigh wrote:

First, thank you for the reply, Roger. I supremely appreciate it.



I'm referring to the *GTK* "C API" here.  Not C in general.  If I 
create a GObject-based "class", either as a subclass of a GTK class or 
as an independent class subclassed from the root GObject, I have to 
*by hand* construct a virtual call table and *by hand* register all 
the class and object construction and release functions, along with 
the instance and class structures with the GType type system. 


Yes, I figured it was something along those lines.  As I mentioned in a 
previous email, my experience with GTK has been mercifully small.  I can 
certainly understand why you would get annoyed.  I'm something of a C 
aficionado so using pointers to do this does not bother me, but that 
said, it is very to make a mistake.


This is work which the C++ compiler would have done for me, with no 
added complexity, and no chance for me to introduce bugs into the 
overly complex mess.  On top of that, the C++ class would be 
completely type-safe in all respects where the GType system requires 
allmost all type safety to be discarded to implement polymorphism.


I apologize for the confusion on my part.  I see what you meant. When 
people say the phrase "type-safe" in relation to C/C++ I'm left to wonder.




The C++ compiler objectively does a better job here.  It's simpler, 
quicker to write, safer, easier to refactor.  And when I've done a 
full conversion of GObject-based C code to C++, the C++ compiler has 
picked up on real bugs which the C compiler hadn't picked up on 
(because the type information had been deliberately cast away).  GTK+ 
programs can be riddled with bugs, without the developer being any the 
wiser in the absence of compiler diagnostics.


That is true to some degree. I don't agree entirely.  It really depends 
on the compiler and what settings are being used.  GCC is not the 
world's greatest compiler by any stretch of the imagination, and there 
are a lot of extraordinarily lazy FOSS programmers who ignore warnings, 
and do not initialize variables before using them. No one can blame you 
for disliking the fact that GTK tends to leak references  (at least from 
warnings I seen on the console) when using Linux.  That's entirely out 
of your hands.  If I had to critique GTK based on what little you have 
told me, I'd say it was probably a bad design, trying to force OOP in C.


That is not to say that OOP cannot be done in C, but as a programming 
paradigm, I personally feel that OOP is a very flawed idea.  I've been 
programming for a long time, and to be perfectly honest, I have seen 
very few cases where OOP methodology actually makes things "better".   
There are some nice features, but I don't buy the whole idea as actually 
making software development easier. I'd sacrifice most of those features 
in a heartbeat not to have to deal with exceptions.



The contrast with C++ is that the assuption here is that the compiler 
will shoulder the burden and will fail to compile if there are any 
mistakes, since the presence of strong typing, RAII and smartpointers 
will guarantee correctness.


This is not to say that I have anything against bounds checks, and 
strong typing - both of which I think are a good idea.  I'm old 
fashioned but I have always felt that saddling a compiler with 
babysitting a programmer 24/7 is a bad idea.  More often that not, it 
creates uncertainty, poor performance, random memory leaks, bad coding 
practices, and ridiculously complex language constructs - all in the 
name of trying to do the job that the human should be doing in the first 
place, with proper and rigorous training.
This too also has its limits, but put it this way: I haven't had a 
memory leak in C++ code in a decade due to the use of shared_ptr, and 
this isn't something I can say for my GTK+ C code, or GTK+ C code in 
general. 


I would  qualify that statement by saying you have not had a leak as 
long as an exception was not generated.


Take care!
T.J.








In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively.

[snip]


That's somewhat true, but if you write C++ code PROPERLY - i.e. make
sure you references are clean, resources released, and you aren't
leaving any hanging exceptions, what he is claiming is pretty much a
non-issue in the context of any OOP language.  A C++ compiler is no more
mysterious that any of the other OOP crap we are forced to endure. C++
code is simply not as robust as C.   You can mitigate a lot of the
annoyance;  like exceptions that cause premature exits - but you are
never really rid of it.


This is not what I meant.

The sentence above should read "you have to be an expert in C++ 
compiler internals just to be able to understand and use [the 
GTK/GObject type system] effectively".  I'm referring to the fact that 
you have to construct GObject virtual call tables by hand, something 
which

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Roger Leigh]

On 24/07/2015 23:24, T.J. Duchene wrote:



On 7/24/2015 5:03 AM, Didier Kryn wrote:


Hey T.J., you seem to contradict yourself when saying "C and C++
are strongly typed" and "Type checking is never C's job." :-)

Actually, yes, C and C++ are typed, but weakly. They silently do
type conversion in pretty much every instruction. One assumes the
programmers knows it and takes care...


I stand corrected.  You are quite right, it is "weakly" typed.  I assume
that everyone could figure out what I meant anyway.  It's been a long
time since language theory. I think the error came from spending too
much time reading about languages like C#.  Even Einstein made major
errors, so at least I am in good company.


This really only applies to the grandfathered-in C numeric types subset 
of C++.  As soon as you use or own types (or wrap the primitives), you 
have control over the conversions and can define your own policies.



Yes, encapsulation in scope is a good thing, but much of that can be
achieved in other ways without using objects. When you take languages
like C++, while the language itself is standardized, the name mangling
that the compilers introduce is not standardized at all.  That makes
prepackaged libraries and sometimes linking questionable unless you are
using the same version and compiler.  It is enough of a problem every
version of Linux recommends not updating your installation piecemeal (eg
if I update XFCE, I better recompile everything that is linked to XFCE -
even if everything is backward compatible).


While this was historically the case, this hasn't been true for GCC for 
many years.  The ABI has been stable for all of the 4.x series, and it's 
unbroken in 5.x (though 5.x does introduce a C++11 ABI in parallel). 
I've been producing C++ shared libraries since GCC 3.x times, and have 
yet to run into any breaking problems.



Microsoft got around it
somewhat by using their COM specification.


To an extent.  But if you want to actually expose a C++ interface in a 
DLL you're stuck--every Visual Studio version breaks the ABI by having a 
new runtime and no compatibility guarantees.  The PE-COFF binary format 
is so dated it's basically unusable for C++ interfaces (try freely using 
templated class members, which works fine on ELF and Mach-O platforms).



The major reason I object to OOP is exceptions.  They make it impossible
to write code with 100% predictable exit points.   When code can exit at
any point above and below your own, that means that things can leak.
"Add a garbage collector," you might say.  What happens when the
collector has a flaw and you do not know about it? Leak again.


Exceptions are not really related to OOP though; you can use them 
without OOP being involved.  With modern C++ and RAII, code is made 
exception-safe by releasing resources in destructors so leaks are not 
possible.  Before RAII and memory management techniques such as 
shared_ptr and unique_ptr became commonplace, leaks and exception-unsafe 
code was quite commonplace, but that's now a rarity except in legacy code.



 I imagine the reason why Glib was written in C is because binding
to other languages is easier with C than C++.


I expect so. C is fairly straightforward.


This was certainly the original intent.  But having used the bindings, 
my experience was that they were of wildly variable quality, had varying 
degrees of wrapper coverage, and some were not exactly usable.  All in 
all, the number of production quality bindings could be counted on one 
hand with some fingers to spare.  Maybe it's improved since I last looked.


Regards,
Roger
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On 7/24/2015 5:03 AM, Didier Kryn wrote:


Hey T.J., you seem to contradict yourself when saying "C and C++ 
are strongly typed" and "Type checking is never C's job." :-)


Actually, yes, C and C++ are typed, but weakly. They silently do 
type conversion in pretty much every instruction. One assumes the 
programmers knows it and takes care...


I stand corrected.  You are quite right, it is "weakly" typed.  I assume 
that everyone could figure out what I meant anyway.  It's been a long 
time since language theory. I think the error came from spending too 
much time reading about languages like C#.  Even Einstein made major 
errors, so at least I am in good company.




What are your preventions against OOP for graphics? Is it against 
OOP in general?
Mostly against OOP in general.  It wasn't a bad idea to start with, but 
OOP started out with good intentions and blossomed more into a 
movement.  The question really is has OOP made code easier to maintain 
and less complex.  Generally speaking, the answer is not really. The 
primary reasons for using OOP are encapsulation, polymorphism and 
inheritance.


Yes, encapsulation in scope is a good thing, but much of that can be 
achieved in other ways without using objects. When you take languages 
like C++, while the language itself is standardized, the name mangling 
that the compilers introduce is not standardized at all.  That makes 
prepackaged libraries and sometimes linking questionable unless you are 
using the same version and compiler.  It is enough of a problem every 
version of Linux recommends not updating your installation piecemeal  
(eg if I update XFCE, I better recompile everything that is linked to 
XFCE - even if everything is backward compatible).  Microsoft got around 
it somewhat by using their COM specification.


Polymorphism?  Yes, I will agree that polymorphism is helpful.  That can 
be achieved with things like pointers,  void arrays, and in the case of 
C11, the use of _Generics.


So that leaves inheritance as the last real standing benefit of OOP, and 
that is really the one everyone hates.  Most OOP languages limit 
inheritance to single instance in order to avoid some very bad problems. 
  Realistically 90% of the time, it is better to not inherit at all, 
but simply instantiate what you would have used as a base class as a 
variable class inside of your class, and then dispose of it when you are 
finished.  You have no problems with multiple inheritance, calling base 
functions, and overall you are wasting less of the stack and memory.


The major reason I object to OOP is exceptions.  They make it impossible 
to write code with 100% predictable exit points.   When code can exit at 
any point above and below your own, that means that things can leak.  
"Add a garbage collector," you might say.  What happens when the 
collector has a flaw and you do not know about it? Leak again.




 I imagine the reason why Glib was written in C is because binding 
to other languages is easier with C than C++.



I expect so. C is fairly straightforward.

Have a good day.

Likewise!


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Hendrik Boom]

On Fri, Jul 24, 2015 at 12:03:08PM +0200, Didier Kryn wrote:
> 
> Hey T.J., you seem to contradict yourself when saying "C and C++
> are strongly typed" and "Type checking is never C's job." :-)
> 
> Actually, yes, C and C++ are typed, but weakly. They silently do
> type conversion in pretty much every instruction. One assumes the
> programmers knows it and takes care...

I agree.

The term "strongly typed" is usually reserved for languges where the 
language guarantees that the program will not violate the type constraints 
at run time.  Free use of malloc and free makes this impossible.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Hendrik Boom]

On Thu, Jul 23, 2015 at 09:30:04PM -0500, T.J. Duchene wrote:
> On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote:
> > On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote:
> > > ... but, yeah, it's outside the scope of Devuan. D-Bus just sucks and is
> > > documented on a random basis, when you compare it to the rest of
> > > GNU/Fedora
> > > it's... like GTK: it sucks, there are alternatives but it's a PITA to port
> > > away 'cause a lot of big codebases uses them as foundation.
> > 
> > So there are alternatives to GTK:  Do any suck less?  What are they?
> > 
> What's wrong with GTK?  I don't care for it, but it is not any worse than 
> Microsoft's UI.  
> 
> There are lots of alternatives.  wxWidgets and Qt are the most common 
> suggestions, but there are far more esoteric ones.  If you are aiming for 
> widest portability support, Qt is probably your best bet.  
> 
> I don't care for it myself - because it is C++.  I do not believe in OOP as a 
> decent paradigm for software development.  I'm know I am in the minority, but 
> I am not alone.  Even Google has reined in use of some of the worst features 
> of OOP.  Programmers working for Google are not allowed to use exceptions.

I believe in OOP as a tool in my toolkit, but I do not believe in C++.  If 
you want to see an example of statically typed OOP  done right, look at 
Modula 3.  Although the syntax is excessively wordy, the semantics is 
clean.

> 
> Laters!
> 
> T.J.
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Didier Kryn]

Le 24/07/2015 07:14, T.J. Duchene a écrit :
C and C++ are both strongly typed, so I am assuming that he must be 
referring to GTK using a pointer in C presumably to dynamically handle 
function names and data for polymorphism.  He can't help it if GTK is 
sloppy, but I can't make sense of his grievance either. Type checking 
is never C's job, it's his!  That is explicit in the design of the 
language.  Everyone who uses C knows that.  C++ is the same for that 
matter.  Neither language checks your variable data for type.


Hey T.J., you seem to contradict yourself when saying "C and C++ 
are strongly typed" and "Type checking is never C's job." :-)


Actually, yes, C and C++ are typed, but weakly. They silently do 
type conversion in pretty much every instruction. One assumes the 
programmers knows it and takes care...


What are your preventions against OOP for graphics? Is it against 
OOP in general?


I imagine the reason why Glib was written in C is because binding 
to other languages is easier with C than C++.


Have a good day.
Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Roger Leigh]

On 24/07/2015 05:14, T.J. Duchene wrote:



On 7/23/2015 10:41 PM, Isaac Dunham wrote:



Now then, as for Roger's comments, I find them confusing.

[snip]

The C API is overly complex and fragile.  You don't want to base your
project on a sandcastle.  And the expertise required to use it is
very high. Implementing dynamic typing and manual vtable construction
rather than using C++ which does proper type checking?  Just use C++!


C and C++ are both strongly typed, so I am assuming that he must be
referring to GTK using a pointer in C presumably to dynamically handle
function names and data for polymorphism.  He can't help it if GTK is
sloppy, but I can't make sense of his grievance either. Type checking is
never C's job, it's his!  That is explicit in the design of the
language.  Everyone who uses C knows that.  C++ is the same for that
matter.  Neither language checks your variable data for type.


I'm referring to the *GTK* "C API" here.  Not C in general.  If I create 
a GObject-based "class", either as a subclass of a GTK class or as an 
independent class subclassed from the root GObject, I have to *by hand* 
construct a virtual call table and *by hand* register all the class and 
object construction and release functions, along with the instance and 
class structures with the GType type system.  This is work which the C++ 
compiler would have done for me, with no added complexity, and no chance 
for me to introduce bugs into the overly complex mess.  On top of that, 
the C++ class would be completely type-safe in all respects where the 
GType system requires allmost all type safety to be discarded to 
implement polymorphism.


The C++ compiler objectively does a better job here.  It's simpler, 
quicker to write, safer, easier to refactor.  And when I've done a full 
conversion of GObject-based C code to C++, the C++ compiler has picked 
up on real bugs which the C compiler hadn't picked up on (because the 
type information had been deliberately cast away).  GTK+ programs can be 
riddled with bugs, without the developer being any the wiser in the 
absence of compiler diagnostics.



I've always noted the GTK code tends to leak.  If  programmers with
experience can't be bothered to clean up after themselves, I'm glad GTK
is dying off.


It's really not so much "can't be bothered" as much as it's very 
difficult to manage all the manual reference counting.  In C++ with 
GTKmm it's all handled with smartpointers, making it impossible to screw 
up.  In regular C++ you have unique_ptr, shared_ptr etc. to do it for 
you as well.


The main point of my original post and in the above comments isn't that 
GTK+ and C can't work.  They can.  It's that the effort required to 
achieve a bug-free program is absurdly high, and in practice it's not 
even possible to verify that your code is actually bug free, and this is 
a problem that becomes increasingly intractable as the program size and 
complexity increases.  This is because the underlying unwritten 
assumption is that "the programmer will be perfect and not make 
mistakes".  It's quite obvious that no programmer is perfect, even great 
programmers make mistakes.  The contrast with C++ is that the assuption 
here is that the compiler will shoulder the burden and will fail to 
compile if there are any mistakes, since the presence of strong typing, 
RAII and smartpointers will guarantee correctness.  This too also has 
its limits, but put it this way: I haven't had a memory leak in C++ code 
in a decade due to the use of shared_ptr, and this isn't something I can 
say for my GTK+ C code, or GTK+ C code in general.



In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively.

[snip]


That's somewhat true, but if you write C++ code PROPERLY - i.e. make
sure you references are clean, resources released, and you aren't
leaving any hanging exceptions, what he is claiming is pretty much a
non-issue in the context of any OOP language.  A C++ compiler is no more
mysterious that any of the other OOP crap we are forced to endure. C++
code is simply not as robust as C.   You can mitigate a lot of the
annoyance;  like exceptions that cause premature exits - but you are
never really rid of it.


This is not what I meant.

The sentence above should read "you have to be an expert in C++ compiler 
internals just to be able to understand and use [the GTK/GObject type 
system] effectively".  I'm referring to the fact that you have to 
construct GObject virtual call tables by hand, something which the C++ 
compiler does for you, and which a C++ programmer doesn't in fact need 
to care about (it being an internal implementation detail of the 
compiler's code generation).  That is to say, to effectively use a C 
library you have to be more familiar with the internal details of C++ 
than most C++ programmers, and for absolutely zero benefit.



I think a lot of GTK's problems could be solved if it were rewritten to
take advant

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Roger Leigh]

On 24/07/2015 06:37, Didier Kryn wrote:

Le 24/07/2015 04:52, Jude Nelson a écrit :


I don't care for it myself - because it is C++.

Minor correction:  GTK is written in C, and relies on GLib, which is
also written C.  However, it's open to debate as to how
similar/different C-plus-GLib is to C++ in practice.


It's quite clear what the differences are.  GLib broadly provides C 
equivalents for what you get in the C++ standard library for free.
  However, the GLib implementations are often naive, inefficient, not 
type-safe and are awkward and complex to use.  Doing all the manual 
type-casting, refcounting and manual memory management etc. is necessary 
in C for generic containers, but completely unnecessary in C.


Consider something trivial, a vector of strings:

std::vector list({"item1", "item2", "itemn"});
list.emplace_back("newitem");
for (const auto& item : list)
  std::cout << "Item: " << item << '\n';

How much code is required to implement the equivalent with GLib strings 
and a list container?  It's a good bit longer and with much more 
complexity to achieve the same thing.  And as we get more complex with 
stuff like GObject, it becomes much, much worse.



Regards,
Roger
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Didier Kryn]

Le 24/07/2015 04:52, Jude Nelson a écrit :


On Thu, Jul 23, 2015 at 10:30 PM, T.J. Duchene > wrote:


On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote:
> On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote:
> > ... but, yeah, it's outside the scope of Devuan. D-Bus just
sucks and is
> > documented on a random basis, when you compare it to the rest of
> > GNU/Fedora
> > it's... like GTK: it sucks, there are alternatives but it's a
PITA to port
> > away 'cause a lot of big codebases uses them as foundation.
>
> So there are alternatives to GTK:  Do any suck less? What are they?
>
What's wrong with GTK?  I don't care for it, but it is not any
worse than
Microsoft's UI.

There are lots of alternatives.  wxWidgets and Qt are the most common
suggestions, but there are far more esoteric ones.  If you are
aiming for
widest portability support, Qt is probably your best bet.


Doesn't wxWidgets use GTK on GNU/Linux?


I don't care for it myself - because it is C++. 



Minor correction:  GTK is written in C, and relies on GLib, which is 
also written C.  However, it's open to debate as to how 
similar/different C-plus-GLib is to C++ in practice.



Yes, opaque structures are everywhere in Glib, AFAIR. That's the 
way to provide encapsulation in C. Some nice features of modern 
programming like encapsulation or generic programming do not belong to 
OOP, except in C++.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Isaac Dunham]

On Fri, Jul 24, 2015 at 12:14:21AM -0500, T.J. Duchene wrote:
> 
> 
> On 7/23/2015 10:41 PM, Isaac Dunham wrote:
> >I'm inclined to agree with you on C++, but I'd like to refer you to Roger
> >Leigh's comments on the subject about seven and a half months ago;
> >I'm only appending the first couple screenfuls (which is maybe a third
> >of the original) but you should be able to find the original email given
> >the headers and this text.
> I don't have a  high opinion of GTK either.  Honestly, I never did, but my
> opinion is subjective rather than objective.  I never bothered to learn GTK
> to a great extent.  I knew enough "back in the day" to hack the gnome-panel
> and add a new option or two that Gnome did not have, and I kept my changes
> to myself. That was the extent of my interest. Generally, I have a low
> opinion of UI kits because the designers tend to be horribly inconsistent.
> After GTK3 was released, I knew it was on the downhill slide.  They should
> have started over from the ground up, kept it generic, and added support for
> Qt desktop integration.  GTK has basically become part of Gnome, and no one
> of consequence except Gnome uses it.
> 
[snip]
> Now then, as for Roger's comments, I find them confusing.

Probably because my comments threw you off as to what he's talking
about.
The post in question is entirely about the problems with GTK.

> >[snip]
> >
> >The C API is overly complex and fragile.  You don't want to base your
> >project on a sandcastle.  And the expertise required to use it is
> >very high. Implementing dynamic typing and manual vtable construction
> >rather than using C++ which does proper type checking?  Just use C++!
> >
> C and C++ are both strongly typed, so I am assuming that he must be
> referring to GTK using a pointer in C presumably to dynamically handle
> function names and data for polymorphism.  He can't help it if GTK is
> sloppy, but I can't make sense of his grievance either. Type checking is
> never C's job, it's his!  That is explicit in the design of the language.
> Everyone who uses C knows that.  C++ is the same for that matter.  Neither
> language checks your variable data for type.

> >In fact, you have to be an expert in C++ compiler internals just to be
> >able to understand and use it effectively.
> >
> >[snip]
> >
> That's somewhat true, but if you write C++ code PROPERLY - i.e. make sure
> you references are clean, resources released, and you aren't leaving any
> hanging exceptions, what he is claiming is pretty much a non-issue in the
> context of any OOP language.  A C++ compiler is no more mysterious that any
> of the other OOP crap we are forced to endure. C++ code is simply not as
> robust as C.   You can mitigate a lot of the annoyance;  like exceptions
> that cause premature exits - but you are never really rid of it.

"it" != "C++"; "it" == "GTK".
The assertion is that GTK avoids using C++ by forcing the programmer to
essentially do what they would do in C++ *and* what C++ would do for them.

Hope this makes it a little clearer,
Isaac
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On 7/23/2015 10:41 PM, Isaac Dunham wrote:

I'm inclined to agree with you on C++, but I'd like to refer you to Roger
Leigh's comments on the subject about seven and a half months ago;
I'm only appending the first couple screenfuls (which is maybe a third
of the original) but you should be able to find the original email given
the headers and this text.
I don't have a  high opinion of GTK either.  Honestly, I never did, but 
my opinion is subjective rather than objective.  I never bothered to 
learn GTK to a great extent.  I knew enough "back in the day" to hack 
the gnome-panel and add a new option or two that Gnome did not have, and 
I kept my changes to myself. That was the extent of my interest. 
Generally, I have a low opinion of UI kits because the designers tend to 
be horribly inconsistent.  After GTK3 was released, I knew it was on the 
downhill slide.  They should have started over from the ground up, kept 
it generic, and added support for Qt desktop integration.  GTK has 
basically become part of Gnome, and no one of consequence except Gnome 
uses it.


I've seen very little new software written that uses GTK, except for 
things that use the Python bindings. (Yes, I despise Python, but will 
not discuss it here.) Most of it is very buggy.   In fact, I would say 
with confidence that GTK has receded so much that except for software 
that already uses it as a legacy, no software of any quality is being 
produced using GTK.  It has even lost a few.  Both Canonical and Google 
have either completely abandoned it or are choosing alternatives for new 
projects.



Now then, as for Roger's comments, I find them confusing.

[snip]

The C API is overly complex and fragile.  You don't want to base your
project on a sandcastle.  And the expertise required to use it is
very high. Implementing dynamic typing and manual vtable construction
rather than using C++ which does proper type checking?  Just use C++!

C and C++ are both strongly typed, so I am assuming that he must be 
referring to GTK using a pointer in C presumably to dynamically handle 
function names and data for polymorphism.  He can't help it if GTK is 
sloppy, but I can't make sense of his grievance either. Type checking is 
never C's job, it's his!  That is explicit in the design of the 
language.  Everyone who uses C knows that.  C++ is the same for that 
matter.  Neither language checks your variable data for type.


I've always noted the GTK code tends to leak.  If  programmers with 
experience can't be bothered to clean up after themselves, I'm glad GTK 
is dying off.




In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively.

[snip]

That's somewhat true, but if you write C++ code PROPERLY - i.e. make 
sure you references are clean, resources released, and you aren't 
leaving any hanging exceptions, what he is claiming is pretty much a 
non-issue in the context of any OOP language.  A C++ compiler is no more 
mysterious that any of the other OOP crap we are forced to endure. C++ 
code is simply not as robust as C.   You can mitigate a lot of the 
annoyance;  like exceptions that cause premature exits - but you are 
never really rid of it.


I think a lot of GTK's problems could be solved if it were rewritten to 
take advantage of C11, but I don't see that happening.  I doubt Gnome 
has enough people willing to do it.







___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Isaac Dunham]

On Thu, Jul 23, 2015 at 09:30:04PM -0500, T.J. Duchene wrote:
> On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote:
> > On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote:
> > > ... but, yeah, it's outside the scope of Devuan. D-Bus just sucks and is
> > > documented on a random basis, when you compare it to the rest of
> > > GNU/Fedora
> > > it's... like GTK: it sucks, there are alternatives but it's a PITA to port
> > > away 'cause a lot of big codebases uses them as foundation.
> > 
> > So there are alternatives to GTK:  Do any suck less?  What are they?
> > 
> What's wrong with GTK?  I don't care for it, but it is not any worse than 
> Microsoft's UI.  
> 
> There are lots of alternatives.  wxWidgets and Qt are the most common 
> suggestions, but there are far more esoteric ones.  If you are aiming for 
> widest portability support, Qt is probably your best bet.  
> I don't care for it myself - because it is C++.  I do not believe in OOP as a 
> decent paradigm for software development.  I'm know I am in the minority, but 
> I am not alone.  Even Google has reined in use of some of the worst features 
> of OOP.  Programmers working for Google are not allowed to use exceptions.

I'm inclined to agree with you on C++, but I'd like to refer you to Roger
Leigh's comments on the subject about seven and a half months ago;
I'm only appending the first couple screenfuls (which is maybe a third
of the original) but you should be able to find the original email given
the headers and this text.

Appending message:
Date: Sat, 6 Dec 2014 21:51:42 +
From: Roger Leigh 
To: dng@lists.dyne.org
Message-ID: <20141206215142.gw1...@codelibre.net>

On Sat, Dec 06, 2014 at 06:44:01PM +0100, mutek wrote:
> On sabato 6 dicembre 2014 18:32:04 CEST, Mihamina Rakotomandimby wrote:
> >On 12/06/2014 04:57 PM, Hendrik Boom wrote:
> >>On Fri, Dec 05, 2014 at 02:54:09PM +0200, Vlad wrote:
> >>>I would propose that we do not waste any time with GDM, GNOME
> >>>or
> anything
> >>>else that has sprung out of that irresponsible organizations
> >>>other than gtk.
> >>I wasn't aware that GTK had anything to do with that organisation.
> >>Isn't it the Gimp ToolKit?
> >>And isn't the Gimp the GNU Image Manipulation Program?
> >
> >Yes, but the Gimp tool kit has been adopted by the GNOME
> >develoment team to be their toolkit too.
> 
> whatever I saw in the industry...GTK it's not taken in account if
> compared with QT,MS-whatever,Java-whatever,HTML5-DOM-canvas-engines,

There are good reasons for that.  As a (former) professional GTK+
developer, I have found out the hard way that it's unsuitable for most
projects.  Nowadays, unsuitable for almost all projects outside GNOME.

> GTK did a very good job but seems invisible to the world out of the
> free softwares

That's because it's a terrible toolkit, and the number of people who
are experts with it is vanishingly small (and shrinking).  It's not a
safe platform on which to build anything serious.  Not because it
doesn't work, but because you can't easily hire people, and because
it's the least efficient and worst documented toolkit to work with.
If you want to achieve your own project's goals on time, this matters.

The C API is overly complex and fragile.  You don't want to base your
project on a sandcastle.  And the expertise required to use it is
very high.  Implementing dynamic typing and manual vtable construction
rather than using C++ which does proper type checking?  Just use C++!
In fact, you have to be an expert in C++ compiler internals just to be
able to understand and use it effectively.  It's like being a master
carpenter and then willingly eschewing your workshop for a rusty swiss
army knife!  While you could probably construct something with the
swiss army knife if you try really hard, the workshop will do a
faster, better, more professional job and let you get on with the job
rather than cursing at your inadequate tools every few minutes.

[snip]

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On 7/23/2015 9:52 PM, Jude Nelson wrote:




I don't care for it myself - because it is C++. 



Minor correction:  GTK is written in C, and relies on GLib, which is 
also written C.  However, it's open to debate as to how 
similar/different C-plus-GLib is to C++ in practice.



Apologies for the confusion.  I was referring to Qt as in the previous 
paragraph.I know GTK is C.  =)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[Jude Nelson]

On Thu, Jul 23, 2015 at 10:30 PM, T.J. Duchene 
wrote:

> On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote:
> > On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote:
> > > ... but, yeah, it's outside the scope of Devuan. D-Bus just sucks and
> is
> > > documented on a random basis, when you compare it to the rest of
> > > GNU/Fedora
> > > it's... like GTK: it sucks, there are alternatives but it's a PITA to
> port
> > > away 'cause a lot of big codebases uses them as foundation.
> >
> > So there are alternatives to GTK:  Do any suck less?  What are they?
> >
> What's wrong with GTK?  I don't care for it, but it is not any worse than
> Microsoft's UI.
>
> There are lots of alternatives.  wxWidgets and Qt are the most common
> suggestions, but there are far more esoteric ones.  If you are aiming for
> widest portability support, Qt is probably your best bet.
>

Doesn't wxWidgets use GTK on GNU/Linux?


>
> I don't care for it myself - because it is C++.


Minor correction:  GTK is written in C, and relies on GLib, which is also
written C.  However, it's open to debate as to how similar/different
C-plus-GLib is to C++ in practice.

Cheers,
Jude
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] GTK (was Will there be a MirDevuan "WTF"?)

[T.J. Duchene]

On Thursday, July 23, 2015 08:22:55 PM Hendrik Boom wrote:
> On Fri, Jul 24, 2015 at 12:12:01AM +0200, Teodoro Santoni wrote:
> > ... but, yeah, it's outside the scope of Devuan. D-Bus just sucks and is
> > documented on a random basis, when you compare it to the rest of
> > GNU/Fedora
> > it's... like GTK: it sucks, there are alternatives but it's a PITA to port
> > away 'cause a lot of big codebases uses them as foundation.
> 
> So there are alternatives to GTK:  Do any suck less?  What are they?
> 
What's wrong with GTK?  I don't care for it, but it is not any worse than 
Microsoft's UI.  

There are lots of alternatives.  wxWidgets and Qt are the most common 
suggestions, but there are far more esoteric ones.  If you are aiming for 
widest portability support, Qt is probably your best bet.  

I don't care for it myself - because it is C++.  I do not believe in OOP as a 
decent paradigm for software development.  I'm know I am in the minority, but 
I am not alone.  Even Google has reined in use of some of the worst features 
of OOP.  Programmers working for Google are not allowed to use exceptions.

Laters!

T.J.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng