[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Application Design
- From: Eric Bohlman <ebohlman@earthlink.net>
- To: Sean McGrath <sean.mcgrath@propylon.com>, xml-dev@lists.xml.org
- Date: Sun, 12 Aug 2001 18:42:52 -0500
8/13/01 4:24:46 AM, Sean McGrath <sean.mcgrath@propylon.com> wrote:
>Remember what happened to C++ - it
>got so complex that the majority of programmers (on Windows anyway)
>ended up with visual tools. These tools in no way allowed you to
>visualize what C++ was. They purely acted as buffer zones between
>the programmer and the complexity of the language. Over time,
>the vendors developed a stranglehold and effectively forced
>organizations using C++ to purchase visual tools and then
>specifically to look for visual programmers.
When recruiters talk about a "Visual C++" programmer, they really mean a programmer who is familiar
with the Microsoft Foundation Classes, an application framework that ships with VC++. But the MFCs
don't exist as buffers between the programmer and the C++ language; they exist as buffers between
the programmer and the complexities of the Win32 API and the message-driven architecture of
Win32(in particular, they try to insulate the programmer from the fact that the architecture is
heavily callback-driven but does not provide any way of associating an instance pointer ("this")
with a callback). A lot of the other "visual" stuff in VC++ deals with the complexity of COM
interfaces, not the language itself.
>XSLT gets complicated quickly. The side-effect free nature
>of its processing model causes much pain for developers.
>The theoretical reason for this - parallelization of execution
>of the stylesheet - seems to me to be unjustified. It puts too
>much complexity on the programmers plate for what is after
>all an optimisation feature.
One of the problems is that people who are into functional programming seem to be *really* into it;
there's an air of True Believership. I suspect it has something to do with personal cognitive
style; some people are just more comfortable thinking in terms of positions on a stack than in
terms of named quantities. Plus FP is quite elegant mathematically, but mathematical elegance
doesn't always translate into usability; most developers don't have "stack minds" and find
procedural programming easier than functional programming.