On Thu, 17 Sep 2009 22:41:16 -0700, Uriel <lost.goblin_AT_gmail.com> 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 ( http://swtch.com/libtask/ ) and
> libthread ( http://man.cat-v.org/p9p/3/thread ).
>
I didn't know that plan9 threads were co-routines. However, mixing them together seems to have atleast one unpleasant effect:
(from http://man.cat-v.org/p9p/3/thread)
" 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".
-- PinocchioReceived 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