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

On Fri, 18 Sep 2009 05:00:05 +0200, Pinocchio <cchinopio_AT_gmail.com> wrote:

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

This is a bit exagerated. Automatic memory management is not required, but
it is nice to have because it removes a lot of burden.

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

Code reuse is not the monopoly of OO. Code reuse is just a matter of
librairies and their usability.
When a program is well designed, you generally end up with an aggregate of
modules, each one doing one thing. They may be turned into libraries with
little
extra efforts and be reused in another project.

Anticipating changes in the code is a generally a bad idea, because your
predictions are likely to fail - but the extra work and the extra code
costs
you something. In my experience, focusing on good design is generally
enough:
it allows you to make the requested changes in an acceptable time.

> 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?

I favour static typing because of the extra safety and optimisations; it
also help
communications between programmers at source level (when the types are not
automatically
inferred, that is). I detest those dynamic languages with which a typo in
the name of a variable
makes your app blow at runtime (if you're lucky).
Received on Fri Sep 18 2009 - 13:22:44 UTC