integraton

WebKit works on every major operating system, including Windows and Linux. IE/Spartan/Edge does not work outside of Windows.

There are some minor feature differences between WebKit, OS X Safari, and iOS Safari, but the reality remains that WebKit exists on Windows, can be built on Windows, and can be used on Windows, while IE/Spartan/Edge works on nothing but Windows.

Edit: I'd love to hear from the ethically bankrupt downvoters about which fact in this comment they are trying to hide from.

Unix pipelines are an operating system feature that coordinates data streams between processes. PowerShell's object pipeline is function chaining feature of PowerShell, a runtime that runs on an operating system as a process, the kind of process whose communication with other processes is coordinated on Unix systems using Unix pipelines.

Python, PowerShell, and Ruby object handling and function/method chaining are not a features at the operating system level, they are features within the Python, PowerShell, and Ruby runtimes and processes. Unix pipelines are a feature at the operating system level that coordinate communication between these kinds of processes.

Unix pipelines are not a feature of Unix shells, they are an operating system feature for which shells provide an interface. PowerShell's object pipelines are features of PowerShell and its runtime, not the host operating system.

This is not a minor distinction. A feature for working with objects and chained functions within particular language or framework's runtime is not the same thing as a feature for coordinating process communication in an operating system.

They are instances of .NET classes that derive from `Cmdlet` and `PSCmdlet` and run in the PowerShell runtime. As stated plain as day in the Microsoft cmdlet documentation:

"Cmdlets are instances of .NET Framework classes; they are not stand-alone executables."

Your entire comment is an attempt to obfuscate the nature of PowerShell cmdlets, which are actually very simple.

>> Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.

> No it is not.

Yes it is.

This is not about the term 'pipeline,' it's about how PowerShell, Unix shells and pipes, and language runtimes work and the scope to which they apply. FACT: PowerShell's object pipeline is internal to the PowerShell / .NET runtime, just as other language features of Python, Ruby, etc are internal to those languages' runtimes. FACT: Unix pipes are primarily for chaining separate processes. They are a lower-level feature than the runtimes of Python, Ruby, or PowerShell, and can be used to chain those runtimes together with each other and other processes.

Here's an illustration of the scope of each one.

PowerShell's cmdlet / object pipeline:

    (PowerShell runtime)

    (Python runtime) | (arbitrary executable) | (PowerShell runtime) | (Ruby runtime)

PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects.

Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands.

The focus of each one is very different, despite PowerShell's syntax.

Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.

That's because Bash is used to tie together separate programs that do the work. PowerShell, on the other hand, is a .NET shell and more equivalent to the shells in Python, Node, Ruby, the JVM, etc, all of which provide ways to work with JSON and many different data structures.

Unix already has the object functionality you see in PowerShell: Python, Ruby, the JVM, etc, and all of these have existed for far longer than PowerShell. The only thing PowerShell has is a bunch of shortcuts for system operations, which Unix already has in the form of POSIX shells and utilities, and which many languages provide language-native abstractions for.

Unix pipelines are for streaming data between processes using standard input and output. PowerShell pipelines are for sharing data between .NET classes called cmdlets and are more like chaining methods within a programming language. There are multiple programming languages with this functionality available in the *nix ecosystems.

Working with the PowerShell "pipeline" is like working in a CLI/REPL for Python, Ruby, Node, not like working with Unix pipelines.

http://www.indeed.com/jobtrends?q=php%2C+javascript%2C+ruby%...

http://www.indeed.com/jobtrends?q=php%2C+node.js%2C+ruby%2C+...

The reality is that lots of companies have been and continue to be created around Rails applications. An AngelList job search focused on server-side technologies currently returns 1267 startup results for "rails" while "node.js" returns 832, "node" returns 854, "django" 434, "python" 1461, "flask" 69, "go" 441, "php" 1192, and "Java" 3163.

JavaScript has become bigger, and it hasn't killed Rails on the server. Java remains huge, and it hasn't killed Rails. Python, Django, and Rails have roughly the same relationship as they did back in 2009.

