abstraction: do haskell and lisp beat forth in abstraction? or no?

[gavino_himself]

curious if forth can be as high level?

[Jason Damisch]

Forth can be any level that you want it to be. Forth transcends levels.

[Ron Aaron]

Forth is the most abstract possible of all possibilities. The Forth
surrounds us and penetrates us, it binds the galaxy together.

[jacko]

He forgot OCaml.

[Rod Pemberton]

"jacko" <jacko...@gmail.com> wrote in message
news:43424b5a-0d2a-4bbb...@googlegroups.com...

Well Jac-kok-ring,

(I hope that was intentional and not accidental. Why? For if it was
accidental, I probably offended you for making fun of your name. I don't
want to insult your name, but I can apologize for that in advance, if it is.
However, if it was intentional, then you're just a sick f... for hiding that
in plain sight. In that case, I owe you nothing. Maybe, we should just
call you ... Simon ... Since "wacko" rhymes with "jacko", maybe Simon
Jackson? Do you like that name? A made up name like that is one we
_can_ make fun of! ROFL ;-)


Anyway, he also forgot C. It you want to see abstraction look at IOCCC code
sometime. With C though, you really don't need to even go that far. All
you need to do is find code by a detail-oriented programmer. They will have
"abstracted" something via numerous layers of complexities, until it happens
to work.

Of course, it *was* Forth that got the "write once" moniker. It's not like
Brainfuck is readable. Of course, there is also INTERCAL for the
ancients...

He also forgot C++ which I think is even worse.

This link is probably best suited to comp.lang.misc. But, there are almost
no posts there lately. I've posted more than a few topical issues in reply
to other things...

http://listverse.com/2011/02/17/top-10-truly-bizarre-programming-languages/


Rod Pemberton

[Mark Wills]

A useless thread altogether.

Forth is perfectly good at abstraction. With the right factoring it's
possible to produce code that reads almost like English. That's not
possible with LISP or C which require parenthesis and a myriad of
other punctuation in order to guide the compiler.

Having said that, C is perfectly good at abstraction, too. I wrote
some pretty readable C code back in the day, even if I do say so
myself. Nothing so complex as a OS or anything like that, but complex
enough (the kernal for an RTU). Perfectly understandable by the
graduates that inherited it.

I do think that though that, given the syntactical differences between
Forth and C, a given 'problem' written in C and Forth would probably
be factored very differently.

Nothing wrong with that.

Even assembly language (if it has a subroutine call/return pair of
instructions) can be factored (thusly abstracted) very nicely indeed.

The real offenders were the early BASIC variants, with their terrible
line numbers! Yack. Thank goodness we've seen the last of those!

[jacko]

On Saturday, 25 August 2012 08:46:13 UTC+1, Rod Pemberton wrote:
> "jacko" <jacko...@gmail.com> wrote in message
>
> news:43424b5a-0d2a-4bbb...@googlegroups.com...
>
> > On Thursday, 23 August 2012 04:25:29 UTC+1, Ron Aaron wrote:
>
> > > Forth is the most abstract possible of all possibilities. The Forth
>
> > >
>
> > > surrounds us and penetrates us, it binds the galaxy together.
>
> > >
>
> > >
>
> > >
>
> > > On 08/22/2012 11:20 PM, gavino_himself wrote:
>
> > >
>
> > > > curious if forth can be as high level?
>
> > >
>
> > > >
>
> >
>
> > He forgot OCaml.
>
>
>
>
>
> Well Jac-kok-ring,

The moniker was jacko-k-ring. It was accidental, but remained as I'd opened too many web accounts before noticing it. The jacko is an obvious contraction, where as the k-ring refers to a data compression idea originally based on rings of p=k[p] indexing into a limit cycle, to provide an entropy not equal to 1 bit per bit, to then perform changes or 'virtual modulation of a simulated carrier using a compact representation of the carrier'. Simple really. I decided not to change it as by the time the internet has been going for thousands of years, people will have to give themselves names like jo_bob_9mil_(noguns), and then hope noguns does not become slang for some dirty great giggleothon....

> (I hope that was intentional and not accidental. Why? For if it was
>
> accidental, I probably offended you for making fun of your name. I don't
>
> want to insult your name, but I can apologize for that in advance, if it is.
>
> However, if it was intentional, then you're just a sick f... for hiding that
>
> in plain sight. In that case, I owe you nothing. Maybe, we should just
>
> call you ... Simon ... Since "wacko" rhymes with "jacko", maybe Simon
>
> Jackson? Do you like that name? A made up name like that is one we
>
> _can_ make fun of! ROFL ;-)

It's my name so don't ware it out! :) It is quite strange how the implication of 'beat' is somehow a request of should 'person x' use said language, as though person x would not know such a thing, but somehow might want to learn such a language. I suggest learning interesting languages, and using analytical skills to then decide on the language to fit the problem.

Cheers Jacko aka Simon aka not number six.

[Rod Pemberton]

"Mark Wills" <markrob...@yahoo.co.uk> wrote in message
news:d81d9a4b-10f6-45fb...@s2g2000vbj.googlegroups.com...

[...]

> Forth is perfectly good at abstraction. With the right factoring it's
> possible to produce code that reads almost like English.

OMG! I can't believe you just said that. I'm feeling queasy now and think
I'm going to be sick ...

