On Fri, 18 Sep 2009 05:00:05 +0200, Pinocchio <cchino...@gmail.com> wrote:
On Wed, 16 Sep 2009 04:58:39 -0700, Szabolcs Nagy <nszabo...@gmail.com>
wrote:
On 9/16/09, Frederic DUBOIS <fduboi...@gmail.com> wrote:
2009/9/16 Uriel <lost.gob...@gmail.com>:
On Wed, Sep 16, 2009 at 12:03 AM, frederic <fduboi...@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).