A lot of very smart people who have extensive experience with many technologies choose Rails for new projects for very good reasons, this has been the case for the 10 years people like you have been making the same FUD-filled comments, and it will likely continue to the be the case for some time.

Furthermore, neither emacs nor vim are hard to learn. There's a widespread myth perpetuated both by novices and elitists that it's an all or nothing kind of thing. The reality is that even in vim you can use arrow keys and mouse/trackpad scrolling and ignore hjkl if you want. You could, for example, use terminal vim every single day and use only about 5.5 vim-specific commands: i, ctrl-c, :w, :q / :q!, and ZZ. With gvim or macvim, you could reduce that to two: i and ctrl-c.

And also note that the posting on the webkit list is from 2012.

There we go. Posted straight from Redmond, no less.

I'm not sure where you guys get off calling another commenter "a prick" over and over again, along with other insults, for a joke pull request, given there is a long history of people (including pretty notably respectable people) creating them. I even listed some in another comment you guys can keep downvoting (because apparently my comments are worse than personally attacking other commenters): https://news.ycombinator.com/item?id=9229987

Edit: I'm just going to point out that even this comment has been downvoted https://news.ycombinator.com/item?id=9230140

I'm not sure what you guys think this kind of nasty behavior benefits you or your favorite company, or why you believe people don't notice and aren't going to do something about it.

The fact that your nasty comment here got upvoted rather than flagged to death is really sad.

There's a well-established tradition of pull requests and issues being used for commentary and humor.

Here's a selection. The first one is by the founder CEO of a company with a ~$1B valuation that's prepping for an IPO and is very similar to the one everyone here is complaining about. The second one has comments from a couple well-known tech folks. And so on...

https://github.com/saberma/shopqi/pull/409

https://github.com/h5bp/html5-boilerplate/pull/1074

https://github.com/ericf/yui3-gallery/pull/21

https://github.com/WhiteHouse/fortyfour/issues

https://github.com/joyent/node/pull/2472

But apparently now that Microsoft is using GitHub, everything is Serious Business™? Is there a dress code now, too?

The name comes from this post:

http://www.adaptivepath.com/ideas/ajax-new-approach-web-appl...

https://en.wikipedia.org/wiki/XMLHttpRequest

https://en.wikipedia.org/wiki/Ajax_(programming)

The original idea came from ActiveX, but it didn't take off until it was implemented across browsers via JavaScript as XMLHttpRequest over the next 6 years, and didn't become "Ajax" until the Adaptive Path blog post about Google's innovations with Maps and Gmail in 2005. Microsoft then added support for XMLHttpRequest a year and a half later in late 2006 with IE7, which of course had very little adoption, particular among businesses, because of IE6 (see IE6 @ 49.8% and IE7 @ 17.1% IE market share at beginning, March 2007, of this graph: http://www.w3counter.com/trends).

That happened January 1998, which was 17 years ago, and 4 years before Firefox was released, which itself was over 12 years ago.

1. Within reason, of course. It's not on my router (but maybe it could be)

Whether it's popular on Windows is also irrelevant with regard to the fact that it does, indeed, work on Windows.

Just because it's not packaged as Safari doesn't mean it's not available.

I agree, as long as they are by companies, organizations, and teams other than Microsoft. And that's what we indeed have already: Gecko, WebKit, Blink (and Blink is new, which is great). I very much look forward to additional open engines (and POSIX-compliant operating systems, for that matter) by companies, organizations, and even unofficial teams of dedicated individuals that are not Microsoft, of which there are many.

Visible urban water usage like lawn watering is a small fraction of the water usage in California, and even if every lawn stopped getting watered it wouldn't come close to solving the issue.

It's usually advisable for people get them from analytics tools on their own sites rather than looking at global stats. For example, IE stats from my Google Analytics account covering multiple different industries, company sizes, and types of sites and applications range from 6.78% to 13.19%, and I've seen similar numbers on every project I've worked on for at least 4 or 5 years.