philstu

If you read the article you'd know that this is about using OpenAPI Overlays and other use cases where JSONPath is literally a requirement. I think you just read the first paragraph then wrote a few about how its bad.

More and more parts of the API ecosystem require JSONPath, and just saying "you should write code instead" doesn't actually help anyone write OpenAPI Overlays, so whats the point?

It would depend far more on the implementation than the concept/spec of JSONPath itself. What implementation are you using?

That wouldn't help anyone working with OpenAPI Overlays or Spectral which is what this article is about.

jq is wonderful but not relevant to the discussion.

This is about using JSONPath for OpenAPI Overlays and automated API Style Guides like Spectral.

You cannot use jq for either of those things.

Notbing against jq, just a different discussion.

The standard was developed because its being used by so many people in so many ways with so many different implementations that a standard was required to align them all, so im not sure the "nobody is really using it" argument holds much weight.

Hey! I cover that a bit ni a followup blog post :)

https://blog.runscope.com/posts/you-might-not-need-graphql

tl;dr: maybe you want OData, JSON-API, or one of the many other standards or practices that solve this simple problem as their super-set of functionality on top of the networking principles of REST.

Using GraphQL for this alone is rather nuclear, as you gain a lot with GraphQL but lose other stuff.

> But since they are already brainwashed from PHP use, it prevents them from seeing the value of doing thing the proper way, and might see the process as contrived. This is the most dangerous aspect of using PHP. It blocks your learning and understanding. It pulls you down and keep it there.

After 10 years of writing PHP I took a look at Python. I was confused for about 10 minutes, until I read about lists and dictionaries and saw they were different things.

Who are these people who are just trying to write other languages without looking at the "getting started with data structures" page in the guide, or reading a single book?

And why is learning something flexible and easy before learning something more advanced a problem?

> So I request every one who is passionate about programming and wants a career in programming to keep away from the php language and community as much as possible.

I was writing PHP for a living for a decade. I did a bit of Ruby along the way because it's all the same and who cares. I was then invited to CTO at a tech startup in NY, giving me a visa and moving me from the UK.

I replaced their shittily built Rails API with a PHP one which was 3x faster, did 10x more and was actually tested properly. Very handy.

Now I work for another company, Ride.com. We're building an API in Rails and it feels just like the one I built in PHP using Laravel. Almost identical.

This comapny got me a visa known as "The Alien of Extraordinary Ability" in which my PHP code was used as the basis of my skills.

All of this leads me to think: What the fuck are you talking about.

1. Languages rarely matter. 2. PHP is just fine. 3. PHP will not fuck up your career. 4. PHP will not ruin your ability to learn new languages. 5. You are an actual idiot.

Stop preaching ignorance and get on with writing software.

Those people need to think a bit harder before smashing out some automagical API that things will rely on for basically forever.

A developer who has been invited into the USA twice because of his skills at building complex APIs for complex companies suggests that automated solutions are a cancer on the API building industry?

Quelle f'ing surprise.

I'm far more than the typical user.

Oh and I know Go, so I must be super intelligent, because only super intelligent people use Go.

It truly blows my mind that any further explanation would be required.

If you want a data store that exposes your database over HTTP then use on of the billion data stores that is designed to do that. None of those are meant to be a public API, and doing this is so incredibly wreckless and short sighted I could write at least a chapter in a book about it.

Actually, I did write a chapter in a book about it.

https://leanpub.com/build-apis-you-wont-hate

A RESTful API is about so many more things than just shoving a generic CRUD interface on top of your data schema.

Seems relevant.

https://twitter.com/philsturgeon/status/544965192883261441

Here's a whole update on the general state of markdown

https://philsturgeon.uk/markdown/2014/11/30/state-of-markdow...

rST > HTML is less likely, but CommonMark > PDF could definitely be a thing.

It depends which bit you're talking about.

A lot of implementations in various languages go with static regex approaches, which is a bit shit. This uses an AST which helps out a lot.

By adding the customization elements, people can write "GitHub Tables" or any sort of other extra syntax in.

And by keeping the HTML Rendering separate from the parsing process, other PDF renderers or whatever else could be added.

Somebody could make a [Maruka](http://markua.org/) extension for example, which is just CommonMark + Extra tags + PDF / eBook / etc.

It's not madness, and it will be optimized over time. Fear not. :)

How about DBAD?

http://www.dbad-license.org/

Hold on, why was my response badly researched?

The point was that NodeJS and PHP were pretty close, and I posted (before the update) that I'm sure Node could go quicker.

You run either of them in suicide mode to RUN ALL THE CONNECTIONS and you'll get a speed up. The point is that NodeJS is not magically 4 or 5 times faster than PHP, they're about the same when you the packages you use support the async approach. This update proves they're exactly the same, but similarity is all I was going for.

Proof: https://pbs.twimg.com/media/BY4jok7IEAADGmE.png:large

Two core devs with a few contributors.

A lot of the components are in production already, it was built by the original developers to be used in production. It's on 0.3.0 for many parts, which is no further behind where Node was when people started flapping about it :)

Nobody should be downvoting you, you raise an excellent point and you are of course right.

NodeJS v0.10.21 + Cheerio

real 0m47.986s user 0m7.252s sys 0m1.080s

NodeJS v0.10.21 + Cheerio + 64 connections

real 0m14.475s user 0m8.853s sys 0m1.696s

PHP 5.5.5 + ReactPHP + phpQuery

real 0m15.989s user 0m11.125s sys 0m1.668s

Considerably quicker! As I said I was sure NodeJS could go faster, but the point of the article was that PHP itself is not just magically 4 times slower, it is in fact almost identical when you use almost identical approaches. :)

I think this was initially caused by RDS playing up, but varnish is in place now.

Let's say - for the sake of argument - that I walk outside, buy a "C for Dummies" book and read that thing cover to cover. In a month I might be a reasonable C developer and after a few more months I might have a good enough understanding of how PHP works internally, fire my code into a feature branch post that RFC up on the board, then... what? If people are dismissing things like Property Accessor syntax after it's coded up by an experienced C and PHP dev, then why are they all going to vote yes on an RFC bashed together by somebody who is brand new to this?

That's not an excuse, thats logic. It's very possible that so few people get involved in core development because there is very little motivation to do so. "I can work really hard on something that I feel really passionate about, then have it totally ignored by a bunch of people who think PHP should just remain a cluster-fuck of inconsistent PHP functions." Yaaaay!

See the issue? It's very easy to say "Well why don't you do more?" but when people see those that try being met with negativity in such a big way it REALLY doesn't make me want to even try to help.

I wouldn't say I have no idea, I've looked into it. I know exactly how difficult it is and respect anybody who manages (or even tries to) make PHP better. I certainly at no point in the article called anyone an idiot.