The reason I think I program well is because I'm nowhere near as good with
English (or wasn't years ago...) as I am with a programming language.
Programming languages aren't supposed to be just like English. There are
too many ambiguities and complexities with English.

> That's not possible with LISP or C which require parenthesis
> and a myriad of other punctuation in order to guide the compiler.

I can't say that's a benefit for LISP. LISP is known for too many of them.
But, that's a benefit with C. There is a clear distinction in C between
operators and keywords. In general (with a few exceptions), the operators
are symbolic and perform some action: arithmetic, address-of, indirection,
indexing, etc, while keywords are names of things: control-flow, variables,
structures, procedures, etc. Early Forth introduced symbolic naming too: @
! +! : ; + - etc. I think Forth doesn't have enough of it, personally.
It's too "wordy" in the sense that it has many words instead of symbols. I
never liked .LE. or .GT. etc for Fortran, and so don't like XOR and AND etc
for Forth.

> The real offenders were the early BASIC variants, with their terrible
> line numbers! Yack. Thank goodness we've seen the last of those!

(I've discussed much of this previously, but I don't recall if it was on
c.l.f. It might've been c.l.m. or a.o.d. etc.)

I think most of the advantage of line numbering at the time was because it
allowed a simple line-oriented "text" editor to be used. But, I don't
recall line numbers being as bad as you remember. Usually, there is a
command (or utility) to renumber the program from a starting line number and
an increment. But, as long as you left a spacing of 10 or 20 between line
numbers originally, you rarely needed to renumber even after many more
lines.

The bad thing about languages that used line numbers had nothing to do with
line numbers: GOTO. If someone programmed BASIC without knowing
structured programming concepts, they ended up with "spaghetti" code - code
which jumped all over the place. Yuck!

A few years ago, I looked at a BASIC I once used to see what merit it had
"today" (a few years ago). This BASIC was on the C64 which I think was an
MS product (?). About the only thing of merit was the string concepts of
right$, left$, mid$, and '+' for concatenation. That's still useful for a
variety of languages today, except for a language like C which has more
powerful equivalents (and no ability to use $ in a name...). I thought the
old BASIC was sufficiently limited that it'd have to be thoroughly reworked
for effective use in a modern environment. I.e., good for 8-bit, but not so
good for 32-bits. E.g., functions limited to what fits on one line, or
limitations of DIM and DATA, or need to use CHR$ or ASC.

That said, I also programmed BASIC for one industrial machine. It was very
effective in that situation. BASIC supplied the console input and output
(keyboard & screen), ability to load and save files, interactivity of an
interpreter, a line editor, and of course the language itself: variables,
control-flow, arithmetic, etc. The machine's operations weren't controlled
by BASIC. An escape character was used to send (or redirect) machine
commands to the machine. So, a bunch of lines in the program would begin
with the escape character. This piece of equipment was an old machine when
I programmed it a decade ago, but I can see any type of modern CAM or CNC
mill or plotter etc working well with the same concept. Wikipedia says the
same basic concept is called "parametric programming" on it's CNC page. So,
I'm not sure why someone added the words:
"A more recent advancement in CNC ..."


Rod Pemberton

[John Passaniti]

On Saturday, August 25, 2012 7:51:00 AM UTC-4, Mark Wills wrote:
> Forth is perfectly good at abstraction. With the right
> factoring it's possible to produce code that reads
> almost like English. That's not possible with LISP or
> C which require parenthesis and a myriad of other
> punctuation in order to guide the compiler.

And if you think that's bad, I just heard about a language called Forth which is so primitive that it expresses all computation in terms of a stack that you have to explicitly manage! Just think of it-- programmers spending huge amounts of time constantly juggling items on a stack.

What's that? Real Forth programmers don't consider the stack an impediment and actually think it's a benefit? Weird. The next thing you'll be telling me is that Lisp programmers don't find parenthesis to be a problem and actually think it's a benefit. What's that? Homoiconicity? Representing programs as data? Well why would anyone want those things. Clearly the only way to think about programs is as a list of procedural imperative statements.

[Mark Wills]

If they are 'constantly juggling items on a stack' then their code
needs to be re-designed. I now have a couple of fairly substancial
Forth applications under my belt, and have not come across any
difficulties with this. In my experience (as a novice) it *does*
require one to sometimes step away from the keyboard and actually
think for a while, rather than tap out code, but I find I do that in
other languages also.

"What's that? Real Forth programmers don't consider the stack an
impediment and actually think it's a benefit?"

It's neither. It's just what it is. I don't think it's a particular
advantage or disadvantage. It's certainly neat. But is it really that
much different from C?

In C: area=calculateArea(width,height);

Forth: width height calculateArea area !

Is it really *that* different? Both pass parameters into calulateArea
and write the result to area.

My point about punctuation (and I admit, it was a (friendly) poke at C
(i've no particular axe to grind with C, except for its pointer
syntax, which still drives me mad and is an un-readable mess IMHO) was
that, in the above C example:

= ( , ) ; are there for the compiler, not the programmer. That's what
Forth strips away. Some like it, some don't. It certainly makes for a
much simpler compiler!

[John Passaniti]

On Monday, August 27, 2012 7:38:19 AM UTC-4, Mark Wills wrote:
> If they are 'constantly juggling items on a stack'
> then their code needs to be re-designed.

No kidding. The point of my response was that the things you cite as problematic in other languages aren't shared by experienced developers in those languages. It's exactly the same as when developers from other languages look at Forth, see an exposed stack, and conclude that Forth programmers spend significant amounts of time with stack manipulation operators. You and I and most everyone here knows that isn't true, but when (some) people look at the surface of Forth, that's the (naive) conclusion they make.

The same is true for parenthesis in Lisp. Lisp doesn't add parenthesis to "guide the compiler." Lisp programs *are* data and there is a direct relationship between data and the source representation (that's homoiconicity). Lisp programmers see this (and value it) as simplicity and directness. But if you're outside of Lisp and just look superficially at Lisp code, the first thing you see are a bunch of parenthesis.

> My point about punctuation (and I admit, it was a
> (friendly) poke at C (i've no particular axe to
> grind with C, except for its pointer syntax, which
> still drives me mad and is an un-readable mess
> IMHO) was that, in the above C example:
>
> = ( , ) ; are there for the compiler, not the
> programmer. That's what Forth strips away. Some
> like it, some don't. It certainly makes for a
> much simpler compiler!

All syntax is for the programmer; the very same ambiguities in code that can confuse a compiler can also confuse a programmer.

Honestly, my experience (and what I've seen from others) is that syntax ceases to be an issue in *any* language once one stops thinking in terms of syntax and thinks instead about semantics. I am very much aware when I'm writing code that I am not thinking about the syntax, but what I want to happen. The syntax more or less comes out when I type. It's the exactly the same when I'm typing English I don't think about the syntax of English. It just happens when I type or write.

It's no different when I'm playing (badly) piano or guitar. The "syntax" of chords is something that over time you internalize and you cease thinking in terms of "let's see, I want a diminished major seventh chord so that's a major seventh with a diminished triad, so I have to move my fingers like this..." You think, it just happens, and you move to the next note. I find exactly the same thing with writing code.

[Unknown]

On Mon, 27 Aug 2012 12:37:57 -0700, John Passaniti wrote:

Let's see if this New USEnet client can 'reply'?

> On Monday, August 27, 2012 7:38:19 AM UTC-4, Mark Wills wrote:
>> If they are 'constantly juggling items on a stack' then their code
>> needs to be re-designed.
>
> No kidding. The point of my response was that the things you cite as
> problematic in other languages aren't shared by experienced developers
> in those languages.

evolution is so speeded-up that we can't expect to have time to be
experienced.

> It's no different when I'm playing (badly) piano or guitar. The
> "syntax" of chords is something that over time you internalize and you
> cease thinking in terms of "let's see, I want a diminished major seventh
> chord so that's a major seventh with a diminished triad, so I have to
> move my fingers like this..." You think, it just happens, and you move
> to the next note. I find exactly the same thing with writing code.

These are the 'skills' of your dog catching a ball.
Software is/has-to evolve beyond the <20's fly-boy fun> stage.
It's not supposed to be fun, like playing jazz.

"You-think, it-just-happens" is good for the horse-&-rider-mode: like
*nix/mc or *M$\nc [do they still offer it?] or ETHOberon's chord-kluxing,
where you've got immediate feedback, and can steer back on to the track.

Also sequences of piped-filters under *nix is GREAT, because you can test
each stage, and if it's OK up-to stage N, you won't have to go back to the
drawing board.

But serious programming should be constrained, with strict type checking
etc.

[Unknown]

On Mon, 27 Aug 2012 12:37:57 -0700, John Passaniti wrote:

Let's see if this New USEnet client can 'reply'?

> On Monday, August 27, 2012 7:38:19 AM UTC-4, Mark Wills wrote:
>> If they are 'constantly juggling items on a stack' then their code
>> needs to be re-designed.
>
> No kidding. The point of my response was that the things you cite as
> problematic in other languages aren't shared by experienced developers
> in those languages.

evolution is so speeded-up that we can't expect to have time to be
experienced.

> It's no different when I'm playing (badly) piano or guitar. The
> "syntax" of chords is something that over time you internalize and you
> cease thinking in terms of "let's see, I want a diminished major seventh
> chord so that's a major seventh with a diminished triad, so I have to
> move my fingers like this..." You think, it just happens, and you move
> to the next note. I find exactly the same thing with writing code.

[Jason Damisch]

> But serious programming should be constrained, with strict type checking

Disagree.

[Andrew Haley]

Unknown <d...@gmail.com> wrote:

> These are the 'skills' of your dog catching a ball.
> Software is/has-to evolve beyond the <20's fly-boy fun> stage.
> It's not supposed to be fun, like playing jazz.

Supposed by whom?

> "You-think, it-just-happens" is good for the horse-&-rider-mode:
> like *nix/mc or *M$\nc [do they still offer it?] or ETHOberon's
> chord-kluxing, where you've got immediate feedback, and can steer
> back on to the track.
>
> Also sequences of piped-filters under *nix is GREAT, because you can
> test each stage, and if it's OK up-to stage N, you won't have to go
> back to the drawing board.
>
> But serious programming should be constrained, with strict type
> checking etc.

Syntax error: "should" without matching "because".

Andrew.

[gavino_himself]

yes but what about lisp and haskell claim that abstraction they have that forth does not makes them more powerful?

[gavino_himself]

hmmm

smalltalk web frameworks seem to have more to offer than forth web frameworks sofar

true?

could u match forth sorcery agaisnt smalltalks for a website?

[Elizabeth D. Rather]

Forth is not specifically aimed at web applications. It is primarily
used for embedded systems.

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
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Unknown]

On Mon, 27 Aug 2012 12:37:57 -0700, John Passaniti wrote:

On Mon, 27 Aug 2012 12:37:57 -0700, John Passaniti wrote:

Let's see if this New USEnet client can 'reply'?

> On Monday, August 27, 2012 7:38:19 AM UTC-4, Mark Wills wrote:
>> If they are 'constantly juggling items on a stack' then their code
>> needs to be re-designed.
>
> No kidding. The point of my response was that the things you cite as
> problematic in other languages aren't shared by experienced developers
> in those languages.

evolution is so speeded-up that we can't expect to have time to be
experienced.

> It's no different when I'm playing (badly) piano or guitar. The
> "syntax" of chords is something that over time you internalize and you
> cease thinking in terms of "let's see, I want a diminished major seventh
> chord so that's a major seventh with a diminished triad, so I have to
> move my fingers like this..." You think, it just happens, and you move
> to the next note. I find exactly the same thing with writing code.

These are the 'skills' of your dog catching a ball. Software is/has-to
evolve beyond the <20's fly-boy fun> stage. It's not supposed to be fun,
like playing jazz.

[Bernd Paysan]

Unknown wrote:
> But serious programming should be constrained, with strict type
> checking etc.

Could you actually give a reason to that? Serious sex should use
bondage, because you prefer that style? Or what are you telling us?

Serious programs should work, stable. There's an old saying that a
program can be simple, and then have obviously no bugs. Or it can be
complicated, and then have no obvious bugs.

I've seen too many people believing in the tools and telling me that
after fixing every problem the tool found the program will have no bugs.
In contrast, in the few hundred lines of my b16 code, the tool found
several "issues", and these would have to be fixed before the code is
considered "good". None of these "issues" would have even helped to
improve the code quality, left alone fix some unknown bug or so. It was
just anal-retentive stuff.

My imagination of these people is that when they go home, there's a
woman clad in black leather with a nine tails whip, telling them "lick
my boots", and they happily comply.

Most of my program errors are actual logic errors, and unless you have a
system like Coq (which is not really ready to use for practical work), a
typechecker can't find these bugs.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[Paul Rubin]

Bernd Paysan <bernd....@gmx.de> writes:
> Most of my program errors are actual logic errors, and unless you have a
> system like Coq (which is not really ready to use for practical work), a
> typechecker can't find these bugs.

In Python, if you say
x = ((a + b) / (c + d)
the compiler might not spot possible lurking logic or type errors, but
it will immediately notice the unbalanced parentheses and tell you to
fix it. One could imagine a language that allowed a value like
d = 5)
so that the "x = ..." statement above would in fact be ok if d had that
value, and otherwise you'd get a runtime error. Most of the time, where
d is an ordinary number, the unbalanced parentheses in the first
expression is an actual error, and it's easier to have the compiler
report it than to wait for a runtime exception to show up during testing
and then debug it. You can imagine the requirement of parentheses
balancing as being in the way sometimes, but most of the time it's not a
problem in practice. Good type systems are similar to that. More
problems get caught at compile time, fewer wait til run time, and
(perhaps more importantly) if you add a chunk of new code to an existing
program, it gets some sanity checking automatically, courtesy of the
compiler. It's not B&D, it's just useful. Per "Real World Haskell":

A helpful analogy to understand the value of static typing is to
look at it as putting pieces into a jigsaw puzzle. In Haskell, if a
piece has the wrong shape, it simply won't fit. In a dynamically
typed language, all the pieces are 1x1 squares and always fit, so
you have to constantly examine the resulting picture and check
(through testing) whether it's correct.

The "jigsaw puzzle" feeling is really palpable and I noticed it with the
first Haskell program I wrote, a cryptography library where the
application was not allowed to decrypt with encryption-only keys and
that sort of thing. I had done something similar in Python earlier,
using OOP and runtime checks, but static types made it even more trivial
to make sure that such stuff didn't get confused.

[Elizabeth D. Rather]

Before developing Forth, Chuck primarily used Fortran, which does a lot
of checking for type, syntax, etc. His experience was that many of
errors it caught were, in fact, "gotchas" caused by expectations of the
compiler, not logic errors. He went out of his way to avoid that sort of
thing (both the "gotchas" and the checking).

His subsequent experience, and mine, and that of the many programmers
I've worked with in the 40 years that I've been around Forth, is the
same. In general in Forth you don't make the kinds of errors that
"strict type checking" would catch. What you want (and get in Forth) is
an environment in which the programmer is empowered to do whatever is
necessary to achieve the result, and the focus of the tools is to help
find the real, logical errors that do occur. That empowerment comes from
the economics of a system that encourages incredibly short definitions
which facilitate unit testing at all levels.

Paul Bennett here specializes in applications with extremely high
reliability and validation requirements. He uses Forth quite
successfully in these applications.

[Paul Rubin]

"Elizabeth D. Rather" <era...@forth.com> writes:
> Paul Bennett here specializes in applications with extremely high
> reliability and validation requirements. He uses Forth quite
> successfully in these applications.

He uses processes that require a lot of up-front design, specifications,
manual code reviews, etc. This is necessary for the critical systems he
works with, no matter what technology is used, so if he's doing well
with Forth, that's great. The typical internet startup (that seems to
be what most programmers around here are doing) is willing to accept a
little more technical risk, since if some feature of a web site
misbehaves because of a code bug, nobody's car crashes and probably
nobody will even notice until the programmers push out a fix a few hours
later.

The result is they are able to develop with far more aggressive
schedules than a critical-systems approach could keep up with. (They
can't deliver similar reliability assurances, but they aren't tasked
with doing so). There are some design meetings with whiteboard
drawings, and some informal documentation such as bug tracker comments,
but the design-code-test-ship cycle is very lightweight and fast
compared with critical-systems projects, from what I can tell. The
customer's overwhelming priority is usually to get working product out
as fast as possible, and they don't care much about machine resources as
long as it doesn't send costs through the roof.

I'm a big admirer of what Paul Bennett does but I don't think his
situation is really typical. Most of us have different constraints and
have to use different methods.

[Elizabeth D. Rather]

All true. I was responding to the assertion that "serious programming

should be constrained, with strict type checking etc."

Both types of projects you describe are quite serious, and both work
very successfully with Forth.

[Mark Wills]

On Sep 10, 2:58 am, Paul Rubin <no.em...@nospam.invalid> wrote:

What's typical just depends on what your day job is ;-)

I work in the subsea oil and gas industry. My company monitors and
controls the oil/gas wells, manifolds and risers that deliver product
from the under the sea to the topside platforms/FPSO's. It's
definately mission critical: If you screw up, you really could end up
with a Gulf of Mexico type situation. I'd say the work I do is
probably quite similar to Paul Bennet's line of work. Though I don't
do SIL stuff much, we tend to contract that out to companies like ABB,
Yokogawa or Hima Sella.

So, my 'typical' development cycle is:

* Requirements capture and review
* Front end design
* Peer review (where the design is torn to peices!)
* Integration of comments into design
* Peer review
(loop until all parties happy)
* Final design review
* Detailed design (plus review cycles)
* Implementation
* In house testing
* Factory acceptance testing
* Final Integration Testing
* Commissioning
* Final testing / punch-list resolving
* Hand over

I'd say coding is 20% of the job. Documentation/reviews/meetings/
minutes etc is 80%

I would also say that it could potentially apply in the web world too.
If you are designing a payment portal ala Paypal, part of the process
will be reviewing the design to ensure that it's secure. That will
entail peer and possibly 3rd party reviews, NDAs, the whole shebang.
Ditto an email portal - it's not as simple as using HTTPS (as I'm sure
you do appreciate!). Ditto any kind of commercial portal - Walmart,
Apple, Amazon etc.

I'd be very surprised if any startup these days was just flat-out
balls-to-the-wall coding. In the 90's maybe. The web is such a hostile
place, and since your web presence *is* your business, it has to be
treated as mission critical "must not fail". That would include
mitigation strategies to keep your business online in the event of DOS
attacks etc.

Yep. Glad I don't work in the web world! Yack!

[Doug Hoffman]

On 9/9/12 9:57 PM, Paul Rubin wrote:

> I'm a big admirer of what Paul Bennett does but I don't think his
> situation is really typical. Most of us have different constraints and
> have to use different methods.

If a Forth programming environment could be created that implemented
some kind of type checking *but* at the same time allowed the same
freedom that we have in current Forths, i.e., didn't require the
ubiquitous type declarations, then I would be all for it. If such a
Forth could catch the "+ instead of F+" programming error then sure, I'd
take that in a heartbeat. Have no idea if such a Forth could be
created. Seems like it might be very difficult, if even possible...

-Doug

[Mark Wills]

I tend to agree. With no explicit assignment operator (e.g. = in C
or := in Pascal) it is very very difficult indeed to detect type
errors.

For example:

: test 3.141 F+ ;

Is perfectly legal code. Moreover, it is not possible (when test is
compiled) to know what will be on the stack when test is subsequently
executed. Maybe there will be a float under the 3.141, maybe not.
Adding a method to determine the _types_ of the parameters on the
stack would add significant execution-time overhead.

The solution in the above example would be to have a seperate floating
point stack, but that's not a mandatory requirement IIRC. Then, at
least one can detect fp stack over/underflow. That's how my FP system
works - a seperate FP stack. Keep integers on the data stack and
floats on the FP stack. The float words can only operate on the FP
stack. Simple as that. That means that the problem just can't arise.

[Anton Ertl]

Doug Hoffman <glid...@gmail.com> writes:
>If a Forth programming environment could be created that implemented
>some kind of type checking *but* at the same time allowed the same
>freedom that we have in current Forths, i.e., didn't require the
>ubiquitous type declarations, then I would be all for it.

Try Factor. I think it fits your description. I found, though, that
it does not allow the same freedom that we have in Forth. StrongForth
might also fit your description.

> If such a
>Forth could catch the "+ instead of F+" programming error then sure, I'd
>take that in a heartbeat.

It will probably eliminate this error by calling both words "+".

- 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 2012: http://www.euroforth.org/ef12/

[Paul Rubin]

Mark Wills <markrob...@yahoo.co.uk> writes:
> I work in the subsea oil and gas industry... If you screw up, you

> really could end up with a Gulf of Mexico type situation. I'd say the
> work I do is probably quite similar to Paul Bennet's line of work.

Yes I can see that as similar.

> * Implementation
> * In house testing

Do you have multi-person, in-depth code inspection as part of the
implementation phase? That seems to be an essential part of Paul
Bennett's process. I've been involved with two projects that supposedly
used it (for embedded C code) but what the first one actually did was
pretty ludicrous. The second one seemed more likely to "do it right"
but the project got reorganized before it got to that phase.

> I would also say that it could potentially apply in the web world too.

> If you are designing a payment portal ala Paypal...

Yeah, I've done some financial-sector security stuff, and of course they
were much more careful than the typical informational web site, though
below (say) aerospace-sector safety-critical processes as far as I can
tell. One good thing we got to do in one project was build an
informally specified prototype in Python to quickly develop the
product's feature set, before writing a solidified spec and
re-implementing (in C) on the target device. This worked out pretty
well, though for various (good) organizational reasons, the next phase
ended up being done by a different group (and they used J2ME (embedded
Java) instead of C, another wise choice IMHO).

I think the end product came out better than a pure up-front design
could have delivered, due to designers' being unable to see too many
moves ahead in the "chess game" without an actual implementation in
their hands. The product won some kind of industry award though I don't
know if the award was a really meaningful one.

> I'd be very surprised if any startup these days was just flat-out
> balls-to-the-wall coding. In the 90's maybe. The web is such a hostile
> place, and since your web presence *is* your business, it has to be
> treated as mission critical "must not fail".

Take a look at thedailywtf.com any day of the week, and cry. ;-)

