3 ms·

> I think Python and Go are two examples where the standard library has very much proven invaluable. C#. The amount of time I've wasted in Java programming t

by rodgerd 12y ago

> I think Python and Go are two examples where the standard library has very much proven invaluable. C#. The amount of time I've wasted in Java programming teams while arguing over things like which of three quirky XML parsing implmentations[1] was the One To Use while the .net team powered off and built useful functionality... [1] This was a few years ago, obviously.

zak_mc_kracken 12y ago
So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. Quite an odd view from a software engineer. I like having as much choice as possible.
- giovannibajo1 12y ago
  Having a standard library for a specific task doesn't forbid alternatives to be implemented and used. But it discourages them enough, which is a very good thing for consistency (especially in reading code), lowers the barrier to entry (eg: I don't have to learn how to parse json with the specific library the project I'm contributing to is using), reduces binary size (I don't link three different http libraries, mine and those chosen by my dependencies) and generically reduce the time wasted by humanity in useless duplications of efforts. When the standard sucks, well, good alternatives will appear. Also, the sad state of Python packaging is the reason why stdlib bitrotted; technically, your package manager could take care of backward compatibility: if eg at some point in the future you want to switch from a json library to a (far) better one, more in line with how idiomatic language has evolved, you just need to repackage the old one as a third party package, and make sure the packager manager brings it down for the user automatically.
- rodgerd 12y ago
  > So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. I prefer to get things done.
ptx 12y ago
C# seems to be in a similar position when it comes to JSON. There's both System.Runtime.Serialization.Json and System.Web.Script.Serialization built-in plus a whole bunch of third-party libraries (e.g. Json.NET seems to be popular). I'm still not sure which one to use.

by rodgerd 12y ago

zak_mc_kracken 12y ago

So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. Quite an odd view from a software engineer. I like having as much choice as possible.

giovannibajo1 12y ago
Having a standard library for a specific task doesn't forbid alternatives to be implemented and used. But it discourages them enough, which is a very good thing for consistency (especially in reading code), lowers the barrier to entry (eg: I don't have to learn how to parse json with the specific library the project I'm contributing to is using), reduces binary size (I don't link three different http libraries, mine and those chosen by my dependencies) and generically reduce the time wasted by humanity in useless duplications of efforts. When the standard sucks, well, good alternatives will appear. Also, the sad state of Python packaging is the reason why stdlib bitrotted; technically, your package manager could take care of backward compatibility: if eg at some point in the future you want to switch from a json library to a (far) better one, more in line with how idiomatic language has evolved, you just need to repackage the old one as a third party package, and make sure the packager manager brings it down for the user automatically.
rodgerd 12y ago
> So you prefer not having a choice over having a choice because choice will lead to discussions to pick the best solution. I prefer to get things done.

ptx 12y ago

C# seems to be in a similar position when it comes to JSON. There's both System.Runtime.Serialization.Json and System.Web.Script.Serialization built-in plus a whole bunch of third-party libraries (e.g. Json.NET seems to be popular). I'm still not sure which one to use.