5 ms·

I'm one of the leads who worked with Donevan on this project. Feel free to ask me any questions and I'll answer as best I can.

• agounaris 10y ago
  I'm interested in the underlying platform and how the software is being shipped? Do you need to go through a specific process in order to install a new version or a bug fix?
  • clem 10y ago
    Anything in a regulated industry such as aerospace tends towards the process heavy. Our requirements get tracked in our QMS system that ensures we're AS9100-compliant. There's a final test-for-credit step after which the software part should be considered hermetically sealed. Any software change requires a new test-for-credit round that likely takes an extensive amount of time. So, in short, developing for aerospace is not agile. :-) It's the Niagara Falls of waterfall methods.
    • paulydavis 10y ago
      I work at BAE and we do quite a bit of software for Boeing. DO178 C could allow you to do Agile if the PSAC was set up from the beginning for that. The problem would be the cost points and contracts and customer buy in that would be needed on all sides. But alas for now it is the mother of all Waterfall methods.
      • dolbydc 10y ago
        We developed OMF using agile scrum, not waterfall, but we ultimately were running our agile process within a waterfall
• dantiberian 10y ago
  On the video it sounded like it was 16,000 lines of code. Was that the amount or did I mishear it? That was claimed as one of the largest Clojure codebases, which seems unlikely.
  • 147 10y ago
    That's what I heard in person
  • clem 10y ago
    That's correct. As for size relative to other projects, we came to that conclusion by combing large GitHub clojure projects and comparing non-blank lines. For instance, LightTable comes in at around 12,000 lines. Clojure is a darn terse language. Of course, there may be private repositories which are larger (thus the weasel words "one of"). Corrections welcome. :-)
    • dantiberian 10y ago
      From memory, CircleCI have around 100k LOC. Nonetheless, it's very cool getting Clojure on a plane.
      • clem 10y ago
        Thanks. Found a reference to the CircleCI code base: http://www.ccs.neu.edu/home/samth/typed-clojure-draft.pdf http://www.ccs.neu.edu/home/samth/typed-clojure-draft.pdf I wonder how their move away from clojure.typed has impacted code size.
  • dolbydc 10y ago
    I was made aware of a private Clojure project that is comprised of over 30k lines. So we aren't the largest, but probably the first to be on a commercial aircraft. But as Tim pointed out auditing of open source projects had most far smaller than 16k. Lamina a very feature rich library I think was on the order of 6k. Perhaps I should have gone with "Clojure on planes" as my title.
    • clem 10y ago
      Or "States On A Plane" with a photo of Samuel L. Jackson. :-)
  • aaron-santos 10y ago
• hcrisp 10y ago
  It's not widely known but Python supports a certain amount of functional-programming idioms. It also supports event-driven data flow. Was it considered at the beginning of the project? (was it even one of the languages Boeing supports?) Why would or why would it not be a good choice for this health monitoring application?
  • yogthos 10y ago
    The big difference between Python and modern functional languages is that Python defaults to mutability. Clojure is immutable by default, and that makes it much easier to reason about code in isolation. When you're working on a large project, it's really valuable to be able to make a change in one place and know that you're not affecting something in another. When things are passed around by reference, it becomes very difficult to guarantee the scope of any change. Even when using immutable data structure libraries in a mutable by default language doesn't really give you many guarantees. As soon as somebody puts a mutable object into your immutable data structure all bets are off. So, you really want a language that defaults to immutability and has different semantics for working with mutable data.
• neurotech1 10y ago
  Does Boeing have a policy on using and defining acronyms? Interesting presentation, although I noticed Donevan used a few acronyms that some people may not be familiar with.
  • dolbydc 10y ago
    Not sure if there is a policy. Are there acronyms in particular, I tried to limit it to the couple applications we interface with. Which truth be told I don't know off the top of my head what they stand for. More importantly is what the application does. I worked at Boeing for 6 years and people talk in acronyms most the time not knowing what it stands for, just what the system does.
• namelezz 10y ago
  Why Clojure and not Scala?
  • mateuszf 10y ago
    I'd pick Clojure between the two because simplicity.
• noir_lord 10y ago
  In the video he mentions that libraries went EOL during development, given the the predicted lifespans of modern airliners how do you plan on been able to build the software a decade from now?
  • dolbydc 10y ago
    If needed we or Boeing would take over the lamina library, or migrate to an alternative like core.async or manifold.