3 ms·

> Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault toler

> Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying. (I generally agree with the gist of your comment, I think. This just stuck out.) I don't believe Clojure belongs in that class (as "proven" for writing reliable software), but whatever. If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use. Several (if not all) the Mars landers were programmed in C -- with very few critical flaws experienced/discovered[2]. The Ericsson switches that achieved previously-unheard-of reliability were programmed in Erlang, but they used process and a huge number of engineers to achieve that. (Plus they're mostly stateless and so can just reset if they do it fast enough and don't lose important state when doing so.) For large-scale software which has to evolve fast, I belive strong type systems do win out. It's not so much that they prevent bugs which could be caught by test suites, but having a strong type system means that you can be certain that there are a lot of tests that you actually will never have to write or, more importantly, rewrite as the system evolves. There have been actual studies which may be of interest[1], but even if I'm on the "winning" side, I don't think I would put too much stock in the methodology/analysis of this particular study. (E.g. concluding that JavaScript suffers from few concurrency bugs relative to other languages is kind of being oblivious of the fact that JS is single-threaded (semantically) and that all the other languages in the comparison permit "real" concurrency/parallellism, and that it should thus perhaps be excluded from the category or at least treated separately.) [1] http://macbeth.cs.ucdavis.edu/lang_study.pdf http://macbeth.cs.ucdavis.edu/lang_study.pdf [2] https://www.usenix.org/conference/hotdep12/workshop-program/presentation/holzmann https://www.usenix.org/conference/hotdep12/workshop-program/... (Sorry, references out of order because edited-post-facto)

sheepmullet 12y ago
In the study you linked to Clojure code is basically as bug free as Haskell and Scala code and Erlang code isn't far behind.
- lomnakkus 12y ago
  As I recall they conclude that the general stats show that "static-functional" is more bug-free than "dynamic-functional" which is more bug-free than "static-procedural/dynamic-procedural", which is more bug-free than... As I said, I'm not sure I buy into the whole design/classification/statistical scheme of the study myself, so YMMV.
mietek 12y ago
> If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use. I also generally agree with your comment, but I have to take issue with this statement. If this were true, Ericsson wouldn’t have had to abandon the AXE-N project. Quoting from Joe Armstrong’s PhD thesis[1]: “1995: The AXE-N project was a project to build a “next generation switch” to replace the Ericsson AXE-10. This extremely large project ran from 1987-95. After the AXE-N project collapsed a decision was made to “restart” the project using Erlang. This project eventually resulted in the development of the AXD301 switch.” “During the period 1996–1997 a three-person group (myself, Magnus Fröberg and Martin Björklund) redesigned and implemented the OTP core libraries.” “1998: Ericsson delivered the first AXD301. The AXD301 is the subject of one of our case studies in Chapter 8. At the time of writing (2003) the AXD301 has over 1.7 million lines of Erlang code which probably makes it the largest system ever to be written in a functional style of programming.” [1]: http://www.erlang.org/download/armstrong_thesis_2003.pdf http://www.erlang.org/download/armstrong_thesis_2003.pdf
- lomnakkus 12y ago
  Thanks for digging out the history. I don't think we can conclude from your excerpts that the deciding factor was Erlang. However, I accept that my statement that it was "just engineers and process" may have been exaggerated or mistaken.
  - mietek 12y ago
    The deciding factor, as always, is the ability to manage complexity. There are many ways to improve this ability, and process is certainly one of them, however, the choice of programming language is, to my mind, the most important one. XenSource/Citrix is another great example[1]: “In 2002, members of Cambridge University released the open source Xen project to provide free high-performance virtualization technology for the masses.” “In 2004, the team founded the company XenSource and began developing the enterprise-level distributed management software that would make virtualization easy and form the backbone of their products in the years to come. A team of thirty dedicated programmers in Palo Alto California began developing the software in C, Python and Ruby.” “Two years later, the US team had succeeded in burning tens of millions of dollars funding but had failed to produce any product. So XenSource, under new management, took the bold step of replacing their large team of US developers with a team of only four British OCaml developers. Within months, all of the Python and Ruby was replaced, both reliability and performance were dramatically improved and the company shipped their first product. One year later, XenSource sold to Citrix for $500M.” [1]: http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides-about-growth-of-ocaml.html http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides-abou...

sheepmullet 12y ago

In the study you linked to Clojure code is basically as bug free as Haskell and Scala code and Erlang code isn't far behind.

lomnakkus 12y ago
As I recall they conclude that the general stats show that "static-functional" is more bug-free than "dynamic-functional" which is more bug-free than "static-procedural/dynamic-procedural", which is more bug-free than... As I said, I'm not sure I buy into the whole design/classification/statistical scheme of the study myself, so YMMV.

mietek 12y ago

> If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use. I also generally agree with your comment, but I have to take issue with this statement. If this were true, Ericsson wouldn’t have had to abandon the AXE-N project. Quoting from Joe Armstrong’s PhD thesis[1]: “1995: The AXE-N project was a project to build a “next generation switch” to replace the Ericsson AXE-10. This extremely large project ran from 1987-95. After the AXE-N project collapsed a decision was made to “restart” the project using Erlang. This project eventually resulted in the development of the AXD301 switch.” “During the period 1996–1997 a three-person group (myself, Magnus Fröberg and Martin Björklund) redesigned and implemented the OTP core libraries.” “1998: Ericsson delivered the first AXD301. The AXD301 is the subject of one of our case studies in Chapter 8. At the time of writing (2003) the AXD301 has over 1.7 million lines of Erlang code which probably makes it the largest system ever to be written in a functional style of programming.” [1]: http://www.erlang.org/download/armstrong_thesis_2003.pdf http://www.erlang.org/download/armstrong_thesis_2003.pdf

lomnakkus 12y ago
Thanks for digging out the history. I don't think we can conclude from your excerpts that the deciding factor was Erlang. However, I accept that my statement that it was "just engineers and process" may have been exaggerated or mistaken.
- mietek 12y ago
  The deciding factor, as always, is the ability to manage complexity. There are many ways to improve this ability, and process is certainly one of them, however, the choice of programming language is, to my mind, the most important one. XenSource/Citrix is another great example[1]: “In 2002, members of Cambridge University released the open source Xen project to provide free high-performance virtualization technology for the masses.” “In 2004, the team founded the company XenSource and began developing the enterprise-level distributed management software that would make virtualization easy and form the backbone of their products in the years to come. A team of thirty dedicated programmers in Palo Alto California began developing the software in C, Python and Ruby.” “Two years later, the US team had succeeded in burning tens of millions of dollars funding but had failed to produce any product. So XenSource, under new management, took the bold step of replacing their large team of US developers with a team of only four British OCaml developers. Within months, all of the Python and Ruby was replaced, both reliability and performance were dramatically improved and the company shipped their first product. One year later, XenSource sold to Citrix for $500M.” [1]: http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides-about-growth-of-ocaml.html http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides-abou...