forth vs lisp

[gavino]

opinions?

[ok]

On 8 Nov, 12:17, gavino <gavcom...@gmail.com> wrote:
> opinions?

they are simply best friends, jus' like you'n me.

P.S. the only real difference is that Forth was inspired by the number
4, and Lisp by the number 7 (the number tells it all).

[fortunatus]

My opinion? Lisp is prefix FORTH. That hit me right off the bat when
I started learning Lisp. Similar (for a beginner) experience of
working with symbol table + interpreter.

Prefix requires full parenthesisation, whereas postfix requires no
parenthesisation, and FORTH opted not to put in parenthesisation.
Full paranthesisation leads to comprehensible complex operand
arrangements. Despite so many '))))' happening, folks can parse out
what the operators and operands are. That gets hard in postfix
without parenthesis. So operators stay fairly simple. Lisp could
grow larger and more complex due to the paranthesis. Also Lisp had
academic attention and bias in its favor for developing complexity.
Although nobody could claim FORTH has not been successful! Its goals
were less lofty from the start, I think.

Notice that Chuck Moore, developer of FORTH, took a class on Lisp from
John McCarthy before developing FORTH.

http://www.colorforth.com/HOPL.html

[Nomen Nescio]

gavino <gavc...@gmail.com> wrote:

> opinions?

My opinion is your a dumb motherfucker

[Nomen Nescio]

gavino <gavc...@gmail.com> wrote:

> opinions?

hhahahahahahahahahahahhahaha
aaahhahahahahahahahahahahaha

[Don Geddis]

fortunatus <daniel....@excite.com> wrote on Tue, 8 Nov 2011 :
> My opinion? Lisp is prefix FORTH.

That's certainly one difference, but hardly the most important one.

> Prefix requires full parenthesisation, whereas postfix requires no
> parenthesisation, and FORTH opted not to put in parenthesisation.

If you think the two languages are basically identical, except that one
put the operators before the operands and the other put them afterwards
... you'll come away with a very broken impression of both Forth and
Lisp.

-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ d...@geddis.org
Correlation may not cause causation, but they often occur together.

[Kaz Kylheku]

On 2011-11-08, fortunatus <daniel....@excite.com> wrote:
> My opinion? Lisp is prefix FORTH.

The syntactic structure of a Lisp expression can be grasped even if you don't
know what it means.

If a Lisp expression adds two numbers X and Y together,
it usually looks like (+ X Y). This is a unit which stays together
even if you rearrange the rest of the expression.

None of the above holds in Forth. A Forth "expression" is just a sequence of
words. To know how they go together, you have to know their implementation.

An expression which adds together X and Y could have this in it:

X Y +

That's if you're lucky. In between these words, there could be arbitrary
quantities of other words, which will work if these sequences leave
the stack where it is, so that by the time we get to the +, it has
the value of X and Y on top of the stack:

X a b c d Y e f g h +

This is a kind of better assembly language for idiots savants.

The success stories on the Forth website are nearly all about trivial one-man
embedded projects, where Forth is an alternative to assembly language (and in a
good number of them, in parallel with assembly language).

To their credit some, some of the projects are mission-critical deployments.
But assembly language is also used in similar mission-critical deployments.

The Blub programmer working in Forth looks down at assembly language and sees
how Forth is so much easier to manipulate.

> Prefix requires full parenthesisation, whereas postfix requires no

Prefix does not require parenthesization when you fix the arity of every
operator:

* + x y + z w (x + y) * (z + w)

This is called polish notation, and the postfix mirror image of
that is reverse polish notation (RPN).

RPN is more prevalent because it can be processed from left to
right using a stack.

> Full paranthesisation leads to comprehensible complex operand
> arrangements. Despite so many '))))' happening, folks can parse out
> what the operators and operands are. That gets hard in postfix
> without parenthesis. So operators stay fairly simple.

Not only that, but more importantly, /programs/ stay fairly simple.

E.g. you don't see a workstation with mass storage, mouse+window GUI and
networking, programmed from hardware on up in Forth.

