The big thing is- who wants to wait 4-5 seconds for their shell to launch? And this is in 64-bit with 2 gigs of RAM and MSH ngened (ngen == cache of pre-JITed.NET code). What used to take a split second can now easily take orders of magnitude longer than the script itself takes to run. Plus, it runs inside the old cmd.exe - this means we're still stuck in a non-Unicode world. Good luck trying to run some quick database queries in non-ascii!
The startup time is something we're aware of and are working to improve as we reach RTM. Our priorities thus far have been primarily around ensuring that the core functionality is correct and the shell experience is a high quality one. As we move forward, we will be tuning up the performance of the Windows PowerShell.
With that said, this is just initial startup of the shell in which you should get the worst hit prior to the prompt loading. If you close the shell thereafter and load it again, the shell should open promptly. Individual commands execute more quickly as well as passing objects does not require a performance sapping test output and reparse phase which is normally required in most shells.
If you have particular scenarios or issues with PowerShell performance, let us know at http://connect.microsoft.com/ (sign up for PowerShell under Available Programs)
One would think so. But find me projects that actually ended up producing a key component for Windows, Office, or many of their other products? I used to follow Microsoft Research because it sounded like they were working on interesting stuff. Over time, however, it became clear that NONE of the projects were ever seeing the light of day. The most that was happening is that the researchers would do some work, post a web page, then say the project is still in progress when it was actually dead.
I'm not sure what you consider to be a "key" component. For example, the shell? Lots of research goes into UI interfaces, but research is generally aimed at specific topics and not a huge set of features and area that a product would cover. So the shell would be what came out of a bunch of research projects.
The thing here is that with Monad is that folks aren't required to write specifically for Monad.
Since Monad can instantiate objects and call methods on any.NET Framework class that's public, any windows developer who writes anything using the.NET Framework will automatically have their classes accessible to Monad.
This is the case with many developers who are writing for any sort of managability. If they want an even nicer syntax, then they can custom write cmdlets which would then use a full verb-noun semantic for an even nicer user experience, but it's not required.
Finally, it's really easy to write Monad cmdlets if you already have the.NET class implemented. The most basic version of get-process is a grand total of 5 lines of code.
Leonard
The intent behind the longer names is really for initial learning curve and scriptability.
In Monad, if I know how to get processes using get-process, I now know the "get" verb. Since the convention is standardized, if I want the content of a file, get-content is a good bet for the right command.
If I really don't know, I can do
get-command -verb get
to get a list of all of the commands that are getters.
Compare this with ls and cat which are just brute memorization. And good luck with apropos.
As people get better with Monad, it's expected that they'll switch to the Monad aliases for these functions (intuitively, get-alias for the list) for shorthand notation, or use Monad's autocompletion.
The other benefit of longer names is that within scripts, people can use the longer forms to make scripts easier to read and understand.
If you're interested in downloading a copy of Monad, visit http://beta.microsoft.com/
The invite code is PDC.
The Monad team is working on a new version as well and will have the new version available before th end of the month.
That's BS. Let's assume that a company admits the patent system is screwed, so it obtains patents for defense. That makes no sense unless it is also working to change the current patent system so defensive patents are NOT necessary.
This is a really poor analogy and understanding of the problem.
Acrobat actually installs a Word plug-in (PDFMaker) and macros which run when Word starts up if you do a full install. This is similar to when Acrobat reader hangs when viewing a PDF in IE and takes out the IE instance.
Slashdot Mirror
The startup time is something we're aware of and are working to improve as we reach RTM. Our priorities thus far have been primarily around ensuring that the core functionality is correct and the shell experience is a high quality one. As we move forward, we will be tuning up the performance of the Windows PowerShell.
With that said, this is just initial startup of the shell in which you should get the worst hit prior to the prompt loading. If you close the shell thereafter and load it again, the shell should open promptly. Individual commands execute more quickly as well as passing objects does not require a performance sapping test output and reparse phase which is normally required in most shells.
If you have particular scenarios or issues with PowerShell performance, let us know at http://connect.microsoft.com/ (sign up for PowerShell under Available Programs)
Leonard Chung
Program Manager
Windows PowerShell
As just one example of projects coming from research to product: Reliable Multicast Implemented in Windows & Cisco Routers
I'm not sure what you consider to be a "key" component. For example, the shell? Lots of research goes into UI interfaces, but research is generally aimed at specific topics and not a huge set of features and area that a product would cover. So the shell would be what came out of a bunch of research projects.
Leonard
TerraServer was created in the '90s by Microsoft Research as a technology scaleout demo by none other than Turing Award winner Jim Gray.
Here's a link to the original presentation on what they were about to build: http://research.microsoft.com/%7Egray/talks/Public _TerraServer_Talk.ppt
Since Monad can instantiate objects and call methods on any .NET Framework class that's public, any windows developer who writes anything using the .NET Framework will automatically have their classes accessible to Monad.
This is the case with many developers who are writing for any sort of managability. If they want an even nicer syntax, then they can custom write cmdlets which would then use a full verb-noun semantic for an even nicer user experience, but it's not required.
Finally, it's really easy to write Monad cmdlets if you already have the .NET class implemented. The most basic version of get-process is a grand total of 5 lines of code.
Leonard
In Monad, if I know how to get processes using get-process, I now know the "get" verb. Since the convention is standardized, if I want the content of a file, get-content is a good bet for the right command.
If I really don't know, I can do
get-command -verb get
to get a list of all of the commands that are getters.
Compare this with ls and cat which are just brute memorization. And good luck with apropos.
As people get better with Monad, it's expected that they'll switch to the Monad aliases for these functions (intuitively, get-alias for the list) for shorthand notation, or use Monad's autocompletion.
The other benefit of longer names is that within scripts, people can use the longer forms to make scripts easier to read and understand.
Leonard
The invite code is "mshPDC".
The Monad team is working on a new version as well and will have the new version available by the 21st of June.
If you're interested in downloading a copy of Monad, visit http://beta.microsoft.com/ The invite code is PDC. The Monad team is working on a new version as well and will have the new version available before th end of the month.
Dude -- you need to get your facts straight. Microsoft *is* calling for patent reform as well.s oftpatent_1.html
Check out this infoworld article at http://www.infoworld.com/article/05/03/10/HNmicro
Obviously because Microsoft is not working to fix the current system, it is using these patents for offensive means, not defensive means.
By your own argument, it is likely using them for defensive means for now.
This is a really poor analogy and understanding of the problem. Acrobat actually installs a Word plug-in (PDFMaker) and macros which run when Word starts up if you do a full install. This is similar to when Acrobat reader hangs when viewing a PDF in IE and takes out the IE instance.