Motivated by the recent discussions about python and lua rocks and by personal dissatisfaction with the C++ standard library. With inflammatory title because we all see a few thousand emails a day.
The standard library is where code goes to die. Design mistakes are locked in forever as breaking users code is noisily unpopular. A better, faster or safer API must coexist with the existing ones, which generally chose good names for themselves.
Think of the problems we have with version changes, not least the unfortunate divergence from luajit, and imagine scaling that to the size of python's blessed library set. With reference to the undying 2.7.
I don't use luarocks. Bad experiences with pip and npm, and to some extent aptitude, have left me wary. So instead I bake libuv, sqlite, penlight and some other stuff into the lua interpreter. I'm pretty sure that's better than the search the directory tree / www and trust to luck that other ecosystems use.
I would urge caution when importing design choices from elsewhere. Most languages do it worse than lua does for basically all instances of 'it'.
It may be a bad thing for some projects, but creating any fork causes a more major problem for later maintenance of bugs that are found extremely late (including security bugs) because the fork is insufficiently reviewed and tested and was created in a limited context.
Stadnard libraries make a lot of efforts to document their API, including their known "caveats" and suggesting other uses for these border cases that have already found to be problematic.
In other words, with standard libraries you must RTFM and apply it strictly! Only if the API says that the behavior is undefined, then you can create an encapsulation layer to isolate these cases only to make sure you get the behavior you expect, then still use the standard libraries for everything else. You limit the damages ! And you have much less cases to test and support. But your application will absolutely need to use your new layer to be consistent, and not mix both (because you would risk to have BOTH the undefined behavior of the standard libary and your defined layer.
One way to do that is to well structure your project dependencies: only your layer will use the standard library and depend on it, all the rest of your application will depend only on your layer but never on the standard libary which acts as a gateway working for your application (most of the tings your layer will do will be to dedelegate the APIs of the standard libary that it does not change; this will have no performance cost for all the rest.
In a good standard libary, the APIs should never change: if there's a change of behavior (or change from undefined to defined behavior) a new distinctive API should be added; as well some APIs that can be potentially dangerous or give unpredictable results in some contexts or not matching the geenral expectation should NEVER be removed, but marked as deprecated/obsolete and your developer suite should inform you when you build the project so that you can check if you need or should perform the switch to a newer API (with the risk of no longer supporting older target platforms) or keep the older (knowing that some newly discovered security may no longer have fixes developed and applied to it with a backport).
An d anyway you must read why the "'standard" library was developed, its goals, who supported it. It's up to you to see if their goals match your need and you assume the risk of maintaining alone what was really a complex and very long development with lot of tests performed on it, that you will not be able to reproduce and support alone.
Yes it is easy to create a fork; the problem is the lifecycle of the software you write immediately, and that you may soon no longer support at all because you left the project: your successors will then really hate you for not adhering to the standard, and you'll add more work for them to find a solution if your code is now broken or simply does not support the useful and common features that you blocked by deviating from the standard of your industry. Deviating from standards hwoever is valid if your project is purely personal and you don't intend to transfer it to someone else to maintain it or you are no longer working for the company that paid you to develop that specific project.
So think twice ! Any fork implies new costs or severe limitations.
Le dim. 19 janv. 2020 à 13:34, Jon Chesterfield <[hidden email]> a écrit :
|Free forum by Nabble||Edit this page|