Well, it all depends on the algorithm. If the algorithm is recursive,
and you dont need those things at tbe bottom before you need those on
the top, and if you do then you have a second stack where you dup
them, or pass copies of them to whoever needs them.
> Perhaps, instead of a stack, you want to use a block of flat memory accessed via a linked-list?
Yes, right now we are all discussing in generalities. I had to discuss
in generalities because if I were to bring in a specific, everyone
would collapse to that example. I want you to bring in examples where
one technique is better than the other. The idea is to know the limits
of stack for processing and where one can deviate from a canonical
stack and get additional functionality.
Isnt stack itself a programming paradigm ? people talk of "stack
languages" and "stack architectures" so its a paradigm to be examined
in its own right by the use of examples. I am looking for illustrative
examples from the readers.
> > Because a stack has push and pop, it is able to release and allocate
> > memory. We envisage an exogenous stack which has malloc() associated
> > with a push and free() associated with a pop.
>
> Allocation on a stack is usually done by the non-standard call alloca().
> Freeing is a part of the procedure exit code, called an epilog, for cleaning
> up the stackframe. But, the C stack, upon which alloca() allocates, is
> endogenous.http://linux.die.net/man/3/alloca
How is it different from malloc ? why is it not promoted in textbooks
like k&r ? The scary part is here :
Bugs
The alloca() function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.
On many systems alloca() cannot be used inside the list of arguments
of a function call, because the stack space reserved by alloca() would
appear on the stack in the middle of the space for the function
arguments.
> > If Forth is a general processing language based on stack, is it
> > possible to convert any and all algorithms to stack based ones
>
> No. You misunderstand Forth. Forth can also store variables, constants,
> etc. data, within compiled "words". The "words" are stored in memory in an
> area called a "dictionary". When one stores data in a "word", such "words"
> are essentially an object-oriented procedure, i.e., word = data + code.
Are these dictionaries closer to an object of C++ or to the lists of
lisp ?
> > We look for an exogenous stack so that
> > element size can vary.
>
> What does a varying element size have to do with an exogenous stack?
you can malloc a long string or dictionary of varying length and one
of the pointers in the stack of pointers point to it.
> In another post of yours:
>
> > cons cell
>
> Lisp? Are you trying to port or compile Lisp?
cons cell is just a convenient name to refer to an exogenous pair of
pointers, the one used everywhere to build an exogenous binary linked
list.
> Rod Pemberton
> PS dropped comp.theory and comp.lang.python due to limitations...
On Aug 17, 6:32 am, "william..." <william.o.ya...@gmail.com> wrote:
> the original question brings up an important point about "stack", or
> "recursion" limits imposed by system/memory/virtual/etc...
>
> an onion has between 40-90 layers, depending on season/breed...
>
> a typical multi-AI construct can require 1500-10K+ layers...
> (call them tails/recursions/far-reach whatever...)...
>
> the answer to the original question is "how much are you willing to
> take responsibility for...?"...
>
> garbage collection, memory sweeps, de-allot pool concat, they all
> address broken methods...
>
> lisp allows more free thinking, but fails on control purity...
>
> c is pure, just so frig'n painfull...
>
> c++, broke the mold... may the mold rule...!
>
> it all comes down to provable machine state...
>
> if ya can't, ya can't... PERIOD...
>
> forth machines are PROVABLE...
>
> the problem with forth, is the very thing which makes it so
> powerful...
>
> no errors allowed... that just exculded 99.9%+ of the population...
>
> java is a language designed for the public to participate...
>
> openblocks will change all this...
>
> forthblocks will make forth dominate...
>
> join in...
>
> william...
The earlier poster probably confused postscript(TM) dicts with Forth
dicts.
By the way, whats the main difference between
Forth and Assembly ?
Forth and P-codes of Java VM ?
Forth and compiled lisp ?
you can tell your side of the story if you are unfamiliar with others.
Forth is a high-level language. Programming in Forth involves managing
a stack-based virtual machine with a very large and extensible command
set. Many versions of Forth include an assembler for the actual
platform they're running on, but using it is not the same as writing
high-level Forth.
> Forth and P-codes of Java VM ?
For most implementations of Forth, there is nothing resembling pcodes,
although token-based systems have been written in Forth for special
situations.
> Forth and compiled lisp ?
There are multiple ways of compiling Forth definitions, including
sequences of addresses and actual machine code. Some of these may or
may not resemble compiled Lisp. Certainly the programmer's view of
Forth is quite different.
> you can tell your side of the story if you are unfamiliar with others.
You would benefit from reading a book on modern Forth.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
> > > [Q] How far can stack [LIFO] solve do automatic garbage collection and
> > > prevent memory leak ?
<snip>
> > Perhaps, instead of a stack, you want to use a block of flat memory
> > accessed via a linked-list?
>
> Yes, right now we are all discussing in generalities. I had to discuss
> in generalities because if I were to bring in a specific, everyone
> would collapse to that example. I want you to bring in examples where
> one technique is better than the other. The idea is to know the limits
> of stack for processing and where one can deviate from a canonical
> stack and get additional functionality.
a stack is good if your memory allocations follow a stack-like
pattern. That is you deallocate in the reverse order you allocated.
Some problems suit stacks. Some don't.
> Isnt stack itself a programming paradigm ?
yes.
> people talk of "stack
> languages" and "stack architectures" so its a paradigm to be examined
> in its own right by the use of examples. I am looking for illustrative
> examples from the readers.
Dijkstra's shunting yard algorithm
> > > Because a stack has push and pop, it is able to release and allocate
> > > memory. We envisage an exogenous stack which has malloc() associated
> > > with a push and free() associated with a pop.
>
> > Allocation on a stack is usually done by the non-standard call alloca().
> > Freeing is a part of the procedure exit code, called an epilog, for cleaning
> > up the stackframe. But, the C stack, upon which alloca() allocates, is
> > endogenous.http://linux.die.net/man/3/alloca
>
> How is it different from malloc ?
malloc() doesn't use a stack... Because its used for memory allocation
patterns that are no stack-like, God this gets tedious...
> why is it not promoted in textbooks
> like k&r ? The scary part is here :
it's non-standard. I've never been tempted by it myself. Its you that
seems to be in love with stacks.
> Bugs
> The alloca() function is machine and compiler dependent. On many
> systems its implementation is buggy. Its use is discouraged.
> On many systems alloca() cannot be used inside the list of arguments
> of a function call, because the stack space reserved by alloca() would
> appear on the stack in the middle of the space for the function
> arguments.
yes? so?
> > > If Forth is a general processing language based on stack, is it
> > > possible to convert any and all algorithms to stack based ones
>
> > No. You misunderstand Forth. Forth can also store variables, constants,
> > etc. data, within compiled "words". The "words" are stored in memory in an
> > area called a "dictionary". When one stores data in a "word", such "words"
> > are essentially an object-oriented procedure, i.e., word = data + code.
>
> Are these dictionaries closer to an object of C++ or to the lists of
> lisp ?
is a whistle closer to a brontosaurus or a sufusion of yellow?
http://en.wikipedia.org/wiki/Category_mistake
what metric are you using to measure "closeness"?
> > > We look for an exogenous stack so that
> > > element size can vary.
>
> > What does a varying element size have to do with an exogenous stack?
>
> you can malloc a long string or dictionary of varying length and one
> of the pointers in the stack of pointers point to it.
>
> > In another post of yours:
>
> > > cons cell
>
> > Lisp? Are you trying to port or compile Lisp?
>
> cons cell is just a convenient name to refer to an exogenous pair of
> pointers, the one used everywhere to build an exogenous binary linked
> list.
to me "cons cell" carries a fair amount of baggage. Scheme calls 'em
"pairs"
--
In a profession plagued by, "when all you have is a hammer, everything
looks like a nail," we get really excited when someone is able to come
along and prove that everything really *is* a nail if lambda is the
hammer.
B.R.Lewis (comp.lang.scheme)
>> > Allocation on a stack is usually done by the non-standard call alloca().
>> > Freeing is a part of the procedure exit code, called an epilog, for cleaning
>> > up the stackframe. But, the C stack, upon which alloca() allocates, is
>> > endogenous. http://linux.die.net/man/3/alloca
>>
>> How is it different from malloc ?
>
> malloc() doesn't use a stack... Because its used for memory allocation
> patterns that are no stack-like, God this gets tedious...
Also, there are different constraints on stack than on the heap.
Usually, stacks are limited to a small size:
% ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 193196
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited <-----
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8515 <-----
cpu time (seconds, -t) unlimited
max user processes (-u) 193196
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
So since my computer has 24 GB of RAM, and 4 GB of swap, I could
allocate up to about 28 GB of heap, while I'm limited to 8 MB of
stack.
Moreover, when you use threads, the stack is even more limited,
threads being allocated by default an even smaller amount of stack.
--
__Pascal Bourguignon__ http://www.informatimago.com/
that's just an implementation detail. He seems (it's not easy to tell)
to be talking about the stack as an abstraction.
<snip>
> You asked if Forth "borrowed" lists from Lisp. It did not. In Lisp,
> lists are constructed with pair of pointers called a "cons cell".
> That is the most primitive component that makes up a list. Forth has
> no such thing; in Forth, the dictionary (which is traditionally, but
> not necessarily a list) is a data structure that links to the previous
> word with a pointer.
Would you show me a picture, ascii art or whatever for Forth ? I know
what lisp lists look like so I dont need that for comparison. Forth
must have a convention and a standard or preferred practice for its
dicts. However, let me tell you that in postscript the dictionaries
can be nested inside other dictionaries and any such hiearchical
structure is a nested associative list, which is what linked list,
nested dictionaries, nested tables are.
> This is in fact one of the nice things about
> Lisp; because all lists are created out of the same primitive cons
> cell, you can consistently process any list in the system. In Forth,
> any lists (such as the dictionary, if it is a list) are specific to
> their purpose and have to be treated individually.
>
> I don't know what you mean by "nested-dictionaries." There is no such
> thing in Forth. Dictionaries don't nest. You can create wordlists,
> but each wordlist is flat. When most people think of a nested
> dictionary, they would think of a structure that would allow any
> arbitrary level of nesting, not a string of flat wordlists.
You indicated that you have a copy of Forth Application Techniques.
Sections 8.1 and 8.2 cover this topic, with some drawings.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
You can see an example of lists in my novice package (in the list.4th
file):
http://www.forth.org/novice.html
Also in there is symtab, which is a data structure intended to be used
for symbol tables (dictionaries). Almost nobody uses linked lists for
the dictionary anymore (the FIG compilers of the 1970s did, but they
are obsolete).
I must say, I've read through this entire thread and I didn't
understand *anything* that *anybody* was saying (especially the OP). I
really recommend that people spend a lot more time writing code, and a
lot less time with all of this pseudo-intellectual nonsense. This
whole thread (and most of what I see on C.L.F. these days) reminds me
of the "dialectic method" of the early Middle Ages --- a lot of talk
and no substance.
Write some programs! Are we not programmers?
Thanks for pointing this out, Hugh. After reading the code in your
novice package and symtab, I am confused: With code of that caliber
and the obvious stunning intellect behind it, why hasn't everyone
adapted your awesome symtab for symbol tables instead? Any why hasn't
there been an effort to translate symtab into other languages so users
outside of Forth can also experience the sheer speed and hyper-
efficient use of memory and CPU? Let me say I find it refreshing that
a great programmer like yourself doesn't bother with stupid fads like
testing algorithms against large data sets and measuring performance
relative to competitive algorithms. That's all academic nonsense.
The only test and measurement anyone needs are the comments at the top
of symtab where you state your algorithm is better. You clearly
wouldn't have written that if it wasn't true.
> Write some programs! Are we not programmers?
Amen! All this academic talk is useless. Who cares about things like
the big-O notation for program complexity. Can't people just *look*
at code and see how complex it is?! And take things like the years of
wasted effort computer scientists have put into taking data structures
(like hashes and various kinds of trees) and extending them along
various problem domains and requirements. Real programmers don't
waste their time with learning that junk. What good did any of that
ever do anyone?!
Thanks Hugh for a refreshing stance on what it means to be a
programmer.
Never thought I I'd agree wholeheartedly with very verbose John.
Hugh, you are complete idiot!
(and other less complementary ...)
Can someone send me a scan copy of sec 8.1 to 8.2 within the exemption
in the copyright law for my personal study and evaluation of the book
only.
I have only looked at the book cover on forth site and its table of
contents on amazon.
why elase would I ask where it is if I had a copy and would go
directly to index assuming it has a good indexing.
Alternative, a link to an open source of explanation would be
requested.
You didnt understand anything because no one explained anything
coherently. Admittedly, I am asking a question that would be thought
provoking to those who claim to be "experts" but these experts are
actually very stingy and mean business people, most certainly worse
than Bill Gates, only it did not occur to them his ideas and at the
right time.
> I really recommend that people spend a lot more time writing code, and a
> lot less time with all of this pseudo-intellectual nonsense.
You have to have a concept to write code.
> This
> whole thread (and most of what I see on C.L.F. these days) reminds me
> of the "dialectic method" of the early Middle Ages --- a lot of talk
> and no substance.
>
> Write some programs! Are we not programmers?- Hide quoted text -
>
> - Show quoted text -
The problem as I see it is that you're asking complex questions in a
forum that, at best, supports simple answers. The information you're
looking for exists, on the net, free. There are free pdfs of manuals on
Forth available with program downloads from FORTH, Inc., MPE, Gforth,
and other sources, as well as some inexpensive books. But you have to
be willing to make the investment to download and read them, because the
answers to your questions are not simple one-liners that you can get
from newsgroups, and the folks in newsgroups are not prepared to host
computer science seminars -- many of us are working programmers,
engineers, and project managers who have limited time to spend here. If
you're willing to invest your time enough to investigate some of these
sources, and still have questions, we'll be happy to try to help.
> Amen! All this academic talk is useless. Who cares about things like
> the big-O notation for program complexity. Can't people just *look*
> at code and see how complex it is?! And take things like the years of
> wasted effort computer scientists have put into taking data structures
> (like hashes and various kinds of trees) and extending them along
> various problem domains and requirements. Real programmers don't
> waste their time with learning that junk. What good did any of that
> ever do anyone?!
It is my experience that in particular graduated (and in particular Phd)
computer scientists don't waste their time _applying_ that junk. They
have learnt to analyze it, they could tell you how bad their own
algorithms are (if they actually bothered applying their knowledge), but
it does not occur to them to replace them by better ones. Or even
factor their solutions in a way that the algorithms and data structures
are actually isolated.
I think there must be some programmer gene. It is not enough to be able
to recognize O(n^k) or worse (though it helps having a more exact rather
than a fuzzy notion of them _if_ you have that gene). You have to fear
it. It has to hurt. You need to feel compassion with the CPU. It's
not enough to sit there in your easychair, occasionally sucking on your
pipeline and listen to its story about a hard realtime youth and its
strained connection to its motherboard. When it stops, you have to see
its benchmarks and feel their pain in your own backplane.
--
David Kastrup
It indicates that you're asking a question that *you don't
understand*.
I'm continually amazed that people come to Usenet, wikis, websites and
other fora and ask questions that even the most basic of research (and
a bit of care with terminology aka "using the right words") would show
to be confused. A quick scan of the available literature on garbage
collection and stacks, starting with the fundamentals, would surely
show you what you need to know.
> Admittedly, I am asking a question that would be thought
> provoking to those who claim to be "experts" but these experts are
> actually very stingy and mean business people, most certainly worse
> than Bill Gates, only it did not occur to them his ideas and at the
> right time.
>
What surprises may is that anyone bothered to answer, as your question
was neither "thought provoking" nor in need of attention from an
expert. Their generosity in the face of so much stupidity stands out
as remarkable.
I wouldn't call the OP "stupid," which is just mean-spirited. That is
not much of a welcome wagon for somebody who might learn Forth
eventually and join our rather diminished ranks. Lets go with "over-
educated" instead! I thought that his question was vague. It seemed
like the kind of question that students pose to their professor in
class to impress him with their thoughtfulness, so that he'll forget
that they never did get any of their homework-assignment programs to
actually work. I yet maintain that writing programs is what
programming is all about.
I see a lot of pseudo-intellectual blather on comp.lang.forth. The
following is a pretty good example, in which Alex mixes big pseudo-
intellectual words such as "scintilla" with gutter language such as
"turd" in an ungrammatical mish-mash --- and defends the overuse of
the return stack for holding temporary data as being readable(?!):
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4b9f67406c6852dd/0218831f02564410
On Jul 23, 4:43 pm, Alex McDonald <b...@rivadpm.com> wrote:
> Whereas yours contained several tens, and nearly every one of them is
> wrong. Hugh, do you actually have any evidence -- even a scintilla --
> that supports this log winded opinions-as-fact post? Take any of the
> statements you make, and demonstrate that you can justify it.
> Reminding us that you said it before doesn't count.
>
> Start with this turd of an assertion and see if you can polish it;
> "Most of the time, when Forth code gets really ugly, it is because of
> an overuse of >R...R> --- that is a big reason why people use GCC
> rather than Forth."
Perhaps I'm just getting less forgiving the older I get, or the more I
read here. The internet is a fine resource for research, and tools
like google, archivx and so on are easy to access and take but a
little effort to use.
> That is
> not much of a welcome wagon for somebody who might learn Forth
> eventually and join our rather diminished ranks.
I care neither to be included in your "diminished ranks", nor do I
take much regard of popularity as you define it. Standish P doesn't
want to join anything; he (like you) has an agenda for yet another
club with a membership of one.
> Lets go with "over-
> educated" instead! I thought that his question was vague. It seemed
> like the kind of question that students pose to their professor in
> class to impress him with their thoughtfulness, so that he'll forget
> that they never did get any of their homework-assignment programs to
> actually work.
It didn't work. He hasn't done any homework, neither do you, and it
shows.
> I yet maintain that writing programs is what
> programming is all about.
You remind me of those that would build a house without an architect,
or fly without bothering to study the weather.
>
> I see a lot of pseudo-intellectual blather on comp.lang.forth. The
> following is a pretty good example, in which Alex mixes big pseudo-
> intellectual words such as "scintilla"
"Scintilla" gets about 2,080,000 results on google; "blather" gets
about 876,000 results. O Hugh, you pseudo-intellectual you!
> with gutter language such as
> "turd"
About 5,910,000 results. It has a long history, even getting a mention
in the Wyclif's 13th century bible.
> in an ungrammatical mish-mash --- and defends the overuse of
> the return stack for holding temporary data as being readable(?!):
I did? Where? You're making stuff up. Again.
> http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4...
>
> On Jul 23, 4:43 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
> > Whereas yours contained several tens, and nearly every one of them is
> > wrong. Hugh, do you actually have any evidence -- even a scintilla --
> > that supports this log winded opinions-as-fact post? Take any of the
> > statements you make, and demonstrate that you can justify it.
> > Reminding us that you said it before doesn't count.
>
> > Start with this turd of an assertion and see if you can polish it;
> > "Most of the time, when Forth code gets really ugly, it is because of
> > an overuse of >R...R> --- that is a big reason why people use GCC
> > rather than Forth."
>
Something you never did address, probably because the statement you
made is just another symptom of Aguilar's Disease; presenting as fact
an opinion based on personal experience, limited observation and no
research.
> John Passaniti <john.pa...@gmail.com> writes:
>
>> Amen! All this academic talk is useless. Who cares about things like
>> the big-O notation for program complexity. Can't people just *look*
>> at code and see how complex it is?! And take things like the years of
>> wasted effort computer scientists have put into taking data structures
>> (like hashes and various kinds of trees) and extending them along
>> various problem domains and requirements. Real programmers don't
>> waste their time with learning that junk. What good did any of that
>> ever do anyone?!
>
> It is my experience that in particular graduated (and in particular Phd)
> computer scientists don't waste their time _applying_ that junk.
Question: do you have a degree in computer science?
Since in my experience: people who talk about their experience with
graduated people often missed the boat themselves and think that reading
a book or two equals years of study.
Oh, and rest assured, it works both ways: people who did graduate are
now and then thinking it's the holy grail and no body can beat it with
home study.
Both are wrong, by the way.
--
John Bokma j3b
Blog: http://johnbokma.com/ Facebook: http://www.facebook.com/j.j.j.bokma
Freelance Perl & Python Development: http://castleamber.com/
Some of the best minds in comp.lang.forth have a penchant for sarcasm
- one of the reasons I always read their posts. Maybe it gets lost on
the international crowd, but I love it.
-Brad
> David Kastrup <d...@gnu.org> writes:
>
>> John Passaniti <john.pa...@gmail.com> writes:
>>
>>> Amen! All this academic talk is useless. Who cares about things like
>>> the big-O notation for program complexity. Can't people just *look*
>>> at code and see how complex it is?! And take things like the years of
>>> wasted effort computer scientists have put into taking data structures
>>> (like hashes and various kinds of trees) and extending them along
>>> various problem domains and requirements. Real programmers don't
>>> waste their time with learning that junk. What good did any of that
>>> ever do anyone?!
>>
>> It is my experience that in particular graduated (and in particular Phd)
>> computer scientists don't waste their time _applying_ that junk.
>
> Question: do you have a degree in computer science?
>
> Since in my experience: people who talk about their experience with
> graduated people often missed the boat themselves and think that reading
> a book or two equals years of study.
I have a degree in electrical engineering. But that's similarly
irrelevant. I have a rather thorough background with computers (started
with punched cards), get along with about a dozen assembly languages and
quite a few other higher level languages. I've had to write the BIOS
for my first computer and a number of other stuff and did digital
picture enhancement on DOS computers with EMM (programming 80387
assembly language and using a variant of Hartley transforms).
I have rewritten digital map processing code from scratch that has been
designed and optimized by graduated computer scientists (including one
PhD) to a degree where it ran twice as fast as originally, at the cost
of occasional crashes and utter unmaintainability. Twice as fast
meaning somewhat less than a day of calculation time for medium size
data sets (a few 100000 of data points, on something like a 25MHz 68020
or something). So I knew the problem was not likely to be easy. Took
me more than a week. After getting the thing to compile and fixing the
first few crashing conditions, I got stuck in debugging. The thing just
terminated after about 2 minutes of runtime without an apparent reason.
I spent almost two more days trying to find the problem before bothering
to even check the output. The program just finished regularly.
That has not particularly helped my respect towards CS majors and PhDs
in the function of programmers (and to be honest: their education is not
intended to make them good programmers, but to enable them to _lead_
good programmers).
That does not mean that I am incapable of analyzing, say quicksort and
mergesort, and come up with something reasonably close to a closed form
for average, min, and max comparisons (well, unless a close
approximation is good enough, you have to sum about lg n terms which is
near instantaneous, with a real closed form mostly available when n is
special, like a power of 2). And I know how to work with more modern
computer plagues, like the need for cache coherency.
So in short, I have a somewhat related scientific education, but I can
work the required math. And I can work the computers.
> Oh, and rest assured, it works both ways: people who did graduate are
> now and then thinking it's the holy grail and no body can beat it with
> home study.
>
> Both are wrong, by the way.
Depends. In my personal opinion, living close to the iron and being
sharp enough can make a lot of a difference.
Donald Knuth never studied computer science. He more or less founded
it. As a programmer, he is too much artist and too little engineer for
my taste: you can't take his proverbial masterpiece "TeX" apart without
the pieces crumbling. He won't write inefficient programs: he has the
respective gene and the knowledge to apply it. But the stuff he wrote
is not well maintainable and reusable. Of course, he has no need for
reuse if he can rewrite as fast as applying an interface.
--
David Kastrup
> John Bokma <jo...@castleamber.com> writes:
>
>> David Kastrup <d...@gnu.org> writes:
>>
>>> John Passaniti <john.pa...@gmail.com> writes:
>>>
>>>> Amen! All this academic talk is useless. Who cares about things like
>>>> the big-O notation for program complexity. Can't people just *look*
>>>> at code and see how complex it is?! And take things like the years of
>>>> wasted effort computer scientists have put into taking data structures
>>>> (like hashes and various kinds of trees) and extending them along
>>>> various problem domains and requirements. Real programmers don't
>>>> waste their time with learning that junk. What good did any of that
>>>> ever do anyone?!
>>>
>>> It is my experience that in particular graduated (and in particular Phd)
>>> computer scientists don't waste their time _applying_ that junk.
>>
>> Question: do you have a degree in computer science?
>>
>> Since in my experience: people who talk about their experience with
>> graduated people often missed the boat themselves and think that reading
>> a book or two equals years of study.
>
> I have a degree in electrical engineering. But that's similarly
> irrelevant.
Nah, it's not: your attitude towards people with a degree in computer
science agrees with what I wrote.
> That has not particularly helped my respect towards CS majors and PhDs
> in the function of programmers (and to be honest: their education is not
> intended to make them good programmers, but to enable them to _lead_
> good programmers).
I disagree.
> That does not mean that I am incapable of analyzing, say quicksort and
> mergesort,
Oh, that's what I was not implying. I am convinced that quite some
people who do self-study can end up with better understanding of things
than people who do it for a degree. I have done both: I already was
programming in several languages before I was studying CS. And my
experience is that a formal study in CS can't compare to home study
unless you're really good and have the time and drive to read formal
books written on CS. And my experience is that most self-educaters don't
have that time.
On the other hand: some people I knew during my studies had no problem
at all with introducing countless memory leaks in small programs (and
turning off compiler warnings, because it gave so much noise...)
> Donald Knuth never studied computer science.
Yes, yes, and Albert Einstein worked at an office.
Those people are very rare.
But my experience (see for plenty of examples: Slashdot) is that quite
some people who don't have a degree think that all that formal education
is just some paper pushing and doesn't count. While some of those who do
have the paper think they know it all. Those people who are right in
either group are a minority in my experience.
As for electrical engineering: done that (BSc) and one of my class mates
managed to connect a transformer the wrong way around.... twice. Yet he
had the highest mark in our class.
So in short: yes, self-study can make you good at something. But
self-study IMO is not in general a replacement for a degree. Someone who
can become great after self-study would excel at a formal study and
learn more. Study works best if there is competition and if there are
challenges. I still study a lot at home, but I do miss the challenges
and competition.
Hi all,
I quite agree with the fact that self learning is not enough.
Another thing you learn in studying in University is the fact that you can
be wrong, which is quite difficult to accept for self taught people. When
you work in groups, you are bound to admit that you don't have the best
solution all the time. To my experience, self-taught people I worked with
had tremendous difficulties to accept that they were wrong, that their
design was badly done, that their code was badly written or strangely
designed.
Because self teaching was done with a lot of efforts, in particular to
figure out complex problems on their own. Most of the time, the self
learned people are attached to the things they learned by themselves and
have difficulties to envisage that being right of wrong is often not an
issue provided the group comes to the best option. They often live
contradiction as a personal offense while it is just work, you know.
That's another interest of the degree, confrontation with other people
that have the same background. And letting the things learned at the place
they should be and not in the affective area.
1001
--
Utilisant le logiciel de courrier révolutionnaire d'Opera :
http://www.opera.com/mail/
You looked up "blather" and "turd" on google *AND* you are not a
pseudo-intellectual??? That is funny!
I don't consider myself to be a pseudo-intellectual. I don't have any
education however, so a pseudo-intellectual is the only kind of
intellectual that I could be.
Yet another thing you learn in studying in University, is the art of
apple polishing! LOL
If a person has graduated from college, it is not clear what if
anything he has learned of a technical nature --- but it can be
assumed that he has learned to be a head-bobber (someone who
habitually bobs his head up and down in agreement when the boss is
speaking) and has learned to readily admit to being wrong when
pressured (when the boss looks at him without smiling for more than
two seconds). These are the traits that bosses want in an employee ---
that prove the employee to be "trainable."
BTW, has anybody actually looked at my software?
http://www.forth.org/novice.html
All this pseudo-intellectual nonsense (including this post) is getting
boring. Why don't we try discussing software for a while? I wrote that
slide-rule program as a showcase of Forth. I've been thinking of
porting it over to another language, possibly C. Maybe one of you C
experts could write the C program though, as a comparison --- to show
how much better C is than Forth. You can demonstrate that my code was
badly written and strangely designed --- with a concrete example,
rather than just a lot hand-waving and chest-thumping.
I don't have any formal CS education, nor a degree in anything else.
But that doesn't make me an anti-intellectual by instinct (the
instinct would be jealousy, I guess), nor does it stop me from
learning. Or using Google, something I'm sure you do too.
We have a great degree of admiration and fondness for intellectuals in
Europe; the French in particular hold them in very high regard.
Perhaps disdain of learning and further education is peculiar to a
certain section of American society, as the label
"intellectual" (often, "liberal intellectual") appears to be used as a
derogatory term. I have no idea what a pseudo-intellectual might be,
but it's evident you mean it in much the same way.
> On the other hand: some people I knew during my studies had no problem
> at all with introducing countless memory leaks in small programs (and
> turning off compiler warnings, because it gave so much noise...)
[...]
> As for electrical engineering: done that (BSc) and one of my class
> mates managed to connect a transformer the wrong way
> around.... twice. Yet he had the highest mark in our class.
Anybody worth his salt in his profession has a trail of broken things in
his history. The faster it thinned out, the better he learned. The
only reliable way never to break a thing is not to touch it in the first
place. But that will not help you if it decides to break on its own.
--
David Kastrup
*LOL* !!!
I remember the day a very senior field service engineer for a
multi-national minicomputer mfg plugged 16k (or was it 32k) of
core (back when a core was visible to naked eye ;) the wrong way
into a backplane. After the smoke cleared ... snicker snicker.
I also remember writing a failure report because someone
installed a grounding strap 100 degrees out of orientation on a
piece of multi kV switchgear.(don't recall nominal capacity, buck
backup generator was rated for 1.5 MW continuous ;) P.S. failure
was demonstrated as manufacturer's senior sales rep was
demonstrating how easy it was to do maintenance on the system.
There were times I had fun writing up inspection reports.
What open-source code have you posted publicly?
BTW, why did you request that your post not be archived, and be
removed in a few days? That doesn't seem very energetic. Also, now
that I've responded to it, it will be archived forever. It is so rare
that anybody agrees with me, I wanted to make a permanent record. :-)
> John Bokma <jo...@castleamber.com> writes:
>
>> On the other hand: some people I knew during my studies had no problem
>> at all with introducing countless memory leaks in small programs (and
>> turning off compiler warnings, because it gave so much noise...)
>
> [...]
>
>> As for electrical engineering: done that (BSc) and one of my class
>> mates managed to connect a transformer the wrong way
>> around.... twice. Yet he had the highest mark in our class.
>
> Anybody worth his salt in his profession has a trail of broken things in
> his history.
Sure. The long version is: he blew up his work when he connected the
transformer wrong. He borrowed someone else's board and blew that one up
as well.
> The faster it thinned out, the better he learned.
He he he, his internships went along similar lines. Maybe he loved to
blow up things.
> The only reliable way never to break a thing is not to touch it in the
> first place. But that will not help you if it decides to break on its
> own.
I don't think transfomers connect themselfs in the wrong way ;-). I
agree with that accidents do happen, but some people just manage to make
accidents happen way above average. And in that case they might start to
think if it's a good idea them touching things.
> And my
> experience is that a formal study in CS can't compare to home study
> unless you're really good and have the time and drive to read formal
> books written on CS. And my experience is that most self-educaters don't
> have that time.
I've read a lot of graduate-level CS books. I think most self-educated
programmers have read more of these books than have 4-year degree
students who were not required to in order to get their Bachelors
degree and who were too busy during college to read anything that
wasn't required.
> On the other hand: some people I knew during my studies had no problem
> at all with introducing countless memory leaks in small programs (and
> turning off compiler warnings, because it gave so much noise...)
I do this all the time. My slide-rule program, for example, has beau-
coup memory leaks. When I have time to mess with the program I clean
up these memory leaks, but it is not a big deal. The program just
runs, generates the gcode and PostScript, and then it is done. I don't
really worry about memory leaks except with programs that are run
continuously and have a user-interface, because they can eventually
run out of memory.
The real problem here is that C, Forth and C++ lack automatic garbage
collection. If I have a program in which I have to worry about memory
leaks (as described above), I would be better off to ignore C, Forth
and C++ and just use a language that supports garbage collection. Why
should I waste my time carefully freeing up heap space? I will very
likely not find everything but yet have a few memory leaks anyway.
IOW Hugh has surpassed GIGO to achieve AGG -
*A*utomatic*G*arbage*G*eneration ;)
When I was employed as a Forth programmer, I worked for two brothers.
The younger one told me a funny story about when he was 13 or 14 years
old. He bought a radio at a garage sale. The radio worked perfectly,
except that it had no case. He was mighty proud of his radio and was
admiring it, but he noticed that the tubes were dusty. That wouldn't
do! Such a wonderful radio ought to look as good as it sounds! So he
removed the tubes and cleaned them all off with a soft cloth. At this
time it occurred to him that maybe he should have kept track of which
sockets the tubes had come out of. He put the tubes back in so that
they looked correct, but he couldn't be sure.
Fortunately, his older brother who was in high school knew
*everything* about electronics, or at least, that is what he claimed.
So the boy gets his big brother and asks him. The brother says: "There
is one way to know for sure if the tubes are in correctly or not ---
plug the radio in." He plugs in the radio; it makes a crackling noise
and begins to smoke. The boy desperately yanks the cord, but it is too
late; his wonderful radio is toast. The older brother says: "Now you
know!"
> On Aug 22, 11:12 am, John Bokma <j...@castleamber.com> wrote:
>
>> And my
>> experience is that a formal study in CS can't compare to home study
>> unless you're really good and have the time and drive to read formal
>> books written on CS. And my experience is that most self-educaters don't
>> have that time.
>
> I've read a lot of graduate-level CS books. I think most self-educated
> programmers have read more of these books than have 4-year degree
> students who were not required to in order to get their Bachelors
> degree and who were too busy during college to read anything that
> wasn't required.
I doubt it. But this all comes back to what I earlier wrote: those with
a CS degree think they are better than people without, and people
without think they can achieve the same or better by just buying a few
books and reading them. On top of that, most of the people I knew in my
final year were very fanatic regarding CS: it was a hobby to
them. During coffeebreaks we talked about approximation algorithms for
TSPs for example. Not always, but it happened. I read plenty of books
during my studies that were not on the list, as did other students I
knew.
If I recall correctly, you don't have a CS degree. I do, and I can tell
you that your /guess/ (since that is all it is) is wrong. For most exams
I've done one had not only to have read the entire book (often in a very
short time), but also the hand-outs. And for quite some courses
additional material was given during the course itself, so not attending
all classes could result in a lower score. Reading additional books and
papers helped. Sometimes reading a book by a different author could be a
real eye opener (and the students I had contact with did exactly this).
On top of that, often in class excercises were done, and with some
courses I had to hand in home work (yikes).
Also, most books are easy to read compared to CS papers. In my final two
years I did several courses which solely consisted of reading a CS paper
and giving a presentation on the subject in front of your classmates
(and sometimes other interested people). Reading and understanding such
a paper is one (and quite an effort). Teaching it in front of a (small)
class within a few days is not easy, to say the least. We also had to
attend several talks by guest speakers. I went to more than the required
number, including a guest talk by Linus. When there was a break-through
in proving Fermat's last theorem there was a talk, which I attended,
like several other class mates.
I am sure there are students who are there just to get a degree and to
make money. But my class mates didn't fall into that category, or I have
missed something.
So yes, I am convinced that there are plenty of self-educated people who
can code circles around me or plenty of other people with a CS
degree. But IMO those people are very hard to find. Most people
overestimate their skills, with or without a degree; I am sure I do. And
it wouldn't surprise me if self-educated people do this more so.
>> On the other hand: some people I knew during my studies had no problem
>> at all with introducing countless memory leaks in small programs (and
>> turning off compiler warnings, because it gave so much noise...)
>
> I do this all the time. My slide-rule program, for example, has beau-
> coup memory leaks. When I have time to mess with the program I clean
> up these memory leaks, but it is not a big deal. The program just
> runs, generates the gcode and PostScript, and then it is done. I don't
> really worry about memory leaks except with programs that are run
> continuously and have a user-interface, because they can eventually
> run out of memory.
Oh boy, I think you just made my point for me...
> The real problem here is that C, Forth and C++ lack automatic garbage
> collection. If I have a program in which I have to worry about memory
> leaks (as described above), I would be better off to ignore C, Forth
> and C++ and just use a language that supports garbage collection.
Several languages that support garbage collection still are able to leak
memory when circular datastructures are used (for example). Also,
allocating memory and never giving it back (by keeping a reference to
it) can also be memory leaking. And the wrong form of optimization can
result in a program using more memory than necessary. On top of that,
you have to understand when the gc releases memory, and things like
memory fragmentation. In short: you still have to use your head (on some
occasions even more).
> Why should I waste my time carefully freeing up heap space? I will
> very likely not find everything but yet have a few memory leaks
> anyway.
Why should you waste time with carefully checking for other issues? In
my experience, once you become sloppy with one aspect it's very easy to
become sloppy with others as well.
The C programmers reading this are likely wondering why I'm being
attacked. The reason is that Elizabeth Rather has made it clear to
everybody that this is what she wants:
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/c37b473ec4da66f1
Every Forth programmer who aspires to get a job at Forth Inc. is
obliged to attack me. Attacking my software that I posted on the FIG
site is preferred, but personal attacks work too. It is a loyalty
test.
*SNICKER SNICKER LOL*
I am not now, nor have been a professional programmer.
I still recognize you.
P.S. - ever read "The Emperor's New Clothes"
Reading CS books doesn't make you a computer scientist any more than
listening to violin records makes you a violinist. Write out answers to
all the exercises in those books, and get your answers to the more
difficult ones checked by a professor, and you'll be getting somewhere.
That's the point someone else was making about self-study: without
someone checking your answers at first, it's easy to not learn to
recogize your own mistakes.
Anyway, as someone else once said, studying a subject like CS isn't done
by reading. It's done by writing out answers to problem after problem.
Unless you've been doing that, you haven't been studying.
Yup. I would like to add the following three:
1) being able to teach to peers what you've read.
As explained in a post I made: during several courses I took you got
a paper from your teacher and had to teach in front of the class the
next week. Those papers are quite hard to grasp on the first reading
even if you know quite a bit of the topic. Understanding it enough
to teach in front of a class and being able to handle the question
round, in which the teacher participates, is quite a killer.
2) being able to program on paper / understand programs on paper.
On several exams I had to write small programs on paper. The
solutions had to compile (i.e. missing a ; for languages that
required so was counted against you, or using optional ;). One exam
was about OOP and several OO languages were taught, and hence on
paper one had to provide solutions in C++, Objective-C, Object
Pascal, Smalltalk, Eiffel, etc. No compiler(s) handy.
And of course questions like: what's wrong with this piece of code
and how should it be written.
3) being able to write papers and a thesis (or two)
No explanation needed, quite some people have no problem reading the
required books, passing the exams, but need quite some time to do
this (and some give up on it).
What about using what I learned to write programs that work? Does that
count for anything?
If I don't have a professor to pat me on the back, will my programs
stop working? That sounds more like magic than technology.
> On Aug 24, 5:16 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> Anyway, as someone else once said, studying a subject like CS isn't done
>> by reading. It's done by writing out answers to problem after problem.
>> Unless you've been doing that, you haven't been studying.
>
> What about using what I learned to write programs that work? Does that
> count for anything?
Of course it does; but who's going to verify your program?
> If I don't have a professor to pat me on the back, will my programs
> stop working? That sounds more like magic than technology.
I am sure you know what Paul means. As for patting on the back: you must
make a hell of an effort to get that.
> On Aug 24, 5:16 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> Anyway, as someone else once said, studying a subject like CS isn't done
>> by reading. It's done by writing out answers to problem after problem.
>> Unless you've been doing that, you haven't been studying.
>
> What about using what I learned to write programs that work? Does that
> count for anything?
No. Having put together a cupboard that holds some books without
falling apart does not make you a carpenter, much less an architect.
--
David Kastrup
Complete bollox. A pox on your persecution fantasies.
This isn't about Elizabeth Rather or Forth Inc. It's about your
massive ego and blind ignorance. Your example of writing code with
memory leaks *and not caring because it's a waste of your time* makes
me think that you've never been a programmer of any sort. Ever.
In a commercial environment, your slide rule code would be rejected
during unit testing, and you'd be fired and your code sent to the bit
bucket.
This isn't about CS BS; this is about making sure that banks accounts
square, that planes fly, that nuclear reactors stay sub-critical; that
applications can run 24 by 7, 365 days a year without requiring any
human attention.
So who designs and writes compilers for fail-safe systems? Who designs
and writes operating systems that will run for years, non-stop? Where
do they get the assurance that what they're writing is correct -- and
provably so? From people that do research, hard math, have degrees,
and design algorithms and develop all those other abstract ideas you
seem so keen to reject as high-falutin' nonsense.
I'd rather poke myself in the eye than run any of the crap you've
written.
Well, I find his approach towards memory leaks as described in
<779b992b-7199-4126...@j18g2000yqd.googlegroups.com>
quite sensible, use something like that myself, and recommend it to
others.
Followups set to c.l.f (adjust as appropriate).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2010: http://www.euroforth.org/ef10/
Hello to those outside of comp.lang.forth, where Hugh usually leaves
his slime trail. I seriously doubt many people will bother to read
the message thread Hugh references, but if you do, you'll get to
delight in the same nonsense Hugh has brought to comp.lang.forth.
Here's the compressed version:
1. Hugh references code ("symtab") that he wrote (in Factor) to
manage symbol tables.
2. I (and others) did some basic analysis and found it to be a poor
algorithm-- both in terms of memory use and performance-- especially
compared to the usual solutions (hash tables, splay trees, etc.).
3. I stated that symtab sucked for the intended application.
4. Hugh didn't like that I called his baby ugly and decided to expose
his bigotry.
5. Elizabeth Rather said she didn't appreciate Hugh's bigotry in the
newsgroup.
Yep, that's it. What Hugh is banking on is that you won't read the
message thread, and that you'll blindly accept that Elizabeth is some
terrible ogre with a vendetta against Hugh. The humor here is that
Hugh himself provides a URL that disproves that! So yes, if you care,
do read the message thread. It won't take long for you to get a clear
impression of Hugh's character.
It obviously counts, but it's not the only thing that matters. Where
I'm employed, I am currently managing a set of code that "works" but
the quality of that code is poor. The previous programmer suffered
from a bad case of cut-and-paste programming mixed with a
unsophisticated use of the language. The result is that this code
that "works" is a maintenance nightmare, has poor performance, wastes
memory, and is very brittle. The high level of coupling between code
means that when you change virtually anything, it invariably breaks
something else.
And then you have the issue of the programmer thinking the code
"works" but it doesn't actually meet the needs of the customer. The
same code I'm talking about has a feature where you can pass message
over the network and have the value you pass configure a parameter.
It "works" fine, but it's not what the customer wants. The customer
wants to be able to bump the value up and down, not set it to an
absolute value. So does the code "work"? Depends on the definition
of "work."
In my experience, there are a class of software developers who care
only that their code "works" (or more likely, *appears* to work) and
think that is the gold standard. It's an attitude that easy for
hobbyists to take, but not one that serious professionals can afford
to have. A hobbyist can freely spend hours hacking away and having a
grand time writing code. Professionals are paid for their efforts,
and that means that *someone* is spending both time and money on the
effort. A professional who cares only about slamming out code that
"works" is invariably merely moving the cost of maintaining and
extending the code to someone else. It becomes a hidden cost, but why
do they care... it isn't here and now, and probably won't be their
problem.
> If I don't have a professor to pat me on the back, will my
> programs stop working?
What a low bar you set for yourself. Does efficiency, clarity,
maintainability, extensibility, and elegance not matter to you?
I agree. Sadly, with managers, especially non-technical managers, it's
hard to make this case when the weasel guy says "See! It's working.".
> On Aug 24, 8:00 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>> The C programmers reading this are likely wondering why I'm being
>> attacked. The reason is that Elizabeth Rather has made it clear to
>> everybody that this is what she wants: [http://tinyurl.com/2bjwp7q]
>
> Hello to those outside of comp.lang.forth, where Hugh usually leaves
> his slime trail. I seriously doubt many people will bother to read
> the message thread Hugh references, but if you do, you'll get to
> delight in the same nonsense Hugh has brought to comp.lang.forth.
> Here's the compressed version:
I did :-). I have somewhat followed Forth from a far, far distance since
the 80's (including hardware), and did read several messages in the
thread, also since it was not clear what Hugh was referring to.
Actually, it's not that hard. The key to communicating the true cost
of software development to non-technical managers (and even some
technical ones!) is to express the cost in terms of a metaphor they
can understand. Non-technical managers may not understand the
technology or details of software development, but they can probably
understand money. So finding a metaphor along those lines can help
them to understand.
http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
I've found that explaining the need to improve design and code quality
in terms of a debt metaphor usually helps non-technical managers have
a very real, very concrete understanding of the problem. For example,
telling a non-technical manager that a piece of code is poorly written
and needs to be refactored may not resonate with them. To them, the
code "works" and isn't that the only thing that matters? But put in
terms of a debt metaphor, it becomes easier for them to see the
problem.
But then it becomes a game of "How bad is this code exactly?" and "How
much technical debt have we accrued?". At least in my company's
culture, it is quite hard.
"Windows applications are immune from memory leaks since programmers
can count on regular crashes to automatically release previously
allocated RAM."