Thu Aug 24 15:37:51 CEST 2000
> Typing *is* useful but not a universal panacea. A type
> As for being insecure in Erlang compared to C IHMO it's the other
> way around.
I totally agree in the vast majority of cases, which is why we are using it
in our GSM Network so extensively and successfully :-)
> > Does he not do integrated testing as he goes? Crank up a temporary
Yes, but it is difficult to test all those hard to reach error cases such as
you may for example find in socket programming when odd things happen in the
network and you get different types of read errors
(recoverable|non_recoverable). I'm sure in every system there are such paths
which are never excercised in testing.
My interest is in how to minimise the occurence of errors in the margins of
the system by improved tools rather than more testing, and the ones I
mentioned originally are not found by compiling or linking. (This is also
why error_report:format("This function doesn't exist"). is such a favourite.
It is reporting an error case, and doesn't work in itself - You need to do
error_report:format("This function doesn't exist",).
Even type errors even of the form f([[..]]) rather than f([..]) are likely
to be in intricate bits of the system which are going to be bomb proof
tested as a core brick and hence less of a problem.
As I get more experience of deploying systems and more understanding of the
gotchas things are improving, but as an engineer I am always looking for
better tools. (Thank you again Joe and the guys!!)
> > Programming in dynamic languages does require a change in
> > development mindset; the compiler no longer catches some kinds of
This is also how I work. I haven't yet managed to wean our guy here out of
stopping and starting the system every time he makes a change (or even move
him from vi to Emacs)!!
One tool which would help in the "keep a node running and do
c(new_version)." development approach would be something which reported back
as info from the runtime if the newly loaded version addressed any undefined
external functions. Immediate feedback is the best kind (and it wouldn't add
any runtime overhead).
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
More information about the erlang-questions