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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Never Reinventing the Wheel Is Anticompetitive

27 点作者 blackhole超过 10 年前

9 条评论

ggreer超过 10 年前
Is there any take-away from this rant? I guess I could have dodged heartbleed if I&#x27;d written my own TLS library and avoided any software that depended on OpenSSL. Considering the effort involved, I think I&#x27;ll take heartbleed and rotate my keys.<p>Given the number and quality of libraries today, one should spend very little time re-inventing wheels. I say that as someone who has re-invented multiple wheels. I wrote a clone of Ack[1]. I&#x27;ve built distributed data stores instead of using open source solutions like Cassandra. Even in those cases, building that software was harder than I thought it would be. Existing projects have graduated from the school of hard knocks. Time has forced them to solve issues like cross-platform compatibility, documentation, and API stability. They&#x27;re certainly not perfect, but unless you&#x27;re a domain expert with a lot of time to spend, you&#x27;re not going to do better.<p>We can only re-invent so many wheels in our limited time. If you do the math, a career consists of approximately 1 million lines of code. Almost always, that time is best spent building on top of existing software.<p>1. <a href="https://github.com/ggreer/the_silver_searcher" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ggreer&#x2F;the_silver_searcher</a>
评论 #8647612 未加载
评论 #8648246 未加载
romanovic超过 10 年前
I also do not see much basis for the opening statements, as written. Which individuals or communities are pushing the dogma that you shouldn’t write anything yourself? I’d be interested to know where Erik has met resistance when writing software specialised for his set of problems. Anecdotally, this is the opposite of my experience as a programmer.<p>OpenSSL and other cryptography libraries are a special case - implementing your own crypto library is almost universally accepted to be a very bad idea for what should be obvious reasons. OpenSSL is used widely because it solves a problem that is best served by a universal solution - the need for standardised protocols to secure internet communications. Of course there are alternative crypto libraries out there, but it is not a bad thing that most of us rely on a single library that really is well-suited to solve this need for crypto. We benefit much more by focusing developer resources and eyeballs on OpenSSL rather than trying to diversify for the sake of diversification.<p>Heartbleed is a very poor example that doesn’t support the premise of this post. It was discovered, publicly disclosed, and immediately fixed <i>because</i> it is open source, widely used, and has so many developer eyeballs on it. This was a positive outcome to a severe vulnerability, not a consequence of failing to diversify. Closed-source crypto libraries (or any that do not undergo the scrutiny of many developers and crypto specialists) are the domain of persistent, equally severe vulnerabilities that go undiscovered and&#x2F;or undisclosed, increasing our exposure to malicious actors.
mwcampbell超过 10 年前
This rant makes some valid points. But if you decide to reinvent a wheel, you should be fully aware of what you&#x27;re getting into, and the responsibility you&#x27;re taking on.<p>For example, if you decide to create a new UI toolkit, by which I mean something that draws the widgets and handles low-level input events itself as opposed to a wrapper over one or more other such toolkits, then you need to be prepared to deal with things like accessibility for users with disabilities. This includes blind users who require a screen reader, but also people with mobility impairments who need to use alternate input devices, speech recognition, or the like. This means implementing the accessibility APIs of your host platform(s), which isn&#x27;t necessarily easy. If you release an application with your own home-grown toolkit (or someone else&#x27;s) that doesn&#x27;t implement accessibility, then your app will be unusable to some percentage of people who need or want to use it. That&#x27;s probably not too bad if you&#x27;re developing a game, but is more of a problem if someone needs to use your app to do their job, take a class, do business with a particular company, or any of the other increasing number of important functions that involve software.<p>Or, to throw out a few other examples beyond my usual soapbox: If you&#x27;re writing a new crypto library (the post did reference OpenSSL), make sure you handle side channel attacks and all the other gotchas that come with crypto. If you&#x27;re rolling your own HTML templating thing, make sure it&#x27;s not susceptible to XSS. If you&#x27;re creating a new database or other form of data persistence, make sure the persistent data isn&#x27;t easily corrupted. And so on.<p>Regarding the part about &quot;most programmers&quot;, I&#x27;d venture to say that for most developers of new applications, it&#x27;s best to build on proven, mature infrastructure as much as possible, and avoid gratuitous reinvention.
api超过 10 年前
Agreed, and then some. I don&#x27;t think it&#x27;s always bad to reinvent the wheel -- especially if the wheel as it exists today is wobbly, flat, or square.
评论 #8647001 未加载
amelius超过 10 年前
&gt; then I invite you to put monster truck tires on your smartcar and tell me how well that works<p>That&#x27;s why I prefer &quot;active libraries&quot; [1], i.e., libraries that can configure themselves based on the needs of a consumer application. Generic types can go a long way to keep things both flexible and efficient, but sometimes the best option is to have a library generate its own code.<p>[1] <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8031" rel="nofollow">http:&#x2F;&#x2F;citeseerx.ist.psu.edu&#x2F;viewdoc&#x2F;summary?doi=10.1.1.40.8...</a>
romain_dardour超过 10 年前
It we never reinvented the wheel it would still be made of stone.
ezl超过 10 年前
&gt; <i>Including the entire jQuery library just so you can have the $(&quot;id&quot;) shortcut is like driving a smartcar with spiked monster truck wheels down a freeway. It&#x27;s dangerous, stupid, and completely unnecessary.</i><p>Gold.
评论 #8647527 未加载
mistercow超过 10 年前
This article fails to take forking into account, which I feel largely nullifies its point. I&#x27;m not saying that reinventing the wheel is always bad, but to leave out forking is to construct a pretty weak straw man.
评论 #8646977 未加载
LukeB_UK超过 10 年前
I have no idea where he gets the basis for his first couple of sentences.