[fortunatus]

On Nov 8, 7:02 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> Prefix does not require parenthesization when you fix the arity of every
> operator:
>   * + x y + z w    (x + y) * (z + w)

Nice analysis on all points... of course, what the heck was I
thinking?? Even, I think, you can't do postfix without parens unless
you fix the arity of the operators, can you?

(LAMBDA (A B &REST C) ... )

Or more "complex" arity?

(LAMBDA (A (B C &OPTIONAL D) E) ... )

[fortunatus]

On Nov 8, 5:23 pm, Don Geddis <d...@geddis.org> wrote:
> If you think the two languages are basically identical, except that one
> put the operators before the operands and the other put them afterwards
> ... you'll come away with a very broken impression of both Forth and
> Lisp.

Oh, crikey! I believe I qualified the limits on my opinion pretty
well: "Similar (for a beginner) experience of working with symbol
table + interpreter."

[Tim Bradshaw]

Kaz Kylheku <k...@kylheku.com> wrote:


> Not only that, but more importantly, /programs/ stay fairly simple.
>
> E.g. you don't see a workstation with mass storage, mouse+window GUI and
> networking, programmed from hardware on up in Forth.

the HP48 & related calculators were quite substantially programmed in a
sort- of Forth. it's not really Forth though, and it certainly is hard to
write substantial programs.

I do think Forth is spiritually similar to Lisp in some ways though.

[Fritz Wuehler]

> the HP48 & related calculators were quite substantially programmed in a
> sort- of Forth. it's not really Forth though, and it certainly is hard to
> write substantial programs.

There are Forth machines, see greenarrays.com and ask on comp.lang.forth if
you're really interested. The previous poster's comments were incorrect and
uninformed.

> I do think Forth is spiritually similar to Lisp in some ways though.

How? They are dissimilar in fundamental ways. FORTH is based on a stack
machine and it's not meaningful when separated from the underlying
architecture. LISP is a complete abstraction from its implementation. FORTH
is fundamentally interactive, LISP is not, not fundamentally. FORTH is not
appropriate for everything, nor is LISP. When you use tools appropriately
you get the best results. The only general purpose languages are assemblers
and low-level languages like C, PL/I, PL/M. Any higher than that and a
domain specific language helps. Yes I can pound nails with a screwdriver but
no I don't have to.

[jvt]

Better to compare Factor and Lisp. Forth is simply too low level for
appropriate comparison. It is no type system whatsoever, for
instance, either run time or compile time. Obviously such could be
implemented, but that is not standard practice. It also lacks
facilities for higher order functional programming, which Joy/Factor
remedy.

Also, I wrote this stack language integrated into emacs lisp:

https://github.com/VincentToups/emacs-utils/blob/master/with-stack.md

But, again, its much more like Factor than Forth.

[Larry Coleman]

It also bears mention that Factor has stack-effect checking. When you
define a word, you also have to define the stack effect. If the
defined effect doesn't match the results of the definition, the word
won't compile.

[jvt]

Stack effect inference and checking is a really interesting aspect of
Factor which I wish Slava would write a paper about (maybe he already
has?) Checking stack effects is essentially like a very simple type
system, and so can serve as a kind of toy model for type checking and
inference.

[paul-d...@sbcglobal.net]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>
writes:

>> the HP48 & related calculators were quite substantially programmed in a
>> sort- of Forth. it's not really Forth though, and it certainly is hard to
>> write substantial programs.
>
> There are Forth machines, see greenarrays.com and ask on comp.lang.forth if
> you're really interested. The previous poster's comments were incorrect and
> uninformed.
>
>> I do think Forth is spiritually similar to Lisp in some ways though.
>

> FORTH is fundamentally interactive, LISP is not, not
> fundamentally.

What do you mean?

[Raymond Wiker]

The programming language used in the HP-48 family of calculators is
called RPL - Reverse Polish Lisp.

[Rob Warnock]

fortunatus <daniel....@excite.com> wrote:
+---------------

