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.'"
Makes you wonder what he'll be shooting for? A cheaper, compatible MS Word competitor?
And a word on hungarian notation. It makes me want to puke. Your variables should be named well enough that it shouldn't need extra letters to tell you the type.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Even Hungarian Notation is a big improvement over having no naming conventions at all.
The only thing that we learn from history is that nobody learns anything from history.
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.
thank you. A voice of reason. Hungarian (while not perfect, and not that pretty) is DAMN useful.
I was someone who was introduced to it kicking and screaming, but eventually I came around. As soon as you have to work in a LARGE software project it's a godsend. It makes reading someone else's code, or your own code 2 years later, MUCH easlier. When i can look at a variable in a strange piece of code and tell it's type and scope just from it's name, that saves a ton of time.
Most geeks don't like it cause it's extra typing.
Will Microsoft wait till the new company comes up with something truely nifty, and then buy it up (like they did to get their hands on Halo)?
Blog Prophyts - Right On, Man
You're right, the Open Source community is much better at playing catch-up than innovating anyway.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
Comment removed based on user account deletion
Companies can not get patents. Typically the human gets the patent and assigns the rights to the company.
A quick peek into the USPTO shows the Simonyi has something like 8 patents (probably from two applications, one of which was split into many parts) all of which are assigned to Microsoft.
So, Microsoft must have granted him rights to use the patents in his new venture. And Microsoft must have gotten something in return or they have not acted in the interest of their shareholders. What they got is the mystery.
there is also the chance that his contract was written when MS was merely a 75lb gorilla, and is more fair than their current contracts.
Cretin - a powerful and flexible CD reencoder
'Mr. Simonyi has --left-- Microsoft with the right to use the intellectual property he developed and patented while working there.'"
:)
"Left", as in he left it there, for them to use, or...
"Left", as in departed with that right so that it was no longer there and they couldnt use it.
dont tell me i need to read the damn article....
There's nothing Intelligent about Intelligent Design.
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
Others have given examples, but here's the core:
Reverse Polish Notation calculators are really stack machines, and the stack is exposed to the user. On an RPN calculator, operations are generally done between the Top Of Stack and the Next On Stack, leaving the answer on TOS. The Enter key pushes TOS to NOS, but also delimits so you can type another number.
So in the simple example given:
6 - TOS=6 NOS=??
Enter - TOS=6 NOS=6
12 - TOS=12 NOS=6
+ - TOS=18 NOS=??
The stacks in HP calculators were (don't know if this has changed) 4 deep, and that was generally enough. There is a key to exchange TOS and NOS, and a Roll key to roll the whole stack.
Back when RPN got its foothold in the calculator business, algebraic calculators were handling parenthesis poorly, if at all. Some had a single parenthesis, some had one level of nested parenthesis. RPN avoided the issue, by making the user think differently.
The living have better things to do than to continue hating the dead.
My basic feeling about HN is as follows:
If you don't know the type of the variables you are dealing with _anyway_ then you have big problems that aren't going to be solved with a few reminder characters.
> A voice of reason. Hungarian (while not perfect, and not that pretty) is DAMN useful.
2 560
I agree - except I use a practical Hungarion Notation, not an overly-idealistic one. I posted a comment a while ago about this.
http://slashdot.org/comments.pl?sid=32873&cid=358
The problem occurs when you take Hungarian notation to its logical conclusion: You get lost amongst the alphabet soup of glyphs. Variable names provide the abstration of memory addresses, but over zealous use obfuscates the name.
Cheers
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
It has been brought to my attention [mindprod.com] that no sane programmer would design a record keeping system that involved giving the a customer a text editor and a manual and making him enter his records in a particular format in files with a particular name and extension
I guess we can conclude from this that no sane programmer chooses programmers for his customers.
I think its' remarkable how well text editing files suffices to the needs of programmers. As a programmer who is the customer of other programmers, one deals with two aspects of their work: logic and metaphor. The things which are the most work-a-day useful tend to be rigorous in the logic department and rather pitiful in the metaphor department. The behavior of a data structure like a B-tree is rigorously defined. I do not expect to find sap running from its root to its leaves.
That's a silly example, but most of the time I see attempts to revolutionize programming comes down to creating new metaphors for logic. Programmers are terrible at metaphorical thinking (which is why we usually create terrible user interfaces), and once you are in the business of ginning up new metaphors, it's hard to know when you've gone from the sublime to the silly. Usually it's a short trip.
The most successful metaphors in programming are ones that are worn smooth with time and usage. The figurative computer file is more familiar than the real thing and the shortcomings of the metaphor are are not shortcomings because we know what to expect from a file's behavior. I'm not saying there won't be successful new ways of looking at programming, but I don't expect to see it revolutionized any time soon. I'm skeptical of systems that tie things up in some kind of seamless web of something-or-other because sooner or later the limitations of the metaphor being imposed on the programmer will become apparent.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
As a general rule you're correct, however in this case it's actually the other way around. Languages that support a 'variant' data type do not require type checking (strong or weak) because type conversions are handled automatically (you never have to cast anything or even worry about what type anything is. 99% of the time the compiler figures out what you meant based on the code you typed in. This leads us to the usefulness of Hungarian Notation:
Hungarian Notation allows the code to be more meaningful to the reader. This creates less work for the programmer because in languages with a 'variant' data type more work is already being done by the compiler. If you are adding an integer to a string, but the string happens to contain a number, then the compiler will automatically calculate the value that is the sum. The sum can then be concatenated to another string or added to another number, whatever you choose. Of course, the risk with this kind of thing is that you accidentally write code that means the wrong thing and the compiler doesn't complain. That's where Hungarian notation comes in: It forces you to think about what the code means when you are writing it. I think that for most people this is a Good Thing.
Amazing magic tricks
Not odd considering Simonyi's reputation: headstrong, brilliant, utterly impractical, lacking in organizational and leadership skill.
According to friends, Simonyi had a history of losing direct reports due to poor decisions and poor communication skills. Over time, he was ousted from important positions within Microsoft, and kept happy by having free rein over an Intentional Software research project; when this produced nothing practical after nearly eight years, he was ousted from that too.
I should also add that (according to these same friends) the work that Simonyi did accomplish in the research space was very novel and innovative; most posters claiming otherwise lack any concrete knowledge of Simonyi's techniques.
Assuming the organizational and managerial talent comes from elsewhere (and Simonyi certainly knows his strengths and limitations,) Intentional Software will be one to watch in five years' time.
if the language in question is javascript, and the environment is a client browser, what alternative tools would you suggest? javascripts lack of types sucks (since the type is inaccessible, but sometimes critical), but that's the language you've got. I find very simplified hungarian notation invaluable here when *I* have to enforce variable typing since the language does not.
There is plenty Microsoft could do. However Microsoft tends to behave as a rational actor.
The release does not discuss the funding of the new venture but I would not be at all suprised if Gates, Balmer, Microsoft were investors. If so providing access to IP is not suprising.
I would not be suprised if there was not some sort of reciprocal IP agreement so Microsoft can use IP developed by the new company.
It is unlikely that the new company is going to grow so big that it puts Microsoft in the poor house. On the other hand they can probably buy it if it does lok like it has a winner.
Companies like Microsoft tend to find it very hard to get existing sales and marketing organizations to accept a new product that might canibalize an existing market (see Christiansen's Inovator's dilema). It is actually more effective to buy in R&D even at what appears to be a ludicrous premium over the cost of building from scratch.
Take Vermeer as an example, it is very unlikely that they would ever have made $180 mil in sales let alone profit. Microsoft has earned many times that from distributing their product, Frontpage through their existing channels.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
I've been increasingly troubled that I perhaps was alone in thnking textual representation fo source code is silly. As a Java programmer, every IDE under the sun ahs a little side panel where the structure ofyour class is represented as a tree, and as you clickon elements in the tree, the file jumps to that delcaration.
Turns out, though, that it doesn't really matter that method A appears before method B in the file. Code folding is a very simple step in this direction. And all of this arguing over tabs vs. spaces, curly-braces on their own line, etc. would be obliterated if code were stored in some other, unformatted manner.
I know IBM's alphaWorks has a project that transforms Java into XML and back. Once in unformatted XML, it is easier to see if a file changed functioanlly whereas typical diff programs would higlight a curly brace being moved to its own line.
Now the interesting thing I found out there is that the *other* founder is Kiczales, a Xerox PARC person who was a prime mover in the Aspect-Oriented programming movement. So it looks like we have here is a start-up featuring really smart people whose efforts to do world-changing programming tool/language research did not get anywhere in the large companies they previously worked for. Or something like that.
The success rate for start-ups is not very high, but this is at least an interesting sort of venture, unlike so many of the dot-coms of the past few years.
Babar