Charles Simonyi leaves Microsoft 592
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.'"
Hungarian notation? (Score:5, Funny)
Re:Hungarian notation? (Score:2)
6
enter
12
+
and
6
+
12
enter
In both cases I press 5 keys, "6", "+", "1", "2", and "enter" it is only the order that changes. And I can't think of an example of how it would work to save keypresses.
Re:Hungarian notation? (Score:3, Insightful)
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.
Let's hope... (Score:5, Funny)
Re:Let's hope... (Score:5, Funny)
Grab him! (Score:2, Funny)
Re:Grab him! (Score:3, Insightful)
Fleeing the ship (Score:4, Interesting)
Re:Fleeing the ship (Score:2)
1) The guy had been working for Microsoft for 21 years (how long have you worked anywhere?)
2) He's a billionaire (how much money do you have?)
These are perfectly good reasons to move on and try something different. In fact, most people in the industry switch companies much, much more often, so this is actually a rather positive sign for Microsoft (that people are staying for so long).
Re:Fleeing the ship (Score:4, Informative)
- adam
Hope he checks out IBM (Score:5, Interesting)
D 'n D - Been There, Done That (Score:3, Informative)
Re:Hope he checks out IBM (Score:3, Informative)
I agree with you that they indeed *tried* to do that, but they ended up with a system (Visual Age) that was in fact a lot harder to use than a traditional "notepad-style" environment.
Not everybody can do programming, it requires a special kind of imperative, cause-effect type of thinking. Such visual tools will (maybe) manage to make one aspect of programming easier, but I don't think they'll ever manage to make the whole easier enough so that aunt Tillie could do, let's say, her own custom expense manager. And the reason lies in the fact that most software projects are unique in at least one aspect. This uniqueness in most cases requires a Turing-complete programmer.
Visual Age was eventually replaced by Eclipse which is, in terms of the programming interface, as standard as you can get.
The Raven
Yup (Score:3, Funny)
WTF? (Score:2, Funny)
????!!!!!Errrrr??????
(conspiracy) Something seems to be going on here.(/conspiracy)
Hungarian Notation (Score:2, Insightful)
Even Hungarian Notation is a big improvement over having no naming conventions at all.
Re:Hungarian Notation (Score:3, Insightful)
Just name the var what it is supposed to represent. If it is representing an age, call it "age" and not "iAge". Just my opinion.
Re:Hungarian Notation (Score:2)
Re:Hungarian Notation (Score:2)
Even Hungarian Notation is a big improvement over having no naming conventions at all.
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.
Sometimes the key is just to have a structure, and it doesn't matter what the structure is.
-a
Comment removed (Score:5, Insightful)
Registration-free link (Score:4, Informative)
Re:Registration-free link (Score:5, Informative)
Ever heard of LabView? (Score:3, Informative)
Re:Ever heard of LabView? (Score:3, Informative)
Re:Ever heard of LabView? (Score:3, Informative)
The thing that hooks you onto LabView is you've got a bunch of test equipment that you want to automate. National Instruments has a HUGE list of "virtual" instruments that match the ones on your bench. Great, you say: these modules will be just the thing, and I'll be done in no time at all, because they've done all the work. WRONG.
The main feature of the NI VIs was that they could reproduce, on your computer screen, a GUI version of the front panel of the test equipment. (The other trend was to sell you a piece of test equipment that plugged into an expansion slot of your PC or an external chassis, and had a GUI instead of a front panel, but that is a separate topic.)
Well, big f**king deal. If I wanted to click an button-shaped icon on a GUI all day, I would have stuck with pushing the real button on the front panel. I want to write a PROGRAM, i.e., something more abstract than pressing the button.
The only real abstraction that LabView provided was a block which could have dataflow "wires" connected to the terminals. Once there were more than four terminals (think, function parameters), it became impossible to keep the wires neat, or keep straight which terminal was which.
Plus, the blocks were either ridiculously low-level (a GPIB command or two) or ridiculously baroque (a series of GPIB commands, with input wires for every possible setting of the instrument). I often had to resort to looking at the source, reading the GPIB sequences, then reading the instrument manual to translate into English.
Any kind of structured programming, other than blocks (functions) required some hokey GUI expression, often involving multiple-page (like tabs in a modern dialog box) displays. By design, you couldn't see the multiple branches of a case statement at the same time. Plus, the need to keep sane wiring meant that these pages kept growing to hold the most complex case, so programs of any sophistication became huge.
Forget it. I ended up writing my data collection code in a bastardized Pascal-like language supported by my data analysis program (Igor Pro). That was gross, but at least I could write a for loop without going insane, and I got a decent graphing environment.
Paper clip (Score:2, Funny)
Intellectual Property for your Soul (Score:3, Funny)
intellectual property he developed and patented while working there.
That's only because Bill Gates owns his soul.
This approach is nothing new (Score:5, Informative)
I personally don't think that either a purely visual approach is necessarily better. Anyone looking into this should probably build it from the ground up by looking closely at how actual programmers write code, and treat it as a usability problem. Try to reduce key-stroke redundancy, and figure out ways to reduce errors. A friend of mine and I once considered writing a language editor which guaranteed that at any time, the program displayed in the editor window was syntactically correct. This would mean autogeneration of text (auto-completion of variables and syntax), and restrictions to prevent the developer from entering impossible code.
I think the mistake people have made is often to start out with unfounded assumptions about how it should be done - such as assuming that a "drag and drop elements, then connect them up with lines" approach is the right direction (I don't think it is - or we would all be programming with Javabeans right now).
Re:This approach is nothing new (Score:3, Informative)
IMO, redundancy of a code or code text pattern is often a sign that either you are doing it wrong, or that the language is insufficient.
For example, if the code has something like:
foo.bar.yukims.glock(a, 1)
foo.bar.yukims.glock(a, 2)
foo.bar.yukims.glock(a, 8)
foo.bar.yukims.glock(a, 13)
foo.bar.yukims.glock(a, 19)
There should be a way to do something like:
x = "foo.bar.yukims.glock(a,"
x& 1)
x& 2)
x& 8)
x& 13)
x& 19)
Not exactly like this, but something roughly similar, with better names of course.
IOW, there are two approaches to dealing with such repetition: 1. Automating the reproduction copy-n-paste style, or 2. Use the language itself to eliminate the redundancy. The first approach makes programs harder to change IMO because you then have to change every copy if you change the parts that are the same.
Re:This approach is nothing new (Score:3, Funny)
#define x(n) foo.bar.yukims.glock(a, n)
x(1);
x(2);
x(8);
x(13);
x(19);
#undef x
Hmm?
(Note, I am not advocating this practise!)
Re:This approach is nothing new (Score:2)
I agree. I would add that there are many visual techniques already present in most every programming language. In perl, a hash can be formed and referenced in a way that is (to me) visual:
my $hashref = {
'ref1'=>{'color'=>'blue'},
'ref2'=>{'color'=>'red'},
};
Compare this to forming the same sort of data structure in java using hashTable. In java, you might approach this by forming instances of hashTable and then individually adding keys and values, one at a time.
Hashtable hashRef = new Hashtable();
Hashtable ref1Hash = new Hashtable();
Hashtable ref2Hash = new Hashtable();
ref1Hash.put("color","red");
ref2Hash.put("color","blue");
hashRef.put("ref1",ref1Hash);
hashRef.put("ref2",ref2Hash);
The perl example is much more self-documenting and "visual" than the java example. Perhaps more can be said for visual techniques with ASCII code?
If you ask me, lets use unicode to create more wacky characters for perl to take advantage of! :)
Simonyi. (Score:5, Informative)
Not mentioned in this article, he developed the Multiplan interface, which a gazillion of CPM based boxes used, the first version of Access, and had peripheral involvement of the development of the first Mac GUIs.
This guy started writing programs on a soviet vacuum tube (Ural II) computer. He snuck into Eastern Europe, and from there moved to the US.
If I had any cash I would invest in his company.
Not ironic (Score:5, Informative)
It was a technique for making types easy to identify in a language (C) that doesn't have any native way of indicating type. In BASIC, you know that A$ is a string. In Perl, you know that @names is a list. In C you don't know what "last_position" is. A pointer? An index? A floating point vector? It's not as if Hungarian Notation was designed to be the ultimate language-independent programming tool.
Re:Not ironic (Score:4, Insightful)
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.
Re:Not ironic (Score:2)
But then there's the dark side to that, specifically what happens when the type of the variable gets changed (say from int to class InterlockedULCounter for a counter). This being C++, the programmer's defined the correct methods to make the ++ and other operators work right, except that the number's now an unsigned long instead of an int, so only a few places where it was output needed touched to keep everything compiling cleanly and working properly. Nobody wants to go to the trouble of tracking down every initialization or increment of the variable across the entire program just to change the type prefix and now you're back to a situation where you can't tell the type of the variable from the prefix. Except that you're assuming you do know, and are in for a nasty suprise in the near future.
Re:Not ironic (Score:2)
Re:Not ironic (Score:5, Funny)
(scroll down to #29 in the list, it's worth it)
Re:Not ironic (Score:3, Insightful)
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
HN *Solves* Variable Type Changes (Score:3)
The task of progogating a change of variable type includes visiting the affected code and verifying that the change will not have unwanted consequences. It almost always does. Hungarian notation allows you to do this quickly, effectively, and in a single pass. Waiting for the regression test to come back negative is reckless and unprofessional.
We don't allow code to be checked in if it is not in HN. If it can't be visually audited for type correctness by an independent team, without the use of an IDE or some type of code browser, it's a liability and therefore has no business in our code base.
-Hope
Re:Not ironic (Score:2)
I agree. If you write decent code and organize things properly, then type and scope tags just create eye-clutter and line-width bloat.
And, like somebody said, types and scopes change. For example, "customerID" may change from numeric to alphanumeric if you merge with a company that has alpha ID's. Nobody wants to hunt and replace 200 references to "int_customerID". Booleans are frequent candidates for guaduating to more than 2 values.
But, if it floats your boat (pun), that is fine. Just please remember that what works for you does not necessarily work for others. Be respectful of that if you ever become a manager, please. Injecting your fav habits onto others will not necessarily help them the same way they helped you, perhaps even do the opposite.
Re:Not ironic (Score:2)
Yes, but the value of having the type information accessible in the variable name has to be weighed against the confusion and clutter that adding that information causes.
The names it creates are hard to read and remember, impossible to pronounce. It doesn't scale very well beyond a few native types, like BASIC and perl -- how many meaningful prefixes is a programmer supposed to remember? How many characters of a variable name are you willing to devote to type information? And finally, the type of a variable is usually obvious from it's context, and it can be commented where it isn't.
I've never met anyone who has asserted that Hungarian notation is worth using. It is ugly and confusing, plain and simple.
taken to extremes, anything is brutal (Score:2)
intLocalFnnameModulenameX
THAT gets a little absurd, IMHO. Not arguing that intX, or even intLocalX isn't useful, but you can twist yourself around an axle pretty damn quickly with this stuff.
Hugarian notation is EVIL (Score:5, Insightful)
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.
Re:Ever heard of "search-replace"? (Score:5, Insightful)
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.
Re:Ever heard of "search-replace"? (Score:3, Funny)
context (Score:5, Informative)
(In summary, don't.)
A very strange thing. (Score:5, Funny)
obvious? (Score:5, Insightful)
Code-free programming (Score:5, Insightful)
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.
Re:Code-free programming (Score:3, Informative)
OOP is great, RIGID object models are bad (Score:2)
Personally, I find OOP can be a bit rediculous when everything is mindlessly reduced to a rigid object model as dictated by some guy's rigid methodology. (Not all are rigid)
What I've found, is that most of the time is a matter of versatile interfaces. Myself wanting the best of my procedural language and SQL, I found myself creating interfaces that implement smart tables. A smart table is an object that exposes an arbitrary number of properties, like that of a named collection. Unlike a normal named collection, a smart table allows you to implement adhoc rules (changing this field causes this), using code, stored procedures, etc. Need more than just smart properties? Fine, derive from the Smart Table base class, and add your own functions (usually stored procedures)
Re:Code-free programming (Score:2)
It will have to be interchangeable at some level. No matter what you do at the highly-abstracted-developement-interface level, the hardware is still procedural. All the fancy tables and relational tools, and all the OOP modules, and all the event driven interfaces, have to be translated into step-by-step machine code eventually or they do exactly nothing.
I'm not saying any of your ideas are bad, but it's important to recognize at some level that all of this stuff is really just window dressing. If it makes things easier for you to understand, great, but it doesn't fundamentally change how things actually get done, and at the end of the day a good programmer still needs to have some understanding of how the machine actually works.
Other than text representations of programs? (Score:5, Informative)
Graphiq and Cellworks (Score:5, Informative)
Graphiq provided a rudimentary GUI that let you plan program flow with individual modules coded in something called C-- (this is no joke).
CellWorks provided a much better GUI but a different low level language that resembled in only the worst possible ways: Basic.
What we discovered using these tools is that they could indeed be powerful and almost any yahoo could use them. Once you wanted to solve something complicated and the problem immedietly started to look like programming 101.
In other words, complicated things are complicated, and it doesn't matter what the tool is. If you want to solve it you need someone specialized in that tool to solve it.
It's as simple as that.
Hungarian (Score:5, Funny)
Wait... I never actually get invited to parties... damn... day dreaming again...
In the age of corporate consolidation... (Score:2, Insightful)
He gets to keep his work....no suprise (Score:3, Informative)
If he patented stuff, he owns the rights to it and can use it if leaves MS. Now if his work was patented in MS' name, then he couldn't take it.
Re:He gets to keep his work....YES suprise (Score:3, Insightful)
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.
he's not the first (Score:5, Informative)
Has he heard about COLORFORTH [colorforth.com] ?
Free blah di blah (Score:5, Informative)
Hey! The printable version that was linked to didn't blah di blah me when I tried to access it! Maybe this is the cure for all of the NYT registration stuff, link to the printable version rather than the one with ads. Of course, I'll miss seeing all of the ads, but I'm willing to make the sacrifice.
Bravo was the first WYSIWIG editor (Score:5, Informative)
See PARC [xerox.com]'s history and search for "Bravo", or read the summary below:
For those looking for more on Simiyoni and Bravo (Score:3, Interesting)
aha ! (Score:2)
Oh... you mean like Magic [magicsoftware.com] ?
Programming language w/ visual features (Score:3, Interesting)
bad choice of words (Score:4, Insightful)
"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....
Re:bad choice of words (Score:2)
"Mr. Simonyi has [departed] Microsoft with the right to use the intellectual property he developed and patented while working there."
Meaning that Microsoft holds the patents and he has been given the right to use them without forking over license fees.
Intentional Programming (Score:5, Informative)
Simonyi was big on what he called 'Intentional Programming' (yes, as opposed to UNintentional programming, which is what we've been doing all along I suppose.) It's been in the works since at least '94 which is when a classmate of mine went to work on the project after graduating.
He got shafted as the power inside the dev tools group shifted. Most of his group got cut loose and ended up looking for other positions, Oddly enough, Simonyi himself left the group and gave up on it a year or so ago apparently without telling the remaining core of the group.
See:
http://web.archive.org/web/20000815211509/http:
http://www.edge.or
http://www.omniscium.com/nerdy/ip/
http://ww
I think the article is incorrect... (Score:2)
Mr. Simonyi's departure, to be announced today, will leave Microsoft with only three senior people from the team that led the company in the early 1980's: Bill Gates, a co-founder and the company's chairman; Steven A. Ballmer, the chief executive; and Jeffrey S. Raikes, a group vice president.
I'm pretty sure Marc Macdonald is there again; Marc was the first employee of Microsoft.
Aspect-oriented programming and Java? (Score:3, Informative)
Instead of the Times article, look at this one [washingtonpost.com] in the Washington Post which gets a little closer to this interpretation.
The company itself (Score:5, Informative)
The company can be found at http://intentionalsoftware.com/ [intentionalsoftware.com] with some vague-but-cool-sounding stuff about changing the world.
Kiczales is the other co-founder! (Score:3, Insightful)
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.
Blackmail? (Score:5, Funny)
Charles S.: I'm leaving to go my own stuff
Bill G.: Charles, you'll have to give up your rights to all the stuff you've developed over the years
Charlies S.: Did I metion that I still have a copy of those memos that the government never saw?
Bill G.: Well when you put it like that, I'll give you the rights to all your stuff. Need any cash? No? Here have some anyway. Anything else I can do? Anything at all? Coffee, Water? Sure..?
Interview? (Score:5, Interesting)
I'm not alone! (Score:3, Insightful)
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 [ibm.com] 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.
Re:IP? (Score:2)
Re:IP? (Score:2, Interesting)
I doubt that he negotiated this arragement upon his leaving. He more likely arranged it long ago, when his future value to the company outweighed the potential value of his contributions.
This does seem unusual (and not just for Microsoft). He had to have hammered this out long before his creations spawned a cash-cow like Word.
Re:He probably (Score:3, Informative)
He didn't work on the business side of the company. He was a hard core geek, thinks, codes, and collects a check.
Re:He probably (Score:2)
...all of which means precisely nothing. Nada. Zilch. Top-level (and often even mid-level) technical staff sign the exact same employee agreement as the business-side folks, and the part about "all your patents are belong to us" is there specifically for them. Dr. Simonyi might indeed have had some extra-special agreement, but if so it's because he's Simonyi and not because he's a geek instead of a suit.
Re:He probably (Score:2, Informative)
Abstract
A method and system is described for generating executable code for a computer program, A programmer creates an intentional program tree using a syntax-independent editor. The editor allows a programmer to directly manipulate the intentional program tree. The intentional program tree has nodes. Each node represents a high-level computational construct of the computer program. For each node representing a high-level computational construct, the system transforms the node into an implementation of the high-level computational construct using low-level computational constructs. For each node representing a low-level computational construct, the system generates executable code that implements the low-level computational construct. The system further provides that where a high-level computational construct has a plurality of implementations of the high-level computational construct, the system transforms the nodes by selecting one of the implementations and transforms the node in accordance with the selected implementation. The system further provides that the implementation is selected by automatically analyzing semantics of the intentional program tree.
5,790,863 - Method and system for generating and displaying a computer program
Abstract
A method and system for generating a computer program. In a preferred embodiment, the present invention provides a program tree editor for directly manipulating a program tree. A program tree comprises of plurality of nodes corresponding to computational constructs. The program tree editor receives commands from a user that are independent of a programming language syntax. The present invention also provides a display representation generator for generating a display representation of the program tree. The display representation generator retrieves nodes from the program tree and displays a display representation of the node. A user of the present invention preferably interacts with the program tree editor based on the display representation.
---------------
These patents probably not that broad in the crowded field of "visual representations of program structures".
So MS not really giving up that much.
They figure, hey, if the guy achieves success based upon these patents then they will be much more valuable to us in our cross licensing with IBM, Sun, HP, etc.
Re:No (Score:2)
Re:He probably (Score:3, Informative)
That's so totally wrong that I hardly know where to begin. Patents have both inventors and owners, with only the latter really meaning anything legally. It's standard practice throughout the industry for employee agreements to require that ownership of patents be turned over to the company, so all the actual inventor(s) get is their names on the patent and maybe a bronze plaque if the company's feeling generous (which they weren't for my patent). There's very little Simonyi can do about it; the employer almost invariably holds all the cards.
Re:He probably (Score:2)
Re:He probably (Score:2)
It is indeed possible that Dr. Simonyi had such a special arrangement, but he doesn't just get rights to the ideas because he developed them (what this post's great-grandparent seems to assume). Exclusive ownership of intellectual property by the employer rather than the actual inventor is so commonplace that it's the exceptions which are noteworthy.
Re:He probably (Score:5, Informative)
Sorry to nit pick on one detail, but:
If the inventor(s) are not listed correctly (if an individual contributed toward the invention but was not listed as an inventor on the patent) then the patent can be invalidated.
So the inventor designation does have legal ramifications on a patent.
Re:He probably (Score:2)
Point taken, and thanks for the info. I hope some kind moderator will take a break from glue-sniffing long enough to mod that up.
Re:He probably (Score:3, Funny)
Hrrrmmm - Does this mean that, if he gets struck down by God in a blinding flash of light, he could be converted and release his stuff under GPL?
Quick - you get the camera flash, and I'll get the sodium pentathol...
Re:He probably (Score:3, Informative)
'Mr. Simonyi has left Microsoft with the right to use the intellectual property he developed and patented while working there.'
Last time I checked, works for hire belong to the company - not the employee. This is generous of Micro$oft. It gets to that sticky area that when you develop something, even in your spare time, there is a chance that the company you work for can claim it (they have first 'dibs' on it). There are a lot of instances where companies sue the pants of employees when they try to do this.
Then again, Microsoft may let him go now and come after him later - let him turn it into a success and then claim it was a work-for-hire later.
It's why 'freelance' open-source developers should be careful to make sure their current (and any future) employer won't snatch away their work.
Re:He probably (Score:3, Insightful)
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.
Comment removed (Score:4, Insightful)
Re:That or...(Re:He probably) (Score:4, Insightful)
Re:programming (Score:2, Funny)
You must be too young to have ever seen a flowchart.
How one codes without text syntax. (Score:2, Informative)
Re:programming (Score:2)
This has been done before but has not been very successful, depending on how you measure that success, but it has not taken off. I remember specifically seeing one new
Re:MS Word Competitor in the works? (Score:2, Informative)
Re:This could be key... (Score:2)
The thing that's slowing Linux's takover of the desktop is the same thing that has historically kept the Mac from taking over the desktop: lack of commercial games.
Programmers (Score:5, Interesting)
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. Yet that's exactly what we do to ourselves with programming languages.
What we need is something that goes from UML all the way down to ASM, and more importantly, all the way back up. Editable at every level in between. Use colour, fonts, sounds and whatever else you want to indicate the age of a piece of logic (at whatever level), who last changed it and
I don't imagine this is going to be easy. However, the implementation is almost certain to be easier than getting people like me to start using it. Perhaps you youngsters should just write off everyone over 22 and start again. You'll thank us when we're gone.
Re:Programmers (Score:3, Insightful)
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.
Re:Programmers (Score:4, Informative)
Check out Argo UML, it generates code from the UML diagrams, which is not that original, but it's pretty good, and open source.
One of the main reasons the Java community is moving towards this concept is the reflection and introspection capabilities in Java, combined with the BECL project at Jakarta we can hand craft
The frameworks like J2EE and Struts are implementing common patterns, aleviating the tedious coding and allowing us to focus more on design and architecture. Since these frameworks are well defined we have code generation tool like XDoclet and Middlegen that handle the needs of the framework while we only write the business logic.
Java looks pretty big with all the acronyms you'll find on Sun's site, but since the tools started to develop, most of the work is reduced to design, architecture and coding business logic. When I use a J2EE application server like JBoss I don't have to deal with setting up and tearing down database pool connections. JBoss provides my Enterprise Java Beans with this. Threading is handled by the server as well as persistence and synchronization with the database. Because these things are well defined and allow you to integrate hand coded stuff if you need more flexibility I am freed from solving the same problems that people have solved 15 times before. I can also migrate to a new application and be pretty certain that I'll be able to seperate the core logic from the system maintainence and utility code that any app would need.
It's not perfect YET, nor do we have the whole UML to ASM and back thing, but with gjc (java gcc front end) and the classpath project we're getting there.
You should see the reuse too. The well defined APIs and frameworks make integrating other people's code easy, and the OOPness of java allows everything to act as a library. Just look at any established open source Java project and you'll see they've built of many of the other projects out there.
Granted I'm a bit of a fanatic, I've been doing both open source and Java for about 6 years, but I've yet to see any development system that had this much promise and consistently delivered. Check it out, you won't be sorry.
You can find these projects at Sourceforge or jakarta.apache.org and xml.apache.org.
Re:Simplify Programming Language? (Score:2)
'--------BEGIN CODE----------'
public sub DeleteNastyComment(Poster as object,ByRef strComment as string)
if Poster.Name = "Deathlizard" then
msgbox "You have been ownjed by vbm0nst3r",vbInformation + vbOkOnly,"I Ownjed Y0u"
set Poster = Nothing
strComment = ""
else
strComment = ""
end if
end sub
Re:strBias = "don't be so hard on hungarian notati (Score:3, Insightful)
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.