In reality web sites don't often suffer serious total outages due to
application-level software problems. Instead, out of the 100's of
features (most of them non-critical), there are usually a few obscure
things not working completely correctly. There might be some customer
annoyance (or better, nobody notices), and you push out a fix when you
can. I used Paypal yesterday and saw some problems like that, and
didn't consider it a big deal.

I do know some guys who work at Paypal and I hear generally good things
about how Paypal does stuff. I may ask them about it sometime.

[Anton Ertl]

Mark Wills <markrob...@yahoo.co.uk> writes:
>For example:
>
>: test 3.141 F+ ;

...

>The solution in the above example would be to have a seperate floating
>point stack, but that's not a mandatory requirement IIRC.

Well, for testing its sufficient if the system you use has a separate
FP stack (which all serious systems support).

Concerning mandatory requirement, a separate FP stack was preferred
already in Forth-94 (there was some unclear "default" wording to that
effect, and is mandated in Forth200x (but there is also some wording
that explains that a system can declare the environmental restriction
of having a unified FP stack; systems can declare environmental
restrictions for pretty much everything, so the only unusual thing is
that this is mentioned explicitly in the standard).

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:

>Mark Wills <markrob...@yahoo.co.uk> writes:
>> In the 90's maybe. The web is such a hostile
>> place, and since your web presence *is* your business, it has to be
>> treated as mission critical "must not fail".
>
>Take a look at thedailywtf.com any day of the week, and cry. ;-)
>
>In reality web sites don't often suffer serious total outages due to
>application-level software problems. Instead, out of the 100's of
>features (most of them non-critical), there are usually a few obscure
>things not working completely correctly. There might be some customer
>annoyance (or better, nobody notices), and you push out a fix when you
>can. I used Paypal yesterday and saw some problems like that, and
>didn't consider it a big deal.

