Programmer Productivity Pumped Post Picture-Picking Paradigm?
Mitch Barnett responds to \<a href="http://www.knowing.net/PermaLink%2cguid%2cfde0f610-3773-47b8-9be6-d6e5a8a76858.aspx"" target="_blank" rel="noopener noreferrer">No Silver Programmers with a discussion of visual programming in BizTalk:
[Y]ou drag n dropped onto the canvas (kinda like Visio) and then you would set a bunch of design time properties and sometimes call out to some C# assemblies, or web services or adapters, but most often it was a matter of using the design surface, which included a designer for mapping one file format to another and a rules engine design surface, etc.
If you thought of the designers as "raising the level of abstraction" or a visual Domain Specific Language, in a lot of cases, not much real C# code was written ? you spent most of your time in this abstract kind of world. Point being, when I was hiring programmers, like in the traditional sense of yeah, I can write lots of C#, I found that some programmers found using the designers, very easy and others, just could not get their heads wrapped around, to the point, that they could not actually do the job ? period.
Meaning that in this specialized instance, I found programmer productivity was totally dependant on how well your head dealt with abstractions and not traditional programming constructs ? to the point where some of my guys could whip out a BizTalk solution in a matter of days, others maybe a week or so and others, never.
Just to be a skeptic, I'm not sure that there's just 1 thing (raising the abstraction level) going on when you're developing on a design surface. You're engaging the visual and spatial and pattern-recognition components of a your mind in a way that, perhaps, leads to different problem-solving skills (whether inherent or learned). I dunno'. The interesting thing would be to study the problem-solving ability of developers using a visual design surface with an equivalently high-level abstraction that used a text representation (block_1 = new Foo; block_2 = new Bar; block_1.outputPlug1 -> block_2.inputPlug1; etc...)
A related point, and an important one, is that different languages "engage" your mind in different ways and part of the joy of being a computer programmer is finding a good match (or better yet, good matches) for your particular wiring. Personally, I quite like pictures in some development tasks, but have never found a visual design surface that actually delivered a high-enough level of abstraction (in terms of "things you can do with code," i.e., meta-programming, reflection, code generation).