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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

On C popularity vs. Python, size of stdlib, package managers in languages

21 点作者 urlwolf超过 1 年前

8 条评论

weinzierl超过 1 年前
<i>&quot;1. It complies on lots of architectures. Behold what Justine Tuney is doing :) Portable C is actually real!@</i><p>There is no other language that runs on as many platforms as C, that much is true. If Justine Tunney&#x27;s Portable C, as much as an accomplished as it is, is a practical solution is a different question.<p><i>&quot;2. You don&#x27;t have to audit code from a lib, nor trust it by default&quot;</i><p>Now you have to audit the LLM generated code - all of it - and you have gained exactly nothing. It&#x27;s even worse, because you can assume your library code has been tried and tested by others even if you don&#x27;t trust them whereas you LLM generated code is fresh and new and probably full of quirks and missing corner cases.<p>&quot;<i>3. You don&#x27;t have to fear that updating packages in your system (or virtual env, or container) would break your &#x27;batteries included&#x27; code&quot;</i><p>True, but you don&#x27;t benefit from updates that fix bugs and security vulnerabilities that <i>others</i> have found for you.<p><i>&quot;4. You can do formal verification (this I know nothing about, just learning now on your prompting!)&quot;</i><p>You can, but how practical is it? Have you ever done it?<p>&quot;<i>5. It&#x27;s far easier to deploy&quot;</i><p>This is a valid point but I also think it depends a lot on your environment.
评论 #38557303 未加载
gemstones超过 1 年前
Aren’t most security vulnerabilities in C or C++ code? Seems a bit rich to point to C’s write-your-own approach as being a security benefit. I’d want to see some data on that before I arrive at that conclusion.
评论 #38560104 未加载
mlsu超过 1 年前
The &quot;C is a shark&quot; is really apt, I like it. Keeping that one for future use.<p>&quot;Write it yourself&quot; ... I&#x27;m not so sure. It will come back in a limited way; stuff like leftpad is obviously stupid. But chatGPT is not good at tackling very large problems.<p>I think GPT require both breadth (large context size) and depth (smarts) to create good programs, organized well, with consistent behavior. Some code is very local. It&#x27;s easy to write yourself because it touches only a small bit around it. Competitive programming problems are like this. GPT is good at those. The jury is still out on its ability to do anything further.<p>But a lot of code is far more global. It takes the work of a skilled programmer to take all of the small local pieces under an API and organize them to produce a cohesive whole. This large-scale organization of software is and always will be excruciating in a language like C.<p>C is a shark, yes. A shark is a hundred million years old; it&#x27;s fast, stealthy, and sleeps with one eye open. But try getting 20 sharks to collaborate in a hunt, like orcas do. It&#x27;s simply impossible.
habitue超过 1 年前
I think the author is right that if writing small pieces of straightforward functionality is easier with coding assistants, then on the margin, people will use less dependencies.<p>I definitely think C is the wrong language to do it in. A strong type system is an amazing counterbalance to LLM generated mistakes.
maegul超过 1 年前
The idea of GPT or code generators supplanting the need for libraries and languages with large standard libraries is likely jumping ahead with optimism.<p>But … I think the idea is relevant and, security&#x2F;QA issues aside, this is a real hard-to-see shift that might be brought on by AI: shifting of the equilibria and practicalities around what parts of the craft and profession are worth caring about and which are best left to the computer&#x2F;AI.<p>Dependencies vs “write it yourself” (with an AI). Syntax&#x2F;API design for readability&#x2F;comprehension vs for computer&#x2F;AI parse-ability and thoroughness. Rewrite something to be better vs train an AI on its usage and move on.
eqvinox超过 1 年前
&gt; [Packages] Then the cracks started to show. A security vulnerability here. […]<p>&gt; But C? You can actually perhaps write a solution in C as fast as one in python &#x27;batteries included&#x27; now just because of those code generators.<p>… sure, it might be fast and easy to pull some code out of <i>&lt;AI&#x2F;ML of the day&gt;</i>. But the AI doesn&#x27;t do security fixes for you. And it&#x27;s trained on people&#x27;s imperfect code, potentially including vulnerabilities.<p>Whether this is a winning trade…
cxr超过 1 年前
On modern &quot;language package managers&quot;: it&#x27;s better to think of them in terms of what they are—orthogonal version control systems. You start with your main, base-level VCS (most commonly Git these days, and therefore not just a VCS, but a DVCS), and then you have this secondary hack of a version control system layered on top—or rather, interwoven directly into the source tree itself. With these secondary SCMs, you&#x27;re manually writing the VCS metadata (version strings) using your text editor into a file or files that live right beside your source code (instead of a hidden directory that your project is completely agnostic to, like .git). This only exists because people don&#x27;t really want to completely buy in to distributed version control after all (they still prefer to defer to the network for things they think &quot;shouldn&#x27;t be in version control[sic]&quot;) and in some instances they also don&#x27;t think the base-level VCS has a rich enough (i.e. semantic) understanding of the objects it&#x27;s managing.<p>One of the interesting and unfortunate effects of this is that people don&#x27;t notice it; because they think of these as package managers first (and as version control systems not at all), it means they&#x27;re not graded against the standards that a version control system ought to be.<p>(Additionally, if you start talking about disregarding conventional wisdom and checking your dependencies into version control[1][2], people become totally irrational and respond as if you&#x27;re insisting they stop using package managers. You can keep using your current package manager and <i>still</i> check the dependencies in. The only thing you&#x27;re changing is that when you run `npm update` or whatever, there&#x27;s no entry in .gitignore that stops Git from picking up the changes. Again, people begin responding totally irrationally if you suggest that they should just let their primary VCS track the changes, as if you&#x27;ve instead just told them to untether themselves from the ISS and go out on their own. Nothing about &quot;check your dependencies into version control&quot; requires you stop tracking upstream, or anything else—it just means to check your dependencies into version control!)<p>1. &lt;<a href="https:&#x2F;&#x2F;www.forrestthewoods.com&#x2F;blog&#x2F;dependencies-belong-in-version-control&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.forrestthewoods.com&#x2F;blog&#x2F;dependencies-belong-in-...</a>&gt;<p>2. &lt;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38425042">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=38425042</a>&gt;
rvz超过 1 年前
&gt; It will be abused by junior programmers and probably the code quality of humanity on average WILL go down. But that doesn&#x27;t mean that you (as someone who has written code for decades) cannot use it as an extra pair of hands, knowing full well of the limitations.<p>Not just juniors, but anyone who just want less programmers in general; seniors included. If you just hit generate in the prompt and still don&#x27;t understand the code yourself,<p>&gt; 1. It complies on lots of architectures. Behold what Justine Tuney is doing :) Portable C is actually real!<p>Very portable C&#x2F;C++ level security vulnerabilities all in a single binary and executed on any platform. Fantastic! &#x2F;s
评论 #38555458 未加载