Python, Haskell and Safety

(Programming in Python is simpler than programming in Haskell. However, a Haskell-based Elastos IoT System would be better ..)

It is in the nature of Lambda-Functional languages that advanced warnings of pending Runtime problems are given, even at Compile time, something not possible in Python

Functional programming, as we have with Haskell, is less error-prone, due to an ability to enforce “strict typing” of data variables, and is generally safer in software-methodical ways – especially considering the physical situations the final compiled software may be controlling

There will be high-risk networks of Factory Machines, and much more

Our organisation is currently lobbying the Elastos Foundation to recognise this gap in the DApp development framework, and commit to preparing a Haskell (or other Functional-) Programming SDK to be used with IoT devices

As argued convincingly in these references: (1) and (2), the consequences of software failure could be catastrophic in an “Internet of Things” ie Engineering environment. A functional language such as Haskell is a much safer alternative to Python. It operates recurrently and repetitively such that “excursions” of the system after embedding will not occur, and will not need to occur. There would be no need to ‘patch’ Haskell-coded IoT devices due to security holes or other problems, as the Elastos System itself is completely safe, and a Haskell device is designed, coded, tested, fixed and deployed to be as much a predictable device with a permanent operating envelope, as any physical component. We have seen the effectiveness and efficiency of Haskell already in our own web servers, in a role not dissimilar to an IoT role, as far as the cyclical nature of their operation. This is not at all true of an IoT device with a Python based Runtime, where the software is not as hermeneutically sealed, still requiring patches, updates etc and being prone to the emergence of runtime errors as software is updated and inevitably ‘tinkered’ with. An extended discussion of these topics is available here.

These are, and will be, Real World considerations in Security, Safety, Medical, Pharmaceutical, Architectural, Electrical, Civil, Structural, Mechanical, Industrial/Manufacturing, Marine, Agricultural, Automotive, Aeronautical, Mining, Chemical and Environmental control and recording systems. The reliability of overall systems needs to be 100%. Therefore, this is the same standard as required of their software components – 100%. As so many thousands of Real Engineers know, “We cannot afford to have a ‘Blue Screen’ on the factory floor”. Python simply does not fit the bill in a risk-conscious world. Haskell delivers a closed and cyclic end product, ideally suited to the repetitive work performed in real world engineering systems by the IoT devices themselves as electrical sensors, switches and actuators.

We do not want any of the “Bridges” we build to “fall down” – EVER! They are not like the relatively tolerant and safe computer software/hardware systems in times of crisis. Murphy’s Law applies here. A server failure is one thing. A large building control system with door switches and locks could cause a lot of havoc in a crisis. It is not too hard to imagine even worse situations. An IoT system dysfunctioning is a dangerous prospect. This is serious, Mum!