4 ms·

This applies to machine-level C code and no high-level languages. Functional high-level languages prevent most of these out of the box, for example

sacado2 11y ago
This is far from true. > 1 Restrict to simple control flow constructs. Details give the precision : no recursion allowed. Functional languages are out, there. > 2 Give all loops a fixed upper-bound. Func languages give no warranty on that either. > 3 Do not use dynamic memory allocation after initialization. You have no access to memory layout, but func languages heavily rely on the creation on-the-fly of data and rely on garbage collection (which is forbidden, too). > 4 Limit functions to no more than 60 lines of text. > 5 Use minimally two assertions per function on average. > 6 Declare data objects at the smallest possible level of scope. > 7 Check the return value of non-void functions, and check the validity of function parameters. OK, that might be easier with func languages. > 8 Limit the use of the preprocessor to file inclusion and simple macros. Not relevant > 9 Limit the use of pointers. Use no more than two levels of dereferencing per expression. OK, no pointer manipulation with these languages. > 10 Compile with all warnings enabled, and use one or more source code analyzers. Name one professional code analyzer for any func language of your choice.
- lectrick 11y ago
  > Details give the precision : no recursion allowed. Functional languages are out, there. > Func languages give no warranty on that either. Actually, what you can do in this case is when you call recursively, pass back an incremented counter variable as part of the state, and if it passes some upper limit, handle it appropriately. You don't need to "avoid recursion" just to get control over the number of times something loops. > and rely on garbage collection (which is forbidden, too) Fair enough, but if I work in a language that doesn't even give me much control (if any) over the GC, then how is this relevant to non-C coders, again? Which was my original point. > Name one professional code analyzer for any func language of your choice. Erlang (and by association Elixir) has Dialyzer http://www.erlang.org/doc/man/dialyzer.html http://www.erlang.org/doc/man/dialyzer.html which is a static code analyzer. Static code analysis has been endorsed by John Carmack (and of course, all the 3 year old links to the blog post are now dead, sigh) For anyone (like me) who is hooked on Elixir, https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir provides a bit of easier Dialyzer management Elixir (and I suppose Erlang) has this concept of "specs" which you don't have to use, but which help code analysis if you do... http://elixir-lang.org/docs/v1.0/elixir/Kernel.Typespec.html http://elixir-lang.org/docs/v1.0/elixir/Kernel.Typespec.html
  - sacado2 11y ago
    > Fair enough, but if I work in a language that doesn't even give me much control (if any) over the GC, then how is this relevant to non-C coders, again? Which was my original point. This is relevant to users of assembly, forth, C++, Fortran, Ada, Rust and probably a few others. Beside the very last one (which is way too young), these are the languages embedded developers used most of the time, precisely because of their virtues regarding the 10 points in the original post. I have to agree with you, though, regarding this list functional languages are probably as good as, or even better than most other high-level languages, but they clearly fail on most requirements. Thanks for the reference about Dialyzer, I'll check it out.
