Slashdot Mirror
Charles Simonyi leaves Microsoft
tibbetts writes "The New York Times reports (printable version) (Free blah di blah) that Charles Simonyi, the former chief architect at Microsoft and creator of Bravo, a text-editing program that later became Microsoft Word, has left the company to form his own startup. The focus of his new company is to "simplify programming by representing programs in ways other than in the text syntax of conventional programming languages," which is highly ironic in light of his infamous Hungarian Notation style of naming variables. Perhaps more amazingly, 'Mr. Simonyi has left Microsoft with the right to use the intellectual property he developed and patented while working there.'"
Could it be that maybe this man just wants a change of pace? Maybe he wants to move geographically? Maybe he wants more freedom to spend time with people important to him? Maybe he just decided to do it on a whim? Can we consider that maybe, just maybe, this has nothing to do with Evil Empire Microsoft (TM), politics, Open Source, or geekiness?
The masses are the crack whores of religion.
This topic raged recently on comp.object.
There are basically two common candidates: drag-and-drop "box-and-line" diagrams, and tables (my favorite).
I argued that OOP puts too much of the "noun modeling" into code. The more that is put into tables (relational databases), the easier it is for me to search, sort, filter, navigate, etc. the information (assuming decent relational tools).
The alleged downside is that algorithms are decoupled from data, which is "bad" in most OO philosophy. However, I don't see any huge penalty of this, and the benefits of being able to apply relational algebra and relational modeling outweigh any small drawbacks IMO. Besides, I have put code into tables on occasion.
I personally find code more rigid than a (good) relational system. In procedural/relational programming, mostly only "tasks" end up dictating code structure, and not the noun models, noun taxonomies, and noun relationships; which are all subject to too much change and relativism to use code to manage IMO. OOP is too code-centric WRT noun modeling.
It is probably subjective, so I hope that whatever he comes up with to replace code, it does not become forced down everyone's throat if it catches on in all the PHB mags. One-size paradigm/approach does NOT fit all.
Perhaps he can strive to make all 3 methods (code, tables, diagrams) interchangable. That way a given developer can use the representation that he/she likes the most without shop-wide mandates.
Table-ized A.I.
Hugarian notation is EVIL, and here's why.
....
....
...
....
/* ????? */
...
...." but otherwise the notation creates more problems than it is worth.
Consider a large program, in which we manipulate lots of ints. We have lots of pointers to ints, so our code looks like:
int *piFoo = &bar;
*piFoo += 1;
*--piFoo = 5;
and so on.
Now, we discover that ints aren't big enough - we need to use longs.
long *piFoo = &bar;
*piFoo += 1;
*--piFoo = 5;
OK, now we have two equally bad choices:
1) We leave the variable names alone. But now they are lying, and therefor are introducing more errors.
2) We change the variables. Now what SHOULD have been a simple change is rippling all over the code.
Even if you do as you should, and use a typedef, things are still bad:
typedef int Thingy;
Thingy *pThingy_mythingy = 0;
....
How do you create the "warts" for typedefs without creating ambiguity?
It gets even worse if you have structures:
struct Narf
{
int *pi_Poit;
};
....
*narf.pi_Poit = 5;
....
Now, you have to rev all the items that reference that structure, all documentation that refers to that structure, etc.
I can somewhat understand the use of a leading "p" to indicate "pointer to
The proper place to trace variable types is not in the name of the type! It should ideally be traced by your editing environment, along with the location of the variable's definition, the location of it's instantiation, the location of it's initialization, and any comments that you want to assign to the variable.
www.eFax.com are spammers
To all the die-hard C programmers who refuse to make the Linux kernel C++ compatible because they are using variable names such as "new", let me point out that this wouldn't be a problem if you had called the variable nNew, gNew, new_p, or any kind of mangled name at all.
Let me just point out that C++ is not a feature.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
First of all, have YOU ever heard of it refered to as "search and destroy"? Quite frequently such operations end up screwing things up because the SnR tool got confused.
Second, you are driving changes in files that you shouldn't have to change. As a result, you clutter up your revision control system with a bunch of crap.
Third, if you deal with any kind of QA department, they will insist upon verifying all code that you've changed - "But it was a simple search and replace" won't cut it (nor should it!). So you will have QA time being spend on verifying a bunch of things that you shouldn't have to verify.
The whole idea behind ANY programming methodology, be it OOP, Hungarian notation, extreme programming, team programming, or whatnot, is to make things easier . Anything that adds more work than it saves is a loss. I assert that the time saved by being able to tell that piFoo is a pointer to integer is much less than the time costs Hungarian notation imposes.
www.eFax.com are spammers