Yes. I recently tried to book a flight on British Airways through the
web. It was a very time-consuming and annoying experience that
culminated in me having almost completed the booking, and then having
no "proceed" button on one of the last pages.

The sad thing is that this failure did not cost them business (at
least in my case). I eventually tried another browser, and there I
got the button. It just cost me half an hour in failed tries and
eventually doing the booking again with the other browser.

If I knew that there was someone who was doing that better, BA would
lose business, though. But all the other airlines and booking sites I
tried (ok, not that many) are just as bad.

In contrast, I recently ordered something through Amazon, and they did
everything right: Amazon functions without JavaScript, and the
workflow is very easy.

[Paul E. Bennett]

Somewhere in these first two stages we are allowed a little exploratory
prototype work but none of that goes any further than extracting something
useful for the requirements specification. Prototype tools include Forth,
Spreadsheets and the occasional simulation environment. What comes out of
this is pretty good but the next step is still extremely important to us.

> * Peer review (where the design is torn to peices!)
> * Integration of comments into design
> * Peer review
> (loop until all parties happy)
> * Final design review
> * Detailed design (plus review cycles)
> * Implementation
> * In house testing
> * Factory acceptance testing
> * Final Integration Testing
> * Commissioning
> * Final testing / punch-list resolving
> * Hand over