| Kaz Kylheku <k...@kylheku.com> wrote:
| > Prefix does not require parenthesization when you fix the arity of every
| > operator:
| >   * + x y + z w    (x + y) * (z + w)
|
| Nice analysis on all points... of course, what the heck was I
| thinking?? Even, I think, you can't do postfix without parens unless
| you fix the arity of the operators, can you?
|
| (LAMBDA (A B &REST C) ... )

+---------------

IIRC, PostScript [and maybe Smalltalk as well?] has a way of MARKing
the argument stack, and then APPLYing all of the args between the mark
and the top of the stack to a function. I forget the exact syntax,
but that's the effect. [I think the Adobe extension "pdfmark" does
approximately that: "mark <arg1> <arg2> ... <argn> <function> pdfmark"
is roughly (APPLY FUNCTION (LIST ARG1 ARG2 ... ARGn).]

Yes, it's not terribly uniform/orthogonal. Many of the mark-using
operators are named DOFUNCTIONTOMARK, e.g., "dicttomark", "cleartomark",
but not all (or even most?). Some take alists as args, e.g.,
"mark <key1> <value1> <key2> <value2> ... .dicttomark" ==> <dict>".

But as I said, I don't remember the exact details. (Anyone?)


-Rob

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403

[D Herring]

On 11/09/2011 11:02 PM, Rob Warnock wrote:

> IIRC, PostScript [and maybe Smalltalk as well?] has a way of MARKing
> the argument stack, and then APPLYing all of the args between the mark
> and the top of the stack to a function. I forget the exact syntax,
> but that's the effect. [I think the Adobe extension "pdfmark" does
> approximately that: "mark<arg1> <arg2> ...<argn> <function> pdfmark"
> is roughly (APPLY FUNCTION (LIST ARG1 ARG2 ... ARGn).]
>
> Yes, it's not terribly uniform/orthogonal. Many of the mark-using
> operators are named DOFUNCTIONTOMARK, e.g., "dicttomark", "cleartomark",
> but not all (or even most?). Some take alists as args, e.g.,
> "mark<key1> <value1> <key2> <value2> ... .dicttomark" ==> <dict>".
>
> But as I said, I don't remember the exact details. (Anyone?)

I never wrote much PS, but... On my old HP48G, there were commands of
the form <stack> <N> <op>, where <N> specified how many parameters
<op> would consume from <stack>. For example, ROLL would use this to
determine how many levels of the stack to rotate.

- Daniel

[Tim Bradshaw]

On 2011-11-09 10:18:39 +0000, Fritz Wuehler said:
>
>> I do think Forth is spiritually similar to Lisp in some ways though.
>
> How?

Obviously they aren't, it's just people like me who've programmed in
both who get confused and think they are. What would I know?

[Tim Bradshaw]

On 2011-11-09 20:40:26 +0000, Raymond Wiker said:

> The programming language used in the HP-48 family of calculators is
> called RPL - Reverse Polish Lisp.

People often did call it that, I agree, though I think it's not clear
if HP did. The expericne of programming in it, I found, was much more
Forth-like than Lisp-like though. What I really meant though was that
the HP48 was a kind of mini RPL-machine in the interesting Lisp-machine
sense of being a fairly seamless environment built around a language,
not the boring "executes the language directly in HW" sense.

[Pascal J. Bourguignon]

Tim Bradshaw <t...@tfeb.org> writes:

> On 2011-11-09 20:40:26 +0000, Raymond Wiker said:
>
>> The programming language used in the HP-48 family of calculators is
>> called RPL - Reverse Polish Lisp.
>
> People often did call it that, I agree, though I think it's not clear
> if HP did. The expericne of programming in it, I found, was much more
> Forth-like than Lisp-like though.

Of course. The essential difference between lisp code and the other
programming languages, is that in lisp, you don't need to know the arity
of the operators (or the "priority" of the operators, there's no such
notion in lisp), since applications are always parenthesized.

