I need to make an argument for using Component Pascal for a project to deliver software as a service over the web.
The software will be based on code I have developed using Blackbox for use on a single machine locally.
Among the perceived choices are:
1. translate the algorithms from CP to a language the developers are more familiar with.
2. move the code from Blackbox to GPCP and use the components to interoperate with code written in other languages (using JVM or .Net)
In the past there have been testimonials on this list regarding positive experiences with Blackbox. If any of the authors have easy access to those testimonials and can forward to me (offlist or onlist) I would be appreciative as it would be easier than searching thru the archives.
Any such that address similar problem spaces would be especially helpful (i.e. web access, databases).
In particular, experience with moving from BB to GPCP, experience with O3, and comparisons of development speed, maintainability vs other languages are appreciated.
Thanks.
Antony Tersol
On Thu, Sep 24, 2009 at 1:43 AM, Campbell, Robert (SELEX GALILEO, UK) <robert.d.campbell{([at]})nowhere.xy
>> On Tue, 22 Sep 2009, Chris Burrows wrote:
>>
>> David Jackson of MIT has written an interesting article
>> titled "A Direct
>> Path to Dependable Software". In part he says ...
>> You can download the complete article from:
>> http://sdg.csail.mit.edu/pubs/2008/cacm-08.pdf
An interesting article ...
Some years ago I wrote a fairly extensive piece of code to solve a
difficult
mathematical problem in CP / BlackBox. Some time later a colleague (who
uses C# / .NET)
had the same problem, and so wanted access to my solution. I compiled
the code into a .NET
dll using the Gardens Point CP compiler, he linked it into his C#, and
all seemed well - a
success!.
A year or so later some inaccuracies were noticed, then the CP module
began to 'hang' in
infinite loops. This was a big problem, caused a lot of anguish, and
gave CP a bad name locally.
Ultimately we traced the immediate cause to the assumption made in the
CP code that the floating
point unit was working in 64 or 80 bits accuracy. In fact the C#
application had grown a 3D graphics
capability that used DirectX, which set the floating point unit to 32
bit accuracy, and left it there.
Result - a non-(*dependable*) programme.
Do we just accept this? - or should there be a solution? Maybe the CP
(*language*) needs a command
to set the floating point control register explicitly, and we should
call this in our source code
before each and every floating point operation?
I would prefer a more elegant and efficient solution.
Maybe some (*mistake*) was made in the way the C# application was coded
(I honestly don't
know whose 'fault', if indeed it was a fault, this problem was). But
that fact that such a
fault can occur without obvious prompting seems to me to be a
dependability issue very similar
to a memory leak or an out-of-bounds array access; things that a
dependable language would
simply eliminate.
Regards
Robert
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
----
To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Thu Sep 24 2009 - 20:15:36 UTC