AxImp can't import COM/ActiveX controls with type libraries that use importlib

It's late.


I'm tired.


Wanted to rant.


AxImp really stinks when it comes to handling type libraries that use importlib (ok, typelibraries built from IDL that uses importlib).


The workaround is so pained, so contorted that it deserves a blog entry.  More on that later.  Nothing like having to write a program whose sole purpose is masking the error returned due to a bug in another program.  The buggy program is aximp.  Masking the error allows the visual studio 2005 prebuild event to not fail.  Ugh.

Visual programming

While talking with a colleague the topic of visual programming came up (ala Simulink).  I'm a fan of anything that improves programmer productivity since increased productivity translates, over the long haul, into increased wealth and all other things being equal increased wealth is nice.


My gut reaction was that while some kinds of visual programming are great boons for productivity (e.g., a forms designer) directly translating loops, conditionals and function calls into graphical widgets won't yield much bang for the buck.  This is also why I'm skeptical of Windows Workflow Foundation.


For starters, no matter what language a program is implemented in, the underlying process - identifying and acquiring inputs, processing/algorithms and producing the desired output are steps that need to be done.  And it takes a certain kind of mindset to even be interested in precisely determining/designing these steps.  Translating the loops, conditionals and function calls into graphical widgets doesn't remove the need to do this kind of design.  So you're still targeting the same sort of people that enjoy the process of solving problems with algorithms/procedures in software.


If visual programming doesn't change the pool of people that can productively write complex software perhaps it makes it easier for people to understand what a program does.  This would be valuable and might even be worth a slight decrease in the productivity of people creating software.  But is this the case?  Depending on the graphical widgets used replacing text statements can actually decrease the information density of a given area of screen space.  A conditional in text takes a line or 2 but a graphical if statement, with separate lines connecting each of the possible branches might take up half the screen.  More importantly, at this low a level there isn't any increase in understanding derived from looking at a condition graphically.  If statements operate on very low level state (booleans in fact).  It takes a lot of booleans to construct something useful; graphically this would just take up a lot more space, take longer to navigate when tracing through, and yields no simpler a program than one implemented in text.


I believe the attraction of visual programming for general purpose programs stems from erroneously overapplying a technique that, because general purpose programs involve so much low level detail, is inappropriate.  Flowcharts are great for high level design, even good for middle level design but because the instructions that computers understand are so primitive it takes a lot of them to accomplish meaningful tasks.  A flowchart's benefit is in abstracting away the details but a big part of programming is explicitly handling the details.  A flowchart with a thousand symbols and several thousand arrows is no easier to understand or construct than thousands of lines of code separated into functions; each of these is what is required to get computers to do useful work.  I don't believe the former is a serious competitor to the latter.


Another way to look at it is to consider visual programming as a different notation for expressing the same underlying instructions.  Sometimes notation can make a world of difference.  Take roman numerals vs arabic numerals.  A simple switch to arabic numerals enables multiplication of any 2 numbers with the application of only a few simple rules.  Multiplying roman numerals is a black art and is well beyond the capability of most people.


The other side of the coin is the not every notation provides benefits worth the trouble of learning and using them.  Take Turing machines.  A Turing Machine is a formal model of computation that, supposedly, lends itself to rigorous treatment of the properties of a given algorithm.  It's got a nice mathematical definition which, in theory, allows mathematical tools to be brought to bear on the analysis of algorithms.  Outside of a small section of academic computer science, Turing Machines are completely useless.  For the kinds of problems most software is used to solve Turing Machines don't provide enough of a benefit over imperative programming to justify their use.


In my opinion, visual programming is a kind of notation that doesn't provide enough of a benefit over imperative programming to justify its use.