OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Application Design



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.