This is the feature (with attendant homoiconicity) that makes macro
programming a breeze in lisp, but more importantly, that frees
programmer neurons for better programming. It allows lisp programmers
to read lisp code even without knowing thee operators used. On the
other hand, in forth or Postscript and even with languages with complex
syntaxes, you cannot read the code without knowing all the operators,
their arity, and their priority.


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Kaz Kylheku]

On 2011-11-10, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> to read lisp code even without knowing thee operators used. On the
> other hand, in forth or Postscript and even with languages with complex
> syntaxes, you cannot read the code without knowing all the operators,
> their arity, and their priority.

Note that even raw machine language in a disassembly dump does not
have this readability issue.

[Antsan]

"On the other hand, in forth or Postscript and even with languages with complex syntaxes, you cannot read the code without knowing all the operators, their arity, and their priority."

That's not correct, as in Forth you don't need to know priority, as is the case for all stack based languages.

[Tim Bradshaw]

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> Tim Bradshaw <t...@tfeb.org> writes:

> Of course. The essential difference between lisp code and the other
> programming languages, is that in lisp, you don't need to know the arity
> of the operators (or the "priority" of the operators, there's no such
> notion in lisp), since applications are always parenthesized.
>

Yes, that's right, I think: in Forth and RPL you don't have to worry about
priority, but you do have to know the arity, and that makes it hard, I
find.

[Fritz Wuehler]

> > FORTH is fundamentally interactive, LISP is not, not
> > fundamentally.

> What do you mean?

The first LISPs ran on IBM machines, in batch AFAIK and this was true for
many years. That is as far from interactive as it gets. You code something,
you punch it on cards, you submit a job to the operator, he runs it when he
gets a chance, it prints out, the operator hands you the printout when he
gets a chance. You fix what you mispunched or miscoded and try again.

There is nothing fundamentally interative about LISP.

FORTH is fundamentally interactive. That's how Moore designed it. You type a
command (word) or a definition for a word. The machine accepts it or flags
and error. You build your program step by step, interactively.

[Kaz Kylheku]

On 2011-11-10, Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:
>> > FORTH is fundamentally interactive, LISP is not, not
>> > fundamentally.
>
>> What do you mean?
>
> The first LISPs ran on IBM machines, in batch AFAIK and this was true for
> many years. That is as far from interactive as it gets. You code something,
> you punch it on cards, you submit a job to the operator, he runs it when he
> gets a chance, it prints out, the operator hands you the printout when he
> gets a chance. You fix what you mispunched or miscoded and try again.

This process was a necessity due to the I/O limitatons of the hardware,
as well as the need to share one very expensive room-sized box among
an entire department.

Had Forth come along at that same time, it's hard to see how it could
have avoided job submission on punched cards.

You're writing about a historic dialect which quite different from
what Lisp became even ten years after that.

> There is nothing fundamentally interative about LISP.

Later Lisps like InterLisp and MacLisp were quite fundamentally
interactive.

But Lisp does support the "edit compile and build image" deployment model.

As does Forth.

[Anton Kovalenko]

Tim Bradshaw <t...@tfeb.org> writes:

>> Of course. The essential difference between lisp code and the other
>> programming languages, is that in lisp, you don't need to know the arity
>> of the operators (or the "priority" of the operators, there's no such
>> notion in lisp), since applications are always parenthesized.
>>
> Yes, that's right, I think: in Forth and RPL you don't have to worry about
> priority, but you do have to know the arity, and that makes it hard, I
> find.

And in Forth, arity that you have to know is really /two/ stack effects
(compile-time and run-time), and one input stream effect, with each
stack effect consisting of input-arity and output-arity. That is, we
really have 5 distinct arities.

--
Regards, Anton Kovalenko <http://github.com/akovalenko/sbcl-win32-threads/wiki>
+7(916)345-34-02 | Elektrostal' MO, Russia

[Tim Bradshaw]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:

>
> There is nothing fundamentally interative about LISP.

In the same way, there's nothing fundamentally mammalian about humans,
because once, there were no mammals.

