In software engineering and related to Forth, there is a huge and not always appreciated gap going from programs which can be managed by a single individual to programs that need multiple programmers to develop. The already larger complexity of the program that requires many programmers is further compounded by the fact that none of the programmers comprehend the entire thing as well as a single programmer would, and therefore can’t do all the good design decisions that take the entire system into account that a single programmer would.
A Forth story from 1995 is about this. The author was massively productive developing in Forth through the 80s, but only as far as he was able to be the single principal developer of his aggressively whole system optimized programs. Once the 90s came, he realized he could no longer manage all the complexity contemporary software required, and decided that Forth wasn’t a viable option compared to languages that provided more fixed idiom for multiple developers.
I’m not sure if working memory, IQ and the end result in system complexity are quite aligned here. Just being able to fit more knowledge of the program in your head seems like it should help, even though your IQ stays the same (then the bottleneck becomes that a single programmer can type only so fast, so maybe a hyperbolic time chamber would help). IQ will let you discover compact designs that may subsume more laborious solutions, maybe there’s a single clever design that is a generalization of all the 17 special cases the programmer with the inferior design needs to implement by hand. (Or not. Some problems can be just plain complex. Sometimes the problem isn’t even in code, you necessarily need a Byzantine business logic program to model Byzantine legislation, but now the problem starts with the design of the law, not with the design of the program.) But high IQ can also help a programmer keep juggling all the complexity that emerges from a design that should have been strangled in the crib, when another programmer would have become overwhelmed faster and started looking for simpler ways to do the thing. High IQ can also create straight up signaling perversities with complexity, like how we use natural language with needlessly complicated grammar to gauge and signal intelligence.
When designing systems, the power of the abstractions you use limits the pool of programmers you can use who can work with those abstractions, and the amount of complexity you have, generally the less abstraction, the more complexity, brings you up against the hard limit of the system no longer fitting in any single individual’s head, after which you’ve got a complex in your hands and you’d better have a really clever idea of which joints in it to carve to keep the complexity from exploding into a ball of horror where semicommunicative subdevelopers duplicate each others’ effort.
I keep thinking that there should be a science of this.
In software engineering and related to Forth, there is a huge and not always appreciated gap going from programs which can be managed by a single individual to programs that need multiple programmers to develop. The already larger complexity of the program that requires many programmers is further compounded by the fact that none of the programmers comprehend the entire thing as well as a single programmer would, and therefore can’t do all the good design decisions that take the entire system into account that a single programmer would.
A Forth story from 1995 is about this. The author was massively productive developing in Forth through the 80s, but only as far as he was able to be the single principal developer of his aggressively whole system optimized programs. Once the 90s came, he realized he could no longer manage all the complexity contemporary software required, and decided that Forth wasn’t a viable option compared to languages that provided more fixed idiom for multiple developers.
I’m not sure if working memory, IQ and the end result in system complexity are quite aligned here. Just being able to fit more knowledge of the program in your head seems like it should help, even though your IQ stays the same (then the bottleneck becomes that a single programmer can type only so fast, so maybe a hyperbolic time chamber would help). IQ will let you discover compact designs that may subsume more laborious solutions, maybe there’s a single clever design that is a generalization of all the 17 special cases the programmer with the inferior design needs to implement by hand. (Or not. Some problems can be just plain complex. Sometimes the problem isn’t even in code, you necessarily need a Byzantine business logic program to model Byzantine legislation, but now the problem starts with the design of the law, not with the design of the program.) But high IQ can also help a programmer keep juggling all the complexity that emerges from a design that should have been strangled in the crib, when another programmer would have become overwhelmed faster and started looking for simpler ways to do the thing. High IQ can also create straight up signaling perversities with complexity, like how we use natural language with needlessly complicated grammar to gauge and signal intelligence.
When designing systems, the power of the abstractions you use limits the pool of programmers you can use who can work with those abstractions, and the amount of complexity you have, generally the less abstraction, the more complexity, brings you up against the hard limit of the system no longer fitting in any single individual’s head, after which you’ve got a complex in your hands and you’d better have a really clever idea of which joints in it to carve to keep the complexity from exploding into a ball of horror where semicommunicative subdevelopers duplicate each others’ effort.
I keep thinking that there should be a science of this.