4 ms·
A common theme in this thread is the relatively typical software development approach of 'well, I'll let them sort it out'. It's not lazy, and it sort of resemb
by kevingadd 8y ago
A common theme in this thread is the relatively typical software development approach of 'well, I'll let them sort it out'. It's not lazy, and it sort of resembles delegating problems you can't handle to someone else - but the problem is if you do it enough on large scale projects you just end up with a huge stack of miscommunications, and a talented team that has put together a high quality product that completely fails to do what it needs to do. You can't successfully delegate without ensuring that everyone knows what their commitments are, and you need to pay attention on a regular basis to make sure that everyone still knows what the plan is.
It's easy to end up in a position where you're making that mistake if you're a small team used to shipping smaller products or features. Suddenly you're on a bigger project, maybe a bunch of the developers work at another company, maybe you've got a few million users instead of a smaller set like a hundred thousand, and the same planning and team collaboration techniques you've used are subtly harmful and produce bad outcomes a year or two down the line. I observed the WebAssembly design process suffering from same of the same problems early on because it was a group of engineers from multiple companies who were generally used to just working in tiny silos on experiments or features of their own, not A Collaborative Effort For Millions Of Users, much like what Go has turned into now that it's scaled out and not just a prototype language made for Google internal use.
- rurban 8y agoFor me the important point was that the implementer cannot delegate the community discussion to someone else. He needs to be part of it, and waste hours of important development time on bike shedding. Or just ignore it and apologize afterwards for rendering the bike shedding useless.
- sgift 8y agoYeah, it is bike shedding to discuss dependency management, because dependency management is an "insignificant or unimportant detail" of a programming language. /s
- majewsky 8y agoYou say "/s", but for some reason, many people still hold the sincere position that dependency management is something that can just be tacked on to a language as an afterthought.
- coldtea 8y agoOf course it can. npm, composer, etc all added it to their respective languages as afterthoughts, and many years (or decades even) after the language was out.
- al2o3cr 8y agoGiven the whole mjs-vs-js situation with npm, it's more of a counterexample for adding dependency management late.
- coldtea 8y agoThat's nothing really. They have to use 2 different suffixes to denote 2 kinds of files vs modules. Meanwhile millions of people use it for 10 or so years for all kinds of deployments. If only all languages had that unimportant problems.
- rurban 8y agoIt's bike shedding when you have no actual idea about the problems and solution, but decide on something anyway. The implementor in the meantime figured it out by himself and just did it.