Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #15105 > unrolled thread

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

Back to article view | Back to comp.lang.forth

Contents

  abstraction: do haskell and lisp beat forth in abstraction? or no? gavino_himself <visploveslisp@gmail.com> - 2012-08-22 13:20 -0700
    Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Jason Damisch <jasondamisch@yahoo.com> - 2012-08-22 17:31 -0700
    Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Ron Aaron <rambamist@gmail.com> - 2012-08-23 06:25 +0300
      Re: abstraction: do haskell and lisp beat forth in abstraction? or no? jacko <jackokring@gmail.com> - 2012-08-24 08:41 -0700
        Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-25 03:46 -0400
          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? jacko <jackokring@gmail.com> - 2012-08-25 10:03 -0700
        Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-25 04:51 -0700
          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-26 06:03 -0400
          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? John Passaniti <john.passaniti@gmail.com> - 2012-08-26 20:19 -0700
            Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-08-27 04:38 -0700
              Re: abstraction: do haskell and lisp beat forth in abstraction? or no? John Passaniti <john.passaniti@gmail.com> - 2012-08-27 12:37 -0700
                Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Unknown <dog@gmail.com> - 2012-08-29 18:53 +0000
                  Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Jason Damisch <jasondamisch@yahoo.com> - 2012-08-29 12:30 -0700
                  Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-29 14:37 -0500
                Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Unknown <dog@gmail.com> - 2012-08-29 18:53 +0000
                Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Unknown <dog@gmail.com> - 2012-09-08 22:14 +0000
                  Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-09 01:12 +0200
                    Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Paul Rubin <no.email@nospam.invalid> - 2012-09-08 18:04 -0700
                    Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Elizabeth D. Rather" <erather@forth.com> - 2012-09-09 15:01 -1000
                      Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Paul Rubin <no.email@nospam.invalid> - 2012-09-09 18:57 -0700
                        Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Elizabeth D. Rather" <erather@forth.com> - 2012-09-09 18:47 -1000
                        Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-10 01:19 -0700
                          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Paul Rubin <no.email@nospam.invalid> - 2012-09-10 08:18 -0700
                            Re: abstraction: do haskell and lisp beat forth in abstraction? or no? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-10 16:21 +0000
                          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-09-10 18:41 +0100
                          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Bernd Paysan <bernd.paysan@gmx.de> - 2012-09-11 00:37 +0200
                            Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2012-09-11 19:07 +0100
                            Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Mark Wills <forthfreak@gmail.com> - 2012-09-12 00:32 -0700
                        Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Doug Hoffman <glidedog@gmail.com> - 2012-09-10 09:09 -0400
                          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Mark Wills <markrobertwills@yahoo.co.uk> - 2012-09-10 06:49 -0700
                            Re: abstraction: do haskell and lisp beat forth in abstraction? or no? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-10 15:17 +0000
                          Re: abstraction: do haskell and lisp beat forth in abstraction? or  no? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-10 14:17 +0000
                            Re: abstraction: do haskell and lisp beat forth in abstraction? or  no? Doug Hoffman <glidedog@gmail.com> - 2012-09-14 11:54 -0400
                              Re: abstraction: do haskell and lisp beat forth in abstraction? or no? Paul Rubin <no.email@nospam.invalid> - 2012-09-15 02:11 -0700
                                Re: abstraction: do haskell and lisp beat forth in abstraction? or no? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-09-18 12:11 +0000
                    Re: abstraction: do haskell and lisp beat forth in abstraction? or no? gavino_himself <visploveslisp@gmail.com> - 2012-09-14 03:22 -0700
          Re: abstraction: do haskell and lisp beat forth in abstraction? or no? gavino_himself <visploveslisp@gmail.com> - 2012-08-30 20:13 -0700
      Re: abstraction: do haskell and lisp beat forth in abstraction? or no? gavino_himself <visploveslisp@gmail.com> - 2012-08-30 20:16 -0700
        Re: abstraction: do haskell and lisp beat forth in abstraction? or no? "Elizabeth D. Rather" <erather@forth.com> - 2012-08-30 17:44 -1000

Page 1 of 2  [1] 2  Next page →

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

curious if forth can be as high level?

[toc] | [next] | [standalone]

#15112

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

[toc] | [prev] | [next] | [standalone]

#15115

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?
> 

[toc] | [prev] | [next] | [standalone]

#15137

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.

[toc] | [prev] | [next] | [standalone]

#15148

"jacko" <jackokring@gmail.com> wrote in message
news:43424b5a-0d2a-4bbb-a385-e06f4f287853@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,

(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

[toc] | [prev] | [next] | [standalone]

#15156

On Saturday, 25 August 2012 08:46:13 UTC+1, Rod Pemberton  wrote:
> "jacko" <jackokring@gmail.com> wrote in message
> 
> news:43424b5a-0d2a-4bbb-a385-e06f4f287853@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.

[toc] | [prev] | [next] | [standalone]

#15152

On Aug 24, 4:41 pm, jacko <jackokr...@gmail.com> wrote:
> 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.

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!

[toc] | [prev] | [next] | [standalone]

#15171

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:d81d9a4b-10f6-45fb-b8cd-6e2af143c448@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

[toc] | [prev] | [next] | [standalone]

#15184

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.

[toc] | [prev] | [next] | [standalone]

#15190

On Aug 27, 4:19 am, John Passaniti <john.passan...@gmail.com> wrote:
> 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.


"Just think of it-- programmers spending huge amounts of time
constantly juggling items on a stack."

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!

[toc] | [prev] | [next] | [standalone]

#15201

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.

[toc] | [prev] | [next] | [standalone]

#15244

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.

[toc] | [prev] | [next] | [standalone]

#15249

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

Disagree.

[toc] | [prev] | [next] | [standalone]

#15250

Unknown <dog@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.

[toc] | [prev] | [next] | [standalone]

#15245

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.

[toc] | [prev] | [next] | [standalone]

#15539

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.

"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.

[toc] | [prev] | [next] | [standalone]

#15543

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/

[toc] | [prev] | [next] | [standalone]

#15546

Bernd Paysan <bernd.paysan@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.

[toc] | [prev] | [next] | [standalone]

#15564

On 9/8/12 1:12 PM, Bernd Paysan wrote:
> 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.
>

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.

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#15566

"Elizabeth D. Rather" <erather@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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web