Charles Simonyi is the Hungarian behind Hungarian notation.

My cynical impression is that he is a very smart person who has a lot of big-sounding ideas, but I've never liked the execution much. But I'll freely admit that I may be biased both by the Microsoft connection, and from my intense dislike of Hungarian Notation.

Still I can't help but feel that he tends to solve the wrong problem from my perspective in a way that makes the right problem harder. For instance Hungarian Notation solves the problem of losing track of the data type of a variable by making the variable name a compact comment on its own data type. At the cost of causing huge code maintainance problems when you need to change a data type. Besides in some languages that problem is already solved perfectly well by type-checking in the compiler. In others the number of "types" is effectively infinite (it is the number of classes) and so his naming scheme does not extend.

Looking at the interview, I detect a similar concern. It isn't put as clearly there as it is in this older interview. His programming style seems to be to figure out his data structures first, and then to write his code as a series of transformations that preserve invariants in his data structures. This is indeed a powerful approach. Furthermore it is obvious why someone working this way sees data structures as being primary.

This concern showed up before in Hungarian notation - if you want the data structure to remain invariant then you really care about never losing track of what the full thing is supposed to be. And his intentional programming seems to be a reiteration of this concern. If you think that data structures are primary, and you want to encourage high-level programming, then you want to move control of the data structures up the chain. Which is what he's trying to do - make it easy to have the clients specify the data structure that they want, and the engineers write code that will work on that data structure. Afterwards the clients can add to the data structure and the engineers' code will continue to work.

Or so goes his vision.

This vision of how to program doesn't seem like a fit for me or the problems that I've worked on. It feels to me like he's solving the wrong problem for how people really work. But he's clearly solving the right problem for him, and there is probably an appropriate space for his solution. I just don't know what it is.


In reply to Re: Multiple representations by tilly
in thread Multiple representations by zby

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.