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

On Wed, 16 Sep 2009 04:58:39 -0700, Szabolcs Nagy <nszabolcs_AT_gmail.com> wrote:

> On 9/16/09, Frederic DUBOIS <fdubois76_AT_gmail.com> wrote:
>> 2009/9/16 Uriel <lost.goblin_AT_gmail.com>:
>>> On Wed, Sep 16, 2009 at 12:03 AM, frederic <fdubois76_AT_gmail.com> wrote:
>>>> I'm pretty sure that if C featured closures, Anselm would cleverly use
>>>> them
>>>> and
>>>> make an even more simple, customizable and elegant dwm.
>>>
>>> I'm pretty sure that if C featured closures, Anselm and many others
>>> would promptly and cleverly hang themselves with them.
>>>
>>
>> This is slightly ambiguous. Do you mean:
>> - that they would hang themselves in despair? In that case, why do you think
>> so?
>> - that they would hang themselves by accident? In that case, you
>> consider that a dangerous features be offered. But then, I would argue
>> that pointers are as dangerous as closures.
>>
>
> i'd argue that closures don't mix well with the c style of programming
>
> eg if you add closures then you'd need anonymous functions then you'd
> start writing in the functional style passing around functions then
> you'd need memory management to clean up the return values and
> arguments (so you can write print(sum(map(atoi,
> split(read(filename)))))) and of course exception handling as return
> values have different purpose, not to mention multiple return values
> and sometime polymorphism is required as well with a bit more powerful
> type system with possible runtime dispatch oh and don't forget about
> module systems...
>
> it seems to me that c is a fairly closed design with a simple mental
> model, pointers are dangerous but fit into this model closures would
> make it a bit more convoluted with little additional gain
>
> if you need closures then a new language design is needed and you'd
> probably end up with a lisp or ml like language which is not good for
> managing flat memory spaces but useful in other areas..
>
>

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. 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.]

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.

Tying code to data allows encapsulation. If you think about the vtable pointer in objects as data then it also allows polymorphism. So, whether tying code to data is a useful programming paradigm is more complex than straightforward generalization. If you could include the next feature in your program with minimal changes because of encapsulation or polymorphism then tying code to data helps. If you appreciate the reuse value of the unix tools like grep/head/tail then you would also appreciate the "encapsulation" of the regex engine, or line/byte count inside the tool.

People who have given up on OO:
     - either have had too many setbacks with OO design of their software... (not entirely their fault, predicting feature requests is not easy)
     - or have figured out better ways of managing software evolution and at the same time reducing programming effort. Sadly, I haven't seen a good discussion on this topic.

Also, I would like to know, what do people on this list feel about type checking in general? A lot of language research in academia focuses on typing constructs when at the same time the industry seems to be favoring scripting languages and "duck" typing for productivity. What do you think?

-- 
Pinocchio