That's an absurdly partisan statement considering his likely opponent is currently under investigation for reckless behavior while serving as a senior government official.
Since I haven't noticed anyone mention it directly while advocating for voting functionality: GitHub issues originally had voting. The feature was removed with the release of Issues 2.0. Back when the GitHub blog had comments, the Issues 2.0 announcement's comments included this one from pjhyett (https://web.archive.org/web/20110412131836/https://github.co...)
> Issue ordering and voting were used by an incredibly small number of users and we made the decision to drop them. Leaving features in that only ten people use is how to create Jira, not GitHub.
Obviously, that was a while ago and things might be different now.
Physical ability and job qualifications are a central issue in the debate about discrimination in hiring. It's not just limited to disabilities, since the same debate has repeatedly taken place around the issue of whether women are physically qualified for certain jobs, as can be seen in the current debate over whether women are physically qualified for special operations roles in the US military.
Absolutely. There are jobs that discriminate against people with eyesight disabilities (some aircraft pilot jobs, for
example) and there are many products that don't account for people wearing glasses.
People with glasses are widely stereotyped as nerds or geeks and often experience bullying.
People wearing glasses were also reportedly targeted in mass killings by the Khmer Rouge due to that same stereotype.
They are tools for managing multiple installed versions of a programming language. When developing software, we often specify dependencies using version numbers, which indicate the version of the language or library that should be used when running the software. Running the software with the specified language runtime or library version ensures that the expected features of that library or language runtime are available and also helps avoid unexpected issues related to differences in the environments, including different developer's local systems as well as remote server environments.
In the case of a programming language runtime, if you have one project that's configured to use version 2.2.4 of a language and another that's configured to use version 2.1.0, these tools provide an easy way to install and switch between the two versions.
Be aware that Homebrew Cask [1], which your comment is referring to, is a separate project being built on top of Homebrew ("brew") [2] and it currently has a number of shortcomings that are independent of anything to do with Homebrew itself.
Your comment is interesting since it contains a lot of political extremism and insults toward people who hold different viewpoints, while also advocating censorship.
There are whole ecosystems of developers and teams getting work done and building companies (including some of the biggest companies in the industry) without these applications, so they clearly aren't necessary to "get work done."
Your statements about cmdlets are simply false, and you are again trying to handwave past the fact that PowerShell is a .NET CLI and that its object pipeline only exists within its .NET runtime and is analogous to function chaining within a single runtime like in Python or Ruby, not Unix pipelines.
From the Microsoft documentation, which I quoted to you in a previous discussion, so you should already know it (which would then indicate you are being deliberately dishonest): "Cmdlets are instances of .NET Framework classes; they are not stand-alone executables."
> they can also be implemented through script (i.e. not .NET classes)
Your statement here is factually wrong. They are called "advanced functions," previously "script cmdlets," mimic the behavior of true cmdlets ("bind as cmdlets"), but are not true cmdlets. They also exist within the .NET runtime, which is the relevant issue.
> through manifests where cmdlets are generated for WMI/CIM classes.
Then those generated cmdlets must be instances of .NET classes, because by definition that's what cmdlets are, and they exist within the .NET runtime, which is the relevant issue.
And in all cases, they exist within the PowerShell/.NET runtime and are not arbitrary executables written in arbitrary languages.
Thank you, however, for providing yet another demonstration of how PowerShell advocates consistently resort to handwaving, obfuscation, and false claims in order to try to pretend PowerShell is functionally different than it actually is.
useerup, virtually everything in your comment is irrelevant handwaving and obfuscation, including a bunch of irrelevant comments about features that are internal to the PowerShell runtime.
No matter how much you want to try to talk around it, PowerShell is a .NET CLI, the object pipeline exists within its .NET runtime, and the commands are instances of .NET classes. Unix shells work primarily with arbitrary executables outside of the shell runtime using OS system calls to create pipelines with standard streams.
Here's the cold hard fact stated yet again: PowerShell's object pipeline is functionally analogous to function chaining in languages like Ruby, Python, and JavaScript, not Unix pipelines.
Your long-winded comments about PowerShell's internal language and runtime features are utterly irrelevant since they exist within with PowerShell runtime, just as the features of Ruby, Python, JavaScript, the JVM languages, etc all exist within those runtimes.
You also tried to falsely claim that cmdlets are not instances of .NET classes in a previous discussion (https://news.ycombinator.com/item?id=9461682) and your comments are perfect examples of how PowerShell advocates use long posts of handwaving, obfuscation, and verifiably false claims to try to pretend PowerShell's functionality is different than it actually is.
That's because the object pipeline is functionally analogous to function chaining within a single runtime like in Python or Ruby, not streaming data between arbitrary executables like in Unix pipelines.
This would be a lot clearer if PowerShell advocates compared it to things that it's actually functionally analogous to, but they are trying to position it as a Unix shell competitor.
The word "shell" in this context already means something. A text shell is a command line interpreter (https://en.wikipedia.org/wiki/Shell_(computing)#Text_.28CLI....). There are many shells that do not use the pipeline convention (e.g., irb), so your attempt to redefine it to promote PowerShell fails from the start.
PowerShell's object pipeline is functionally analogous to function chaining in languages like Ruby, Python, and JavaScript, not Unix pipelines. PowerShell's object pipeline does not exist outside of the .NET runtime and you can not stream objects between arbitrary executables outside of the .NET runtime.
You can't compare an apple to an orange and say one is "objectively better," no matter how hard PowerShell advertisers try to pretend their apple is an orange.
PowerShell's object pipeline only exists within the PowerShell/.NET runtime and is functionally analogous to method/function chaining in languages like JavaScript and Ruby. The object pipeline does not exist outside of the PowerShell/.NET runtime.
Pipelines in Unix shells use OS-level functionality to connect standard streams of data, often encoded as text, between arbitrary executables written in any language.
The reason this is confusing is because one of the main tactics used in PowerShell promotion is to disingenuously compare PowerShell's "object pipeline" to Unix pipelines in order to try to make it appear to be more novel than it is, when they should be comparing it to what it's functionally equivalent to, which is function chaining within a single runtime.