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

On Sat, Sep 19, 2009 at 3:33 AM, Pinocchio <cchinopio_AT_gmail.com> wrote:
> 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.
> "

This is not a problem, this is by design, makes things simple, clean
and elegant, and is a very good thing.

That is why one uses something like ioproc:
http://man.cat-v.org/p9p/3/ioproc which solves the problem in an
infinitely more elegant and clean way than the async IO insanity full
of callbacks and events and such crap.

And with this I'm done with this thread. Have fun

uriel

>
>>
>>> 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".
>
> --
> Pinocchio
>
>
Received on Sat Sep 19 2009 - 06:09:24 UTC