[Tim Bradshaw]

Kaz Kylheku <k...@kylheku.com> wrote:

> This process was a necessity due to the I/O limitatons of the hardware,
> as well as the need to share one very expensive room-sized box among
> an entire department.
>

Worth mentioning that the first interactive Lisp was 1963.

[Pascal J. Bourguignon]

To read assembly, you still need to know the operand of each operation.
Not all operands are always explicitely written in the assembler sources.

[Tim Bradshaw]

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> To read assembly, you still need to know the operand of each operation.
> Not all operands are always explicitely written in the assembler sources.
>

Also: depends on the instruction set and architecture of the machine. For
instance:

push 1
push @0022a2b2
push 2
sum

[Pascal J. Bourguignon]

So we have one explicit value, and an implicit register reference and an
implicit memory reference, and some implicit updating. If you don't
know that, you're lost. Thanks for making my point.

> push @0022a2b2
> push 2
> sum

Does that suggest even more implicit indirect referencing?

[Fritz Wuehler]

You missed the point completely but then again if you think people came from
monkeys that would explain your approach.

[Fritz Wuehler]

Kaz Kylheku <k...@kylheku.com> wrote:

> This process was a necessity due to the I/O limitatons of the hardware,
> as well as the need to share one very expensive room-sized box among
> an entire department.

It may have been related to expense but it wasn't related to any I/O
limitations. The operator consoles worked just fine. Data is displayed and
could be read line by line.

> Had Forth come along at that same time, it's hard to see how it could
> have avoided job submission on punched cards.

I don't remember when TSO came out but that would have been enough to
implement FORTH as it was implemented on other machines. All you really need
is line-oriented output and input.

> You're writing about a historic dialect which quite different from
> what Lisp became even ten years after that.

Ok, I am not an expert in this so I leave it to you guys but even so, we
must agree that LISP (as in what McCarthy designed) started out as a batch
language. That's why I said "fundamentally". I am not saying there are no
interactive character-oriented LISP implementations, but then we get into
what is LISP? Is LISP based on needing interactivity? Surely not, since for
the first decade or so it remained a batch model. Adding interactive support

doesn't change LISP, but it does mean what I wrote:

> > There is nothing fundamentally interative about LISP.

> But Lisp does support the "edit compile and build image" deployment model.

It always has, since 1959 ;-)

> As does Forth.

I don't know anybody who uses FORTH that way until a project is finished.

[Espen Vestre]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>
writes:

> Ok, I am not an expert in this so I leave it to you guys but even so, we
> must agree that LISP (as in what McCarthy designed) started out as a batch
> language. That's why I said "fundamentally".

So say "historically" when you mean it.
--
(espen)

[Kaz Kylheku]

On 2011-11-11, Pascal J. Bourguignon <p...@informatimago.com> wrote:
> Tim Bradshaw <t...@tfeb.org> writes:
>
>> "Pascal J. Bourguignon" <p...@informatimago.com> wrote:
>>
>>> To read assembly, you still need to know the operand of each operation.
>>> Not all operands are always explicitely written in the assembler sources.
>>>
>>
>> Also: depends on the instruction set and architecture of the machine. For
>> instance:
>>
>> push 1
>
> So we have one explicit value, and an implicit register reference and an
> implicit memory reference, and some implicit updating. If you don't
> know that, you're lost. Thanks for making my point.

I know what "push 1" means: it means put 1 into the stack, and I start
looking for the corresponding "pop" or perhaps "pull".

I place my trust in the instruction set and opcode designers that "push" means
what I think it ought to mean: that they have not stupidly given a new meaning
to old jargon.

But note that "push 1" is getting close to Forth, which also makes my point.

But Forth will take away the "push", leaving you with just "1". Oops!

[paul-d...@sbcglobal.net]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>
writes:

Hmm, that seems more like historical accident than anything
fundamental.

[Kaz Kylheku]

On 2011-11-11, Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:
> Ok, I am not an expert in this so I leave it to you guys but even so, we
> must agree that LISP (as in what McCarthy designed) started out as a batch

