The downward spiral of unnecessary complication

[Henry Skoglund]

I once gave PowerShell a shot, I had a curl command line that was a bit tricky from good ol' cmd. curl is preinstalled on Windows 10 so it works fine from cmd. But using it from PowerShell? No dice, if you type curl in there you end up with a built-in "better"/"improved" version of curl, which does not have the same syntax as the real curl. Solution: to invoke the real curl in PowerShell, you have to type C:\Windows\System32\curl.exe and Bob's not your uncle.

[englebart]

I was always told that requiring .\mycommand was security related.(from Unix) “Never include . in your path or people will bury common exe names in directories. It is very easy to drop a custom ls executable in a directory that behaves exactly as ls, but will do other stuff when it detects you are root. “

[Super Lloyd]

Man, PowerShell is the forbidden tool that is not for mere mortals to use! That's where you got it all wrong! :O

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Super Lloyd]

True story! :-\

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[The Real Paps]

Why doing simple when you can make it complicated? Over time we've rather slowly moved from CLI (MS-Dos, Unix) to IDE. And now we're rushing back to CLI again. Everything is CLI now. Why? IMO, esp. the open-source community, with so many people adding their own little brick, exotic requirement, ego-trip, or whatever, is probably to blame. The whole thing ends up being one big bloated confusion of options and possibilities. Like an exaggerated Swiss army knife which next to the knife and screwdriver also has a chainsaw, axe, and whatnot. There's a German expression

eierlegende wollmilchsau

(look it up :)) which perfectly explains this. It's a kind of Jack of All Trades, but worse :) I'm so tired having to learn new commands all the time. I'm about to give up.

[lmoelleb]

Adding .\ is indeed not user-friendly. Instead it is secure. And as almost all security it gets in the way but is necessary. At least tab-expansion helps by prefixing the .\ automatically. The way PowerShell handles pipes is far superior to bash (bash pipes characters around, Powershell pipes objects). But the syntax is horrible (though to be fair... so is the syntax of bash). And when do people designing languages learn that fail on error should be default, parameters should only be optional if explicitly told so, you should not have "sometime methods must be called with parenthesis around the arguments, other times this will create an array and pass the array to the first argument... good luck" crap. So overall: Yes, I understand why PowerShell has the word "Power" in the shell. There might be other shells with equal power, I just don't know any. But the syntax... oh my that is CRAP. If you use it regularly you can learn I guess, but I tend to have to dig it out 3-5 times a year and always struggle.

[den2k88]

How is that different from Linux not loading executables outside of $PATH variable?

GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++*      Weapons extension: ma- k++ F+2 X

[Mike Winiberg]

The 'thing' about Powershell, for me, despite it's wierd syntax and complexity, is that it has access to all sorts of 'under the hood' windows stuff that is hard to manipulate any other way. Having said that, it's almost impossible to 'learn' as there is just SO much stuff buried in there. But I do have a little sympathy for the way this has grown into the beast it now is... There's no such excuse for the increasing complexity in just about everything else - especially programming languages. No doubt the script kiddies fluent in today's (as opposed to yesterday's or tomorrow's) version of C++ will say it's my failing - and they could be right - but when it became harder to work out how to use C++ effectively than it did to solve the (business) problems I was working on, I stopped using C++, despite having written some large applications with it. Nowadays more new 'best ever, replaces all that has gone before' frameworks come out every day, sometimes being significantly revised and updated before you've had time to even build a test prog, which is just madness. Ironically, my main work now is developing on a 19 year old app that has been in continuous use using MSAccess front end, SQL Server backend. I've added Python/Bootstrap/HTML5 frontending a web app linked to the data, same again to provide on-line card payments for emailed invoices, plus more VBA to hook the main app into Xero accounts. With the exception of Xero, none of this is new, shiny, exciting or modern in any way. You know what? It works and has improved the competitiveness of the business for many years - surely that's what software dev should really be about?

[RickZeeland]

Some alternatives can be found here: scripting-languages-for-writing-shell-scripts[^] If you have Git installed, you can also use Git Bash btw. :-\

[GuyThiebaut]

I agree that the .\ is a pain and I regularly forget it. That said I have found some of PowerShell's features to be very useful in writing scripts. In particular being able to use and manipulate .NET classes like List, which means that I can write a script which is reasonably readable, compared to one written in Windows Batch Script commands with all the horrors that entails.

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

[megaadam]

Chris Maunder wrote:

Man. What happened to this industry?

Microsoft.

"If we don't change direction, we'll end up where we're going"

[jsc42]

lmoelleb wrote:

