Re: the necessity of Lisp's Objects?
- From: Tim X <timx@xxxxxxxxxxxxxxx>
- Date: Sun, 27 Jan 2008 16:34:03 +1100
Xah Lee <xah@xxxxxxxxxx> writes:
Jon Harrop wrote:
«Exactly. You must be aware of stack consumption in C just as you must
be aware of it in Mathematica. There is no difference.»
Well, in my programing experiences since 1992, i don't know what is a
stack other than its mathematical concept of “first in last out”, but
i wrote a lot programs. In my programing in Mathematica, Perl, Python,
PHP, emacs lisp, SQL, i don't think here's a moment i thougt i need to
understand stacks more than its mathematical concepts.
Then I would suggest your programming experience has been quite limited
and the problems you have worked on fairly trivial.
I venture to say, more than 80% of today's professional programers
don't know what a stack is other than a vague idea of its mathematical
properties. (“professional programer” = people who's income are from
coding.)
A stack is one of the most basic of all the ADTs and for a programmer
not to know it or never use it is rediculous. However, I think that many
of the refernces in this thread refer to the call stack rather than the
more generic concept of a stack ADT. I would agree that due to improved
hardware, issues associated with the call stack are less frequent than
they use to be. At the same time, I think programmers do need to know
what the call stack is and the role it plays because an abstract
udnerstanding of this makes it a lot easier to make the right decision
when implementing an algorithm. I also think it helps in understanding
other aspects of programming, such as scope, closures etc.
i think, once a programer have some expertise in compilers, then
everything's a stack or some such mumble jumble. A language to specify
computation, do not require the concept, unless you are talking about
manipulating hardware.
Disagree. The stack and its role in a specific algorithm has impact on
the way you will implement the algorithm. For example, in C you may
decide to implement a function using call by reference rather than call
by value because you are dealing with large data structures and call by
value will result in a lot of memory allocation and increased stack
sizes that will make things slower and use more memory.
In our context of recursion error ... You characterise it as not
being aware of the language's stack consumption. I see it just as not
familiar with the language. There is no need, to speak of stacks, just
as there is no need, to speak of the CPU's architecture, or
electronics and electricity.
How would you explain the language limitation with recursion without
reference to the stack? The bottom line, the stack is the underlying
cause and you can't understand the cause without reference to this. You
could just find out that the language is limited in some way wrt
recursion, but how would you understand what this limitation is and
where else it may have an impact without have some understanding of the
stack and how it works? When you run into the recursion limitation, how
will you know what solution to apply in order to get around the problem
if you don't understand the underlying cause - for example, how do you
understand how tail recursion and recursion optimisation works if you
don't understand the role of the stack?
but why do you have such an issue with mentioning the stack - it is the
reason the language has the limitation. I also disagree with your
assertion you don't need to know about the CPU. Assertions like these
only hold true if you are doing very trivial programming. If you have
something less trivial, then it is essential information.
A simple example. You are writing a program and have to work out the
algorithm for a specific part. You need to make a choice regardig the
basic data structure to use. There are two possible choices, both with
their own pros and cons. One is to use a hash and the other is to use
some form of tree. The pros and cons relating to the different
properties of a hash and tree are fairly balanced given the current
problem, so we look at other issues that may have impact. One such issue
is efficiency of accessing the different data types. In some
cases, there may be large differences in this area due to the CPU and
the type of and size of cache it has. It is quite possible that the hash
may be more efficient because of a higher likelihood that subsequent
lookups are already in the cache. The tree structure o the other hand is
slower because of a higher number of cache misses because the memory
layout of the tree means that subsequent accesses are less likely to be
in the cache and the disk seek time is adding to the overhead
etc. Knowing this information about the CPU , cache, RAM and disk, I
might decide to still use a tree structure, but I may implement it in
such a way that I have an increased likelihood of subsequent accesses
being found in the cache. for example, maybe I will implement it so that
its actually built on top of an array and therefore all of the tree
nodes are in a contiguous block of memory rather than being scattered
through the memory, on different pages etc or maybe I will grab a single
block of memory and map the tree onto that etc.
--
tcross (at) rapttech dot com dot au
.
- Prev by Date: Re: the necessity of Lisp's Objects?
- Next by Date: Re: type algebra
- Previous by thread: Re: the necessity of Lisp's Objects?
- Next by thread: Re: the necessity of Lisp's Objects?
- Index(es):
Relevant Pages
|
