Re: Teaching new tricks to an old dog (C++ -->Ada)

From: jayessay (nospam_at_foo.com)
Date: 03/26/05


Date: 25 Mar 2005 22:28:22 -0500

Jared <nowhere@nowhere.nowhere> writes:

> And that is why $YOUR_LANGUAGE should allow arbitrary array indices.
  Or
> should have all types be anonymous. Or should use structural type
> equivalence. Or should combine data and method declarations for object
> types. <Looks around guiltily.> Or should have a preprocessor. Or
> infer all types. Or whatever. Just like $MY_LANGUAGE.

I don't buy this total "relativism". It smacks of the "Turing
equivalent" arguments.

> > Robert Duff made a comment a while ago about how silly most (I would
> > say without much hyperbole 99+%) of the points in these threads would
> > be to Lisp (and Smalltalk) folks. I couldn't agree more. You are all
> > arguing over differences that mean almost nothing looked at from these
> > other perspectives.
>
> This is quite correct, but also largely irrelevant. The general context

I suppose you are correct here. I'm here because I still do follow
(at least in passing) how Ada is doing and what it's followers are up
to. I try not to get into these things, but the comment from J.Coffin
comparing Lisp macros to a "preprocessor" was too much to ignore.
It's sad really how very little people here have even the ghost of an
idea of what something like Common Lisp is, can provide, and can do.

> of a language flamewar is that every feature $YOUR_LANGUAGE has that
> $MY_LANGUAGE doesn't have is unnecessary, and a clear sign of its
> inferiority. Any feature $MY_LANGUAGE has that $YOUR_LANGUAGE lacks
> is absolutely essential, and a clear sign of its superiority.

Well, now _that_ is certainly on target.

> A functional language like Lisp lacks many of the features being argued

Lisp is not really a functional language, though it can be used as
one. It is very much multiparadigm.

> Yes, a person can do all kinds of neat things in Lisp. A good programmer
> can do all kinds of neat things elegantly in any language, and a bad
> programmer cannot.

This again sounds like a TE argument and so not particularly good.
The key thing aboug Lisp is that it is a programmable programming
language and thus can incorporate at any point any construct from any
language seamlessly and transparently into it. Does that make it
_necessarily_ superior to anything else? No - that typically is
heavily context dependent. But after having analyzed and used all
these "lesser" languages it is clear to me that in _most_ cases it is
definitely superior. Nobody here is going to believe any of this.
Then again, next to nobody here even has the ghost of a clue about the
facts that would undermine their belief.

> > And the level
> > of _expressive capability_ in
>
> Aldor?
>
> > is so
> > _low_ that it again is simply amazing to see people so vehemently
> > arguing over differences that are almost invisible.
>
> I'm sure you meant expressive convenience. Turing completeness ensures

No, I meant expressive capability also called expressivness, or
expressivity. Turing equivalence is totally irrelevant. If it had
any meaning in such discussions we would all be toggling in programs
as 1' and 0's at consoles.

> "The sooner we can forget that FORTRAN has ever existed, the better, for
> as a vehicle of thought it is no longer adequate: it wastes our
> brainpower, is too risky and therefore too expensive to use."
> - E.W. Dijkstra, EWD 340
>
> The arguments being carried on here echo this complaint. Implicit in the
> arguments for both sides is that the one wastes brainpower while the
> other conserves it. That's fairly important, given that brainpower is
> the only tool a programmer really has.

Yes, indeed. This is very on target and is at the heart of the issue.
Which brings us full circle to the point here that the differences
being argued, from the perspective of Lisp (or Smalltalk) are so small
as to be meaningless.

/Jon

-- 
'j' - a n t h o n y at romeo/charley/november com


Relevant Pages

  • Re: [OT] PostLisp, a language experiment
    ... >>latter method in Lisp, and C and many other languages so that the code ... >>the complexity and number of stack items for each definition. ... I do the same thing with my assembly language code, my Java code, my C++ ... >>useless to any experienced Lisp programmer. ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... will still leave Lisp a very marginal language, ... "Macros are one of the worst problems with Lisp, ... If you don't write macros, ... C++ programmer, productivity wise. ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... will still leave Lisp a very marginal language, ... "Macros are one of the worst problems with Lisp, ... If you don't write macros, ... C++ programmer, productivity wise. ...
    (comp.lang.lisp)
  • Re: CL failure stories?
    ... > after deciding on Lisp as an implementation language. ... > question are failures based on unwillingness to properly indent code ... programmer starting with C++. ...
    (comp.lang.lisp)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... idea of what something like Common Lisp is, can provide, and can do. ... Lisp is not really a functional language, though it can be used as ... Turing equivalence is totally irrelevant. ... > the only tool a programmer really has. ...
    (comp.lang.cpp)