I suspect I do speak for everyone in saying that what McCarthy's team
originally designed is of little interest to modern Lispers, at least the ones
that hang out here. I haven't seen a real discussion about that dialect in the
ten years I've been on comp.lang.lisp, except where it was brought up in some
historic context (``what is the etymology of such and such construct'').

I've read some of the old papers and documentation about the original work, but
not in great detail and not recently. Obviously, there are numerous vestiges
of the ancient dialect in modern Common Lisp, like atoms and conses, the
symbols NIL, et cetera. (But the original had little /else/ besides these,
really!) If you want to know why we have the function named CAR, then of course
that will take us back all the way to that time.

To me, the most interesting history is that which is captured in _The Evolution
of Lisp_, which is a paper that describes the rich unfolding of events after
McCarthy's Lisp. There were many important people and a large influx of many
new ideas, many of them being developed separately by people working largely in
isolation and then the "best of breed" of them combined together.
People like David Moon, Gerald Sussman, Alan Bawden or Guy Steele.

Lisp can absorb arbitrary complexities, yet the code can manage to look the
same to someone who doesn't know much about it. A code structure made of
nested lists containing atoms can represent anything, the same way that
text can represent anything. What is (a b (c d) (e))?
Is it a call to function A with arguments B, (C D) and (E)?
You don't know. A could mean "define class", where B is the name,
(C D) are the parent classes (multiple inheritance!) and (E) is the list of
new slots in the derived class. Or it could be a declaration of logically
chained facts. Inference rule B (being entered into a knowledge base) says that
(C D), D satisfying the predicate C, is a consequence of (E).

[Tim Bradshaw]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:

> You missed the point completely but then again if you think people came from
> monkeys that would explain your approach.

So what was the point? if I wrote, today, an ab-initio Forth and a Lisp,
would one somehow be interactive and one not because of some historical
detail? Would that still be the case if the Forth had no interactive
features and the Lisp did? what about if the Forth was implemented in Lisp,
or the other way around?

[Tim Bradshaw]

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> Tim Bradshaw <t...@tfeb.org> writes:

> So we have one explicit value, and an implicit register reference and an
> implicit memory reference, and some implicit updating. If you don't
> know that, you're lost. Thanks for making my point.

Yes, I was trying to agree with you... no registers though.

[Pascal J. Bourguignon]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>
writes:

> Kaz Kylheku <k...@kylheku.com> wrote:
>
>> This process was a necessity due to the I/O limitatons of the hardware,
>> as well as the need to share one very expensive room-sized box among
>> an entire department.
>
> It may have been related to expense but it wasn't related to any I/O
> limitations. The operator consoles worked just fine. Data is displayed and
> could be read line by line.

Ignorant!

Here what a 7090 console looked:
http://upload.wikimedia.org/wikipedia/en/1/15/IBM_7090_console.nasa.jpg

No keyboard, no screen!

[Tim Bradshaw]

"Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>

> writes:

> Ignorant!
>
> Here what a 7090 console looked:
> http://upload.wikimedia.org/wikipedia/en/1/15/IBM_7090_console.nasa.jpg
>
> No keyboard, no screen!
>

The 704 manual here
http://www.cs.virginia.edu/brochure/images/manuals/IBM_704/IBM_704.html is
also interesting in this respect.

[Richard Fateman]

Is LISP fundamentally interactive?
Historically, LISP dates from 1958.
One of the first time sharing systems, CTSS, dates from 1961. By 1964
(guess), the preferred mode of using LISP was at an interactive computer
terminal.

