Removing APIs is not a great practice though. Look at AWS, they version their APIs, they don't just remove them, and removing them should be unnecessary if your underlying tech isn't brittle and badly written. "Depreciated" is a far better term to use, with a far better outcome in my opinion. Companies that remove old versions of APIs and break existing client apps (that possibly can't be udpated) really suck.
Yeah, nope yourself. It seems like a lot of people aren't really thinking this through very much.
And that is absolutely the wrong way to approach API development. An API that is being sun-setted should never be removed, because older clients could still use it but sometimes can't be upgraded to newer clients. Removing a v1 API breaks those clients and it's a shitty thing to do to users. Yeah, people should be building NEW things with it, but there's no reason to look at the v1 API with "disgust" as "deprecated" implies - It's simply an older version that should remain functional, if your system is worth half a shit. AWS doesn't terminate older API versions, they just create new versions. Or you can be like Facebook and "deprecate" stuff and just shut it down before your official shutdown date, or not give any notice at all - that's REALLY a fun culture to work in, I guess, for them. "deprecated" is a really negative word, and doesn't even really translate to anything good in terms of software development. It's my opinion that "depreciated" is a far better word and far better outcome when used in software development instead of "deprecated". YMMV.
Whoever the first developer was that used "deprecated" got it kind of wrong, the word should have been "depreciated".
Deprecate: "express disapproval of."
Depreciate: "diminish in value over a period of time."
I kind of cringe when other developers say "deprecated".
Edit: Versioning and not removing APIs is kind of the way to go, so you don't break client apps that possibly can't be updated easily or at all. "Depreciated" is a far better word to use with a far better outcome. AWS versions their APIs, they don't remove old ones. "I disapprove of using this API and we're taking it away at some random date" vs "this isn't the latest API, use the current one for new development" seems like a pretty stark difference in thinking to me. YMMV.
Thanks for posting this - I've been down that road. I regularly have to parse about 20GB of JSON split up into 8MB JSON files - tried this library but was sad that it didn't help. I'm currently using threading in nodejs and that has helped quite a bit though, parsing up to 8 of those files at a time has given me quite a performance boost - but I always want to do it faster. Switching to using C just isn't really a viable option though.
Your comment seems a bit disingenuous - how much time passed between when you got the i7 and when you got the i5? Today's i5's can be faster than long-ago's i7's but todays i7's are still far faster than today's i5's.
Maybe you missed the part where the program tells the user it's running in "CPU Mode" and may be slower, "Try running on a GPU" is another message that would make it clear.
So many comments here make it seem like we're dealing with people with a negative IQ.
Just show an appropriate message and let the user run the software. It's GREAT that there is a simple CPU fallback and it's enabled by default.
It's really an edge-case where a user would want to run the code and have it fail if there isn't a GPU - that is mostly an edge case of 1 user, the developer, except in very specialized situations where nobody would want to run it without a GPU, again an edge-case.
>Prediction: someone deploys this and doesn't notice it's incredibly slow for mysterious reasons, and then spends several hours to figure out that the right version of CUDA wasn't installed.
Why not just print out a message "Running in CPU mode" or "Running in GPU mode". There's no reason it has to be a mystery.
The comments here tell me that programmers have a narrow idea of what other programmers should/would/could do with their software.
>This is a bad thing, not a happy thing to be advertised. Software fallback was of the most frustrating parts of working with OpenGL circa 2010.
>If you're making a hardware accelerated library, stop trying to make it "gracefully" fail. Just fail! That way people can address the root problem.
No. I want my code to run locally sometimes (possibly with a GPU), and sometimes I run the same code across hundreds of EC2 instances or just 1 instance, and I have good reasons for that. Sometimes a machine doesn't have a GPU, but I still want that code to run on it.
The "bad thing" is imagining you know every possible use of javascript, and then telling other people about how they should be running javascript (or any language).
Her "data" is mostly liking cute dog videos. China can have that data for all I care. Meta data about my network, devices? If China really wants to know that I'm on Spectrum internet, and have a few other devices connected, sure, go ahead. I monitor my network and haven't seen any suspicious traffic that would worry me.
AREXX was around in 1987. It was amazing. Pretty much every application had an "AREXX port" to allow scripting. And I used it extensively. The closest I've seen to anything like it is OLE on Windows, but it's not very accessible or pervasive like AREXX was in every application.