5 ms·

This reminds me of the famous quote by Joe Armstrong -- You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. Most moder

This reminds me of the famous quote by Joe Armstrong -- You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. Most modern software has incredibly complex dependency chains and that's what makes it fragile and unpredictable most of the time. If we focus on making the languages, runtimes and core libraries flexible enough that we don't need to assemble code from dozens of hobbyist GitHub projects to put up an app with a reasonably modern UI, we would make a huge step forward.

ajross 11y ago
So... the right solution is just to do it again the Right Way, you say? https://xkcd.com/927/ https://xkcd.com/927/
- ori_b 11y ago
  Who says that it's a competing standard? It's a simple local implementation that fits the needs of the application. This isn't the right case all the time, but if implementing something is only a few dozen lines and isn't already provided in an appropriate form by a library that you're using, there's nothing wrong with just implementing it from scratch.
  - itsybitsycoder 11y ago
    Agreed, I've had to compile pieces of C++ software that had dependencies on third party libraries for completely ridiculous trivial reasons. Like requiring OpenSSL for a project that's completely unrelated to networking/crypto just to be able to use its SHA-1 implementation to hash an image and check if it has changed from a previous version. 20+ dependencies later and it starts getting really annoying to compile that project for different platforms, because invariably there will be one little dependency that isn't supported because of some feature that's not even being used.
bpatrianakos 11y ago
I disagree. I can relate to application setup and deployment feeling like its a fragile, error prone process but library usage in general is a good thing. Now if you're picking up obscure, poorly maintained libraries from GitHub I can see that going south quickly but as long as you're smart about not only which dependencies to choose from whom but also knowing when you really need them then you end up with a robust, easy to maintain system in the end. The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself. This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far. Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment. I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.
- bluetomcat 11y ago
  A perfectly valid case for using a library is when it implements a huge standard that you don't have the time, knowledge or expertise to implement yourself. Think of zlib, libpng or libcurl. These are de facto "reference implementations" of the respective standards, so you'd better rely on them in order to be future proof. > We have so many hobbyist libraries precisely because our languages and tools are so flexible. I beg to differ. The (initially) small hobbyist libraries are often working around the deficiencies of the language/runtime/core libraries. This has been the case for JavaScript since jQuery. If a third-party library doesn't implement a format or a protocol, or an intricate algorithm, but rather tries to augment the language, that is a huge red flag.

ajross 11y ago

So... the right solution is just to do it again the Right Way, you say? https://xkcd.com/927/ https://xkcd.com/927/

ori_b 11y ago
Who says that it's a competing standard? It's a simple local implementation that fits the needs of the application. This isn't the right case all the time, but if implementing something is only a few dozen lines and isn't already provided in an appropriate form by a library that you're using, there's nothing wrong with just implementing it from scratch.
- itsybitsycoder 11y ago
  Agreed, I've had to compile pieces of C++ software that had dependencies on third party libraries for completely ridiculous trivial reasons. Like requiring OpenSSL for a project that's completely unrelated to networking/crypto just to be able to use its SHA-1 implementation to hash an image and check if it has changed from a previous version. 20+ dependencies later and it starts getting really annoying to compile that project for different platforms, because invariably there will be one little dependency that isn't supported because of some feature that's not even being used.

bpatrianakos 11y ago

I disagree. I can relate to application setup and deployment feeling like its a fragile, error prone process but library usage in general is a good thing. Now if you're picking up obscure, poorly maintained libraries from GitHub I can see that going south quickly but as long as you're smart about not only which dependencies to choose from whom but also knowing when you really need them then you end up with a robust, easy to maintain system in the end. The whole point of having a dependency chain is to benefit from well tested code that often does mundane things that you neither have the time or expertise to create yourself. I've found that as long as I choose libraries that are up to date, look to be maintained, are decently tested, and do something that I couldn't do as well or don't have the time to implement as well then all is well. I also have a rule that if a dependency is at all mission critical or not easily replaced I will either fork that library and maintain my own copy or create one for myself. This has been true for every language I've worked with. Go, PHP, Node, or Ruby so far. Updating might be cumbersome but if you're following best practices then you've got tests that ensure updating a library won't break your code. You also don't go around mass updating things. You update when there's a good reason to (security patches, language compatibility, etc.). Deployment should only suck the first time. Nowadays we have tools to ensure systems are replicable so you can be confident code will run fine regardless of the environment. I don't think we'll ever have a plug and play experience. We have so many hobbyist libraries precisely because our languages and tools are so flexible. Hiding complexity is what programmers do for users. To hide from developers too would likely do more harm than good and result in a generation of programmers who don't understand how their systems really work. I point to Rails and Meteor as examples. There are Rails developers who are a thing in and of themselves. They're not Ruby devs who know Rails, they're just Rails developers. There needs to be the person like the Rails core team who know how to put dependencies together in a way that creates a functional modular system.

bluetomcat 11y ago
A perfectly valid case for using a library is when it implements a huge standard that you don't have the time, knowledge or expertise to implement yourself. Think of zlib, libpng or libcurl. These are de facto "reference implementations" of the respective standards, so you'd better rely on them in order to be future proof. > We have so many hobbyist libraries precisely because our languages and tools are so flexible. I beg to differ. The (initially) small hobbyist libraries are often working around the deficiencies of the language/runtime/core libraries. This has been the case for JavaScript since jQuery. If a third-party library doesn't implement a format or a protocol, or an intricate algorithm, but rather tries to augment the language, that is a huge red flag.