|
The days of 16-bit minicomputers (PDP-11 class) were in the period when alpha radiation was being discovered as a source of bit rot. People were seriously afraid that 64 kbit memory chips would be the end of the pat for static RAM, fearing that we would have to use dynamic RAM (i.e. flip-flops) in the future, or develop some completely new memory technology, not Si-based. (Such as waves in mercury filled tubes  ).
The video mentioned ECC RAM, but not in much detail. The first computer I got to know in any detail was a 16-bit mini where the customer had a choice between 21 and 22 bit memory cards. Each 16 bit data word was protected by either 5 or 6 ECC bits per 16 bit word. I believe that the 21 bit memory could automatically correct any 2-bit error, while the 22 bit version could also detect 3 bit errors.
When I some 15 years later got my first PC, discovering that common PC RAM doesn't even have a simple parity bit, my reaction was What??
I never found a good explanation of what happened with RAM production, how they got around the problem. The alpha radiation certainly didn't disappear. RAM chips of today are six orders of magnitude(!) as dense as those 16 kbit chips mentioned in the movie (and each memory cell is correspondingly smaller). Yet, RAM chips do not suffer from those problems. I'd like to know why not!
|
|
|
|
|
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 .\command
Why 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
modified 16-Nov-21 13:57pm.
|
|
|
|
|
PowerShell just baffles me. For me I don't really spend a lot of time writing scripts. At the beginning and end of projects mainly for generating or loading images (bamboo server stuff). cmd.exe has simple syntax and I can search for examples and get a script up and running quickly, bash is another straight forward tool. But PowerShell, if you haven't used it in a while it takes days to get even the most simple thing to work. When I'm told to run a PowerShell script they never work the first time (typical MS). I worked briefly at MS years ago (was fired, I can laugh about it now, the area I worked in failed miserably and was disbanded) but it is filled with people that think they are at the top of the food chain, look at the 10 billion dollar mess Windows CE was. It was like being in a cult, I said early that Windows CE would never work (I worked on bare metal systems enough to know) and they looked at me like I was stupid and said their mom wears army boots. I have to say the new CEO is doing a great job all things considered. PowerShell is just one example of a group that got paid good money to write software that didn't have a hard "earn money" metric. In the end they are the smart ones, get paid to write software that no one cares about when looking at the revenue numbers. Its like the CA life guards that get $120k and full pensions. So when looking at that sometimes I do feel stupid but I like having challenging projects to work on.
|
|
|
|
|
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". 
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.
|
|
|
|
|
|
|
True story! 
|
|
|
|
|
Totally agree with this. Tried Powershell, hated it. I'm old enough to remember when the whole point of an IDE was to assist in moving away from arcane command line tools so that the developer could focus on the application being developed. My personal theory is that universities teach using *nix command line tools, so graduates only know those tools. But many of those tools date back to the 1980s (or earlier) and back in the 90s we would have thought that they were hopelessly outdated. We'd moved past that, or so I thought. It's like the younger developers don't even realise how much easier everything could be...
|
|
|
|
|
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.
|
|
|
|
|
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. “
|
|
|
|
|
Man, PowerShell is the forbidden tool that is not for mere mortals to use! That's where you got it all wrong! 
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
