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 2 of 2 — ← Prev page 1 [2]

#15568

On 9/9/12 3:57 PM, Paul Rubin wrote:
> "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.

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.

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]

#15569

On Sep 10, 2:58 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erat...@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.

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!

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

#15585

Mark Wills <markrobertwills@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.

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

#15588

Paul Rubin <no.email@nospam.invalid> writes:
>Mark Wills <markrobertwills@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.

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

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

#15591

Mark Wills wrote:

> On Sep 10, 2:58 am, Paul Rubin <no.em...@nospam.invalid> wrote:
>> "Elizabeth D. Rather" <erat...@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.
> 
> 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

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.Bennett@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..
********************************************************************

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

#15594

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.

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

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

#15602

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.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@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..
********************************************************************

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

#15614

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 :-)

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

#15577

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

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

#15582

On Sep 10, 2:09 pm, Doug Hoffman <glide...@gmail.com> wrote:
> 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

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.

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

#15586

Mark Wills <markrobertwills@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
-- 
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/

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

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

Doug Hoffman <glidedog@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/

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

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

On 9/10/12 10:17 AM, Anton Ertl wrote:
> Doug Hoffman <glidedog@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

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

#15673

Doug Hoffman <glidedog@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.

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

#15709

Paul Rubin <no.email@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).

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

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

#15661

On Saturday, September 8, 2012 4:12:09 PM UTC-7, 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.
> 
> 
> 
> -- 
> 
> Bernd Paysan
> 
> "If you want it done right, you have to do it yourself"
> 
> http://bernd-paysan.de/

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

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

#15288

On Saturday, August 25, 2012 4:51:00 AM UTC-7, Mark Wills wrote:
> 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!

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

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

#15289

On Wednesday, August 22, 2012 8:25:29 PM UTC-7, 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?
> 
> >

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?

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

#15290

On 8/30/12 5:16 PM, gavino_himself wrote:
> On Wednesday, August 22, 2012 8:25:29 PM UTC-7, 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?
>>
>>>
>
> 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?
>

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web