1. 5
  1.  

  2. 2

    This problem is unavoidable, no? In fact, we have the tools to avoid it, and it we still run into it. The tools to avoid it being formal logics (programming languages are formal logics for example). The reason why it’s still a problem even with formal logics is that in order to be fully formal, they need to be described in painful detail. Humans have a hard time coping with that level of detail, so we have trouble interpreting statements in the logic unambiguously, without tracing through all of the rules manually.

    Until we can connect our brains together with wires and exchange ideas directly, we have to have a language for describing concepts. What’s the way to avoid that?

    1. 1

      The way to avoid that is to limit the use of formal logic to very narrow contexts in order to produce composable applications. It’s that scoping of provable code to narrow contexts that we don’t make happen.

      Agreed that it’s very painful to do an entire application like that. That’s why we shouldn’t do it that way, not abandon the concept altogether because of our scoping problems.

      1. 1

        So you’re saying that formal logic is the root of the issue? Or that formal logic is the solution, but it’s too difficult to apply everywhere?

        1. 1

          Neither. Formal logic is the answer, but only in limited cases with specific boundaries. The boundaries are not there because it’s too difficult. They’re there for intelligence-language-logic reasons that don’t involve just one of those areas

      2. 1

        In fact, we have the tools to avoid it, and it we still run into it

        The tools need to be accessible to the people who understand the domain.

        Until we can connect our brains together with wires and exchange ideas directly, we have to have a language for describing concepts. What’s the way to avoid that?

        IMO, we need better tools for using the languages that we are already constructing.

        That is - we already construct a shared language (when we talk to domain experts). We then attempt to translate our understanding of that language into code - but our understanding is frequently incomplete or wrong.

        There is some work on this kind of toolkit - eg the ActiveFacts project.

        From this example text, ActiveFacts can generate

        • A normalized OLTP SQL schema
        • A denormalized data warehouse schema
        • The ETL code to move OLTP data into the warehouse
        • Classes to store / validate in-memory representations of the data

        Currently, only the ruby in-memory representation is open-sourced, and there’s no automatic save/load between the in-memory representation and the database.

        1. 1

          I think it’s a mistake to think that non-programmers will ever write or interact with code. I think programmers should continue to firmly exist as interpreters of code. It’s way too specialized of a skill.

          But I do think that programmers should have a toolkit that can express concepts at the level of the domain. This is actually the basis of my main side project - a specification language for building model-based test suites.

          What you showed is fairly close to that (the specification language that is), though it looks like it’s only describing a static data model. Can it describe system behavior?

          1. 1

            I think it’s a mistake to think that non-programmers will ever write or interact with code.

            Write, yes. Interact? I haven’t given up that dream just yet. The language I linked to specifically aims at non-programmers being able to identify model errors.

            only describing a static data model. Can it describe system behavior?

            IIRC, it can describe ‘relaxed’ constraints (eg something like Doctor prescribes Medication to Patient where Patient is not Doctor, otherwise report to medical board), but not any behavior associated with what “report to medical board” entails.

            Some early work has been done on integrating it with Alloy to model state transitions, and it looks likely to work but I don’t think it’s a current focus.

      3. 2

        I don’t see siloing as a problem with real-world programming specifically. Rather, it’s a problem with real-world organizations in general, and programmers are no more immune to it than anyone else. Go to, say, the customer support organization at any big company, even one that develops no software at all, and you’ll find plenty of people who have no clue that the sales department is about to do something that will have a big impact on support.

        I think this matters because it suggests the problem can’t be fully solved by, say, switching to a different development methodology.

        1. 1

          I agree.

          At the risk of being over-the-top, I think that by defining software development as different than business operations you have created the exact silo referred to in the essay.

        2. 1

          We don’t have to have named variables.

          Every business is its own silo. Part of your complaint is inherently rooted in how corporations behave; if they were upstanding members of a Free Software commons, then code reuse would be much easier.

          1. 1

            Every business is not its own silo. Silos are specialties not related to businesses. In fact, if every business was a silo, there would not be a problem.

            Also, it is awesome that you see that variable names are not needed. The issue becomes how to solve real-world business problems in such a way that this can be accomplished

            1. 3

              Tacit programming is part of the real world. OpenFirmware, jq, UNIX shells, railroad diagrams, and more; there are so many examples. It sounds like you’re describing a social issue: how do we lead professional programmers out of the Turing tarpits?