Newbie questions 
Author Message
 Newbie questions

[Followup-to comp.lang.lisp]

Quote:
>....
>| C++ is a concerted effort to reduce that possibility of self-destruction.

>  it must be Slobodan Milosovic's favorite programming language, then.

Oh, grow up.

Quote:
>| True, Lisp gives you the option of run-time program correction... but
>| sometimes requirements don't allow that comfort.

>  you know, I'm a little irritated by the ignorant newbies who come here
>  and on other lists and aske all sorts of inane questions, but it beats
>  having to deal with ignorants who think they now enough to make blanket
>  statements.

>#:Erik

Once again, grow up.

Joshua Scholar



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> >...  compose(
> >    bind2nd(equal_to<string>(), string("John")).
> >    mem_fun(&Person::getName)) ..

> I've never seen an expression like this.  Perhaps I misunderstand, but
> it looks to me like you're fighting the language in order to get
> anonymous functions, FORGET ANONYMITY!

I don't think using standard library functions and idioms could be
called 'fighting the language'. With the exception of 'compose' of
course. 'compose' never made it into the standard but was in the
original STL and is provided by the SGI STL libraries. 'bind2nd',
'mem_fun' and 'equal_to' are in the standard and the sort of code
above is a reasonably common idiom in standard C++ - certainly not
'fighting the language'.

Quote:
> You're sacrificing readable syntax just in order to not name
> something - that's a rip off.  So the function needs a name, so
> what?

The amount of overhead in writing a function or class member to
perform small operations can be larger than you realise. Every time I
want to do something like the above i'd have to write a function, give
it a name, pollute some namespace somewhere to do it. It also removes
locality of code. The function to do the comparison for the specific
string won't be located near where it is done. If I want to add one to
every item in a vector I don't want to write a new function just to do
this. I want to be able to 'inline' some code to make it easier to
read:

vector<int> source = [...];
vector<int> destination;

transform(
  source.begin(),
  source.end(),
  back_inserter(destination),
  bind1st(plus<int>(), 1));

I could write an iterative loop to do the above but there is more
likelyhood of error (getting loop termination incorrect, etc). Better
to reuse the standard library components.

for(vector<int>::iterator it = source.begin();
    it != source.end();
    ++it)
{
  destination.push_back(*it + 1);

Quote:
}

But getting back to the main subject. You mentioned in a previous post
that you didn't see a use for closures. Yet you have the counted
pointer and closure classes that you've created to try and emulate
some of the functionality. This sort of thing is much easier to use
and much more general if it is provided by the language itself. In
Dylan the transform code above is:

destination := map(curry(\+, 1), source);

Chris.



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

| Oh, grow up.
:
| Once again, grow up.

  it is amusing to give simple people something trivial to hold on to and
  watch them completely miss everything more challenging than kindergarten
  responses.  you were tested, Joshua, and you failed, unsurprisingly.
  next time, do yourself a favor and consider getting the jokes and the
  ridicule and respond to the issues you now conveniently elided.  that
  would _show_ us that you have yourself grown up.

  it appears that you belong in comp.ai, still.  followups redirected.

#:Erik



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> Well Bagheera didn't state the problem quite right.  The overall point
> is that type checking saves you from tons and tons of late night typos
> and logic errors.

Nothing in CL forbids you from type-declaring every variable.  Knock
yourself out.  Don't forget to send bug reports when the compiler
fails to use them well or flag problems, so your vendor will know
you care.

But the language itself already supports this.  It's simply up to the
market to decide if this is what stands between it and success. I doubt
it is, but you're welcome to make the case otherwise.

Quote:
> And the time is when you have to deliver working code in the morning
> and there isn't enough budget for more than a week more of testing!
> So any error that gets into the code is far too many.  It happens all
> the time in the game business.  

This is a pure engineering choice.  To the extent you want to make it,
you're right.  But there are many things in the world that you don't
know well enough at code-writing time and still have to code up.
If the very same compiler won't compile until the code is type-safe,
that code can't be delivered.  What is right depends on your need
(based on your personal requirements, project requirements, and
customer needs).

I won't try to tell you not to write declarations if you won't try to
tell me that I must write them.  As to the question of how they are
used, the language is designed in a way that it doesn't affect the
semantics--it's purely a performance issue, to be sorted out by
individual vendors as they see fit.  There are a lot of vendors.  Surely
one of them will care.  Or grab CMU CL and start from there.  It cared
a lot about declarations.

Quote:
> <evil voice> WELCOME TO MY WORLD. HA HA HA HA HA! </evil voice>

> Passing the wrong parameter, parameters in the wrong order, the wrong
> subfield etc. are common typos and often caught by the compiler -