> I'd say coding is 20% of the job. Documentation/reviews/meetings/
> minutes etc is 80%

I have the ratio as between 15% to 85% and 21% and 79% (with just software).
More often than not I also have hardware design to include for and that gets
to be a split of 10% software 15% hardware and 75%
documentation/reviews/meetings etc.

> I would also say that it could potentially apply in the web world too.
> If you are designing a payment portal ala Paypal, part of the process
> will be reviewing the design to ensure that it's secure. That will
> entail peer and possibly 3rd party reviews, NDAs, the whole shebang.
> Ditto an email portal - it's not as simple as using HTTPS (as I'm sure
> you do appreciate!). Ditto any kind of commercial portal - Walmart,
> Apple, Amazon etc.

Sometimes one could wish it applied more often in the web-world.

> I'd be very surprised if any startup these days was just flat-out
> balls-to-the-wall coding. In the 90's maybe. The web is such a hostile
> place, and since your web presence *is* your business, it has to be
> treated as mission critical "must not fail". That would include
> mitigation strategies to keep your business online in the event of DOS
> attacks etc.
>
> Yep. Glad I don't work in the web world! Yack!

Me too!
--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Bernd Paysan]

Mark Wills wrote:
> I'd be very surprised if any startup these days was just flat-out
> balls-to-the-wall coding. In the 90's maybe. The web is such a hostile
> place, and since your web presence *is* your business, it has to be
> treated as mission critical "must not fail". That would include
> mitigation strategies to keep your business online in the event of DOS
> attacks etc.

