Here's the problem I had with my previous game project. JSON writing and parsing. I type "JSON" into your search box and get 20 libraries without much difference explained. 17 of those match my license requirements. And then I have to try each one to compare.
You might say that I could just pick one at random and see if it works... I did exactly that for my previous project. 11 months into development when I had huge chunks of code depending on it, I discovered a subtle bug that only showed up on big JSON files (over 2MB) and only when the library was compiled with MSVC. The author doesn't want to debug it because he doesn't use Windows. I wanted to use use MSVC because of Steam API. So I had to either rewrite the code to use another library or give up on SteamAPI. I picked the latter.
Dumping a list of 20 libraries to solve a single problem isn't "curating".
I suggest you remove "the best" from the title as this site doesn't solve that problem.
I feel you, but one problem is that it is often hard to rank libraries best to worst. 20 may be a bit much, but still -- one library may be the most popular, another fastest, another correctly handles this one specific unusual case, another works well with large objects, another has more convenient interface for your case, etc.
What would be ideal is if there was useful information about such things available right on the aggregator site -- Amazon style reviews wouldn't be too useful here tbh, ideally one would like to see multiple comparisons from people like you who tried or at least looked at a few of them.
Your problems, if common enough, suggest a startup opportunity to address this area - on a paid basis. Testing validation / curation of various software libraries and tools for various languages, with comments and ratings about suitability for various purposes, and along different dimensions, such as code quality, performance, docs, etc.
There was a company in a roughly similar area (IIRC) called SpikeSource, co-founded by (?) Kim Polese of Sun and later Marimba. Not checked recently about them.
I looked at the code... writing my own parser would be faster than fixing it. But that's beside the point. I decided to use a 3rd party library because I did not want to invest my time into that. The moment I had to even look at the source code, that was broken.
Surely thats the 'cost' of using someone elses' work without paying for it/otherwise remunerating the author? Its hardly their fault you found a bug that you decided you couldn't/wouldn't fix ..
But surely, the moment you integrate the random library into your project, you assumed responsibility for it - warts and all? I just can't see the moral authority that you've granted yourself to complain about the library and the effort required to continue to maintain it, when it clearly was of advantage to you to integrate it into your project in the first place .. Don't you think it was a privilege that some stranger wrote code that you used in your project, in spite of the thorns?
You completely took that out of the context. I wrote about it to show how risky it is to pick a random library, not to complain about the author.
> But surely, the moment you integrate the random library into your project, you assumed responsibility for it.
No, you don't. Your only responsibility is your project. If the library is broken, and the original author doesn't want to fix it, it's time to evaluate whether it's easier to remove it, replace it with something else or fix it yourself. You are not obliged to fix it yourself at all. I'm sorry to disappoint you, but the world doesn't work that way.
Alas, you and I simply disagree. I wager that full responsibility for ones project implies the onus of fixing whatever problems you introduce into the project by importing the external dependency in the first place.
Were you my junior, telling this to me as your project manager, I'd demand you fix the bug. The reason is - we already gained from your decision to advance the project by including the external work, and at the moment you included it in your project you accepted responsibility for the issue. Failing to take responsibility for this code, whether you wrote it or not, would be a major distraction from the task, and thus does not reflect positively on you as a developer...
So you're okay with 3rd-party features, which you willingly import into your project and utilize to make your job easier, but you're not okay with taking responsibility for any bugs in those 3rd-party libraries. Doesn't make any sense. I'm glad you're not my junior, too.
As you can see, I gave a link to the problematic .json file. If I were a developer of the library, this would be enough for me. I have made and maintained open source projects (see my bio on HN) and I have often got less to work with (people just explaining the problem without even giving me a data sample).
He was asking me to drill it down and basically debug his program and I simply wasn't interested in doing that.
Copyright (C) 2015 Faraz Fallahi <fffaraz@gmail.com>
THE LIST IS PROVIDED "AS IS" WITHOUT ANY WARRANTIES.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION:
1. You just DO WHAT YOU WANT TO.
The classification can be done a little better, maybe a tree-view with available branches where it makes sense to sub-classify. The project seems to be a good (useful) thing otherwise.
I find it hard to justify starting a new projet using C++ today when there is languages like Rust, swift and golang to a lesser extent. C++ was the only viable option for a compiled, fast and scalable language. Java has replaced C++ on the server/backend side for years and the same thing is going to happen on the Desktop/mobile in the coming years as the other new language offerings start to gain momentum.
I'm not sure C++ is more stable than Rust. It's pretty stable but it does introduce breaking changes and code written 10 years ago will not compile as C++11 without changes. Of course if you need to port C++ code across platforms, which can easily happen if code is to survive a decade, then even if the built-in type sizes don't change, you'll have to deal with things like there being no standard build system for C++, no standard interfaces for most of the functionality found in an OS, etc.
Overall, while C++ indeed is fairly stable, I wouldn't bet on C++ code to be easier to drag into the future than code in those other languages (of course I wouldn't easily bet the other way, either; it's hard to know in advance with these things which will bite you the hardest.)
> code written 10 years ago will not compile as C++11 without changes
I have a lot of projects from 2002, 2003, 2004, 2005 and 2006 that compile and run just fine. All those use "make" as a build system.
I even have some stuff was developed using Borland's Free C++ compiler (5.5) and with a few minor fixes to #pragmas and #includes it compiles using clang and GCC.
I've seen and ported such programs. I no longer remember what the problems were, but I think some of them had to do with array initializers - C++11 seems to have become stricter wrt implicit casts of values used to initialize arrays (meaning that more casts need to become implicit.)
Perhaps it's a compiler issue, not a language issue; my only point is that the issue exists (and I'm not saying it was that terrible - I recommend everyone to upgrade to C++11 - just that code will not compile unchanged.)
Sister comments say that they have old C++ code that compiles just fine. Of course such code exists, I'm just saying that not all code is like that; I bet you can get there with Rust or some other reasonably stable new language if you program conservatively enough. Also a big question is what platform your code runs on; if you've targeted gcc since forever and you don't use -Werror, then your code and your Makefiles will be very stable relatively to having to port to VS - even if you're not really targeting standard C++ but the dialect GNU C++. Different C++ compilers, build environments and platform libraries are very different, and it seems a safe bet that newer languages will do a better job of minimizing differences between implementations (or keeping their number small.)
Porting C++ code compiling fine under g++ to clang, for instance, is a metric ton of work (and this one I gladly wasn't involved in but I've seen others do it; again, if your C++ code ports just fine, more power to you.) And g++ and clang are much closer to each other than the average pair of C++ compilers.
I've "ported" ~200k lines of C++03 to C++11 and so far I've had to make exactly one change due to language changes (C++11 forbids narrowing conversions in braced inits, while C++03 just did nonsensical things). That's not to say that no other changes were required, but the rest were things like fixing code that had both C++03 and C++11 versions and the C++11 version was broken, and fixing compatibility issues with libc++.
Ok except for language stability which is by the way one of the reasons C++ is lagging behind. For anything other than that I would not recommend C++. The day C++ offers modules, a package manager like Python pip or rust cargo and a multiplatform build system (there is cmake but still) I would reconsider. I am not saying C++ is no more viable, far from that actually, take the swift compiler for example is written is C++ and for that kind of software C++ is excellent (fast, stable etc.) but down the road I am sure it's going to be less popular for the kind of applications for which it's/was considered the only viable option.
Of course, because you can be 100% sure that your C++ program does not contain any subtle undefined behavior that was already disallowed in the C++98 standard and which next decade's more advanced optimizing compilers would turn into hilarious machine code.
Here's the problem I had with my previous game project. JSON writing and parsing. I type "JSON" into your search box and get 20 libraries without much difference explained. 17 of those match my license requirements. And then I have to try each one to compare.
You might say that I could just pick one at random and see if it works... I did exactly that for my previous project. 11 months into development when I had huge chunks of code depending on it, I discovered a subtle bug that only showed up on big JSON files (over 2MB) and only when the library was compiled with MSVC. The author doesn't want to debug it because he doesn't use Windows. I wanted to use use MSVC because of Steam API. So I had to either rewrite the code to use another library or give up on SteamAPI. I picked the latter.
Dumping a list of 20 libraries to solve a single problem isn't "curating".
I suggest you remove "the best" from the title as this site doesn't solve that problem.