TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

On software popularity

140 点作者 djanowski大约 10 年前

19 条评论

beat大约 10 年前
It&#x27;s turtles all the way down.<p>Using a lightweight, comprehensible framework is good, until you hit the limits of that framework and start pulling in lots more libraries to fill the gaps (the Sinatra&#x2F;Cuba world). Using a heavyweight, complete library is good, until you start suffering from bugs caused by incomprehensible magic buried deep inside (the Rails world).<p>I see the same problem in microservices versus monolithic apps. If you use microservices, you have a lot of duplication and inter-component configuration management complexity. If you use monolithic apps, you get the big ball of mud.<p>Or, as I sometimes put it, &quot;Which kneecap do you want to get shot in?&quot;<p>The underlying problem isn&#x27;t fashion, or bloat. It&#x27;s that software is very, very complex. Unless you&#x27;re doing hardcore embedded work in assembly language, you&#x27;re building a raft on an ocean of code you won&#x27;t read and can&#x27;t understand.<p>A friend of mine put it well once. He said that you should have deep understanding of systems one layer from yours (ie your frameworks), and at least a shallow understanding of things two or three layers away (operating systems, etc). If you don&#x27;t have some grasp of the things you depend on, you&#x27;re relying on magic and are vulnerable. But you can&#x27;t realistically expect to know it all.
评论 #9348010 未加载
评论 #9350090 未加载
t4nkd大约 10 年前
I find it pretty interesting that the only real concern was &quot;can this team solve my technical problem using the best tools in the shortest amount of time&quot; but did not seem to consider things like, &quot;What happens when this team moves on&quot;. One of the biggest assumptions that I&#x27;ve made is that when choosing tools, choosing the most popular ones gives you the highest chance of bringing someone on board who already groks them, finding learning material, etc.<p>I seem to be noticing more often now that &quot;the best tool for the job, for the person, at the time&quot; is completely acceptable. I feel as though this didn&#x27;t used to be the case, and I know a lot of more &quot;established&quot; engineers who believe it&#x27;s naive to choose tools based on an inclination or personal&#x2F;team preference. While in this case, we&#x27;re getting less code in the dependency, I&#x27;m highly suspicious of how their working knowledge, method of code organization, etc... can be transferred over time.<p>Ultimately though, knowing what actually happened over time with this project would be the most interesting. Does he eventually find new team members who convince him to switch back to a framework that is more widely understood and practiced?
评论 #9348378 未加载
评论 #9348459 未加载
seppo0010大约 10 年前
This article feels like a follow up on &quot;On Ruby&quot;[1] and related to &quot;It’s OK for your open source library to be a bit shitty&quot;[2]. The common theme I find in all three is the quality and health of a dependency. I agree with OP that stars and latest commit are not clear indicators of quality.<p>I think more useful indicators are tests, documentations and pull requests.<p>* Tests. These are things you can actually run to see if the library actually works. In most cases, you can read them and understand how it is supposed to be used. On some platforms even if the tests passed in the past, they may not pass now, for example using different version of the language or platform. The coverage of the tests would be nice, but it is hard to measure at first sight, therefore using the ratio of tests LOC to library LOC might be an indicator.<p>* Documentation. The documentation itself does not change how the library behaves but it is a clear indicator whether the author expected someone else to be able to use it or not, and shows a sort of responsibility. Most of weekend hacks would not have one.<p>* Pull Requests. If there are old and open pull requests, that seem useful, it is a bad sign for the maintainer of the project.<p>[1] <a href="http:&#x2F;&#x2F;hawkins.io&#x2F;2015&#x2F;03&#x2F;on-ruby&#x2F;" rel="nofollow">http:&#x2F;&#x2F;hawkins.io&#x2F;2015&#x2F;03&#x2F;on-ruby&#x2F;</a><p>[2] <a href="http:&#x2F;&#x2F;www.drmaciver.com&#x2F;2015&#x2F;04&#x2F;its-ok-for-your-open-source-library-to-be-a-bit-shitty&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.drmaciver.com&#x2F;2015&#x2F;04&#x2F;its-ok-for-your-open-source...</a>
mcguire大约 10 年前
&quot;<i>That didn&#x27;t prevent further criticism, and many comments followed recommending Rails and Sinatra as alternatives based on familiarity and popularity.</i>&quot;<p>Ah, the &quot;industry standard&quot; argument, where <i>industry standard</i> seems to be defined as &quot;whatever I&#x27;ve read the most blog posts about&quot;, or &quot;whatever was used at my last job&quot;, or possibly &quot;what I learned in school (last year)&quot;.<p>One of my major dissatisfactions is newly hired, junior (or mid-level) developers coming on board and then immediately wanting to change <i>everything</i> to be more &quot;industry standard&quot;. They rarely seem to try to understand why we&#x27;re already doing what we&#x27;re doing, they almost never seem able to explain <i>why</i> what they want to do is strongly better, and they frequently just go off and do it, leaving a pile of projects each doing the same task in different ways.
评论 #9348127 未加载
hasenj大约 10 年前
One of the problems with popularity is you will get a lot of mediocre developers who don&#x27;t know what they are doing. You know, the people who pick up tools only because they think it will land them a job more easily. The same people who picked up VB.<p>You can&#x27;t build a product with a mediocre team, no matter what tools you have.<p>If you have a decent team, I think they will be able to manage to build great products even with not-so-great tools. Of course, if you force them to use shitty tools, they might just decide to leave.
评论 #9348581 未加载
评论 #9347924 未加载
Ologn大约 10 年前
He talks about the virtue of using new and untested languages and frameworks. The example he uses is Twitter&#x27;s use of the relatively new Ruby on Rails framework.<p>Unfortunately for him, this is a bad example. Twitter was notorious in its early days for being down all the time. So Twitter decided to migrate to Java - a dull, over-verbose, yet reliable language.
评论 #9349323 未加载
matthewmacleod大约 10 年前
It&#x27;s an interesting thought.<p>I&#x27;m primarily a Ruby developer. Literally every single time I&#x27;ve started a web-oriented project using something like Sinatra or Padrino etc., I&#x27;ve ended up regretting it. I end up building a shitty, half-featured, buggy version of Rails. My experience is that most other projects end up the same.<p>I suppose mileage may vary; perhaps it&#x27;s easier to write bloated apps in Rails. I&#x27;m not convinced that&#x27;s a good reason to avoid it, though.
评论 #9350478 未加载
评论 #9349760 未加载
jingo大约 10 年前
That Knuth quote by itself is interesting.<p>Perhaps he is not suggesting that popular ideas likely to be are wrong.<p>Instead maybe he is saying that to think and develop ideas like Knuth&#x27;s one needs a certain amount of irreverance for what is popular.<p>(Undue?) reverance is rampant in the software industry, in my opinion. Would Knuth agree?
评论 #9347598 未加载
评论 #9347971 未加载
评论 #9347812 未加载
zkhalique大约 10 年前
Wrong according to whom?<p>If most people believe X and that makes you think X is probably wrong, then you are probably in one of the groups that believes alternatives to X. There are lots of groups like yours, they can&#x27;t all be right, and therefore your chances of being any more right than X is are slim (all things being equal). At least, with X, you have the support of the population and can fit into society during your lifetime.<p>And the nice thing about X is that it has been battle-tested by many people, and while it may be &quot;wrong&quot;, it WORKS.
评论 #9348081 未加载
评论 #9348001 未加载
animatedgif大约 10 年前
Aforementioned CTO here. Great writeup soveran (:<p>With the past year in retrospect, I can say with certainty that I&#x27;m quite pleased with our decision to embrace Cuba. It&#x27;s led to a highly-declarative codebase with clear layering and very little magic.<p>If anyone has any specific questions I&#x27;d be more than happy to answer.
hyperpallium大约 10 年前
Mainstream stuff isn&#x27;t necessarily the best, but it&#x27;s &quot;good enough&quot;. The big benefit isn&#x27;t the product itself, but a market effect: multiple third-party add-ons and service will be available. Bugs and gaps will have been found and gaffa taped. A large skilled employee pool, commodity-priced. Basically, &quot;if we <i>all</i> make the same mistake, it will be worth someone&#x27;s while to take care of us&quot; (baby boomer effect).<p>This is what makes established products unreasonably difficult to dislodge (from a technical perspective).<p>At the other end of the capability spectrum, Alan Kay said there&#x27;s an exception to the rule to <i>reuse not reinvent</i>: those who <i>can</i> make their own tools <i>should</i>.
ChrisArgyle大约 10 年前
On the flipside, &quot;Is this task so special that we need to break from the pack?&quot;
评论 #9349202 未加载
redwood大约 10 年前
Would be interesting to check in with the team now
_greim_大约 10 年前
I think the article makes a good point.<p>Counter-point: at least in the open source world, popularity can translate into lots of eyeballs on the code, lots of bug fixes, better ability to hunt down solutions on Google, hire people, etc.<p>Counter-counter-point: lots of people depending on a project may slow its progress and prevent its maintainers from correcting fundamental design mistakes, all for fear of breaking existing installs.
评论 #9348960 未加载
评论 #9351423 未加载
emodendroket大约 10 年前
&gt; When Rails was created, Ruby wasn&#x27;t mainstream. When Twitter launched, Rails had been out for just four months. Adopting Ruby and Rails were bold moves made by people that didn&#x27;t care about popularity. They were forced to assess the quality despite the lack of stars.<p>Apparently they didn&#x27;t do a good job since they&#x27;ve long since abandoned it.
评论 #9351031 未加载
meistro大约 10 年前
I don&#x27;t remember his name, but one of the creators of Angular said (paraphrasing) &quot;When choosing between libraries and in doubt, choose the one that has more testing in place&quot;. This is something I&#x27;ve personally found true the majority of the time.
评论 #9348114 未加载
serve_yay大约 10 年前
Sure, sure. If a tool or an idea is popular it still may not be any good.<p>But the thing about groupthink is, it is at its most insidiously effective when its participants don&#x27;t recognize it as such. It works best when one feels oneself an iconoclast for saying what most everyone around them believes.
sinful大约 10 年前
&quot;Following the crowd is easy, but it&#x27;s often a shortcut to the wrong place.&quot;<p>In the first place, if the product does not work well, it won&#x27;t even get much attention or popularity. There are reasons why products got massively popular in the first place.
xtx23大约 10 年前
for micro vs. monolithic, why does it have to be versus decision? &quot;I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.&quot;