joeyaiello's comments

Yup, and it actually wasn't working until fairly recently (maybe a few months ago? I was keeping an eye on it for a while).

But yeah, it's even fully integrated into NixOS options now. You can set up a default install with one line: https://search.nixos.org/options?query=photoprism

I'm a PM and I ended up graduating with an econ BA instead of a CS degree, but I took a few intro CS classes at UCLA in...2011/2012.

Intro to Programming 1 and 2 were taught in C++. Can't remember which one taught pass by reference, but it was definitely in one of those two.

Third class I took was Intro to Systems or something like that. The whole class was C and x86 ASM. Lots of binary operations in that one, used K&R a fair amount in that class (also learned debugging assembly in GDB and some other "low-level"-ish stuff).

Just looked it up, can't say 100% it's still C++, but the syllabus looks about the same as I remember for both class. It gets to pointers by week 7, and then in the second class goes deeper:

* https://web.cs.ucla.edu/classes/spring22/cs31/syllabus.html#...

* https://web.cs.ucla.edu/classes/spring22/cs32/syllabus.html#...

And again, I didn't even get a CS degree. This was all lower-div CS work at a public university, and I'm not even a career engineer.

> So no, not knowing the difference between passing references or values, or pointers and dereferencing them is not as strange as you seem to think it is. It is not a piece of knowledge or experience that is seen as valuable enough by the people that create the curriculum or the companies that employ the largest quantities of inexperienced workers in this part of the world.

This attitude is why you're getting flak in this thread. Your claim that "We don't teach pass by reference these days" was too absolute, and not accurate for a ton of people. Then someone came back and told you that, and you told them that their claim was too absolute.

I'll also say that it's something that was absolutely valued around the orgs I worked in at Microsoft (Azure, DevDiv, Windows, very roughly bottom half of the stack teams). If not C/C++ pointers, than __absolutely__ passing by reference in C#.

Point being: __knowing__ about pointers, passing by ref vs. value, etc. is not as strange as __you__ seem to think it is.

I read all of it, as well as some more of your writings that I found, and I very much appreciate your thoughtfulness. I don't agree with everything you've said here, but you raise some very good points. Thanks, friend. :)

Unfortunately, we can't ever change that one, or the whole world of existing stuff will break.

It's intended as a shell semantic where anything bare on the command line just gets run, no matter your scope.

However when we introduced classes, we thought it was a more "dev-oriented" semantic, so we changed return there.

This will only return 'this will return':

  class foo {
    [string] ReturnTest() {
      'this will not return'
      return 'this will return'
    }
  }
  
  ([foo]::new()).ReturnTest()

Good to know! I've generally understood that the bar for package inclusion for both Debian and Ubuntu is fairly high (where Debian wants you to push to them and Ubuntu will pull from you).

Our setup today is simply to add an apt repo[1] (of which there is just one domain for all Microsoft Linux packages), and then you can `apt install`.

We also ship pretty minimal Ubuntu and Debian (and Alpine and a bunch of other) container images here.[2]

Oh, and we ship on the Snap Store if you're using Snapcraft stuff.

[1]: http://aka.ms/install-pslinux

[2]: https://hub.docker.com/_/microsoft-powershell

We've fixed a ton of these in PowerShell 7 (pwsh.exe, as opposed to Windows PowerShell / powershell.exe), particularly because we needed to support Linux and more of its semantics.

If you're seeing issues within PowerShell 7, please file issues against us at github.com/powershell/powershell

Thanks for the thoughtful response! Many of these are totally legitimate: in particular, we're making steady progress to centralize module design, release, documentation, and modernization, or at least to bring many teams closer together. In many cases, we're at a transition point between moving from traditional PS remoting modules and filling out PS coverage for newer OAuth / REST API flows.

I don't know how recently you've tried PS7, but the back-compat (particularly on Windows) is much, much better[1]. And for those places where compatibility isn't there yet, if you're running on Windows, you can just `Import-Module -UseWindowsPowerShell FooModule` and it'll secretly load out-of-proc in Windows PS.

Unfortunately, the .NET problems are outside my area. I'm definitely not the expert, but I believe many of the decisions around the default assembly load context are integral to the refactoring of .NET Core/5+. We are looking into building a generalized assembly load context that allows for "module isolation", and I'd love to get a sense in the issue tracking that[2] whether or not fixing that would help solve some of the difficulties you're having in building modules.

For Azure, you should check out the PSArm[3] module that we just started shipping experimentally. It's basically a PS DSL around ARM templates, as someone who uses PS and writes the Azure JSON, you sound like the ideal target for it.

As for the help content, that's a very funny story for another time :D

[1]: https://aka.ms/psmodulecompat

[2]: https://github.com/PowerShell/PowerShell/issues/2083

[3]: https://github.com/powershell/psarm

