4 ms·

One of my takeaways: When I see "stitch together black boxes," to me that says that aspects of academic math are becoming similar to opportunistic software deve

One of my takeaways: When I see "stitch together black boxes," to me that says that aspects of academic math are becoming similar to opportunistic software development. When such an effect happens in group psychology it is typically part of the "grounding" effect happening. There is a high supply of theory without the energy to go into analyzing so many individual black boxes anymore, and a correspondingly high demand arises for integrative applications which bring the high-minded ideas down to more fundamental, widely-scoped, or practical effect. Down to earth, so to speak. Some would think of this as an economic-benefit effect. The point is, it tends to bring all those stitched-together black boxes much closer to the end user space, where application is key, not so much theory. So I wonder if in the coming years we will see a dramatic closing of the gap between direct access to mathematics inputs and daily living. It may be that the typical non-math-minded individual will soon readily and happily bootstrap themselves into the language of mathematics via the closing in of a perception of direct competitive or economic value. To share an example, in 2003 I started to use a node-based editor to edit 3D textures for graphics projects. This node-based tool gave more control than standard sliders, color pickers, and checkboxes. But soon I discovered that in a lot of cases it was easier to enter a math formula in a node than to chain nodes together. Maybe a single checkbox designated whether the function was periodic, but other than that, enter math here, please. Your mathematical wish is our graphics-producing command. So I wonder if we'll soon get to the point where formulaic systems control with direct mathematic input will be more desirable and common in unified system interfaces that are found in office and household work. Let's say you want to write the perfect formula for a given air quality factor in your office... Or your competitive game which allows you to program AIs is made much more efficient if you can tweak formulae by hand... Or you need to design a new form of printed steak, but simple toggles and switches just won't do... (Then...when the time is right for the black-box theory end to pick up a lot of momentum again, imagine how large a pool of new mathematicians will be ready...)

rocqua 5y ago
I think the reason for this black-boxing in software and mathematics is quite different. In top-level mathematics its that you have no choice but to treat results as black-boxes because the complexity otherwise is just too high. Its the only way forward, and mathematicians would prefer not to take this approach. In software development, black-boxing is a way of accelerating development. It allows people to abstract away and disregard complexities. And it allows re-using big works. It comes at the cost of some integration losses and performance losses. But, since they are not at the complexity limit, software developers can dive into their black boxes if required for performance or other reasons.
- webmaven 5y ago
  But "accelerating development" and "lowering complexity" are, if not synonymous, then at least highly correlated.
  - rocqua 5y ago
    The difference is in why. Mathematicians do it out of necessity because they are at the edge of complexity they can handle. Developers do it because it is convenient. Developers have a choice.
    - webmaven 5y ago
      I think you may be underestimating how much "because they are at the edge of complexity they can handle" is a driver of mainstream SE. In particular, as a factor in the popularity of frameworks and libraries. I'm not taking a stance like "if it was hard to write it should be hard to use", but quite a lot of software only seems to exist in order to hide complexity away in black boxes, often in trivial ways.
      - rocqua 5y ago
        Any software dev worth their salt can drop down 1 level in the stack and be productive, if maybe less so. I'd wager most software devs could drop down 2 levels and fully grok everything that is happening.
        webmaven 5y ago
        There is a difference between a Python web developer dropping one level down to examine and debug the SQL the ORM is producing, and dropping one level down to examine and debug a performance problem in the CPython implementation.
  - joppy 5y ago
    In research maths, there are some results you use as a black box because even though you could re-derive the result, it’s just a ton of work and you’re glad someone else has done it. For example perhaps it involves some very tedious case-by-case checking, or a large and long inductive argument. Then there are some results you use as a black box because it would take you (in this case you already have a PhD in the field, so let’s say at least 8 years of field-specific education) literally years of full-time study to become familiar enough with the underpinning technology to even follow the statement of the proof, let alone deeply understand it yourself. I think there are very few, if any, things in software development that have an analogue in that second category.

rocqua 5y ago

I think the reason for this black-boxing in software and mathematics is quite different. In top-level mathematics its that you have no choice but to treat results as black-boxes because the complexity otherwise is just too high. Its the only way forward, and mathematicians would prefer not to take this approach. In software development, black-boxing is a way of accelerating development. It allows people to abstract away and disregard complexities. And it allows re-using big works. It comes at the cost of some integration losses and performance losses. But, since they are not at the complexity limit, software developers can dive into their black boxes if required for performance or other reasons.

webmaven 5y ago
But "accelerating development" and "lowering complexity" are, if not synonymous, then at least highly correlated.
- rocqua 5y ago
  The difference is in why. Mathematicians do it out of necessity because they are at the edge of complexity they can handle. Developers do it because it is convenient. Developers have a choice.
  - webmaven 5y ago
    I think you may be underestimating how much "because they are at the edge of complexity they can handle" is a driver of mainstream SE. In particular, as a factor in the popularity of frameworks and libraries. I'm not taking a stance like "if it was hard to write it should be hard to use", but quite a lot of software only seems to exist in order to hide complexity away in black boxes, often in trivial ways.
    - rocqua 5y ago
      Any software dev worth their salt can drop down 1 level in the stack and be productive, if maybe less so. I'd wager most software devs could drop down 2 levels and fully grok everything that is happening.
      - webmaven 5y ago
        There is a difference between a Python web developer dropping one level down to examine and debug the SQL the ORM is producing, and dropping one level down to examine and debug a performance problem in the CPython implementation.
- joppy 5y ago
  In research maths, there are some results you use as a black box because even though you could re-derive the result, it’s just a ton of work and you’re glad someone else has done it. For example perhaps it involves some very tedious case-by-case checking, or a large and long inductive argument. Then there are some results you use as a black box because it would take you (in this case you already have a PhD in the field, so let’s say at least 8 years of field-specific education) literally years of full-time study to become familiar enough with the underpinning technology to even follow the statement of the proof, let alone deeply understand it yourself. I think there are very few, if any, things in software development that have an analogue in that second category.