One of the first large LISP programs was James Slagle's symbolic
integration program, SAINT, which was done in 1961 at MIT
(see http://esd.mit.edu/Faculty_Pages/moses/Macsyma.pdf )
Slagle used punched cards.

Two subsequent large LISP programs, Joel Moses' SIN and William A
Martin's Symbolic Mathematical Laboratory were written at MIT; theses
completed in 1967. Especially Martin's work was heavily interactive
using keyboard, graphical display etc.

LISP was "batch" oriented only so long as there was essentially no
alternative. Its use under CTSS and on a DEC pdp-6 was interactive
approximately as soon as interactive programming became possible. BBN
LISP (later, InterLisp) was heavily interactive, circa 1967, on the
SDS-940 timesharing system.

The mode of operation of Lisp is, in my view, fundamentally interactive
in that for program development and testing the computer acts as a kind
of reactive typewriter, responding immediately to each "command".
Contrast that with a batch system in which an
edit-compile-link-test-binary_dump cycle is repeated.

I have no idea how a contemporary FORTH programmer goes about
interacting with a computer.

[Kaz Kylheku]

On 2011-11-11, Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:

>> But Lisp does support the "edit compile and build image" deployment model.
>
> It always has, since 1959 ;-)
>
>> As does Forth.
>
> I don't know anybody who uses FORTH that way until a project is finished.

What, no nightly builds for QA until the project is finished?

No version control?

How do you take a diff between what you had this morning
and the changes you made?

What if a project is ongoing for a decade or two, what then?

[Fritz Wuehler]

Fundamentally means "from the beginning". You wanna split hairs, go fuck
yourself. You guys seem to like arguing. I'm right, you're too new to
realize it, just apologize and go away.

[Kaz Kylheku]

On 2011-11-13, Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:
> Espen Vestre <es...@vestre.net> wrote:
>
>> Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net>
>> writes:
>>
>> > Ok, I am not an expert in this so I leave it to you guys but even so, we
>> > must agree that LISP (as in what McCarthy designed) started out as a batch
>> > language. That's why I said "fundamentally".
>>
>> So say "historically" when you mean it.
>
> Fundamentally means "from the beginning".

No, it literally means "from the foundation". Something fundamental is the base
or core on which other things are based.

When things originate, their beginning often unfolds by the generation of a
foundation from which other features emerge. So the original and the
fundamental may be one and the same, intially. But over time, the relationship
can become increasingly tenuous, possibly leading to a dissociation. A thing
can morph into something else and acquire new foundations.
Sometimes foundations are discovered: for instance unifying, simplifying
principles that re-invigorate some scattered body of knowledge.

Today's Lisp does not have 1958 Lisp as a foundation, but there are some
etymological vestiges, like the cons cell with car and cdr accessors.

The fundamental frequency is also the lowest mode of vibration of a string, and
then there are the harmonics or overtones. If a string is struck, the
fundamental isn't necessary what plays first, or at all.

You know, the insistence on superimposing ancient origins on something new is a
form of prejudice. For instance consider something like this being said between
two people: "You will never amount to anything because your mother was a
crack-addicted whore and your father jailed for murder. So, fundamentally
speaking, you are scum and that is your place in the world."

Speaking of vibrating strings brings us to music, whereupon it occurs
to me that "from the beginning" is "da capo".

[Tim Bradshaw]

Fritz Wuehler <fr...@spamexpire-201111.rodent.frell.theremailer.net> wrote:

> Fundamentally means "from the beginning".

Do you have a reference for that?

[Tim Bradshaw]

Might be worth mentioning that this Fritz Wuehler person seems to have some
history..

[Antti J Ylikoski]

Just think of a modern LISP with its IDE and REPL. Say, GNU EMACS and
SLIME plus SBCL.

LISP may be "historically" batch-oriented if you go back to the 1960's
-- but no one in their right mind would call a modern LISP
"fundamentally batch-oriented".

Cheers, Antti "Andy"

[Blake McBride]

On 2011-11-08 11:17:24 +0000, gavino said:

> opinions?

Lisp and Forth are similar in the regular and simple syntax they employ
- quite unlike other languages. I think Lisp's choice it better for
the reasons stated by the other commentors.

The much, much bigger difference is in semantics. Lisp has much higher
level constructs and is far, far more expressive - not even including
macros. For this reason, comparing Lisp to Forth is like comparing a
biscycle to a jet aircraft.

Blake McBride