The question however is if you by not coding until the middle of the
project ever get to understand what your problems are? I'm especially
against too much up-front documentation: You think you got everything
right, but you never tried...

The proof of the pudding is its eating. A secure payment transaction
site should be concerned about security from day one. But the message
we get here is that you get security by not coding, but doing other
things. I'm not convinced. Security is the most difficult to test, as
it requires a malicious attacker to pass through. It's not just a bug,
it is an intentional malicious attack.

So, yes, you should think about security. You should think about
deliberately attacking your own product to see if there are weaknesses.
But to do so, you need a prototype! You can't do that based on specs.
There is a constant illusion on programming, it's the illusion of
control.

What I smell here is the sweat of fear. Your buggy code can blow up an
oil platform or cause a company to lose it's net worth on the stock
exchange during the lunch break. The latter actually did happen
recently. Because it is so worrysome, you postpone the actual project
start to later, and be "very carefully" about your requirements etc.

And after months and months of specifying, you end up with the most
expensive bugs you can get: wrong specs.

Agile development isn't less safe. It's just that you must specify a
confidence level when to deploy the product. This seems to be the
problem, agile development is fast, and after a few rounds, the thing
looks quite promising. Hey, it isn't ready! It's just the first demo!

Management often doesn't understand that kind of thing. In a climate of
fear, people start sandbagging, hoping that the management will be more
patient that way. But management is not *that* stupid, either, they
will discover your first prototypes, and say "Hey, you were just
sandbagging. The program already runs! Great, let's deploy it in
production yesterday!"

