|
|
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? 
|
|
|
|
|
|
|
"Real Programmers" don't exist. We're all just hobbyists at heart.
ed
|
|
|
|
|
Real Programmers are just the Norm of complex programmers.
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
|
|
|
|
|
I recently had good success with a "no churn" salted caramel ice cream recipe so when I found a Nigella recipe for "no churn coffee ice cream" I just had to try it. Ice cream and coffee? No, hold me back! 
I'm a developer, and many of us run on coffee: some of us have "bean to cup" machines as a result.
So I bought a tin of Lavazza Instant Espresso (the recipe calls for instant expresso powder, and if it's good enough for the Domestic Goddess it's good enough for me) on the grounds that they should know what they are doing, where Nescafé and Kenco clearly never have had a clue.
And today I made a cup of instant espresso with it.
It was foul. Didn't smell of coffee, didn't taste of coffee - the "burnt taste" just overwhelmed and destroyed anything else - worse even than Costa serve, which is my benchmark for poor quality café culture.
So ... Do I risk it and make the ice cream? I suspect it'll be as bad ... 
"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!
|
|
|
|
|
Take a brick. Suspend it partially in the coffee so it can absorb the foul taste. Then throw away the coffee and chew on the brick. 
Get me coffee and no one gets hurt!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
