[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A path for CSP-based Solutions towards HUGE Industrial Success.
This exchange is great... but don't give up too quickly, Marcel, you can
only expect to START change in a moment, not complete it.
My contention is that we can punch through the fog with this one simple
fact: rigorous channel based CSP (occam) programming creates software
components that behave logically identically to hardware components.
I know we have to fight against the fact that "component" has already
been appropriated by the OO crowd, but their component requires giant
centralized information structures to be identical and can't just be
plugged in like a new alternator in a car. This is identical to Marcel's
description of distributed computing; but speed, recofiguration, and
precise program definition are possible with our model.
WE NEED TO FIND A PROBLEM THAT NEEDS SUCH A SOLUTION. Reconfigurable
robotics of any sort seems to be a natural. Here is the technical key,
in my opinion (based on experience):
Web-like stuff works as long as it can run on top of standard system
software, treating that as an inviolable "black box". As soon as one
enters the system arena (interrupts, drivers, Ring 0 stuff) everything
turns into a nightmare of complication (we are experiencing this in
RAID implementation). This drives people toward RTOS solutions which
are "a gob of raw code" - stiff and unmodular. We can have both worlds
- the absolute power of system code and the modular reconfigurability
of distributed code and hardware components.
>From: M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>
>Date: Thu, 5 Oct 2000 12:14:31 +0200
>To: mboosten@xxxxxxxxxxxxxxxxxxx, b.m.cook@xxxxxxxxxxxxxx
>Subject: Re: A path for CSP-based Solutions towards HUGE Industrial Success.
>Cc: java-threads@xxxxxxxxx, occam-com@xxxxxxxxx, richard.beton@xxxxxxxxxx,
>Barry, Peter, Tom, ...
>> > - However, they start showing up when the application is roughly over
>> > 600.000 lines of code, and multiple releases of the product are made:
>> > changing existing code becomes intrinsicly difficult.
>> > My guess is that there is a practical upper-limit of about 1M lines of
>> > code, at which point people realize that they had better start from
>> > scratch...
>> > - The proper solution is CSP-based.
>> Just trying to get a feel for what sort of work we need to do before we can
>> make a convincing case ...
>> While many people believe the above, do we have any evidence - i.e. examples of
>> 1M+LOC applications done with CSP? I'd guess that some of the Transputer
>> applications were large but I don't remember figures much bigger than 10's
>> of K LOC.
>This is indeed one sort of proof.
>And yes, there is such application: the WEB.
>Remarkably, distributed computing seems to allow nearly infinite growth,
>as long as... ...the communication protocol are simple and clear...
>...there is a clear way to share data (via a channel)... and
>...each process has at least practically, its own address space...
In other words, at any moment, it is practically CSP.
>Single-threaded OO applications don't grow.
>All you need to do is make a convincing case that the principles
>used in the WEB are the CSP bases... FOCUS ON THE PRINCIPLES
Yes but you also have to answer, "Why bother with that nasty math
when the web stuff is good enough"?
The answer (for a particular application) has to be: "Because it
is far easier and more reliable." That case becomes convincing
when reconfigurability and system capabilities (interrupts, drivers)
>This is the social situation: BEWARE OF IT!
>- Management in Industry pays "experts" for technical advice.
> (I consider myself as one of those industrial experts, people
> that KNOW computing science, but also KNOW the industrial needs)
>- By winning the confidence of these so-called experts, you can
> cause the ideas to be accepted to solve practical problems...
> the industry makes a huge profit... the ideas get popular.
>- This is what such a so-called expert needs:
> Convincing articles/lectures/information that show HOW and
> WHY their TODAY's problems can be solved.
Or, one specific problem.
>- Most experts are convinced that they are excellent experts:
> never tell them that they have been doing stupid things in the
> past: you will loose them immediately.
>- Help them identify the problem area, and convince them of the
> HOW and WHY of the solutions.
>- Make sure the concept is SO SIMPLE that they can easily
> communicate it to others.
Software components that are logically IDENTICAL to hardware
>- Note that experts like to "discover" solutions to huge problems,
> becuase that's exactly what they are pays for: it strengthens
> their personal position (and salary!) in industry.
>- I have talked like hell to Chief Experts.
>- Some have been convinced fully.
>- Some have been convinced a bit.
>- Some think it is all nonsence: the rest of the World is simply
> not as smart as they are, and there are more important problems.
>- Convincing, short, simple, single-subject articles that convince
> to lead to solution of industrial problems.
>- To indicate PRACTICAL industrial problems (to bring them to life for
> the acadamics)
We need ones that: (a) are not being solved by current methods
(especially if programming budgets are spinning out of control)
(b) we, with our experience, know CSP techniques would make them
easy and reliable.
>- To give my critical "Industrial" view on those articles.
>- Industry has got other problems as well: problems with a
> CSP-based solution might be just in the TOP 10 of problems...
> Do not think it is top priority: it definitely IS NOT!
> The loss of EUR 100,000 yesterday because of some stupidity
> GETS full attention.
>- CSP-based solutions require a significant INVESTMENT.
>- CSP-based solutions are considered to be LONG TERM investments.
Not necessarily. In my professional career I have used CSP techniques
(but C and assembler tools) several times to make working, salable
items (i.e. the Superset Bridge Box). I worked as a "loner". This
was using the raw system power of DOS and assembler: this approach
has become much more difficult with protected mode, Ring 0
restrictions and bloated operating systems.
We need a simple, anarchic, DOS-like operating system that allows
easy access to the full power of a chip (ie x86). This is NOT a large
project but someone needs to bite the bullet. Then we structure
C and occam compilers and CSP-friendly linkers that permit soft
AND HARD channel communication over it. At this point true
hardware-equivalent components become possible.
>- Solving yesterdays problem IS TODAYS concern, avoiding the
> situation will give IMMEDIATE benefit.
>- Management is focussed on PROBLEM SOLVING instead of PROBLEM
But if we can convince them that programming a specific project is
much quicker and cheaper using our techniques, then problem
avoidance IS (budget) problem solving.
Yes, I realize there is a chicken and egg problem here. Go back to
that expert you fully convinced?
>- My time is limited.
>- My industry pays for every e-mail I sent to this list.
>- I spent this time because I expect SIGNIFICANT RESULTS (the
> convincing articles) in the SHORT TERM from my comments here
If you give me your snail mail address, I can send you a copy of my
component article... Peter knows about it.
>- Being accused of "wasting time" is one of the experts worst
> nightmares: it leads to disrespect in the job, which has an
> nearly immediate financial and functional drawback.
>- I'll soon be fad up if nobody GRABS the OPPORTUNITY I'm offering.
>Yes, I'm quite frustrated!
>Cc: java-threads@xxxxxxxxx, occam-com@xxxxxxxxx
>Subject: Re: A path for CSP-based Solutions towards HUGE Industrial Success.
>From: "P.H.Welch" <P.H.Welch@xxxxxxxxx>
>Date: Thu, 5 Oct 2000 13:16:21 +0100
>I am very sympathetic to what you have been posting. I have seen for
>years (decades!) industry (and academic computer scientists) react in
>the way you describe when presenting them with core CSP design,
>verification and implementation principles and the tools from which the
>solutions they need can obviously be built. They won't pick it up
> o CSP is "different" to what people are used to ... presumably large
> serial designs, threads-and-locks or passive structures kicked
> around by call-backs ...
> o CSP is remembered from college days - if at all - as some pretty
> hard maths ...
But those simple diagrams you did of hardware-equivalent components
are not so hard.
> o although most things are an admitted "mess", we're "getting by" ...
> and, anyway, our customers don't know anything can be done about
> it ...
Find someone whose project is suffocating in complexity.
> o CSP, because it's not the norm, is "high risk" ... unlike what we're
> doing at the moment ...
>All the above I have been told so many times by so many people over so
>many years - including very recently by senior decision makers in one
>rather large and influential technology provider.
>BUT ... we're wearing them down! I am optimistic that a whole bunch of
>circumstances means that resistance, as they say, will soon be futile.
>Now - much more than the mid 1980s when appication needs/ambitions were
>much lower - would be the time to launch transputer and associated
>software and hardware technologies. The applications really do need
>So, maybe we should stop giving away solutions on a plate and start
>*selling* them instead. They'll take that seriously! Who wants to be
Convince some supporter - such as a military or space agency - that
the comparatively small OS/compiler/linker project I described will
have a big payoff for their needs... Like not having to spend
a man-year fighting system code to get some trivial driver-related
code working reliably...
Once it's done, keep the ball rolling (with other chips and other
comms protocols). Just one working model will make all the later