Re: [dev] Conversation with Anselm R. Garbe of

From: Pinocchio <>
Date: Fri, 18 Sep 2009 18:33:48 -0700

On Thu, 17 Sep 2009 22:41:16 -0700, Uriel <> wrote:

>> Did you take a look at the "blocks" extension to the C language in Apple's
>> recently opensourced GCD? They fought with some of the same problems you
>> mention above but they worked around it.
> Please, lets kill this before it even gets started, we had a huge
> discussion about this crap in 9fans if anyone is interested.

Can you summarize why do you think it is crap, for those who are not on the 9fans list?

>> What do you think about
>> co-routines? They are more general (and useful) than closures and also
>> explicitly deal with state / storage. I also like them because it helps
>> developers view actions within their program linearly instead of jumping
>> around functions referring to global state. [I would love to elaborate but
>> the post would become very long.]
> For coroutines in C see libtask ( ) and
> libthread ( ).

I didn't know that plan9 threads were co-routines. However, mixing them together seems to have atleast one unpleasant effect:
" System calls such as
           read(3) block the entire proc; all threads in a proc block
           until the system call finishes.

>> The OO debate in this thread is also very interesting. I would argue that
>> its really a trade-off between "predicting" future changes in your source
>> and "getting the prediction wrong". I would argue that it is _great_ to see
>> a lot of code reuse due to OO inheritance and polymorphism (the good thing
>> about OO) but at the same time extremely painful if the inheritance and
>> polymorphic structure is not aligned to new changes to the source.
> And I would argue you have no clue what you are talking about, one can
> have polymorphism without OO, inheritance on the other hand is about
> the most stupid way to do code reuse and causes one to write more code
> and in more convoluted ways than not using it at all, even if you had
> an omniscient crystal ball.

I agree with your "polymorphism without OO" point. However, C function pointers in structs is a very limited way of looking at it. I would like to know which ways of doing polymorphism do you prefer.
For the rest, I humbly beg to differ.

>> Tying code to data allows encapsulation.
> *BULLSHIT* Grep and sed allow encapsulation, OO does not, it allows
> tight coupling between components which is the opposite of
> encapsulation.

Tight coupling doesn't imply OO.
OO doesn't imply tight coupling.
C doesn't imply non-tight coupling.

Grep and sed adhere to the stdin/stdout "interface". I think those tools are enjoyable because that interface is a well established standard and doesn't evolve as most other software. Think about all the changes you might have to make in Unix tools once you change something subtle (blocking / signaling semantics) in the stdin/stdout "interface".

Received on Sat Sep 19 2009 - 01:33:48 UTC

This archive was generated by hypermail 2.2.0 : Sat Sep 19 2009 - 01:36:02 UTC