The downward spiral of unnecessary complication
-
Stolen from the Linux work around for path stuff, although many of the commands work without it. Reminds me of a project I worked on that was almost impossible to install and configure. The reason: "They told us the users were sophisticated, so we made it complicated to use". :sigh: Yesterday, I said something in the house and my wife wasn't there. Was I still wrong?
>64 If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
Possibly...
ed
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
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.
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
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
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
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
-
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.
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
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
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
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 :-)
-
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?
-
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.
-
Quote:
Suggestion [3,General]: The command go was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default.
My understanding was that PowerShell was to be the bestest thing ever, way more better than bash or cmd, or Windows Terminal or any of the billion shells out there. They even introduced a most inscrutable syntax to make it feel even more awesome. And yet, on my Plain Jane Windows installation, running as an Admin, with a PowerShell instance launched as Admin, I can't actually just run a program. I can, I just need to say pretty please by doing
.\commandWhy do they do this? Why are there constant barriers to productivity thrown in front of developers every day? I feel like I'm pair programming with Google when I code these days. And I've been coding a looong time. Programming used to be basic (no pun intended), then we got IDEs and integrated debuggers, and it started becoming fun, and crazy productive. We had intellisense, and auto-complete, and real-time linting and then...then they couldn't stop. 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. Their tools are a necessary evil. Their tools should be totally and completely hidden from view, even hidden from knowledge for new developers, and help, not hinder. Man. What happened to this industry?cheers Chris Maunder
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."