Yes, already done.  But remember also that passing the wrong parameter
may not be fatal.  Error handlers may catch it.  The code may be going to
get updated before it's run.  The caller may be wrong or the callee.
I would not like to see any of these flexibilities removed.

Quote:
> especially if you design your class interfaces to catch as much as
> possible.

Lisp is a language for being flexible.  That is why it has survived
all these years. I think it's fine for you to give up your flexibility
on a case by case basis, but please don't confuse your personal need
with a design theory.  None of the things you're saying are false but
neither are they "uniquely determined points of view".

Quote:
> In code that rarely runs or isn't expected to run under
> normal conditions, this sort of correctness checking is very
> important.

You don't say what your point is.

This sounds like fodder for bug reports.  IMO, There is nothing wrong
with the language in this regard.  You're welcome to disagree, but
please be specific about what you'd like to see done instead so that
people (including myself) can evaluate whether your perfect world
infringes theirs.



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

| The overall point is that type checking saves you from tons and tons of
| late night typos and logic errors.

  well, type checking is necessary, but it appears that you don't know the
  difference between compile-time and run-time type checking, and assume
  that without compile-time type checking, there wouldn't be any.  _that_
  would be a source of tons and tons of typos and logic errors.  however,
  the ridiculously simple-minded static type checking in C++ restrict you
  to a single line of inheritance, has no universal supertype, and offers
  no way to know the type of an object at run-time except by embedding it
  in a class and using RTTI.  that is sufficiently inconvenient that the
  customary way to deal with multiple types of return values is to use an
  "invalid value", like the infamous NULL pointer.

| Passing the wrong parameter, parameters in the wrong order, the wrong
| subfield etc. are common typos and often caught by the compiler -
| especially if you design your class interfaces to catch as much as
| possible.  In code that rarely runs or isn't expected to run under normal
| conditions, this sort of correctness checking is very important.

  it sounds like you think you're telling people something new.  why?  this
  is so obvious it's been taken care of in much better than to require the
  programmer to declare the types of _all_ objects _explicitly_, which is,
  unsurprisingly, a major source of typos and logic errors, not to mention
  recompilation and header file (interface) changes that need to propagate
  to other team members.

  oh, by the way, since I see your favorite argument coming: knowing C++ is
  part of growing up.  discarding C++ is a matter of course once you have
  grown up.  explicit type declarations is useful for new programmers the
  same way bicycles for kids have support wheels.  few kids argue against
  their removal.

#:Erik



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

I want to make it clear that I haven't been trying to argue that C++
is better than LISP.  

What happened is that I stumbled into a thread on comp.ai where a few
people, a couple of whom I know enough about to respect, were arguing
that LISP is more appropriate than C++ for AI.

Now in my work (game programming) I don't really have a choice, I more
or less have to use C++.  

What I wanted to find out is what exactly were the reasons that some
preferred LISP so that I could abstract those strengths or methods
into my work, under the limitations I work under.

Unfortunately I got sidetracked by an evangelist who was more
interested in convincing me to use a specific language than in talking
about programming techniques and I also ended up trying to defend and
explain the limitations I work under - none of which is actually an
attack on the usefulness of LISP.  The strongest thing I have to say
is that my company is not going to be willing to let its programmers
use LISP, that some of the reasons for this are quite valid and that I
haven't been given enough ammunition to challenge anyone's opinion on
the matter.

So everyone who thinks been defending LISP from a detractor, you can
calm down, that's not what is going on.

Joshua Scholar



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

>>        C and C++ map more closely to the Chicken Pulley Unit's
>> instruction set than any other high-level landwich.  You could write a
>> LISP compiler in C, but you'd have quite a problem if you wanted to
>> write a C compiler using LISP.

>Symbolics had C, fortran and I think Pascal compilers written in, erm,
>Lisp.

>I was really disappointed when I found they had an X implementation,
>only to discover when looking at the source that it was just MIT X,
>compiled with their C compiler.

An X implementation written in a Lisp would indeed be extremely
interesting.  Definitely would need some interesting compilation
techniques to stay fast; it would doubtless {*filter*}le some bugs out of
existence.
--
"Microsoft builds product loyalty on the part of network administrators and
consultants, [these are] the only people who really count in the Microsoft
scheme of things. Users are an expendable commodity."  -- Mitch Stone 1997



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> What I wanted to find out is what exactly were the reasons that some
> preferred LISP so that I could abstract those strengths or methods
> into my work, under the limitations I work under.

http://world.std.com/~pitman/PS/Hindsight.html

It's not a full list, but it might be helpful to you.

(Someone noted after I wrote this article, that I'd failed to mention
automatic storage management (gc) in the article; kind of a glaring
omission.  Oh well..)



Sun, 21 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software