The world is full of tools for folks who write programs for a living. Lots and lots of tools.
The world has very few tools for folks who only program on occasion... and in my less than humble opinion this is why many people who ought to write their own programs don't even try to.
A program is simply the outcome when a set of requirements (something you want a computer to do) is translated into instructions that a computer can execute. Over the years, our expectations of what a computer should be able to do have vastly increased in complexity... Once we thought it was cool that we could "draw" faces with a computer. Now we expect the computer to recognize faces in a photograph.
The software that performs these functions is wildly complex, composed of millions of "lines of code"... and that's led most people to believe that all software has to be wildly complex and hard to write... but that's not the case. The "hard parts", and there are many "hard parts" can be packaged as "black boxes" with relatively straight forward "interfaces" to expose functionality for the occasional programmers to use. If the functionality of the "box" maps pretty closely to the requirements of what we want the computer to do, then it should be pretty easy for us to write a program.
This was the promise of Object Oriented Programming. Build a lot of black boxes with well defined interfaces and then put them together to create whatever program you need.
Great idea, but we got it wrong. We designed languages for building our black boxes, and then we convinced ourselves that we should use those same languages to connect our black boxes together to create useful programs. Bad mistake. Really, really bad mistake.
Using the same language for building boxes and for connecting boxes allowed the experienced programmers to pretty much ignore the way that the black boxes were supposed to be used. The "code" they wrote to put the boxes together was pretty much as unintelligible to the occasional programmers as the code that was used to build the boxes themselves. It all pretty much looks like Greek or Swahili to an occasional programmer (who can't read either Greek or Swahili).
Imagine the distress of the occasional programmer who has the gall to try to build something using the boxes created by a master programmer... To even read the master programmer's code the poor novice has to learn the intricacies of a dozen or so esoteric topics. It's like having to understand the ignition sequence of the cylinders in your car's engine before you can turn the key. No wonder they're terrible programmers.
It's time for a wakeup call in the world of programming... Our collective need for custom programs is growing at a much greater rate than our supply of master programmers. We can either continue to focus on tools for these master programmers - to make them even more productive - or we can figure out how to empower those occasional programmers to do it for themselves.
If we don't build tools that are targeted at the "occasional" audience, then nothing will change. Occasional programmers will continue to suck.
The world has very few tools for folks who only program on occasion... and in my less than humble opinion this is why many people who ought to write their own programs don't even try to.
A program is simply the outcome when a set of requirements (something you want a computer to do) is translated into instructions that a computer can execute. Over the years, our expectations of what a computer should be able to do have vastly increased in complexity... Once we thought it was cool that we could "draw" faces with a computer. Now we expect the computer to recognize faces in a photograph.
The software that performs these functions is wildly complex, composed of millions of "lines of code"... and that's led most people to believe that all software has to be wildly complex and hard to write... but that's not the case. The "hard parts", and there are many "hard parts" can be packaged as "black boxes" with relatively straight forward "interfaces" to expose functionality for the occasional programmers to use. If the functionality of the "box" maps pretty closely to the requirements of what we want the computer to do, then it should be pretty easy for us to write a program.
This was the promise of Object Oriented Programming. Build a lot of black boxes with well defined interfaces and then put them together to create whatever program you need.
Great idea, but we got it wrong. We designed languages for building our black boxes, and then we convinced ourselves that we should use those same languages to connect our black boxes together to create useful programs. Bad mistake. Really, really bad mistake.
Using the same language for building boxes and for connecting boxes allowed the experienced programmers to pretty much ignore the way that the black boxes were supposed to be used. The "code" they wrote to put the boxes together was pretty much as unintelligible to the occasional programmers as the code that was used to build the boxes themselves. It all pretty much looks like Greek or Swahili to an occasional programmer (who can't read either Greek or Swahili).
Imagine the distress of the occasional programmer who has the gall to try to build something using the boxes created by a master programmer... To even read the master programmer's code the poor novice has to learn the intricacies of a dozen or so esoteric topics. It's like having to understand the ignition sequence of the cylinders in your car's engine before you can turn the key. No wonder they're terrible programmers.
It's time for a wakeup call in the world of programming... Our collective need for custom programs is growing at a much greater rate than our supply of master programmers. We can either continue to focus on tools for these master programmers - to make them even more productive - or we can figure out how to empower those occasional programmers to do it for themselves.
If we don't build tools that are targeted at the "occasional" audience, then nothing will change. Occasional programmers will continue to suck.