PM lead for PowerShell here, thanks for the callout! I'll take "isn't the worst". ;)

I'd love to get more of your thoughts around how PowerShell might be more useful for the kinds of scenarios you're thinking about. We see a lot of folks writing portable CI/CD build/test/deploy scripts for cross-platform apps (or to support cross-platform development), but we're always looking to lower the barrier of entry to get into PowerShell, as it can be quite jarring to someone who's used Bash their whole life (myself included).

Structured shells have so much potential outside of that, though. I find myself using PowerShell to "explore" REST APIs, and then it's easy to translate that into something scripted and portable. But I'd love to get to a place one day where we could treat arbitrary datasets like that, sort of like a generalized SQL/JSON/whatever REPL.

Plus, PS enables me to Google regex less :D

I'm a PM at Microsoft that worked on open-sourcing PowerShell. As Windows PowerShell, it's a built-in Windows component, and the number of assumptions that could be made because it was both closed-source and part of the OS were immense. Even getting it to build outside of the rest of the operating system was crazy hard. Then figuring out to install it in a supported way was hard, and only then did we get to start figuring out how to eliminate usage of private APIs and start doing legal reviews.

And we're "just" a language runtime and a shell shipped in the OS. I can't imagine how hard it would be to unwind the proprietary bits of something like a GPU architecture running in a tightly integrated SoC with multiple vendors who are all deeply protective of their IP.

I say this all as someone who has been a proponent of open source for 15 years. And all the work was absolutely worth it, and deeply rewarding from a personal perspective.

But I can't say it would probably make the same sense for Nintendo to go through that effort with Pokemon or the N64 architecture.

Linux is actually half of our usage on PS Core[1], so it's a great question. A lot of folks use PowerShell inside of CI/CD pipelines, especially for cross-platform app development of .NET Core applications (having a single build/test/deploy script is often cited as vastly preferable to trying to maintain a split of .ps1/.cmd/.bat and .sh/.py/.rb).

But also, lots of folks prefer an object-oriented pipeline. Many of those folks (our primary use case for 10+ years has been IT management) are used to PowerShell on Windows and starting to learn or be exposed to other environments.

We've also got lots zsh-style optimizations in PSReadline. In some cases, we've got some catching up to do, but there's also lots of unique interactive optimizations hiding around[2].

It's also great for interactively exploring REST APIs and building scripts via that experimentation. Try running

Invoke-RestMethod [or irm] https://api.github.com/.

Store that as a variable:

$a = irm https://api.github.com

And then look at all the properties you can explore:

$a | Get-Member [or gm] $a.<tab><tab><tab>

Oh, and of course, one of the big reasons is "so you don't have to open a Windows VM to remote into your Windows Server boxes and manage them from a Macbook".

This is obviously not an exhaustive list, but it'd take a lot more time to write about every benefit and scenario here. In any case, it turns out that our user base is pretty spread out among different scenarios, but between our repo and usage numbers, we've been really happy with how excited that such a diverse group of folks really love PowerShell.

And feel free to reach out to me on Twitter @joeyaiello if you ever want to talk more about your experience (or just hop into our GitHub repo). :)

[1] https://aka.ms/PSGitHubBI [2] https://docs.microsoft.com/en-us/powershell/module/psreadlin...

> If it becomes at all popular then you have further ongoing overhead.

THIS is the one that comes into play. All that stuff you listed before is a slog to go through when you go to open-source, but unless you're parking the thing as a proof-of-concept/end-of-life, you're now signed up for maintaining the repo. That means triaging issues, pull requests, helping out when contributors don't understand why their build is breaking, etc.

And there's the PM aspect of it: you don't just want to develop a bunch of features without talking to your community, so communicating (in a public friendly way) what you're planning to work on, when folks might reasonably expect that, how they might be able to help out, which of their contributed features you might be able to take depending on where you're at in your lifecycle, and RESPONDING TO COMMENTS all takes way more time than just "building [closed-source] product" in a team of 5-20.

And of course, one of the hardest of all: telling people "no, we can't take that change" when they've spent hours and hours doing work for your project for free. In that regard, we're still very much iterating on a transparent design process that allows for consensus BEFORE too much work has been done (though as we all know, building prototypes is often one of the best ways to find out if a design works right or not).

If you're doing it all right, everyone involved in the project should be doing some amount of all of this every single day. There's no compartmentalizing an engineer on an OSS project as "someone who just writes feature code" vs. "someone who does the repo stuff".

So going back to OP's point: no, it doesn't literally "cost anything" (or very much) to do the basic act of open-sourcing, doing it the "right way" at scale where you're truly engaging and working with the bazaar is very expensive.

Full disclosure: I'm a PM at Microsoft working on PowerShell and was heavily involved in it being open-sourced and ported to macOS/Linux.

Full disclaimer: I'm the PM for PowerShell Core.

