“PowerShell is the COBOL of the scripting world. In that I mean as you type out what you need to do your fingers actually get tired. Powerful no doubt, but it will require most PowerShell scripters to buy a gripmaster to build up finger strength for those marathon scripting sessions or more likely, there will be a good market for autocomplete IDEs for writing PoS code.”
-
logon:
-
visitors:
-
- Journalized Theme Copyright © 2002–2025 Mike Little.
Explicitness is great for self-documenting production scripts. In the middle of the night, when things have gone pear-shaped, you want to be able to read a script and know exactly what it is doing.
That said, verbosity is NOT the friend of power users doing interactive sessions. That is why we support Aliases, Positional parameters, parameter disambiguation (and as you say – tab completion).
We don’t view this as an either/or situation.
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
Yes, it’s almost as verbose as PERL even 😉
most of my scripts will get as big as a complete line.
Greetings /\/\o\/\/
Hi Joe,
I spend last few years writing very complex (few hundreds scripts) frameworks. Due to historical reasons it was completely written in batch (sometimes custom vbscript\.net).
Because this scripts were really big and were not typical batches, but rather build on complex script blocks (for example tons of “If” and “For” produced 500 lines block), I was really unstatisfied with readibility of these scripts.
In batches all elements in For are 1 character – so in big scripts you soon had %%a, %%b, %%c, %%d …. %%K and it was not really easy to read such scripts. Due to fact that delayed expansion is by default disabled and with delayed variables some functions are not working, this was really big problem.
What I really love about PowerShell on the other hand is that it is very easily readable in scripts. However when I use PS interactively, I use aliases instead (and of course PowerTab ;))
Martin
As a backslidden bash user in the *nix world, I don’t understand the parallel MSFT attempts to draw.
With PowerShell, as usual with much MSFT produces, elegance is the bastard orphan step-child.
Regarding the autocomplete via an IDE, there is a mechanism for autocomplete baked into the shell also – tab completion, which has been greatly expanded in functionality by the user community:
PowerTab-http://thepowershellguy.com/blogs/posh/pages/powertab.aspx
PowerShell Community Extensions-http://codeplex.com/powershellcx
Jeffrey: Good comment. However, I put it on the writer if they don’t write decent comments, that is the sign of poor writing skills IMO. You don’t have to write a book but giving road signs where there are tricky passages as well as chapter overviews for sections should be something script writers should be doing period. Don’t care how verbose the script language is because even with verbose writing you could do some non-inuitive things.
MOW: Perl verbose? Line isn’t a good unit of measure, how long is a line? Don’t need any newline line breaks in perl that I am aware of, every perl script in existence could likely be a single line and you wouldn’t burn out the hyphen key. 😉 Would you do that, nah, but if you want to compare size by number of lines… I was thinking sheer number of characters to type.
Martin: Not sure what your point is but yes, PowerShell is a world of improvement over batch. But so is vbscript.
Fred: Hey you may have nailed it for me and the overall “errrr” I feel when looking at PowerShell code. I look at a PoS script and I don’t see beauty nor elegance. Interesting. It kind of gives me a BASIC vibe and never really liked BASIC all that much with a short term exception of BASIC on RSTS/E back in the mid-80’s until I became proficient in Macro Assembler.
Steven: Thanks. That will be useful for the readers of the blog.
hi joe,
> Perl verbose?
my reaction was a bit suprized, if you call PoSH verbose I would think that goes for PERL also as I think PoSH is much closer to PERL as COBOL in this aspect.
> I was thinking sheer number of characters to type
as with PERL, you can do some real damage per square Character in PoSH
Some examples ( I agree not realy honest ones, but just some I picked from your blog :
http://blog.joeware.net/2008/04/02/1141/
could be done in one line of PoSH code ( as working with CSV files as object collections is the default in PoSH)
$i = Import-Csv outmp.csv
$i | select gplink
another one I took is translating text to objects :
http://blog.joeware.net/2006/08/21/539/
“SniffLocal V01.00.00pl Joe Richards (joe\@joeware.net) August 2006”
“PowerShell translation by /\/\o\/\/ 2008”
$ipc = ipconfig
$ip = ($ipc -match ‘IP.*Address’) -replace “.*: (.+)”,’$1′
$gw = ($ipc -match ‘Default Gateway’) -replace “.*: (.+)”,’$1′
“IP Address : $ip”
“Gateway Address: $gw”
“`nCurrent Routing Table”
route print
route add $ip MASK 255.255.255.255 $gw metric 10
“`nNew Routing Table”
route print
I will happily agreed this this is NOT a good comparison as in other tasks we could get completly different results.
and both PERL and POSH have there own strengths
the only point (as JPS made) as that you do not HAVE to be verbose in POSH, you can also be as pithy as PERL most of the times.
for some “some also unfair” Vbscript to PoSH oneliner example see this series on my blog.
http://thepowershellguy.com/blogs/posh/archive/tags/Hex/default.aspx
Greetings /\/\o\/\/
MOW: Ah the venerable import-csv. Brandon keeps trying to whap me with that one… One pretty big difference that I see between the perl version you are looking at and what import-csv does though is that I will never see
PS G:\temp\csvtest> $i=import-csv newcsv.csv
Import-Csv : Exception of type ‘System.OutOfMemoryException’ was thrown.
At line:1 char:14
+ $i=import-csv < <<< newcsv.csv with the perl version whether I have 128MB of RAM or 8GB of RAM. I could write a perl module that does the same thing as import-csv, I could call it import-csv in fact, and it could do the same thing including suck up all available memory and then crash. I don't see the various cmdlets like that as a differentiator, I just see them as pieces someone sat down and wrote just like they can write them for perl or other scripting languuages. As an example, there is a perl module for getting CRC info for a file or folder of files, single line. PowerShell could do the same in a single line assuming someone has written a cmdlet for it as well. Differentiators are things like the object piping. That is very cool. MSFT could have brought that to the CMD shell IMO though and did it without the .NET req. I see verbosity where I don't visualize a need in core items... -band/-bor/-bnot... what is wrong with &/|/!? The whole regex stuff seems a bit verbose as well... -match("somestring") (and -notmatch) versus /somestring/? -lt/-gt/-le/-ge... how about lt or <, gt or >, le or < =, ge or >=… The dashes/hyphens themselves. Not sure I see the need.
MSFT seems to think they needed to invent a whole language when, personally, I think they could have taken existing things and enhanced them with some certainly very cool ideas. Had they added regex’s and object pipelining to CMD think of the wide array of things that would already be available and all of the people in place that know how to use the stuff and this is just a small add on delta versus something entirely knew to figure out? They could publish a standard for outputting from a program that the shell could convert to an object stream. Instead of requiring .NET to do it. That would be something that likely would take off across all operating systems as it truly is extremely cool new thinking (from what I am aware of). If they simply wanted to produce a .NET shell to push acceptance of .NET further, just get it over with and call it .NET shell, don’t try to make it seem like something else. Then they also could have made it so people could do the same they do with .NET and use vb.net, c#, *.net and have batch.net or vbscript.net as an extra add on.
joe,
Got me on the memory usage, and yes speed is a good argument 😉
As indicated, the value of this kind of comparisons is mostly amusement and building skills 😉
but good thing of PowerShell beeing based on the .NET framework as that it gives us instant access to all the libraries in the .NET framework, the same libraries the Dev’s (read .NET dev’s ;-)) use, and all 3th party libraries as on codeproject and codeplex for example.
if it’s realy needed we can even invoke Win32 API call’s (or IML assembly IronPython etc) directly prom PowerShell.
I even got a Python 2.5 library loaded in PowerShell as I needed pickle here : http://thepowershellguy.com/blogs/posh/archive/2008/01/11/posh-challenge-part-3.aspx
this give us a simular coverage as for example PERL or Python Libraries have.
and in PowerShell we could write a better Cmdlet to parse big CSV files for example.
and still I have all “good old”cmd utilities (ok, we can argue about the parameter handling ) almost as easy as from CMD.exe.
we might have to face that after years of neglecting, the current CMD.EXE might have become to legacy to bould upon.
back to Topic 😉 , I still think comparing PoSH to Cobol was a “bit overdone”
I think I could keep up pace with Python at least in this series : http://thepowershellguy.com/blogs/posh/archive/tags/PoSH+Challenge/default.aspx
Greetings /\/\o\/\/
PS, I overlooked this remark, this is funny
> how about lt or ,
this is done to make Redirection “>” possible
See our other discussion ;-).
Greetings /\/\o\/\/
Heya,
point is quite simple – if you are building complex scripting environments (frameworks) and you need to maintain them and teach other people to use (or even worse, support them), verbosity of PowerShell is huge advantage… When using in interactive session or in scripts that only I am going to use, I use aliases…
One thing I can see with powershell is a chance for someone to get decent at it and really becoming valuable to their organization.
I’m not talking about getting as good with PS as Brandon because that is not realistic for most of us but I see a lot of people ignoring power shell (and they are not good with other methods like you)
Just seems like it could be a good niche within an engineering/admin team.