8 ms·
There's a corollary with illiteracy but for mathematics, called innumeracy. Perhaps there's another for software, which is essentially a language of logic. It c
by jamesgreenleaf 6y ago
There's a corollary with illiteracy but for mathematics, called innumeracy. Perhaps there's another for software, which is essentially a language of logic. It could be called illogicity. You could make up your own term if you don't like that one.
Literature is not just spelling and grammar, and mathematics is not just numbers and equations. Likewise, software is not just code and computers. Each of these are ways of thinking, methods of communicating, realms to explore, and systems for organizing the world.
I would not be surprised if there are other systems like these which we have not yet discovered or invented. At least, I hope that there are.
- bob1029 6y agoI like this perspective. It also hints at a potential resolution - Pull the team away from the technology for a little while so they can focus on the abstract problem domain. Most developers probably don't have the capacity to think about shiny new technology while simultaneously running traps on the fundamental business domain abstractions. Taking time away from the computer to think about the problem you are actually trying to solve is a big deal. Many just get caught up fighting their own tools and lose sight. One simple trick - If you are not yet at a point where you can cleanly model your problem domain in terms of SQL tables & relations (even if you don't intend to use this technology), you have absolutely no business touching the rest of the effort. There are notions that you can actually have a provably-correct model of your domain at a certain level. 3NF/BCNF schemas have fundamental mathematical implications that are very powerful. Entire classes of accidental complexity can be obviated with a clean domain model.
- lifeisstillgood 6y agoYes. I think it is a Brooks quote that is something like "don't show me your code - I won't understand it, show me your database and I will understand your application." Simple robust Data structures with complicated code acting on it.
- thesuperbigfrog 6y ago"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious." -- Dr. Fred Brooks
- UncleMeat 6y agoI think it is easy to see programming as the language of logic. But this is what I've observed as my wife has learned to use python, javascript, and R for her work. The huge majority of errors have nothing to do with inability to think logically. Instead it is "I'm getting some incomprehensible fucking error message from conda" and it turns out the root cause is that her machine has multiple python installations and the places where dependencies end up installed are all fucked up and the solution has nothing to do with programming. The second most common source of errors are "weird language things". Something can be expressed perfectly reasonably if you were to read it as pseudo-code but weird edge cases cause problems. Consider "==" vs "===" in JS. All sorts of fun issues there and it isn't really failing to understand "the language of logic" that causes people to bash their heads into a wall until somebody says "oh, JS has multiple ways of doing equality and you just need to know that". The existing software ecosystems are nowhere near ready to support people who just want to think logically about problems and algorithms. It is just too filled with "wtf does PC_LOAD_LETTER mean".
- fossuser 6y agoYeah - I think there's lots of bad tooling, but a lot of it does come down to logic. Once people realize they're not doing something 'wrong' really and that it's just the tooling that's bad - they can start to understand that troubleshooting and debugging is most of what we're doing. Being good at troubleshooting and debugging is largely logic (isolating variables, testing, thinking about what it could be, knowing what to ask/search). It's why the dev joke of 'it works on my laptop' is funny. The narrow scope of solving some explicit programmatic problem is one area where logic is needed, but debugging things is the more common use. Lots of historical things people had to debug are past that tooling stage and now mostly 'just work' (like compilers). Lots of newer technology is not close to that yet. The analogy to literacy I think is a good one. I wrote a little about this here: https://zalberico.com/essay/2020/04/19/how-to-become-a-hacker.html https://zalberico.com/essay/2020/04/19/how-to-become-a-hacke...
- jamesgreenleaf 6y agoI can see what you're getting at here, and perhaps "language of logic" is not the most accurate way to describe what software is. Maybe "language of complexity" or "language of systems" or something else. Someone could come up with better terms or metaphors here. The difficulties you describe, however, assuming they aren't being caused by flaws or bugs, are part of the "language" we're talking about. I think one of your assumptions here is that logic is simple. That's true to begin with, but the software systems we build are usually towering arcologies of logic, with all manner of intricate, sometimes counter-intuitive details. A single detail, when examined by itself, is relatively easy to understand, but when taken together, they form a serious challenge for any human mind to grapple with. I think you could make comparisons to sprawling works of literature or advanced forms of mathematics, where the bits and pieces can be grasped, but the number of pieces, and the connections between them are often too difficult to see all at once.
- alcaide-mor 6y agoCould that word be computacy?