January 18, 2017 at 10:32 pm
Comments posted to this topic are about the item The (Former) Complexity of PowerShell
January 19, 2017 at 1:39 am
The PowerShell of today is almost unrecognisable to the PowerShell I was using commercially in 2007. There has been so much simplification without dumbing it down. It is a great story of software design success.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 19, 2017 at 2:53 am
These days I doubt I could function well without Powershell.
I use it to poll all my servers and create an excel report on the backup status.
It is an incredibly powerfull tool and look forward to its further development.
January 19, 2017 at 5:53 am
What would really be nice is if MS would build in such great functionality into T-SQL and SQL Server itself. I suspect that the ISO and portability zealots would take strong exception to all of that, though. What the hell... we can't even get them to add a machine-language level Tally function to the product never mind them making it easier to do backups or effectively monitor disk space at enterprise levels or have an effective method for handling external files for purposes of ETL or even do a bloody bulk export.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2017 at 6:02 am
And then there's things like the following post...
https://www.sqlservercentral.com/Forums/1851783/parsing-records-with-empty-spaces
Why is the user insisting on doing such a thing with PowerShell?
1. Whomever created the data doesn't understand the concept of avoiding hierarchical data (although it's not as bad as the tag bloat associated with XML, JSON, or any other markup method).
2. The OP doesn't have a clue how to do this in SQL in a fairly easy manner so they've fallen back to a method they don't actually know but think should work rather than learning how to do it in SQL.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2017 at 6:15 am
Think I will have to catch up with PowerShell this year. I last used it about five years ago and although powerful it was very complicated to use at times especially as my MS-SQL involvement was reducing.
January 19, 2017 at 7:07 am
They say that PowerShell will legitimize the use of the CLI on Windows.
All us illegitimate children that have been using the CLI for decades say, "Welcome!" 😛
January 19, 2017 at 8:16 am
PowerShell is an extremely feature rich language; I'll give it that much. But what a dislike about PowerShell is it's syntax. It's a hodgepodge of commands, functions, switches, and pipes. It's as if the folks who created PowerShell consisted of C++, Visual Basic, and Python programmers who couldn't all agree on what language to standardize on, so they decided to compromise by splitting off into separate teams.
For example:
get-process | get-member
get-pssnapin | where {$_.vendor -ne "Microsoft"}
Comparison operators are switches. For example:
if ("Peter" -gt "Paul")
{
...
}
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 19, 2017 at 8:16 am
chrisn-585491 - Thursday, January 19, 2017 7:07 AMThey say that PowerShell will legitimize the use of the CLI on Windows.All us illegitimate children that have been using the CLI for decades say, "Welcome!" 😛
BWAAA-HAAA!!!! A strong second to that! 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2017 at 9:02 am
Eric M Russell - Thursday, January 19, 2017 8:16 AMPowerShell is an extremely feature rich language; I'll give it that much. But what a dislike about PowerShell is it's syntax. It's a hodgepodge of commands, functions, switches, and pipes. It's as if the folks who created PowerShell consisted of C++, Visual Basic, and Python programmers who couldn't all agree on what language to standardize on, so they decided to compromise by splitting off into separate teams.
I would have preferred they had taken an existing scripting language like Python or Iron Python and leveraged the base libraries and .NET.
I actually find the syntax of F# to be much easier and enjoyable then that of PowerShell. Even the folks at Microsoft agree at times:
The example above highlights another aspect of functional languages: programs tend to be concise. The four lines of code from the program above would be expanded to many more if written in imperative style. This may look like a contrived example but at the scale of Springfield, it yields a codebase that is very easy to maintain.
In fact, we could quantify this phenomenon when we ported some of our components from other languages to F#. In order to remove some legacy dependencies, for instance, we ported a Perl script to a 37% smaller F# program. In a separate effort we ported 1,338 lines of PowerShell scripts to just 489 lines of F# (2.7 times smaller). In both cases, despite the code size reduction, the resulting F# program improved logging, readability and reliability (due in part to static type checking).
January 19, 2017 at 9:57 am
chrisn-585491 - Thursday, January 19, 2017 9:02 AMEric M Russell - Thursday, January 19, 2017 8:16 AMPowerShell is an extremely feature rich language; I'll give it that much. But what a dislike about PowerShell is it's syntax. It's a hodgepodge of commands, functions, switches, and pipes. It's as if the folks who created PowerShell consisted of C++, Visual Basic, and Python programmers who couldn't all agree on what language to standardize on, so they decided to compromise by splitting off into separate teams.
I would have preferred they had taken an existing scripting language like Python or Iron Python and leveraged the base libraries and .NET.
I actually find the syntax of F# to be much easier and enjoyable then that of PowerShell. Even the folks at Microsoft agree at times:
The example above highlights another aspect of functional languages: programs tend to be concise. The four lines of code from the program above would be expanded to many more if written in imperative style. This may look like a contrived example but at the scale of Springfield, it yields a codebase that is very easy to maintain.
In fact, we could quantify this phenomenon when we ported some of our components from other languages to F#. In order to remove some legacy dependencies, for instance, we ported a Perl script to a 37% smaller F# program. In a separate effort we ported 1,338 lines of PowerShell scripts to just 489 lines of F# (2.7 times smaller). In both cases, despite the code size reduction, the resulting F# program improved logging, readability and reliability (due in part to static type checking).
I don't really compare for the comparison operands (-lt -gt, -lte, -gte, etc.) as they are very aesthetically unpleasing when compared to a C based language but PowerShell simplifies many tasks through the use of piping. It may be a non-standard way of passing output but it is very simple, for example, to create, overwrite and append flat files using such concise syntax e.g. FlatFile1.txt >( or >>) FlatFile2.txt. Not only that, it supports regex and can do a great deal of things without having to import namespaces, etc. I am currently reading a fantastic book by an author named Bryan Cafferky called: Pro PowerShell for Database Developers. It is fantastic for DBA's and developers working with SQL to show how to truly unleash PowerShell for SQL Server. IMO, Microsoft really needs to work on its PoSh evangelization so that more IT pros will leverage it and continue to build the community.
January 19, 2017 at 10:40 am
I can see where Powershell would be incredibly useful for a system administrator and/or, perhaps, a DBA, but I'm neither a system administrator nor a DBA and I haven't found that many cases where it would seem an attractive adjunct to anything I'm doing. As a result, when I do find myself in a situation where I think it would help, I can't remember any of the syntax, etc., and need to spend more time refreshing my knowledge than it would take to just go do whatever it is I'd hoped to script out. Part of the reason that its utility seems to be limited is that, like most scripting languages, it works best when the tools it is interacting with were designed to work with it. Being able to access a tool's object model directly is great if the object model is exposed and was designed with an eye towards automation, but most were not. The reason Unix's scripting languages became so popular is that most of the tools in the operating system were designed from day 1 to work in a pipeline so a scripting language that can manipulate pipelines was pretty much guaranteed to get used.
IBM introduced a scripting language called REXX for their mainframe systems (back in the 70's or 80's if memory serves). It took a different approach and required a tool to include a portal which REXX could link up to -- once linked it could manipulate the tool through any commands exposed by that portal. I never used REXX on a mainframe but the language was adopted as the official scripting language of the Amiga computer (dubbed ARexx) and I used it fairly extensively there. It had similar issues to those of Powershell. Tool vendors who added portals with powerful automation commands allowed manipulation by ARexx to do some truly impressive things. Many tools either never implemented portals or did so in a manner which was ill-conceived or simply thrown together so they could advertise support (consider a word processor which allowed one to automate entry and editing of text but without allowing for determining what files were open, where the cursor was positioned or even to read the text in the file). The more support tools have for automation the more impressive will be the uses we will see in Powershell and perhaps at some point I will find it useful enough to learn it and remember it. I wouldn't hold my breath waiting for widespread support, however -- as I recall, when Microsoft introduced the concept of drag and drop in windows, many of Microsoft's tools were the last to implement the concept.
January 19, 2017 at 11:21 am
Eric M Russell - Thursday, January 19, 2017 8:16 AMPowerShell is an extremely feature rich language; I'll give it that much. But what a dislike about PowerShell is it's syntax. It's a hodgepodge of commands, functions, switches, and pipes. It's as if the folks who created PowerShell consisted of C++, Visual Basic, and Python programmers who couldn't all agree on what language to standardize on, so they decided to compromise by splitting off into separate teams.
For example:get-process | get-member
get-pssnapin | where {$_.vendor -ne "Microsoft"}Comparison operators are switches. For example:
if ("Peter" -gt "Paul")
{
...
}
I agree. The -eq gets me constantly. Less now, but I still think in terms of >, <, = rather than switches.
January 19, 2017 at 12:29 pm
I just recently started using powershell so I can't comment on how it was years ago but I will say that a lot of tasks that would either have been impossible or very cumbersome in batch or vbscript are very easy and intuitive once you learn the basics of powershell's design. Recently I had to tweak a script that executed some commands over a remote session, those commands would occasionally freeze, it was pretty straight forward to set up powershell to timeout those commands after awhile and kill the session.
I don't particularly mind the switches in comparison operators but one of the good and bad things is that a lot of arguments are extremely over loaded but very poorly documented, can I send that parameter a file handle, a string path to the file, a regular expression, an array of any of the above? Try it and find out cause it's not documented anywhere.
January 19, 2017 at 1:28 pm
Steve Jones - SSC Editor - Thursday, January 19, 2017 11:21 AMEric M Russell - Thursday, January 19, 2017 8:16 AMPowerShell is an extremely feature rich language; I'll give it that much. But what a dislike about PowerShell is it's syntax. It's a hodgepodge of commands, functions, switches, and pipes. It's as if the folks who created PowerShell consisted of C++, Visual Basic, and Python programmers who couldn't all agree on what language to standardize on, so they decided to compromise by splitting off into separate teams.
For example:get-process | get-member
get-pssnapin | where {$_.vendor -ne "Microsoft"}Comparison operators are switches. For example:
if ("Peter" -gt "Paul")
{
...
}I agree. The -eq gets me constantly. Less now, but I still think in terms of >, <, = rather than switches.<
One of my goals for the year is to increase my proficiency in PowerShell and I'll agree with the comments about the whacked syntax (being a long-time fan and heavy user of Python for, well, everything I'm not using T-SQL for). It has, in the past, introduced a lot of friction when I try to put a script together, leading to discouragement and sporadic use. The verbose cmdlet names (Get-TheCompatibilityLevelOfThisDatabaseYouSpecified etc) were kind of off-putting, but using something like ISE makes life a bit easier there.
Coming from the UNIX world I think 'piping full-blown objects, not just text around' is pretty awesome so with a more committed effort perhaps it will become my third or even second favorite language for things.
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply