|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Well, that I learned the first few minutes using the thing. It took many years to discover the power hidden in there. 
|
|
|
|
|
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
|
|
|
|
|
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?
|
|
|
|
|
|
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
|
|
|
|
|
Chris Maunder wrote: Man. What happened to this industry?
Microsoft.
"If we don't change direction, we'll end up where we're going"
modified 17-Nov-21 5:51am.
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
You: ... 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 ...
...
When mostly, we're better off using the tried-and-true tools we're used to.
Until you are not better off using the tried-and true tools. Doing things as you used to (a.k.a. if it ain't broke, don't fix it.) leaves you susceptible to being wiped out as exponentially more efficient ways of accomplishing the same task are developed and being used by your competition.
Me from before: 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.
In your opinion, what's a manager to do?
|
|
|
|
|
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
|
|
|
|
|
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 
|
|
|
|
|
Permission to shout "Bravo" at an annoyingly loud volume, sir.
you nailed it "The complexity introduced by those who know their own tools deeply, and who in turn forget that we do not care about their tools, is staggering."
|
|
|
|
|
|
Butterflies, flitting
Zooming, soaring, while I toil
Stupid butterflies
|
|
|
|
|
I use butterflies in preference to using vi ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Obligatory xkcd: Real Programmers
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
|
|
She who? 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
