Hacker News Reader

Comment by rocqua | Hacker News Reader

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.

View on HN

But "accelerating development" and "lowering complexity" are, if not synonymous, then at least highly correlated.

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.

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.

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.

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.

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.

> I think there are very few, if any, things in software development that have an analogue in that second category.

Sure, if you're positing that the average developer has a PhD in computer science, or software engineering.

But for the average software developer, gaining an understanding of the implementation details of their preferred programming language, or relational database, or browser HTML rendering engine, etc. (or any of a half dozen or so other systems or components they regularly use as black boxes), would in fact require a similar level of effort.

For any given X, an "X Developer" can mean a developer using X, or a developer of X. The latter is where the analogies lie.

Reply on news.ycombinator.com