 |
Professor von Clueless in the Blunder Dome |
status privacy about contact |
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Atom Feed Associated Blogs 
Recent Items Archives |
Saturday, April 01, 2006Does Visual Studio Rot the Mind?
Does Visual Studio Rot the Mind? Thanks to Doug Mahugh having a dreary day indoors, I’ve found this October 2005 gem from Charles Petzold. Petzold gives voice to a number of problems that have been nagging at me and for which I haven’t found a clear view. Petzold (who’s April 1st 2006 parody on XAML is also brilliant) sharpens the difference between programming fast, programming well, and programming clearly. Doug’s grey-day post and Petzold’s appraisal are instant candidates for Best Software Writing II when Joel Spolsky gets around to it. {tags: software development Visual Studio conceptual integrity software engineering programming practice computer science education [update: There were some nasty typos and mangled wordings. “Does Visual Studio Rot the Mind?” is already on Joel Spolsky’s list, but I was happy to add my vote.] I only recently learned that Petzold has a blog. The RSS feed quickly went into my WinDev category among others including Larry Osterman, Michael Kaplan, Raymond Chen and, of particular relevance here, the MSDN Forum for the Visual C++ 2005 Express Edition. I learned of Doug’s blog through his involvement on the new site on Office Open XML formats and their use in document interchange. I notice that seeing each new offering from him has me smile. First, I think that Doug’s use of a kind of Structured English (what is also known as pseudo-code) for high-level characterization of a programming approach is classic. It’s a recognized software-engineering methodology and is a recognized way to work on the conceptual organization and essentials of a procedure before dealing with the syntax and low-level details that can easily obscure the important overall organization. It’s literally classic: it goes back to the very early days and Grace Hopper’s efforts to make programming languages match that level of expression more closely. (I watched a dismal failure on that, ambitiously and prematurely advertised as “English Spoken Here,” but Cobol has to be counted as the eventual success.) I can even recognize how that approach, which I have used and which I preserve in comments that introduce the detailed sections of code, fits into my breaking down of mainline procedures into use of components. There, I find that I am designing header files with descriptions of interface principles and stub procedures with pseudocode, all to be filled in progressively and confirmed with successive layers of tests as more function is available to exercise. This works great for procedural logic and decomposition of the approach, something that remains a valuable practice. It also ties into how we can tell we’re done and that we have produced what it is we started out to provide. It should also let someone else confirm Where structured-anything doesn’t work very well without a lot of careful preparation and practice is when our code consists of fragments/components of something not in view (and that we may not understand how to debug). For example, our bits might form a cohesive interactive performance only when integrated with a not-so-well understood User Interface threaded-messaging process. We should be concerned about Petzold’s observation that we are losing something with tools that hide this mystery and leave developers with an uneasy sense of incompetence. Old hands can adjust to it by bringing solid experience along with a willing beginner’s mind. That’s advantageous to finding out what is going on and One of the great qualities I find in Petzold’s work is his appreciation for the beginner. I value his care in making sure that his readers are advised about what they need to already know, while letting them operate with as little tool support and startup-cost as possible. You don’t need Visual Studio for his classic Programming Windows (ending with the 1999 5th edition for Win32) and its sequel, Programming Microsoft Windows with C# (2002). You just need the compiler, understanding of command-line operation, and some standard developer utilities plus the appropriate and freely-available SDK. Another common feature of Petzold's work is progressive learning by doing and then doing more, backed up by worked examples that actually do something it is valuable to know about. My interest in the Visual Studio Express Editions is not just that they are currently available for free Comments: Post a Comment Wednesday, March 29, 2006Grady Booch on the Limits of Software
Blog (Handbook of Software Architecture). Grady Booch makes a gracious observation about the furor concerning the announced delay for Windows Vista on his blog (no permalink: current article will scroll off). He looks at the angst posted by Microsoft developers and observes
{tags: software architecture pattern language forces system constraints system requirements Grady Booch orcmid} Booch’s depiction of the limits of software and the situational factors that originate many of those limits is a must-read. The registration process is painless. I heartily recommend the draft materials in the on-line Handbook of Software Architecture to anyone interested in architectural considerations that apply to software systems design and development. One tangential value for me, on my third or fourth scan of the limits page, is that I finally have come to understand where “Forces” come from in templates for pattern languages. I’m still uncomfortable with that metaphor for patterns of non-physical systems, and will stick to concerns. I also notice that it is important to identify important constraints as well as requirements, especially non-functional ones and I haven’t looked at that in the context of patterns for computer-based applications. (I also see that I have one more David Harel book to track down.) Comments: Post a Comment Modeling the Office Open XML Packaging Conventions
OpenXML Developer - Modeling OOX Packages. I've been waiting for an open forum for discussion of the ECMA TC45 Office Open XML Document Interchange Specification (now at draft 1) and especially the OOX package conventions, apparently a subset of the Microsoft Open Packaging Conventions. Now there’s openXMLdeveloper.org (I hate the name — XML is already open — but love the place). I just posted about my interest in the packaging model and though it would be useful to share that more widely. {tags: Open Packaging Conventions Office Open XML conceptual models data models document processing orcmid}
The package model is a very interesting application of Zip files as containers for more-complex related components that may carry references to each other and to material that is elsewhere. The package allows the essential relationships (and the nature of the package components) to be determined without having to know how to process the individual parts themselves. That makes for some interesting opportunities in document processing and in the interchange and preservation of digital assets. Comments: Dennis, I'm with you (I think) on the three-part breakdown, but I'm confused a bit by the choice of words, especially the use of "logical". I know it's common practice to create an abstract model; I think it's required. But I'm just wondering why the abstract model is called "logical". It is about structure and relationships, and, possibly, as you suggest, some metadata. Perhaps, as we've discussed elsewhere, I'm just having a metaphor confusion. But I'm having trouble seeing, say, hierarchy as logic. I also wonder about the persisted model. Isn't serialization just one way to persist stuff? For the sake of parallel construction isn't it better for the persistence model to be named "Package Storage Model"? Great questions. I'm going to ponder these and make a follow-up post, but here is my initial thinking: "Logical" is from old practice in database work and even computer architecture ("logical design"). I could just say navigational [data] model or [navigational] data model (which are still abstract and include notions of hierarchy.) I think it goes back to a logical-physical distinction and is not really logical in the sense of "logical inference." (And then there are "logical operations" and "logical data types"). I will take another look to see if there is something sharper to be done here. I don't think I mean "Storage Model" so I need to think very hard about that one. Serialization may be ephemeral (e.g., as in for transmission whether RPC or something else) and not about recorded digital media. Also, the reference model at this level is in terms of (abstract) ZIP packaging. I'll look at this one again, too, and see what the openXMLdeveloper.org folk have to say, although I think most there are concerned about using OOX and OPC, not conceptualizing it. Dennis, you are correct in the older usage of logical models for datasets, etc. I conveniently put that knowledge aside so I could just ask the question about the choice of words. It may be a good word to use, since it likely has a usable understanding in the software field. The serialization question is an interesting one. Now that I read this again I'm thinking that the logical model exists as a representation of the conceptual one. And finally, on the computers, we have a concreate realization of the logical representation. I think it would be good to, somehow, allow the physical, embodied, datasets to have some kind of self-describing patch sewn on their shirts, that helps convey the model they realize. Maybe that's off base here. But for permanent usability, I'm thinking that some model info has to accompany the stored bits. At some point in the future the bits may be all that's available. (I almost said "readable" there.) Bill, I like what you say here. And I like the last little touch. I suppose it is what is intended by providing metadata with/in our digital artifacts and it is certainly what some see XML as a means to. I always liked the OSI ASN.1 OID method of appealing to some external authoritative source. XML Namespaces can be thought of as a distributed-authority approach to the same problem, given an appropriate community praxis. Heh. |
|
|
You are navigating the Blunder Dome |
template created 2004-06-17-20:01 -0700 (pdt)
by orcmid |