Subject: Re: garnet performance issues
From: Erik Naggum <>
Date: 1999/02/13
Newsgroups: comp.lang.lisp
Message-ID: <>

* Robert Monfera <>
| Haven't you forgotten to attach a smiley at the end of your sentence?


| If not, what have you meant by it?  To me, a parameterized type would be
| something like "vector of integers" or "list of bank transaction objects"
| where you parameterize LIST or VECTOR with your choice of element type.

  this entire issue is a joke on the explicit typing crowd.  by refusing to
  understand that lists and vectors and other generic collections shouldn't
  _have_ to be specialized on the type, they _invent_ a stupid need that
  smart people don't have.

  the whole parameterized type nonsense is a testament to bad language
  design.  it is completely devoid of meaning.

  incidentally, (make-array <dimensions> :element-type <type>) is your
  parameterized type if you didn't like my COERCE example, which I use to
  show these explicit typing doofuses who drop type information at runtime
  what they _really_ wanted, but didn't know how to ask for.  imagine a
  simple function that accepts a type _name_ as argument and tries its best
  to convert an object into that type.  it's template hell in C++.  the
  name of its types are _gone_ at runtime, for starters.

  if you want a list of bank transaction objects, just don't put anything
  else on it.  how hard can it be?  I fail to see the need to construct a
  bogus language construct just to make that _harder_.  if you want a typed
  container, define a class that has a type specifier and a sequence or
  whatever you want to hold them, and provide general functions to add
  things to it after having checked the type.  the problem is that this
  stuff is so seldom _needed_ in a language that remembers the types of its
  objects apart from whatever variable used to hold them.

| You can specialize methods on STRING, but not with something you create
| with DEFTYPE.

  if you're talking about CLOS methods, you're being disingenious.  CLOS
  was designed to dispatch on classes, not types.  if you don't like that,
  nothing whatsoever stops you from running down a TYPECASE or making a
  more general mechanism.  yes, you have to roll your own.  that's true for
  just about everything people want.  "I do not want what I haven't got"
  does not apply to programmers.  incidentally, PPRINT-DISPATCH has a nice
  type-dispatching system that does a lot more than CLOS dispatch does.

  just because something is a good thing to do when you regularly shoot
  yourself in the foot, doesn't mean it's a good thing to do if you can
  avoid shooting yourself in the foot.

  enough comparisons with C++.  I get sick to my stomach thinking about the
  talent wasted in inventing ways that braindamaged language can hurt less.

  Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
  Julk, August, September, October, November, December.