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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

1% the Code (2001)

143 点作者 mr_tyzic超过 9 年前

18 条评论

sam_lowry_超过 9 年前
6 years ago, I rewrote 30 000 lines of C++ code in 1000 lines of Ruby.<p>A year ago, I rewrote 424 lines of Java+Spring+Hibernate in 18 lines of bash. This is less glorious, but if you compare the size of the deliverable, it&#x27;s 39Mb for the J2EE webapp against… 772 bytes for the shell script.<p>At my current job, I maintain an app with 500,000 lines of code that could easily fit in 20,000.<p>Code bloat is indeed a recurrent problem.
评论 #10768388 未加载
评论 #10768296 未加载
评论 #10768459 未加载
评论 #10769646 未加载
评论 #10768227 未加载
评论 #10768691 未加载
评论 #10768875 未加载
评论 #10769785 未加载
评论 #10768413 未加载
评论 #10768556 未加载
评论 #10768456 未加载
评论 #10770406 未加载
评论 #10768319 未加载
archgoon超过 9 年前
&gt;But I&#x27;m game. Give me a problem with 1,000,000 lines of C. But don&#x27;t expect me to read the C, I couldn&#x27;t. And don&#x27;t think I&#x27;ll have to write 10,000 lines of Forth. Just give me the specs of the problem, and documentation of the interface.<p>I could be wrong, but I&#x27;d wager that a lot of projects that are 1,000,000 lines of C don&#x27;t have well defined interfaces or documentation.<p>However, if the author wants to give it a shot, they could try replacing v8 with pure forth. That&#x27;s a fairly well defined problem, they just have to maintain compatibility with the exposed v8 api.
评论 #10768387 未加载
RodgerTheGreat超过 9 年前
The most important idea in Forth is factoring. Breaking complex tasks into small pieces. In an ideal Forth codebase, most definitions are about a line long, contain at most one control structure and reference no named variables.<p>Forth&#x27;s stack-oriented semantics make function calls very cheap- a function call and return is literally two instructions, whereas languages which use activation records will turn a function call into dozens of instructions- copying arguments around, backing up registers, etc. Since it&#x27;s computationally inexpensive, you don&#x27;t need to sweat over whether your optimizing compiler will manage to inline a function.<p>Short, simple and mostly pure functions are easy to test in isolation- there aren&#x27;t deeply nested code paths to exercise.<p>Lots of short functions allow your codebase to reuse more of those functions- any redundancy can be collapsed together, both shrinking the codebase and improving test coverage. This effect is magnified in more complex programs.<p>You can do this sort of thing in other languages, but forth&#x27;s syntax <i>and</i> semantics for function definition and invocation are both very lightweight, and this makes it much easier to apply.
评论 #10770512 未加载
benbenolson超过 9 年前
I think that the author of this article is mistaking LOC for readability. Despite colorForth being wonderfully concise and independent of any operating system, that doesn&#x27;t make it convenient or readable for future programmers. Just because something is a number of lines longer than another something, doesn&#x27;t mean that it&#x27;s less readable.<p>Take Perl, for example. I often write Perl scripts, and they&#x27;re very few lines, but nobody can read them, which is really what matters. So, I&#x27;ll expand it to be more C-like (calling functions with parentheses, using less implied arguments and scalar&#x2F;vector contexts, etc.), thus making it very easily readable by people that don&#x27;t even know Perl. I regard this revised version much better than the more Perl-like and obfuscated (although shorter!) version.
评论 #10769817 未加载
评论 #10769532 未加载
评论 #10770721 未加载
superuser2超过 9 年前
&gt;Code is scattered in a vast heirarchy of files. You can&#x27;t find a definition unless you already know where it is.<p>Not if you&#x27;re using a proper IDE (or the right emacs&#x2F;vim plugins, which are effectively an IDE).<p>&gt;Code is indented to indicate nesting. As code is edited and processed, this cue is often lost or incorrect.<p>Not if you&#x27;re using a proper IDE configured for the project&#x27;s chosen style. My engineering org also has linters in pre-commit hooks and automatically commenting on code reviews.<p>&gt;Sometimes a line of code contains only a parenthesis, or semicolon. This reduces the density of the code, and the difficulty of reading it.<p>Depends on the style guide you choose. Also, some people find this more readable.<p>&gt;There&#x27;s no documentation. Except for the ubiquitous comments. These interrupt the code, further reducing density, but rarely conveying useful insight.<p>The only documentation I&#x27;ve ever found useful (aside from comments) was automatically generated from comments, explaining the signatures of methods and what they do.
评论 #10768891 未加载
modulus1超过 9 年前
&gt; It&#x27;s strongly typed, with a bewildering variety of types to keep straight. More errors.<p>Odd complaint, especially to be levied against C.
评论 #10768385 未加载
评论 #10768244 未加载
评论 #10768314 未加载
mwcampbell超过 9 年前
This post by Yossi Kreinin offers an interesting perspective on Forth and Chuck Moore&#x27;s general approach to programming:<p><a href="http:&#x2F;&#x2F;yosefk.com&#x2F;blog&#x2F;my-history-with-forth-stack-machines.html" rel="nofollow">http:&#x2F;&#x2F;yosefk.com&#x2F;blog&#x2F;my-history-with-forth-stack-machines....</a>
评论 #10770626 未加载
fffrad超过 9 年前
When you look at code you wrote in the past, whether it is 1000 lines, 3000 or 100,000 you could always think of a way to remove the redundancies and such and turn it into a smaller number of lines.<p>But the first time you write it, the first time you are solving the problem, it is much harder to focus on that part.<p>This is not to say that it&#x27;s ok to have unmaintainable million lines of code application, but more that it is not something we willingly do to make ourselves look more important in a company.
chipsy超过 9 年前
Proclaiming that the syntax only causes problems stands in complete defiance of most people&#x27;s preferences in programming syntax.<p>We like syntax errors because they mold thoughts more precisely. Going against that is also going against a lot of &quot;productivity enhancers&quot; - we build them because we expect to have a lot of code, and we want to reduce the kinds of errors that it may contain. That doesn&#x27;t mean that we should abuse them to write as much code as we can, but it does turn out that way in practice.<p>So in an odd way Moore and co are right - we would be more free if we also constrained ourselves more on this point.<p>But the broader thought is that you can apply such constraints at any time, in tandem with what you already like. And that is more likely to produce an innovation than &quot;just Forth&quot;.
评论 #10768294 未加载
throwaway999888超过 9 年前
If some C programmers have that <i>scoff at higher level programmers</i> attitude, Chuck Moore is the equivalent but addressed at C programmers (and higher, I guess).<p>I have a feeling he&#x27;s not the kind of person a C programmer could say things like &quot;C is high-level (obvious one-to-one mapping) assembly&quot; and &quot;C is (blanket) efficient&quot; around, and get away with it.
Procrastes超过 9 年前
Chuck Moore came out and spoke to us at work not long ago, and I have to admit I had a total fanboy moment. There are very few people in the world with as clear a view of how to make an entire system, hardware and software, directly reflect the problem to be solved with no cruft. There&#x27;s alot to learn just from the way he decomposes a problem.
评论 #10770108 未加载
nickpsecurity超过 9 年前
1% the code, 0.01% the reader comprehension. I&#x27;ll stick with a good ALGOL or LISP language anyday. Especially with macros plus support for real HW rather than 18-bit etc.
overgard超过 9 年前
I agree with how verbose some of these languages are, but this is a bogus argument. You can shorten almost any design on a rewrite, regardless of language. Not to mention the &quot;density&quot; metric is ridiculous. Minified javascript is certainly more dense than regular javascript, but nobody would argue it&#x27;s simpler.
necessity超过 9 年前
People like to blame programming languages for programmer&#x27;s faults.
smartmic超过 9 年前
I just started to learn the Factor programming language. I think of it as a modern implementation of a stack based language like Forth (similar what Clojure is for Lisp).<p>I admit, the first step were a bit brain-twisting, but after getting hands dirty, programming feels relieving. Like a rain shower on a steamy hot day. No worrying about syntax and punctation, elegantly shuffling the stack is fun. For me a perfect demonstration of KISS.
mhd超过 9 年前
As someone who&#x27;s still doing a lot of Perl: Can&#x27;t we just ease up on the line count fetish? Some languages are really bloated, but I&#x27;d still say that more often than not, the sheer amount of lines isn&#x27;t the most major factor of a program&#x27;s cognitive load.
qwertyuiop924超过 9 年前
You have got to be kidding me. I mean come on, you&#x27;re joking, right? If you gave me some qualification, maybe. I know that FORTH is more compact than C, and the code decrease in size might be reasonable in some cases, but the reasons you give are insane! come on!<p>Elaborate Syntax: Your syntax is simple, C&#x27;s is less simple. If you want elaborate, look at PERL or Haskell. Redundancy and Confusing Types: Fair enough, but the types have to be the ones they are because C&#x27;s supposed to be close to the metal. Therefore, you need specific bit sized types. It could be better than it is, though.<p>Strong typing causes errors: Um. Take that up with the angry Haskellers lining up behind you. I&#x27;ll just duck off this way... Honestly, C&#x27;s type system is pretty awful, but that&#x27;s not because it&#x27;s strongly typed.<p>Infix:...Yeah, pretty much, but the mainstream won&#x27;t except anything else.<p>Parens: Tell that to the lispers. Parens shine for syntax parsing, and the incredibly common editor support makes it even nicer than Python for editing. Unclear how source will be translated: Well, I guess, but more so than anything higher up the stack, like, just to pick a random example, most modern FORTH implementations. Subroutine calls are expensive: Compared to what? 1 mov or push instruction for for each arg, and than a call instruction, at least on x86. Most other processor architectures seem to have similar things going. Those are all pretty fast.<p>Elaborate Compiler, Object Libraries: Yes, compared to FORTH, the compiler is elaborate, but that isn&#x27;t why object libraries are distributed, seeing as there&#x27;s a C compiler for every system under the sun. And distributing object libraries isn&#x27;t exactly hard.<p>Lots and lots of files: Yeah, this sucks. But every other system is going to have the same problem, and a proper module system that associates functions to files is really the only way to fix it, aside from oddly specific introspection utilities. Most other languages, say, for example, FORTH, don&#x27;t have this, AFAIK.<p>Indentation as an indication of nesting: And you suggest counting braces as an alternative? or just not having nesting? Because most languages, say, for instance, FORTH, have nesting.<p>No Docs: In BAD C code, this is true. As in bad code in any language, like, for instance, FORTH, as any language designer knows that the language cannot make bad programmers good.<p>Names are Hyphenated: &quot;I think hyphens suck&quot; isn&#x27;t a problem with the language, it&#x27;s just a personal preference. Constants are named: With my passing familiarity with FORTH, I don&#x27;t know what he&#x27;s on about here. Could somebody explain, so I can see if I agree?<p>Preoccupation with Contingencies: Because everybody loves leaky abstractions that fail at critical moments for ill-defined reasons.<p>Conditional Compilation: This feature sucks. It really does. The problem is, I don&#x27;t see what else they could have done. So my response here is, Do you have any better way to do cross platform compatibility? Because I would honestly love to see it. I&#x27;m serious.<p>Hooks: Ahhh, I see. You&#x27;re from the beautiful-diamond camp of software design. I can recognize you guys by your catchy slogan, &quot;Don&#x27;t Design With The Future In Mind.&quot; Programmers best interest to exaggerate complexity: No language can fix this. It&#x27;s impossible, because this is a social pressure.<p>Portability: Yeah, basically.<p>Maybe I haven&#x27;t seen enough C. Maybe I haven&#x27;t seen enough FORTH. Maybe I just can&#x27;t get into Chuck&#x27;s mindset here. But his claims just seem insane.<p>EDIT: I read some more off of Chuck&#x27;s pages, he seems to be thinking more in terms of embedded architectures and single purpose code. Fair enough, in those situations, some of his reasoning makes sense. But the presentation of this page still makes him look like he&#x27;s off his rocker.
评论 #10768689 未加载
评论 #10771313 未加载
HillaryBriss超过 9 年前
It has elaborate sytnax