I understand why PowerShell has the word "Power" in the shell

And now you understand why it also has the word 'hell' at the end of its name.

[Slow Eddie]

Possibly...

ed

[MadGerbil]

See: Webpack

[stratoFlyer]

I've done quite a bit of Powershell and curse it everytime... Powershell is basically a scripting language for .Net with allusions of being a shell. It's language design is just horrid though. You can see the influence of Bash (which is not a bad thing)... but it's completely out of its element. It's syntax is inconsistent between Powershell native objects/functions and .Net objects. I really wish Powershell had been some form of EMCAScript (ala... Javascript). That would have fit much better with .Net and sysadmin scripting as well as being much more accessible and consistent because you'd be leveraging what a lot of people already know.

[Steve Naidamast]

What happened to the industry? What happened is that vendors actually ran out of options to enhance existing tools. The tools we use had become very robust and mature over the years. Vendors on the other hand couldn't seem to accept the fact that not everything needs to change. Instead, they began to introduce esoteric features to our development environments and languages that targeted very specific types of work. However, instead of making such additions add-on modules for the developer to decided upon, things were just consistently added to our standard tools making our tools bloated with features that few of us need on a regular basis. As it regards Microsoft, Satya Nadella changed the entire focus of the company to that of Cloud Services subsequently producing new development tools that were thrown into the mix, leaving everything else to stagnate or be thrown out. That's what happened to our industry...

Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com

[Dave B 68]

I think the biggest problem here is that we tend to: - Assume we are the target audience that the tools we try to use were built for. - Assume anything we don't understand about why it works the way it does must be a flaw with the creator and not our understanding of the use cases and issues the tool was built to address. (i.e. in this case, the security of running a default application from the current path) - Assume that whatever we currently know should be sufficient to maximize productivity, or at least be efficient, with most tools we try to use. Those that have familiarity with a tool and are already 10x the speed of a newer (non vested) user are constantly demanding features and enhancements to gain another exponential 10x that you will likely not ever get to as a "casual" part time user of a tool. Each addition adds complexity, learning curve, and the likely failure to adopt a tool of new users. A tool that intentionally limits its complexity for new or casual users does so knowing that it is capping the productivity of its power users. In the end, you can't "win" (win = your stated desire) unless you find tools meant for exactly what you require now and in the future, that contain little more and little less than you need, and that have minimized all complexity beyond YOUR requirements. And there needs to be enough of you to justify the creation (AND MAINTENANCE) of such a tool. i.e. the value obtained must significantly justify the learning cost. Even worse, with so many tools out there and the true cost/value/issues only being truly known once YOU invested the time to learn the tool, we tend to "follow the herd" or an authority, which also allows us to be manipulated into acting outside of the best use of our time. And the true cost is not if you know the tool. It is the cost of making sure that everyone on your team now and in the future knows the tool in addition to the other tools they must know. In the end, specialization, massive dedicated learning in your specialization, teaming with other specialists, and understanding the true cost of fad tools and frameworks may be the best way to "win". But who wants to be dependent on someone else?

Dave B

[PIEBALDconsult]

Member 10621557 wrote:

we tend to: - Assume we are the target audience that the tools we try to use were built for.

I assume no such thing, but then I've been around a while. So many "shiny new things" are not aimed at users and developers, but at managers who read only "industry news" and blogs and watch videos and attend conferences so they can then return to their flocks and extoll the latest piece of rubbish as the wonderful newest thing which will save everyone time and effort. "As the boss it's my job to ensure that my workers always have the latest and best tools!" When mostly, we're better off using the tried-and-true tools we're used to.

[Idaho Edokpayi]

I am reasonably good at PowerShell, but I will fully admit to using Bing as my pair programmer. The other trick that I learned years ago is that hitting tab repeatedly from the PowerShell prompt to auto complete commands. It is only complicated when I fight what the platform wants me to do. I use PowerShell because nearly every Microsoft Platform exposes PowerShell commandlets for automation. Money!

Idaho Edokpayi

[Peter Shaw]

I once bought a powershell book, for one reason and one reason only. I was trying to get remote admin from a windows 7 machine to a hyper-v server working so I could administer the VM's on it from a GUI and not a powershell command line, why the book? It was the ONLY book I could find on any of the shelves in my book store that even mentioned winRM let alone anything else. I read only that chapter, realised how much pain I was putting myself in for, put the book on my bookshelf and it's sat there ever since never to be touched again. As for the Hyper-V server? I learned the .NET/WinRM api in less time than it took me to read the PS chapter on WinRM, and wrote a small service in C# in about half a day that solved the problem for me :-)