TickleSteve 11y ago
only if your VM and/or runtime is itself accredited. Personally I can't remember coming across any Java/Lua/Python/Lisp/Haskell/etc VM's that have been, they're too complex and dynamic. you don't want dynamically-generated code controlling your x-ray machine...
- lectrick 11y ago
  > you don't want dynamically-generated code controlling your x-ray machine... I don't see how it follows that you can't have a functional language controlling an x-ray machine. You can make an appeal to complexity, I suppose, but this can be managed. If Erlang is used to create a 99.999999999% reliable cellphone infrastructure (http://stackoverflow.com/questions/8426897/erlangs-99-9999999-nine-nines-reliability http://stackoverflow.com/questions/8426897/erlangs-99-999999...), I believe it can handle medical device functions :P I mean seriously, at that level of reliability, even if you have a health-critical device with literally just 10 assembly instructions, a cosmic ray could still flip a bit (http://status.aws.amazon.com/s3-20080720.html http://status.aws.amazon.com/s3-20080720.html) and cause a catastrophe! And as far as Java (which I'm not necessarily a fan of, I'm just making a counterargument) and medical devices, look here: http://www.oracle.com/us/technologies/embedded/embedded-java-for-healthcare-433550.pdf http://www.oracle.com/us/technologies/embedded/embedded-java...
  - humanrebar 11y ago
    > You can make an appeal to complexity, I suppose, but this can be managed. If Erlang is used to create a 99.999999999% reliable cellphone infrastructure (http://stackoverflow.com/questions/8426897/erlangs-99-999999... http://stackoverflow.com/questions/8426897/erlangs-99-999999...), I believe it can handle medical device functions :P Imagine you gave someone cancer every time a call was dropped. Even 0.00001% is a big risk, depending on what you're doing. You also want something that reliable out of the gate, not after years of beta testing. > even if you have a health-critical device with literally just 10 assembly instructions, a cosmic ray could still flip a bit (http://status.aws.amazon.com/s3-20080720.html http://status.aws.amazon.com/s3-20080720.html) and cause a catastrophe! Sure. That's why there are dead-man switches, watchdogs, heartbeats, acks, checksums, etc. in the majority of ('all' is a strong word) safety critical software. If random corrupt data gets written to the wrong location, the consuming subsystem (hardware or software) should do the safest thing possible.

sacado2 11y ago

This is far from true. > 1 Restrict to simple control flow constructs. Details give the precision : no recursion allowed. Functional languages are out, there. > 2 Give all loops a fixed upper-bound. Func languages give no warranty on that either. > 3 Do not use dynamic memory allocation after initialization. You have no access to memory layout, but func languages heavily rely on the creation on-the-fly of data and rely on garbage collection (which is forbidden, too). > 4 Limit functions to no more than 60 lines of text. > 5 Use minimally two assertions per function on average. > 6 Declare data objects at the smallest possible level of scope. > 7 Check the return value of non-void functions, and check the validity of function parameters. OK, that might be easier with func languages. > 8 Limit the use of the preprocessor to file inclusion and simple macros. Not relevant > 9 Limit the use of pointers. Use no more than two levels of dereferencing per expression. OK, no pointer manipulation with these languages. > 10 Compile with all warnings enabled, and use one or more source code analyzers. Name one professional code analyzer for any func language of your choice.

lectrick 11y ago
> Details give the precision : no recursion allowed. Functional languages are out, there. > Func languages give no warranty on that either. Actually, what you can do in this case is when you call recursively, pass back an incremented counter variable as part of the state, and if it passes some upper limit, handle it appropriately. You don't need to "avoid recursion" just to get control over the number of times something loops. > and rely on garbage collection (which is forbidden, too) Fair enough, but if I work in a language that doesn't even give me much control (if any) over the GC, then how is this relevant to non-C coders, again? Which was my original point. > Name one professional code analyzer for any func language of your choice. Erlang (and by association Elixir) has Dialyzer http://www.erlang.org/doc/man/dialyzer.html http://www.erlang.org/doc/man/dialyzer.html which is a static code analyzer. Static code analysis has been endorsed by John Carmack (and of course, all the 3 year old links to the blog post are now dead, sigh) For anyone (like me) who is hooked on Elixir, https://github.com/jeremyjh/dialyxir https://github.com/jeremyjh/dialyxir provides a bit of easier Dialyzer management Elixir (and I suppose Erlang) has this concept of "specs" which you don't have to use, but which help code analysis if you do... http://elixir-lang.org/docs/v1.0/elixir/Kernel.Typespec.html http://elixir-lang.org/docs/v1.0/elixir/Kernel.Typespec.html
- sacado2 11y ago
  > Fair enough, but if I work in a language that doesn't even give me much control (if any) over the GC, then how is this relevant to non-C coders, again? Which was my original point. This is relevant to users of assembly, forth, C++, Fortran, Ada, Rust and probably a few others. Beside the very last one (which is way too young), these are the languages embedded developers used most of the time, precisely because of their virtues regarding the 10 points in the original post. I have to agree with you, though, regarding this list functional languages are probably as good as, or even better than most other high-level languages, but they clearly fail on most requirements. Thanks for the reference about Dialyzer, I'll check it out.

TickleSteve 11y ago

only if your VM and/or runtime is itself accredited. Personally I can't remember coming across any Java/Lua/Python/Lisp/Haskell/etc VM's that have been, they're too complex and dynamic. you don't want dynamically-generated code controlling your x-ray machine...

lectrick 11y ago
> you don't want dynamically-generated code controlling your x-ray machine... I don't see how it follows that you can't have a functional language controlling an x-ray machine. You can make an appeal to complexity, I suppose, but this can be managed. If Erlang is used to create a 99.999999999% reliable cellphone infrastructure (http://stackoverflow.com/questions/8426897/erlangs-99-9999999-nine-nines-reliability http://stackoverflow.com/questions/8426897/erlangs-99-999999...), I believe it can handle medical device functions :P I mean seriously, at that level of reliability, even if you have a health-critical device with literally just 10 assembly instructions, a cosmic ray could still flip a bit (http://status.aws.amazon.com/s3-20080720.html http://status.aws.amazon.com/s3-20080720.html) and cause a catastrophe! And as far as Java (which I'm not necessarily a fan of, I'm just making a counterargument) and medical devices, look here: http://www.oracle.com/us/technologies/embedded/embedded-java-for-healthcare-433550.pdf http://www.oracle.com/us/technologies/embedded/embedded-java...
- humanrebar 11y ago
  > You can make an appeal to complexity, I suppose, but this can be managed. If Erlang is used to create a 99.999999999% reliable cellphone infrastructure (http://stackoverflow.com/questions/8426897/erlangs-99-999999... http://stackoverflow.com/questions/8426897/erlangs-99-999999...), I believe it can handle medical device functions :P Imagine you gave someone cancer every time a call was dropped. Even 0.00001% is a big risk, depending on what you're doing. You also want something that reliable out of the gate, not after years of beta testing. > even if you have a health-critical device with literally just 10 assembly instructions, a cosmic ray could still flip a bit (http://status.aws.amazon.com/s3-20080720.html http://status.aws.amazon.com/s3-20080720.html) and cause a catastrophe! Sure. That's why there are dead-man switches, watchdogs, heartbeats, acks, checksums, etc. in the majority of ('all' is a strong word) safety critical software. If random corrupt data gets written to the wrong location, the consuming subsystem (hardware or software) should do the safest thing possible.