Movatterモバイル変換
[0]ホーム
Class Variable Question
Patrick Wraypwmail at my-deja.com
Thu Apr 12 01:02:42 EDT 2001
"Pieter Nagel" <pieter at equinox.co.za> wrote in messagenews:Pine.LNX.4.21.0104101931590.21742-100000 at bast.jhb.equinox.co.za...[...]> In fact, static type systems often force you to overspecify types too> narrowly; which forces one to a) write all kinds of runtime-type or> template or preprocessor gumph to get around the type system, which> is in itself error prone, or b) have code duplication all over the> show because the type system makes it too difficult to hoist the> higher-level abstractions out the code.I agree with these points, especially the part about "hoisting higher-levelabstractions out of the code". This is especially relevant for unsolvedproblems, or systems that are likely to change a lot.In my experience, the errors detected by static typing are usually merebookkeeping errors caused by fiddling and fussing with the type systemitself. Static typing forces you to mess with too many extraneous detailstoo soon, and the errors it detects are irrelevant to the problem you'retrying to solve. Hardly a big win.This is one of the reasons why I like Python and Lisp so much. Being able topostpone decisions about the internal representation of an object (or apiece of 'knowledge' if you will) is crucial for quickly trying out ideas tosee what works best. Static typing makes an evolving system brittle by'concretising' the abstractions too soon, unless you're lucky enough to hitupon the perfect solution up front (which I don't think happens very often).Once a system is very stable, it sometimes makes sense to fill in thenecessary type info for the compiler, or to enforce explicitly typedcontracts with users of the code, if that's your thing. But until then, astatic type system just gets in the way, causing more (real) problems thanit prevents, IMO.
More information about the Python-listmailing list
[8]ページ先頭