Documentation and proper requirements is not stupid. Thinking about how
to implement your program is not stupid; taking breaks in between to let
your brain work on the problems and suddenly find a solution is neither.

But fear of coding is stupid. Deploying a waterfall model will result
in something like "we now use only 20% for the actual coding". Hm, but
our process now takes 10 times as long as the agile one, and if you let
agile programs ripe a little longer, they become stable, too. Maybe the
waterfall model isn't really the good thing, it's having more time which
is the good thing.

[Paul E. Bennett]

Bernd Paysan wrote:

> The question however is if you by not coding until the middle of the
> project ever get to understand what your problems are? I'm especially
> against too much up-front documentation: You think you got everything
> right, but you never tried...

Sometimes it is down to how you structure the problem space. The initial
statement of requirements might be quite vague. There will be areas that are
not fully definable at the start. I am not against prototyping, actually I
quite often encourage it. However, you have to guard against management
thinking they can ship prototypes. Incidently, prototypes don't always have
to be hardware or code, they can be representative models.

> The proof of the pudding is its eating. A secure payment transaction
> site should be concerned about security from day one. But the message
> we get here is that you get security by not coding, but doing other
> things. I'm not convinced. Security is the most difficult to test, as
> it requires a malicious attacker to pass through. It's not just a bug,
> it is an intentional malicious attack.
>
> So, yes, you should think about security. You should think about
> deliberately attacking your own product to see if there are weaknesses.
> But to do so, you need a prototype! You can't do that based on specs.
> There is a constant illusion on programming, it's the illusion of
> control.

I would suggest that the security portion could be prototyped separately and
thoroughly thrashed with malicious attacks. As with all prototype efforts
you only create them to gather the data to improve the final specification
(and hence the final product).

> What I smell here is the sweat of fear. Your buggy code can blow up an
> oil platform or cause a company to lose it's net worth on the stock
> exchange during the lunch break. The latter actually did happen
> recently. Because it is so worrysome, you postpone the actual project
> start to later, and be "very carefully" about your requirements etc.

If you have a sound development process (whether it is waterfall model or
spiral/agile) you should have clear enough markers in there to indicate when
the product reaches a stage where it is going to be ready to ship. In my own
process it the check to ensure that all open issues have been dealt with
that triggers the promotion of the product to final acceptance testing.

> And after months and months of specifying, you end up with the most
> expensive bugs you can get: wrong specs.

Which is why you often need the prototyping effort to ensure that the specs
are correct early enough in the development process.

> Agile development isn't less safe. It's just that you must specify a
> confidence level when to deploy the product. This seems to be the
> problem, agile development is fast, and after a few rounds, the thing
> looks quite promising. Hey, it isn't ready! It's just the first demo!
>
> Management often doesn't understand that kind of thing. In a climate of
> fear, people start sandbagging, hoping that the management will be more
> patient that way. But management is not *that* stupid, either, they
> will discover your first prototypes, and say "Hey, you were just
> sandbagging. The program already runs! Great, let's deploy it in
> production yesterday!"

Which is why your development process needs to be clear about what is and is
not to be considered as a shippable product. Partitioning can help a great
deal, you don't have to prototype everything, just the bits you are unsure
of at the start.

