POV-Ray : Newsgroups : povray.off-topic : GIMP hotkeys/ scripts/ user-defined functions? : Re: Undirected rambling Server Time
7 Sep 2024 05:11:55 EDT (-0400)
  Re: Undirected rambling  
From: clipka
Date: 11 Dec 2008 15:40:01
Message: <web.49417a362c1c4b9af708085d0@news.povray.org>
Orchid XP v8 <voi### [at] devnull> wrote:
> Also, if you *change* how your code works (e.g., you add an extra layer
> of indirection), having a type system means you can just follow the
> error messages to find the exact places where you need to change something.

Not really the wisest approach.

Been there, seen it. Sometimes I confess I do just that. But when it comes to
changes in critical subsystems, or changes in a critical phase of a project, I
make sure I find *ALL* the places that need changing before the compiler does.
Because if the compiler finds some, chances are he's just reporting the tip of
the iceberg.

BTW, I really like (attention - possible flamewar ahead! :)) Microsoft Visual C#
in this respect: Comes with integrated code refactoring, which is a real
pleasure to work with.

Oh, and when it comes to strict vs. dynamic type checking, I advocate the
approach as done by most mainstream OO languages these days (like Java, C#
etc.): Strict type checking, with language syntax allowing to override it
("type casting") where needed. And polymorphism and/or interface patterns
designed into the language, to be able to tell both the static and dynamic type
checking mechanisms which types are interchangeable for which purpose.

The total absence of *any* type checking in some languages, like JavaScript, may
be handy for very small quick-and-dirty stuff, because it is easy to e.g. add
new properties to a whole bunch of objects without needing to rewrite any
interface declarations, but for larger projects I guess it is too inviting for
a write-first-document-later approach. In large enough projects it may work
again because good documentation must be in place anyway - but then again, at
that scale automatic type checking - both at compile and run time - should not
hinder development in any way at all (otherwise your development process is
probably bogus anyway), and the corresponding language constructs may actually
provide a good formalism for certain aspects of the documentation.


I didn't have the opportunity yet to work with functional programming languages,
but from what I see I'd probably experience them as a PITA, and an increased
risk factor for an early death from brain haemorrhaging ;)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.