I'm a huge privacy advocate, but telemetry doesn't have to be a dirty word. With PowerShell Core, we went through an RFC process to define our telemetry goals and implementation[1], we publish our data to a public dashboard[2], and all of the telemetry source code is out there in the open[3]. Our telemetry enables to help drive prioritization and decisions around platform/OS usage, and disabling it as simple as setting an environment variable[4].

If there are any other ways we could make our telemetry implementation more palatable without seriously reducing its usefulness, we're absolutely open to suggestions.

[1]: https://github.com/PowerShell/PowerShell-RFC/issues/50

[2]: https://aka.ms/psgithubbi

[3]: https://github.com/PowerShell/PowerShell/blob/master/src/Mic...

[4]: https://docs.microsoft.com/en-us/powershell/scripting/whats-...

PM for PowerShell here, no ETAs right now, but we're working closely with some O365 teams (starting with Exchange Online) to bring their modules up to compatibility with PS 6.x.

As a product manager (technically "program manager" at Microsoft, but it's roughly the same as product managers across the industry), project management is one of the many things I do, in addition to the list above. But I am explicitly not a project manager in that I'm supposed to minimize time spent on that and share some responsibilities in that space with my engineering counterparts.

As someone who definitely has imposter syndrome, the enlightening part of this post for me was that YOU are also the horse jockey.

In this light, it's important for me to recognize that you could easily see me as someone falsely claiming imposter syndrome, even if I know I'm not.

Not sure it helps with the imposter syndrome, though...

Ooooh yeah, that sounds awesome! Going to share this with some people on our team (lots of folks love and use Hyper already, but we're always looking for new stuff to play with).

I would highly recommend you check out the excellent HistoryPx module[1]. Among (many) other things, it supports automatically saving the most recently emitted output to a magic `$__` variable. Theoretically, you could save a lot further back, but you may start to run into memory constraints (turns out .NET objects are a little heavier than text... ;) )

[1]: https://github.com/KirkMunro/HistoryPx

PM for PowerShell here!

I haven't seen DomTerm before, but it looks pretty awesome. At a glance, it's basically a GUI-fied tmux hosted in Electron? It would be awesome to have in Windows, but wouldn't that just require that DomTerm add support for these ConPty APIs?

In any case, I'm more interested in your proposed interactions. Did you have anything cool in mind? Given that we ship PowerShell on Linux, we could theoretically do some stuff there (including within PowerShell on WSL) before it's hooked up to ConPty

Just to make sure everyone on HN knows you can get real pithy with PowerShell, this also works:

  PS C:\> cd hkcu:
  PS HKCU:\> ls -r | ? name -m 'HeidiSQL'

Oh yeah, it certainly wasn't perfect, but the good far outweighed the bad IMO. Also, I'm now realizing there are probably a lot of parallels in building those sorts of communities with the Eternal September problem: getting too big and people betraying the ethics. It'd be a fun historical analogy to explore...

> I miss that time in my life.

Me too. I'm still in my 20s, but given that I now have a lot more means working in the tech world than I had when I was a teenager, I've been thinking a lot about how I might be able to help foster communities like that for younger generations (opening a venue, starting a small label, patronizing high school bands that want to record, etc.) Curious if you've thought about the same?

EDIT: Holy crap, just realized you're the subject of the article. Definitely didn't mean to imply you didn't play a role, FYI, but I imagine you played a large part given your humility on the matter. ;) Keep up the good fight, man. We're rooting for you.

Only just getting started reading this, but I had to jump into comments to give a shout-out on how amazing 924 Gilman was for me as a kid growing up in the East Bay. I wasn't there for the glory days of the 80s/90s, and I have no idea to what extent Dan played a role in its founding, but as a space for playing and watching music, I've never found a venue in my life that comes even close to what they were able to achieve. We actually had a great scene in the East Bay, with a decent number of spots for young, local punk/hardcore/metal bands to play. But as a teenager, it was frustrating when an overzealous security guard would go off on a 15 year old kid for moshing, or when a skating rink would flip the lights on and kill the power an hour and a half before the bands had agreed earlier.

924 Gilman had none of that. I remember the first time I saw this sign[1] and then realizing that there were no security guards to enforce those rules. And yet, the punk ethos was strong enough that folks were just generally good to each other.

Or the graffiti all over the walls with a graffiti code of conduct posted every so often: don't tag over color with black and white, don't put doodles over real art, that sort of thing. Sure, it wasn't 100% followed, but people really respected it for the most part.

Or the 25 cent bottles of water and cans of soda. No profit, just kids handing out there zines and making sure no one goes thirsty.

Anyway, I'm going to go finish the article now, but if this guy got 924 Gilman, and wants to take that ethos into the internet, I couldn't be more supportive. Godspeed.

[1]: https://www.flickr.com/photos/61992100@N03/23226226149/in/al...