From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id HAA22965; Thu, 20 Nov 2003 07:35:09 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id HAA23141 for ; Thu, 20 Nov 2003 07:35:08 +0100 (MET) Received: from mz1.forethought.net (mzpi3.forethought.net [216.241.36.12]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAK6Z7122779 for ; Thu, 20 Nov 2003 07:35:07 +0100 (MET) Received: from [216.241.35.41] (helo=swordfish) by mz1.forethought.net with esmtp (Exim 4.14) id 1AMiPB-0006If-SZ for caml-list@pauillac.inria.fr; Wed, 19 Nov 2003 23:35:05 -0700 Received: from matt by swordfish with local (Exim 3.35 #1 (Debian)) id 1AMiPH-0001Ij-00 for ; Wed, 19 Nov 2003 23:35:11 -0700 Date: Wed, 19 Nov 2003 23:35:11 -0700 From: Matt Gushee To: caml-list@pauillac.inria.fr Subject: Re: [Caml-list] GC and file descriptors Message-ID: <20031120063510.GC893@swordfish> Reply-To: Matt Gushee Mail-Followup-To: caml-list@pauillac.inria.fr References: <20031118232227.GA8437@swordfish> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Loop: caml-list@inria.fr X-Spam: no; 0.00; gushee:01 gushee:01 caml-list:01 0600,:01 run-time:01 run-time:01 powerfull:01 compile-time:01 distinctions:01 schema:01 obstacle:01 compiles:01 accusing:01 knuth:01 interfacing:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Tue, Nov 18, 2003 at 09:07:17PM -0600, Brian Hurt wrote: > > > > > single-person, throw-away projects. And they aren't that far from > > > > I beg to differ (see below)! > > > > I concede the point. > > > > One problem I have is that programming is going away from strict compile > > > time type checking to run-time type checking. The problem with run-time > > > type checking is that it only catches errors in the field. Static type > > > checking is the most powerfull tool we've come up with to ensure > > > correctness in programs. And no, unit tests are not a replacement for > > > strict compile-time type checking. > > > > But doesn't the value of type checking depend on the types of problems > > you are working with? Many important problems in Web programming, for > > example, depend on distinguishing between differently-structured > > strings (including HTML and XML markup, of course, but also things like > > URI references and e-mail addresses). To my knowledge, there are very > > few existing type systems that even attempt to accommodate such > > distinctions (XML Schema is the only one I know of). > > "Airbags in dashboards don't help you with side-impact collisions, so why > do we need airbags?" Nice metaphor. Though I would point out that "safety" in software, or lack thereof, rarely directly affects life and limb ... so that it may be more acceptable to cut corners on safety for economic reasons (though I don't necessarily agree with that reasoning). > Strong type checking is not a replacement for unit tests either. > > That being said, what advantage does weak type checking, or run-time type > checking, give you in this situation? None, if your focus is exclusively on software-as-product. On the other hand, dynamically-typed languages mostly dispense with variable type declarations (as, of course, does OCaml in most cases). I would claim that elaborate rituals like public static void main(String[] args) { can be an obstacle to clear thinking about the many problems that go beyond type safety. And too much attention to type safety can lead programmers into the trap of thinking that whatever compiles must be good (I'm not accusing you of this error, though I was tempted to do so ;-). As Donald Knuth famously remarked, Beware of bugs in the above code; I have only proved it correct, not tried it. If I read him right, he thought that correctness (including, I imagine, type safety) was a necessary but not sufficient condition for quality software, which seems to be your view also. And I don't disagree, really. One of the reasons I got interested in OCaml was that it offers much of the expressiveness of the "scripting languages" together with strong type safety. But I get worried when I see the quest for program correctness take on a religious tinge, as it sometimes appears to on this list. So I thought it was time to play Devil's Advocate. > > So in some cases, good string manipulation and regexp facilities can be > > much more valuable than type checking ... and this is one of the > > The big advantage Java has is J2EE. Basically, if you're doing any sort > of major enterprise app, J2EE solves the hardest parts (failover, load > balancing, distributed computing, interfacing with legacy systems and DBs, > etc) for you. Okay, I'll grant that, but I don't see what it has to do with the merits of static typing. > I do agree that Ocaml could use better regex handling. Thanks to being > able to define new operators, you wouldn't even need to change the > language, you could do it all in a library. > > > Does the shift away from compile-time checking really mean the world is > > going to Hell in a handbasket, or does it simply reflect the > > (postulated) fact that programmers today are commonly dealing with > > distinctions that aren't accommodated by type systems, even the more > > sophisticated ones such as OCaml's? > > You're arguing that most programmers are doing web programming? Nonsense! I was speaking of a relative shift in emphasis, and offered Web programming as an example. > Yes, things are going downhill. Even within my adult lifetime it's become > more acceptable to ship programs with known flaws in them. Hmm ... I also have the sense that quality is gradually becoming extinct, not just in computer software, but also in most consumer products, in education and politics. But is that true, strictly speaking, in the case of software (sincere question here, I really don't know the answer)? Are the kinds of mission-critical systems that have been around for decades actually getting worse? Or is it rather that business doesn't see fit to provide quality products for the many new uses--and users--of computers that have arisen? > When I was in college, C was derided for having too weak a typing system- > now the new popular languages make C look strongly typed. Perhaps ... but noone has ever seriously suggested that Python, Perl and friends should *replace* C. Rather, the argument is that "scripting" languages are best suited for high-level tasks (especially in text-intensive applications), often in combination with C libraries that will perform common, performance-intensive routines. -- Matt Gushee When a nation follows the Way, Englewood, Colorado, USA Horses bear manure through mgushee@havenrock.com its fields; http://www.havenrock.com/ When a nation ignores the Way, Horses bear soldiers through its streets. --Lao Tzu (Peter Merel, trans.) ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners