Re: [Caml-list] GC and file descriptors

[Matt Gushee <matt@gushee.net>]

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