> Documentation and proper requirements is not stupid. Thinking about how
> to implement your program is not stupid; taking breaks in between to let
> your brain work on the problems and suddenly find a solution is neither.
>
> But fear of coding is stupid. Deploying a waterfall model will result
> in something like "we now use only 20% for the actual coding". Hm, but
> our process now takes 10 times as long as the agile one, and if you let
> agile programs ripe a little longer, they become stable, too. Maybe the
> waterfall model isn't really the good thing, it's having more time which
> is the good thing.

There should really be little difference in the time taken for the same
level of functionality and integrity no matter what model you use.

[Mark Wills]

On Sep 10, 11:38 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Mark Wills wrote:
> > I'd be very surprised if any startup these days was just flat-out
> > balls-to-the-wall coding. In the 90's maybe. The web is such a hostile
> > place, and since your web presence *is* your business, it has to be
> > treated as mission critical "must not fail". That would include
> > mitigation strategies to keep your business online in the event of DOS
> > attacks etc.
>
> The question however is if you by not coding until the middle of the
> project ever get to understand what your problems are?  I'm especially
> against too much up-front documentation: You think you got everything
> right, but you never tried...
>

You are definately correct that it is impossible to think of
everything in the early FEED/design stages. But that shouldn't really
be a problem. If a new set (or subset) requirements emerge as a
natural part of the design process you just apply the same procedures
that I mentioned earlier (peer review, impact analysis etc) to the new
set of requirements. Of course you need extend schedules slightly
(which pisses the manglement off) and also do regression testing to
make sure you didn't break earlier stuff. But it is possible to do.

> What I smell here is the sweat of fear.  Your buggy code can blow up an
> oil platform or cause a company to lose it's net worth on the stock
> exchange during the lunch break.  The latter actually did happen
> recently.  Because it is so worrysome, you postpone the actual project
> start to later, and be "very carefully" about your requirements etc.
>

Again, you are correct. It is very much down to fear (in my industry,
at least). Or perhaps more correctly, it's about not killing people if
you can possibly avoid it! It comes down to documenting the entire
design process, including who made what decisions, based upon what
information, who agreed, who disagreed (that's why I mentioned MoM in
my earlier post) so that if someone *does* get killed, you can protect
either the company, or individuals within the company from possible
legal ramifications. Sad, but true. Having said "sad but true" I *do*
think one ends up with a much better product/solution as a result of
going through the process. It took time for me to arrive at that
opinion (I was the architypical maverick "just STFU and write the
code" type person) but I have (eventually) arrived at that opinion!

> And after months and months of specifying, you end up with the most
> expensive bugs you can get: wrong specs.
>

Wrong specs? KAAAAACHING!

Seriously, if you're client doesn't know what he really wants (happens
a lot in this industry, simply because of the complexity and market
changes (changes in the oil/gas prices). If they get the initial specs
"wrong" (or accurately, they change their mind) then you simply hit
them with variation orders. Project manglement love variation orders.
Not only does it bring in more ca$h to the project, but it allows the
schedule to be extended. They love that, because projects are *always*
behind schedule :-)

[gavino_himself]

you one weird cat bernd

I love that u made gforth with friends tho

bravo

and made your own chip

not sure I coulda done either

although I do consider myself smart

maybe I started programming too late in life

or didnt goto school for it

[Doug Hoffman]

On 9/10/12 10:17 AM, Anton Ertl wrote:
> Doug Hoffman <glid...@gmail.com> writes:
>> If a Forth programming environment could be created that implemented
>> some kind of type checking *but* at the same time allowed the same
>> freedom that we have in current Forths, i.e., didn't require the
>> ubiquitous type declarations, then I would be all for it.
>
> Try Factor. I think it fits your description.

Good suggestion. Thanks. I have spent a few hours with it now. Slava
Pestov has a YouTube video that is worth browsing at least parts of:

http://www.youtube.com/watch?v=f_0QlhYlS8g

> I found, though, that
> it does not allow the same freedom that we have in Forth.

Agreed. Still trying to overcome the "lack of familiarity" bias while
evaluating it.

Although I'm a proponent of objects (when appropriate), they seem to be
forced on Factor programmers in situations where use is questionable.
Not sure yet.

> StrongForth
> might also fit your description.

Tried SF several times and just can't get used to the (seemingly
significant) extra work involved with types. Interferes with focusing
on the problem, IMO.

-Doug

[Paul Rubin]

Doug Hoffman <glid...@gmail.com> writes:
>> Try Factor. I think it fits your description.
> Good suggestion. Thanks. I have spent a few hours with it now.
> Slava Pestov has a YouTube video that is worth browsing at least parts of:
> http://www.youtube.com/watch?v=f_0QlhYlS8g

I wasn't able to view the video, but from its web site, Factor is sort
of Lisp-like in terms of having latent types and garbage collection.
Anyone know if the programming experience is really that different from
Lisp? As does Lisp, it will require a lot more machine resources than
Forth. It says it wants 128 meg of ram, though that seems excessive.
There are plenty of good Lisp dialects that run in 1 meg or less, maybe
even 100k or less. Except for some mostly-useless toy implementations
they can't really get to the 10k range the way Forth can.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>from its web site, Factor is sort
>of Lisp-like in terms of having latent types and garbage collection.
>Anyone know if the programming experience is really that different from
>Lisp?

Definitely. Lisp does not try to do static type checking with type
inference, so it is much less annoying (to me; you might have more
tolerance for Factor).