PowerShell Inventor Jeffrey Snover Interview
evrone.com
evrone.com
And to my surprise I found an example and could indeed open the file in the real office powerpoint, export as a pdf file and close it for each one of them with like 8 lines of code. Hell, I could have probably done it in parallel with a single flag (but that didn’t work on my version) In a way, Windows out-UNIXed linux, because contrary to the latter’s philosophy, you don’t really get communication between components because everything is unstructured.
Linux’s analog would be dbus, but that is not integrated with the shell natively.
In your case, the powerpoint program would never be called. You would simply send the powerpoint data to a program that converts powerpoint to maybe postscript, and you would send the postscript to ghostscript to make a PDF.
The unix like a approach is a bit more decoupled.
I cannot think of a single GUI program on linux that works this way (xfig maybe?) but in my mind, this would be the unix way. Of course by the mid 90s, the unix way lost out to the windows way so our GUI world on linux has something of a personality disorder.
I will be hated for this, but systemd would be another good example — you really can’t and should not subdivide such a complex problem into more specific ones. It should be tackled in one place (although systemd is quite modular besides that)
Where is the complexity and overhead? Ppt exports PDF files just fine, would it really be so complicated to move that to an external program?
Powerpoint is made for correctly understanding .ppt(x) files. This complicated functionality should probably not be replicated at other programs as well.
And even GNU/Linux could offer a similar experience if the ecosystem would actually buy into D-BUS or KParts, but that isn't never going to happen, and when only in a specific distribution, with the distribution specific apps, largely ignored by the remaining eco-system.
libreoffice --headless --invisible --convert-to pdf *.pptxhow is it ad-hoc? this IS the unix interface: command line params mixed with stdin/stdout
instead of DDE/OLE/COM/DCOM/DCOM+/ActiveX/CLR/whatever_it_is_this_week bullshit (mixed in with mountains of crap in the registry)
The reason bash is cool is because i can open it up, and run all these different programs written by different people, in different languages, for different use cases, and they all just work. It's the diversity of the ecosystem that makes the interoperability so cool. If it was all made by a single company, I'd say the usability is a fucking mess.
Until then, the footprint is too big, and the installed base is too small.
Microsoft itself is responsible for the POSIX shell - it was required to compile into a 64k text segment on Microsoft Xenix.
Without Bill's beloved Xenix, ksh88 would have been the POSIX standard.
It's all Microsoft's fault.
I simply cannot relate to this prioritization.
Exactly, that's why having to guess command/args and google the man-page is way less productive by a lot. For minimal productivity gains in the time it takes you to type a few characters you've wasted minutes.
Another big benefit mentioned elsewhere is that you can bring in C# directly into the shell.
The other thing is that idiomatic PowerShell takes a "Python perspective" that scripts are often read way more often than they are written and the best, idiomatic examples often use the most verbose forms of names to make things clearer to read.
PowerShell has a very rich aliases system with many, much shorter names for almost everything (and the ability to define your own to your heart's desire; and the ability to list which aliases are active on a current system), and you absolutely can code golf PS1 commands down into very bash-like lines. Most PowerShell veterans tend to write extremely terse stuff at the REPL even when in scripts and online documentation they try to stick to the idiomatic verbosity for others that need to read the scripts and understand what they do (even sometimes themselves months or years later).
Not only use of cmdlet aliases make shorter syntax but also:
- Shortening parameter names to unique prefix
- Use of parameter aliases
- Use of automatic pipeline property binder
In my experience achieving the same or shorter one-liners for the same task as with bash is typical.
But an example that springs to mind for me is "Get-ChildItem".
Two default aliases for this PowerShell command are `ls` and `dir`.
PowerShell seems to build upon data structures, can pass these around much in the same way that is done in the REPL of an interpreter.
Unix shells lean on the file system for that: if you want to "really" pass around data structures, you pass the name of associated file handles, as defined in the namespace of the virtual file system (VFS).
It turn out that the unix way is usually quite sufficient for interactive sessions. Remarkably so.
But I can write PowerShell functions that do type checking. I can sign PowerShell files with a certificate that implements a security policy...
Stuff like that can be done by a Unix shell and VFS in 2021, but the complexity trade-offs start to favor programming environments with a typed call stack.
PowerShell cmdlets (which is all built-in commands, most first party commands, some second and third party modules and wrappers and anything you can easily do in writing your own functions inside scripts) all share a single argument parser, rather than the usual command line application status quo in other shells where it is every app for itself in argument parsing and some programming languages are better than others at it and some libraries in languages are better than others.
One thing the cmdlet argument parser is good at is that it does make it really easy for the cmdlet author to add aliases (alternate names) for arguments (which PowerShell calls Parameters to the cmdlet) right next to where you define your Parameters. As a comparison, this is equally easy in say Python's argparse where you can provide a list of possible argument names in addition to just a single name. (If you are rolling your own in, say, C it may feel a bit harder.)
The other thing that PowerShell's shared argument parser supports is it always allows you to use the shortest non-ambiguous prefix to name an argument. (This is also something that Python's argparse does by default. Other languages/libraries it varies.) Which is basically that it always supports the "tab completion" automatically without actually having to type tab or "complete" the argument. For instance, the Remove-Item cmdlet often used by the alias `rm` doesn't seem to have any obvious aliases for its parameters, but `-r` works just fine like you would just about expect from other things named `rm` because there is no other parameter that starts R other than "-Recurse". It almost works equally well for Remove-Item's "-Force" parameter with the small hiccup that there is also a "-Filter" so you need `-fo`.
Another thing these last couple things demonstrate is that PowerShell's shared argument parser is case-insensitive. (Python's argparse is not, which is where the shared similarities stop.) PowerShell parameters in documentation are almost always shown in PascalCase for readability but most day-to-day use I see tends to be all lower case just like you just have to do in bash (`rm -r -fo`), only in PowerShell it is an option if you are into brevity rather than the only language that these cmdlets understand/parse.
Having a shared parser for all of this across so much of the shell (and easily used when writing your own functions which are treated as cmdlets just the same) means that you can count on it pretty much everywhere and you don't have to know anything about what language your command line tool was written nor worse what library in that language was used for argument parsing. (Python's argparse was only added to the standard library in Python 3.2! There's still tons of Python command line tools in the wild that don't use argparse at all and manually parse their args or use older libraries with fewer features from before the Python team declared a "winner" and added it to the standard library.)
https://devblogs.microsoft.com/scripting/learn-about-using-p...
If you pipe objects around between cmdlets, PowerShell will auto-bind object properties to cmdlet parameters. Which feels like the magic of the Unix pipe text streams everywhere but lets you skip several text parsers (no grep/awk/sed intermediates perhaps) and feels like even more magic when it just works: `Get-Process -Filter something | Stop-Process`. The blog post gets into some of the details of how it works and that it isn't just magic and that in PowerShell you can even inspect with tools like Get-Help to discover how it is doing it and use that to your advantage to automate complex tasks with very simple command lines.
So, you want them to use it a lot when they don't like it?
Takes care of the parsing and makes pipelines less brittle for sure (just look at things like NO_COLOR [0] that are basically "please adopt this so we can stop having to add endless edge cases to strip ansi color codes") because it keeps data flowing between programs into a machine-friendly format. It's only when it reaches a human that it is formatted for a human to see.
Then when you peel off the surface you realize you can invoke C# directly from the shell. That's right, either you can import any C# .dll out there and call it from the shell or flat out write C# in your script and have Powershell execute it at runtime [2]. You can add syntaxic sugar to make your dll easier to work with but any C# dll can be called from powershell.
As a side effect, this means that if you have a front-end/back-end app with the back-end written in C#, you also have a (bad) scripting interface basically for free.
A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
Really what Microsoft should have done is to make those plugins available to C#. Then make C# usable for scripting purposes -- C# is as easy as most scripting languages in any case, and now with "top-level statements" you don't have to write classes. Make C# usable like Dino for TypeScript (i.e., transparent compilation). Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
Some of the things are not... ideal. And there's a bunch of legacy stuff in modern powershell that we could do without, but a REPL scripting language with pipe semantics is really useful on a day-to-day basis.
I'm not sure C# would work as a shell language at all.
"It isn't what I'm used to, therefore bad, now let me figure out why." After that the length of commands is an easy target, in particular if you don't know enough about it to criticize it for anything substantive.
Powershell is based on small composable commands that are easy to chain together - as you would know if you've used it at all.
Valid criticisms exist of powershell. It baffles me why Linux refuseniks trot out such easily-discounted objections. My belief is that it's a figleaf over a political position: "I will never use a Microsoft product". We're on HN; that's an acceptable position. Why bullshit?
2) You just keep hitting tab until you get the one you want. This is the tab completion behavior of the Windows command line since it added tab completion.
C) Did I mention it's configurable? https://stackoverflow.com/questions/8264655/how-to-make-powe...
https://github.com/lukeschlather/dotfiles/blob/master/src/Wi...
That said, tab completion works, and I used PowerShell on macOS for a long time with no complaints.
Having Invoke-WebRequest originally use the IE engine for parsing by default was also a terrible idea, but at least they reversed that one.
for scripting I'd personally use neither.
Even without the hyperbole you have a comically exaggerated idea of how long it takes to write quick one-liners in PowerShell. For me personally, it helps a lot that I don't have to look up cryptic three-letter command names, obtuse switches, or the precise sed incantation to glue things together.
- They have a list of standard verbs: https://docs.microsoft.com/en-us/powershell/scripting/develo...
- Every command is verb-noun. So get-[whatever], remove-[whatever], set-[whatever] etc.
Therefore, you can guess get-process would be a command as is stop-process or start-process.
That's not a very high bar to exceed. A glass of water seems like champagne to someone in the desert.
The main reason for this though, is that I can use some familiar Linux commands and I don't need to google how to list files in the current dir (PS and bash both have ls, among others)
Can any scripting language check for that? It is beyond the scope of what an interpreter has available to it.
> PowerShell as a scripting language is a major PITA.
Well, except this part.
> After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted.
As mentioned by another commenter, the PowerShell script is parsed up front, so it probably wasn't a syntax error. My guess is the script lacked error handling and some query or connection to a remote server failed.
> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
There we go agreeing again. Although, PowerShell is effectively self-documenting, which is good for busy sysadmins.
> Really what Microsoft should have done is to make those plugins available to C#
A lot of them effectively are available to C#, such as System.DirectoryServices.*. In the early days of Active Directory, before PowerShell, this is how we did things. While fun for us programming nerds, it took a hell of a lot more time to write usable tools.
> C# is as easy as most scripting languages in any case
Hard disagree.
> Make C# usable like Dino for TypeScript (i.e., transparent compilation).
A more C#-like scripting language? I'm all for that, but why not just use TypeScript at that point (ala the JScript days).
> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
No, you run into the exact same challenges, whether it's PowerShell or C#.
IMHO, while I'd rather be doing C# programming any day of the week, PowerShell is more approachable for the vast majority of Windows sysadmins out there. Additionally, due to the command... verboseness of PowerShell, it is effectively self-documenting.
Edit: Snover's original Monad Manifesto paper is worth a read for his reasonings about what is now PowerShell: https://www.jsnover.com/Docs/MonadManifesto.pdf
It might be best summarized by this partial quote: "PowerShell replaces fragile, prayer-based text parsing with pipelines of objects (structured data)"
You shouldnt speak down to a whole group of very intelligent people like that.
IE, the vast majority of SYS admins aren't capable of approaching C#. Fully unsubstantiated heresay. If they can learn the cryptic nightmare that is power shell, they can certainly learn C#.
"A lot of sysadmins:
1. Aren't "very intelligent"."
A spade is a spade.
There’s very few times that I need to write a Powershell script that runs like a daemon. I’m typically using it in a notebook in VSCode, but I do* have Kubernetes jobs that are written in Powershell that run periodically. They were quick and effortless to write, run fast (dotnet core,) and are easy for my team to understand if they want to modify them or someone needs to maintain them.
None of my team would willingly learn C#, nor would the business support them writing C#. A powershell script though? Fair game for anyone who wants to look at something new and innovative, it requires nothing if they use ISE, and if they want to, VSCode is already an approved app. Need a hosting platform? You can deploy on Kubernetes if you really want.
It’s a really big barrier to entry to force someone to use C#.
1. Aren't "very intelligent".
2. Aren't smart enough to learn C#, let alone well enough to do systems programming to replace PowerShell.
3. Don't have the time/desire to learn C#, even if they are capable.
4. Don't have the time to write systems management code in C#, as opposed to PowerShell.
Back when I started UNIX system administration, pretty much all sysadmins knew C and could write arbitrary system management utilities in C.
This is no longer the case, for better or worse, the world needs more sysadmins and Microsoft has released server software that can be managed by relatively minimally-skilled people who know how to Google and copy/paste code from websites.
>A lot of them effectively are available to C#
True, though some of them aren't. I ran into one recently...setting the metric value for an ip interface (not a route, an interface). Powershell has that, C# does not, in any way that I can find.
It can be done in C# via WMI (System.Management), but that's a strange old world if you're not used to it. But it's more convenient in Powershell because MS provide modules such as NetTCPIP so you don't need to touch WMI directly.
Oh no it isn't. Very basic stuff like Get-Something piped into a Remove-Something is, but beyond that, it gets complex quick. Add aliases, weird logic and limitations ( do you know you can't break out of a Foreach-Object?), and it quickly becomes an illegible mess that needs parsing, the same way Python might.
Furthermore, a lot depends on the cmdlet provider, and for instance the VMware ones are steaming piles of horseshit with inconsistent naming of parameters, broken async, and useless error management ( e.g. you get an error which says to check the inner exception, but it's empty and there's no way to get any detail whatsoever).
And I say that as someone who really doesn’t like windows (and thinks it is not fit for development at all) — but powershell is really a gem, if one gets over the at first strange syntax and actually looks into it.
I don't because you can.
> Furthermore, a lot depends on the cmdlet provider,
WTF, bash is unusable unless grep, sed, awk and friends are present .
No one is calling bash self documenting, so that comparison doesn't mean anything.
it's not ideal but tapping into the whole system with a coherent syntax / object network is cool and you have blocks / classes to clean up your logic
you can even tap directly into .net (for some reason there's a shortcut to load and compile a god damn source code string)
It seems you're comparing it to ruby or python, am I right ? because IIUC powershell was more a MS OBash for Windows (without bash eternal fingercuts)
https://docs.microsoft.com/en-us/powershell/scripting/develo...
Think of it as the .NET and PS equivalent of a manage.py script.
I agree that PS as a language is quite unusual (e.g. how it returns results) but on the other hand it’s concept of structured data also makes it powerful in ways that old-school Windows scripting or bash are not.
> The provisioning takes 2 to 3 hours. After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted
Anybody who designed such thing is bad. If stuff fail after 2 hours, you should be able to repeat it in idempotent way to just continue or you skip sections with parameters. Your syntax error problem is the same in any other shell, and in all dynamic languages.
> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.
Nonsense. I almost never use any of the "plugins". PowerShell on its own is game changer. Like the first dude already said, I have yet to see a problem that can't be done in 2-5 lines of code that is joy to read even in shorthand form, unlike countless magic chars, something that is known to be bad pattern in OOP.
> Really what Microsoft should have done is to make those plugins available to C#.
That is really NOT what Microsoft should have done instead of PowerShell, maybe alongside it. But since you have PowerShell, you don't need it that much. Besides, it already exists for almost decade.
> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.
You can do this today.
I'm not sure if the web could have worked any other way. RPC over HTTP and other message/pub-sub web technologies are largely used by enterprise-level applications, and not by modern web sites, correct?
Here's another example where it's discussing a weakness of MSVC, and every other sentence is just passive aggressively blaming the world for Microsoft's problems: https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=10...
His book, The Old New Thing, is like that throughout.
Yes, but most RESTful apis are backed by an OS that is file oriented. Why? because the server deals with persistence while the API deals with compute. The Windows approach is not winning, hosting APIs on the file oriented OS works better for most. Why? because ultimately APIs are a compute problem not a persistence/storage problem. That said, for interacting with a RESTful api, what tool do you use? A programming language like JavaScript, C#, Python, or Java or a shell scripting language like bash, zsh, or PowerShell?
No? Most RESTful APIs are backed by databases. There's are a lot of variance there (Sql, NoSql, Cloudy Vs. Monothithic) but it isn't files. Even for file storage and delivery databases BLOB storage are often used rather than filesystem files.
When all you're using a filesystem for is storing a large continuous memory-mapped blob so that you can avoid interacting with the filesystem's APIs almost entirely, you aren't exactly championing a filesystem's utility in the internet age.
I'd go as far as to say that directly exposing filesystem files to the outside world is an anti-pattern (because it doesn't scale).
I also think it is disingenuous to talk about HTTP APIs when talking about shell scripting as if it's something that needs to be built into the fabric of the shells design when HTTP APIs can be an abstraction that bolts on top. In fact that's exactly how a lot of CLI tools work (awscli, Terraform, even Powershell scripts will make those API calls in composed functions rather than natively from shell).
It's also worth noting that Linux does have plenty of services that support RPCs too (X11, dbus, etc).
I'm not try to argue that Linux and Windows are equivalent though. Just that it's a little silly to argue that Linux can't do APIs.
CreateProcess is probably my favourite example
NT didn't inherit the problems of fork() with unix, but it's still a disaster of giant nested structures, combined with several different ways of creating lists of parameters (some params need quoting in weird ways, others need manual construction of arrays of null terminated strings)
whereas the POSIX APIs tend to be small, clean and simple
Don’t get me wrong, I really like linux. But I don’t think that posix syscalls are that simple.
"Uniform interface constraint" basically means using very few verbs (GET, POST) on nouns or "files".
This is in contrast to a more highly typed RPC style.
https://stackoverflow.com/questions/25172600/rest-what-exact...
I'd go even further than that and say the web is a straightforward extension of Unix (basically adding URLs, which are amazing, and data driven UI)
... And I'll go even further and say that the Unix-y design CAUSED the success of the web, and if it were more like Windows, it wouldn't have scaled to be truly "world wide" !
I know HN is a cloud-first developer community but there is an entire planet of businesses who are software consumers rather than software development firms. Windows is running /a lot/ of stuff even if you personally are not seeing it.
I know a lot of people don't like how verbose cmdlets are, but I find tab completing them to be just as fast and easier to remember than linux's alphabet of case sensitive switches that barely represent the underlying function.
Oh, and keep in mind that we evolved to this from .vbs, which was horrible.
I remember when I was new to shell scripts, thing like basic if loops felt clunky. I would see something like "if [ -r $1 ] && [ -s $1 ]" and not even now where to start. Case statements I could only write by taking an existing one and modifying it.
These days I tend to use Python for all my scripting everywhere I can.
Even within the unix community there are efforts like Elvish and NuShell trying to be more like PowerShell because it's obviously better.
Most Microsoft sysadmins will be living and breathing it.
param statements get you auto-complete, and docs. Powershell can just ingest and deal with JSON, and are one module away from doing the same with YAML.
Using % and ? (aliases for 'Foreach-Object' and 'Where-Object') ends up working very well for most data manipulations that one might be interested in.
It definitely has it's quirks as a language, but so does literally every shell in remotely common use.
And I'd say that Powershell is appropriate for non-trivial scripting use, as long as you familiarize yourself with the conventions for handing data to/from functions vs pipelines.
I've written more than one piece of above ad-hoc software in Powershell, though this is the only one I have in public: https://github.com/yumaikas/psi.
Microsoft should have just adopted an existing shell. They may have problems but the problems are well known and workarounds are well known too. PowerShell is NIH syndrome in action. It has an equally large set of different problems that are unknown. It's a whole new set of quirks and workarounds to learn when you just want to get something simple done.
The only good thing I have to say about it is that it respects my "ls" and Ctrl-R muscle memory.
The end result is I can't really ever get much done without a lot of googling. But thats par for the course these days I guess.
Granted some things are easier done in Linux with a quick bash script. But anything fancy using an sql, api, json and file system I've found ps wins.
But don't get me started with dealing with older versions of PS on production systems.
I no longer work with PowerShell (or Windows) but I still have fond memories.
I remember testing out some new languages and toolchains and following the guides, but I would often get many of them that would not work because I was using powershell. Powershell has different syntax for escaping (backtick), starting arrays (parens), etc., that makes many commands completely incompatible (even very short ones).
People feel inconvenienced, which I get, but I feel like people don't give it enough credit for just how well-thought-out the design actually is.
Once you grasp it (which is admittedly easier if you know a Java-like language) your productivity skyrockets as commands are largely guessable and results are largely self-documenting. They have man-pages/get-help, but when an object is self-describing you don't need them as often.
The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
By why does having richer return types necessarily mean you need to deviate from most other languages for the escape character (backtick in Powershell, but usually backslash)? That doesn't seem related, and it greatly impacts the initial impressions people get.
> The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
I agree, and I hope someone does. But if they do, I hope they just focus on the ideas, and leave out the small and unimportant incompatibilities powershell decided to add.
I honestly think someone should do this "from scratch", as you say. I believe the effort would be worth it, but I doubt that the unix community would be amenable to the idea as it goes against their deeply held cultural traditions.
Java borrowed a lot of syntax from C, and it has been very successful. If Java had instead taken the powershell approach of needlessly deviating with the syntax, it probably would not have become as popular as it did. So that example supports the opposite of what you thought it does.
I agree that doing noun-verb would be easier for autocompletion purposes, but I suspect that ordering was chosen to align more closely with english grammar, specifically https://en.wikipedia.org/wiki/Subject%E2%80%93verb%E2%80%93o...
>Finally, options are also too long. Compare `rm -rf` with `Remove-Item -Recurse -Force`. Capitals, dashes, long words... It's too much!
but they're far more readable. You might be able to remember what -rf does for rm, but what does -o mean for curl? What's the difference between -o (lower case) and -O (upper case)?
rm -r -fo
Complaining about long capitalized names with dashes in them is a little weird in a language that is both case-insensitive and has tab complete for everything though.
Possibly a good idea on paper. In practice, at least as an only occasional PS hacker, it always eats up a couple brain cycles.
https://docs.microsoft.com/en-us/powershell/scripting/develo...
gcm | sort NounIf I'd give an advice to new programmers right now, I wouldn't say learn PowerShell over Bash, because PS is just so niche.
Source? Seems to contradict this page. https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
Based on your link for public facing servers [1] MS Windows has a Market share of ~22%, which Unix-like operating systems have ~78%. [2] However, there are a lot of operating systems that make up that 78%.
Breaking that down even further Linux based operating systems account for ~49% of that ~78% [3], which means Linux based operating systems have a ~38% total market share compared to Windows market share of ~22%
And again, breaking that down even further Debian has the largest market share at ~35% of all Linux based operating systems. [4] Which means Debian has a total market share of ~13%. Substantially lower than your claim.
In the context of this discussion you can't make the claim that all Linux based operating systems can be lumped together as they all have varying default shells and different versions of shells, so the portability of shell scripts comes into question.
However, beyond this that's only publicly facing systems. There's no way to determine how many installs of each operating system there are in private networks.
Long story short, it's a silly thing to debate.
[1] https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
[2] https://w3techs.com/technologies/overview/operating_system
I partially blame Microsoft because of their idea to aggressively recommend non-aliased PowerShell for EVERYTHING (it backfires entire decade and they still do it, along with the army of "MVP"s, which is amazing head in the sand behavior when entire Internet bitch about it) and because they obviously don't manage user education well.
I then blame everybody else for not RTFM and always complaining about the same nonsense: verbosity, performance, missing short circuit bashizm etc.
Seriously people - PowerShell is one of the best inventions since the first computer that you can use on any OS. If you didn't grok it, its about ====> YOU <==== not about PowerShell.
Once the only real issue is solved (performance is not greatest, but not too bad either), it would border to incompetence to not put it by default on any OS.
- Cross platform
- Extensive Integrations and 3rd party ecosystem
- Generally much shorter code for the same stuff
- Package manager
AHK was never considered a general purpose language nor a good language. I was probably one of the first people to use it that way (See Forms framework). With AHK2 incoming it is much better language (although Lua would be way better instead).
AHK is oriented toward GUI automation, PowerShell toward CLI automation. AHK is not there out of the box on any Windows.
You can basically do anything in anything, but that doesn't mean you should.
Its a nice language, with some massively fatal issues, and awkward weirdness that takes me about 10x as long to sort out vs say c++, but its better then bash files on windows (it just doesn't work, really), or bat files on windows etc.
P.S. I'm a cross platform native developer, if windows wasn't in the mix, I'd probably stick to bash
Another thing that bothers me about it is how many Windows system administrators claim they can "script" or "code" because they chain a few cmdlets together.
He covers almost every point discussed here and then some.
Fascinating read, way more interesting than the small religious squabble here.