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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Those Who Say Code Does Not Matter

266 点作者 swannodette大约 11 年前

52 条评论

eldude大约 11 年前
This is fundamentally what I call the Tower Defense[1] model, borrowed from my old manager here at LinkedIn, Rino Jose[2].<p>The Tower Defense model is an approach to software reliability that focuses on catching bugs at the lowest level, to avoid the inevitable combinatorial explosion in test coverage surface area. In other words, deal with problems like these at the language level, so there is NO NEED to deal with them at a higher process-level.<p>No one is disputing that processes, QA or Devops couldn&#x27;t&#x2F;shouldn&#x27;t hypothetically catch these bugs before entering production. The problem of course is that they usually don&#x27;t, because the lower level defenses are allowing too many bugs through, that they really shouldn&#x27;t and the higher level processes become overwhelmed, fail, and allow bugs to cross the critical production threshold.<p>This means always giving higher priority to lower-level methods of reliability. For example,<p>* Language rules <i>are more important than</i><p>* Unit tests <i>are more important than</i><p>* Integration tests <i>are more important than</i><p>* Code reviews <i>are more important than</i><p>* QA <i>is more important than</i><p>* Monitoring <i>is more important than</i><p>* Bug reports<p>[1] <a href="http://en.wikipedia.org/wiki/Tower_defense" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Tower_defense</a><p>[2] <a href="https://www.linkedin.com/in/rinoj" rel="nofollow">https:&#x2F;&#x2F;www.linkedin.com&#x2F;in&#x2F;rinoj</a>
评论 #7600045 未加载
评论 #7599859 未加载
评论 #7600032 未加载
评论 #7599785 未加载
loumf大约 11 年前
He&#x27;s right, but he&#x27;s disingenuous in saying that random line duplication can&#x27;t cause catastrophic problems in Eiffel. This very specific bug can&#x27;t happen in Eiffel, but the class of bug can (bug caused by bad merge or accidental, unnoticed line duplication).<p>If most code were idempotent, functional, immutable, etc -- then we&#x27;d start to get there, but usually randomly duplicating lines is going to be an issue unless it&#x27;s always a syntax error.<p>I&#x27;d say clojure has more of a chance. (1) lots of immutable data and functional style (2) duplicating code lines is likely to result in unbalanced parens -- the unit of atomicity is the form, not a line. Many forms span lines in real code, and many lines contain partial forms (because of nesting).<p>Still there is plenty of clojure code that is line oriented (e.g. data declarations)
评论 #7599234 未加载
评论 #7599040 未加载
ChuckMcM大约 11 年前
That was a long way to go to insult C and brag about Eiffel. Ada doesn&#x27;t have this problem either but nobody is jumping up and down saying how its the one true language. Back when I was looking at Phd topics (I ended up jumping into work instead) &quot;provably correct&quot; code was all the rage. Lots of folks at USC-ISI were looking into proving the code expressed the specification, and the resulting executable faithfully expressed the intent of the code. End to end correctness as it were.<p>What struck me about that work was that invariably there was some tool you ran over the specification and the code and it implemented some algorithm for doing the work. And yet if you went that far, then you should at least be willing to run something like lint(1) and had anyone at Apple run it, or made warnings fatal (always good practice), the repeated goto would never have escaped into the wild (useless code is useless, its a warn in both GCC and Clang, and always flagged by lint).<p>So is the challenge the language? Or the processes? I tend to favor the latter.
评论 #7600511 未加载
评论 #7599832 未加载
评论 #7600617 未加载
评论 #7600334 未加载
评论 #7600776 未加载
freyrs3大约 11 年前
Whenever &quot;language doesn&#x27;t matter&quot; or &quot;use the right tool for the job&quot; is used in an argument it&#x27;s quite often as a thought-terminating cliche used as a post-hoc justification for personal prejudices. I think almost everyone intuits that there is at least a partial ordering to language quality and safety, we just often disagree about how that ordering is defined.
评论 #7599129 未加载
habosa大约 11 年前
PSA: Always put brackets after your conditionals (for languages where you can). You never know when a one-line conditional will become a ten-line, and you can get this sort of bug. It&#x27;s not worth the two saved keystrokes now to have the NSA in your data later.<p>I think the most readable code has no shortcuts and no tricks. I&#x27;ll take unambiguous over concise or &#x27;beautiful&#x27; any day.
评论 #7599442 未加载
评论 #7599602 未加载
评论 #7599587 未加载
评论 #7601004 未加载
评论 #7599566 未加载
评论 #7599406 未加载
pjungwir大约 11 年前
Paleographers have a whole catalog of scribal errors, which can be useful when trying to reconstruct a text from conflicting extant copies. Perhaps it would be helpful to compile such a list of common programming errors, and consider that list when designing a new language. It would include &quot;scribal&quot; errors like Apple&#x27;s goto or = vs ==, and also low-level logical errors. It seems like this could make a fun paper for any CS grad students out there.
评论 #7599523 未加载
评论 #7599550 未加载
AnimalMuppet大约 11 年前
&quot;My pet language renders that problem impossible.&quot;<p>Um... OK.<p>&quot;Therefore you should use my pet language rather than one written in 1968 for a PDP-11.&quot;<p>Not so fast.<p>First, when the language was written has nothing whatsoever to do with how useful it is today. (Cue the Lisp advocates.) It&#x27;s just a gratuitous slam, and it comes off as being petty.<p>Second, even if Eiffel does completely prevent this class of problem, what about the reverse situation? What classes of problems does Eiffel allow that other languages prevent? (Don&#x27;t bother claiming &quot;None&quot;. That&#x27;s not realistic. It just means that either you don&#x27;t see the flaws, or you&#x27;re a propagandist.)<p>It&#x27;s about the best tool for the job. Now, it&#x27;s fine to argue that another tool would have been better for that particular job, but &quot;avoiding one particular class of bug&quot; is nowhere near good enough.<p>One point for the original article, though: Code does matter. Choice of programming language matters. Code reviews matter. Testing matters. Code review policies matter. Develop training matters. Developer culture matters. It all matters.
guelo大约 11 年前
Since he lumps in Java with C and C++ it&#x27;s worth pointing out that this specific bug is not possible in Java since unreachable code is a compiler error. I assume the same for C#.<p>Also, many style guides such as Josh Bloch&#x27;s highly influential &#x27;Effective Java&#x27; recommend against the 2-line if statement without curly braces since it&#x27;s known to be prone to this type of error. His argument that keywords are better than braces for ending blocks is weak.
评论 #7599122 未加载
评论 #7599798 未加载
评论 #7600006 未加载
评论 #7599127 未加载
rguldener大约 11 年前
Well the ironic part is that the official eiffel compiler compiles the eiffel code down to C, which is then compiled again into assembly. So technically speaking eiffel still relies on C... Note that its not very optimized C either, its much slower than Java for most of the stuff I tried (with contracts disabled).<p>Said compiler also happens to be terribly buggy and unreliable: The author still teaches the CS &quot;Introduction to programming&quot; class at my university with this language and every year students struggle with the language and the obscure IDE. Also don&#x27;t know anybody that ever wrote a line of Eiffel again after that class even though the idea with contracts is kind of interesting.<p>Summa summarum: Best language constructs don&#x27;t help if your basic tools are broken and make it a pain to write in that language.
byuu大约 11 年前
I really don&#x27;t see how enforcing {} syntax on all conditionals is going to make us so much safer.<p>Yes, people make mistakes, but this is a pretty huge screw-up. If you are modifying an unbraced if-statement and aren&#x27;t paying attention to scoping, then you are being woefully negligent at your job. Especially when you are working on cryptographic code used by millions of people to protect their most valuable information.<p>So let&#x27;s say we force more red tape to make sure this doesn&#x27;t happen. Those of us who pay attention to scoping probably won&#x27;t mind too much, it&#x27;s good practice to do this anyway.<p>But what about the mediocre programmer? He may decide that now his if&#x2F;else if&#x2F;else three-liner, when adding new lines for {}, should really just turn into a switch&#x2F;case. And now he neglects a fall-through case, or adds an unconditional break; before important code. And we&#x27;re right back where we started.<p>It doesn&#x27;t matter how much we safeguard and dumb down languages. We can load our languages full of red-tape: extra braces, no jumping or breaking, no fall-throughs, always requiring explicit conversions, no pointers, no null types ... all we&#x27;ll end up with is code that is much harder to read (and possibly write), while the mediocre programmers will find new and inventive ways to screw things up. It&#x27;s just as likely to make them even more lax, and attract even less disciplined programmers into important development roles. You know, since it&#x27;s presumed to be so much safer now.<p>The real problem is the amount of poor programmers out there, and the lack of repercussions for these sorts of things. A doctor that leaves a scalpel in a patient is (rightly) ruined for negligence. Do you think the &quot;goto fail;&quot; writer even received a written warning? Why not?<p>I&#x27;m not saying people can&#x27;t make mistakes, but I think your pay scale and the importance of what you do should come with some actual responsibility for your errors. Just like in every other profession out there.<p>Yes, sometimes you can blame the tool. But there are also times when you need to blame the user.
评论 #7599834 未加载
评论 #7600480 未加载
评论 #7599822 未加载
评论 #7599884 未加载
评论 #7599828 未加载
评论 #7599675 未加载
评论 #7599598 未加载
评论 #7599590 未加载
评论 #7600001 未加载
评论 #7599790 未加载
评论 #7601775 未加载
评论 #7600373 未加载
评论 #7599696 未加载
haberman大约 11 年前
&quot;When people tell you that code does not matter or that language does not matter, just understand the comment for what it really means, &quot;I am ashamed of the programming language and techniques I use but do not want to admit it so I prefer to blame problems on the rest of the world&quot;, and make the correct deduction: use a good programming language.&quot;<p>As emotionally satisfying as it can be to stick it to people we disagree with, I think we as an industry could do with a lot less of this black and white thinking.<p>Programming languages do not fall into a neat good&#x2F;bad dichotomy. Tell me your favorite programming language and I will tell you three things that absolutely suck about it (even if I like it overall).<p>Yes, if C could do it all over again it would probably mandate that brace-less blocks go on the same line as the &quot;if&quot; (or are disallowed completely). So I agree with the author that certain features of programming languages can make it more or less error-prone.<p>But people still use C for a reason. That reason is that C has real advantages. If you really want to improve software engineering, then help the Rust guys out, but don&#x27;t just tell C users to &quot;use a good programming language.&quot;
darrencauthon大约 11 年前
His code example is:<p>if (error_of_fifth_kind)<p><pre><code> goto fail; goto fail; </code></pre> if (error_of_sixth_kind)<p><pre><code> goto fail; </code></pre> The_truly_important_code_handling_non_erroneous_case<p>My question: If the &quot;truly important code&quot; is really that important, where are the unit tests to verify that it &quot;handles&quot; the &quot;non erroneous case????&quot;<p>Test. Your. Code.
评论 #7600065 未加载
评论 #7599013 未加载
评论 #7599170 未加载
john_b大约 11 年前
To address only the &quot;goto fail&quot; example the author uses, I don&#x27;t see how the proposed Eiffel solutions are conceptually any different than always using brackets in your C&#x2F;C++ constructs. Brackets are the mathematical notation for a set, and having a set of instructions inside them makes perfect sense even if the set only has a single element.<p>Since<p><pre><code> if(condition){ instruction; } </code></pre> instead of<p><pre><code> if(condition) instruction; </code></pre> is already considered good practice, couldn&#x27;t it also be enforced via compiler pragma?
评论 #7599569 未加载
评论 #7599213 未加载
评论 #7599243 未加载
评论 #7601053 未加载
ryanobjc大约 11 年前
It&#x27;s about both!<p>From a programmer point of view, the ideal is a language that doesn&#x27;t let you make simple mistakes like the goto fail; bug.<p>From an engineering point of view, it&#x27;s having the processes in place to make sure that when such bugs inevitably happen, they don&#x27;t end up in the final product.<p>The reality is having both of these things would be ideal.
评论 #7599120 未加载
评论 #7599580 未加载
jw2013大约 11 年前
But the problem the author described in the article can be solved just by better programming habit- always add braces even for a one line condition statement.<p>Or just put the one line statement in the same line with the conditional statement such as: if(condition) statement; so when you try to add a line next time, you will notice it was a one line if statement.<p>But yeah, not explicitly requiring braces for one line condition statement can give us more succinct code but does requires better programming pratice.
评论 #7599248 未加载
评论 #7599004 未加载
评论 #7599483 未加载
nshepperd大约 11 年前
The &quot;improving our tools is no silver bullet, so let&#x27;s keep using what we already have&quot; thinking that this guy is criticizing is an excellent example of the fallacy of gray (<a href="http://lesswrong.com/lw/mm/the_fallacy_of_gray/" rel="nofollow">http:&#x2F;&#x2F;lesswrong.com&#x2F;lw&#x2F;mm&#x2F;the_fallacy_of_gray&#x2F;</a>). Of course, using Haskell doesn&#x27;t prevent all bugs, and PHP doesn&#x27;t <i>always</i> cause disasters. But it&#x27;s easy to see which of these is the darker shade of gray. And there <i>is</i> a point where switching to safer (but not perfectly safe) tools is the right thing to do.
acbart大约 11 年前
A lot of the Computational Thinking movements seem to stress that &quot;Computer Science is more than just computers!&quot; And that&#x27;s true, we have a lot more to offer! But at the same time, it&#x27;s so misleading because so much of our really cool stuff is wrapped up in being able to program. I mean, CS is about solving problems at scale, and computers are how we best solve problems at scale. We can teach lots of carefully crafted things without them, but it&#x27;s always going to ring a little false, and we won&#x27;t get students more than an inch-deep into why we&#x27;re truly cool.
pron大约 11 年前
<i>Of course</i> the programming language matters. The problem is, that there are many ways in which it matters, and some of those come at the expense of others.<p>A language may be more concise, leading to shorter code (which is good), but do so using tricks and &quot;magic&quot; that is hard to follow, which makes it, eventually less prone to analysis by others (which is bad). A language could be very declarative, thus clearly communicating intent (which is good), but do so with leaky abstractions that remove it away from the computer&#x27;s view of things, and introduce subtle, and severe bugs that, in order to catch, require expertise in exactly <i>how</i> the language is implemented (which is bad).<p>So while there are certainly languages which are categorically better than others (at least for some domains), there is no consensus on the right path to choose among the &quot;better languages&quot;, and they all take completely opposing approaches. I&#x27;d even say that most languages used in new code written today are among those &quot;better languages&quot;. So while in theory the choice of the programming language matters a lot, in practice -- not so much (as long as you choose one of the many good languages). I don&#x27;t think that we have a language (or several) that is <i>that much</i> better at preventing bugs as to offset any other advantages other languages may have.
PavlovsCat大约 11 年前
&gt; &quot;If you want the branch to consist of an atomic instruction, you write that instruction by itself&quot;<p>No, I don&#x27;t, I generally use curly braces for those too. So for me, the solution would be throwing an compile error when those are missing. Is that really all it takes to make a language &quot;modern&quot;?<p>I also don&#x27;t understand the jab at semicolons, which I like, nor do I see how getting rid of brackets around the condition is really a net saving when you have to write &quot;then&quot; or &quot;loop&quot; instead. Apart from being twice as many characters to type, words distract me (much) more than symbols, and now that I think of it, I wonder how programming would be like with symbols for reserved keywords like &quot;if&quot; and &quot;function&quot;, so the only text you see anywhere in your code would be quoted strings or variable&#x2F;function&#x2F;class names...<p>Anyway, I think when talking about distractions, one should be careful with claiming to speak for everybody (at least unless you did a whole lot of studying test subjects or something).
评论 #7599300 未加载
wellpast大约 11 年前
This is terribly wrong.<p>Correctness is brought about by ALL of your tools in hand. These tools include unit testing, processes like continuous integration and code review, and so on, <i>in addition</i> to language features such as its syntax and static analysis capabilities.<p>The job of the programmer is to understand all of your tools and to then use them conscientiously and use them well. There is NO tool a programmer can&#x27;t shoot themselves with. There&#x27;s no prima facie perfect tool. And the combination of your tools is a better thing to evaluate anyway. A nail isn&#x27;t universally useful. With a Phillip&#x27;s head screwdriver things get a little better; but with a hammer, you&#x27;ll start moving.<p>A good architecture and intelligent, disciplined execution is WAY WAY WAY more important than the specific tools we use. Arguments like this one are bike shedding.
评论 #7599544 未加载
aetherson大约 11 年前
It&#x27;s clearly true that having a language which forced an explicit ending to an if block would have prevented the goto fail bug.<p>But is there any actual evidence that code written in modern languages have fewer bugs overall? Or is it all, &quot;let&#x27;s focus on this one example&quot;?<p>As another commenter mentioned, the goto fail bug would have been utterly trivially caught by any unit test that even just tested that it reached the non-error case in any way (you don&#x27;t even need to test the correctness of the non-error code).<p>I would like to see data before I believe that &quot;errors that would have been prevented by non-C semantics&quot; constitutes a significant fraction of all bugs, or that they aren&#x27;t just replaced by bugs unique to the semantics of whatever replacement language you&#x27;re using.
评论 #7599195 未加载
TheLoneWolfling大约 11 年前
How about forbidding newlines in a single-statement if and requiring a newline after the first statement after the if?<p>So this is allowed:<p><pre><code> if (foo) bar(); baz() </code></pre> But this isn&#x27;t:<p><pre><code> if (foo) bar(); baz() </code></pre> And this isn&#x27;t:<p><pre><code> if (foo) bar(); baz() </code></pre> Edit: formatting
评论 #7599221 未加载
评论 #7599209 未加载
评论 #7599219 未加载
AdrianRossouw大约 11 年前
Code doesn&#x27;t matter, what matters is what it does.<p>How usable, secure, stable or fast it is are properties of how well it accomplishes it&#x27;s task.<p>There&#x27;s an amazing presentation by the author of Clojure called Simple Made Easy. Since I couldn&#x27;t just link people to a 1 hour presentation, I made some notes on it :<p><a href="http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-describe-software-complexity" rel="nofollow">http:&#x2F;&#x2F;daemon.co.za&#x2F;2014&#x2F;03&#x2F;simple-and-easy-vocabulary-to-de...</a><p>The code that we write he calls a construct, and our application is what he calls the artifact.<p>We need to evaluate constructs based on the complexity they create in the artifacts.<p>Using C, for instance, affects the complexity of our applications by introducing many more opportunities for human error.
dasil003大约 11 年前
I absolutely believe that languages matter and are the best hope for improving code quality and productivity overall. We need better languages.<p>But the way we get there is not to pick some small but critical bug that could be avoided by an arbitrary style change and declare that a language which does not suffer that stylistic pitfall is superior. The new language may have much worse flaws. You&#x27;re just playing language flaw whack-a-mole at that point.<p>If we want to improve we have to get a sense of what types of bugs are most common across all programs and reason from a logical standpoint about how they may be prevented. This will solve orders of magnitude more problems than fiddling around with the syntax to minimize the number of typos people make.
wpaprocki大约 11 年前
There are other reasons why choice of language matters. If you need a simple web app, you&#x27;re probably writing it in PHP or Ruby instead of C. But you&#x27;ll likely use C if you&#x27;re interfacing with hardware. A lot of apps that need high concurrency use Erlang. If you can write a quick Python script that solves a problem before you can even get Eclipse to load, then why would you even bother trying to write the solution in Java?<p>Language errors aside, it&#x27;s pretty obvious that at least in some cases, the choice of programming language does matter.
MortenK大约 11 年前
Some types of errors might be easier to make in one language versus another, but a language that through syntax eliminate the possibility of all errors, is of course a ridiculous notion. Cherry picking particular error types that are avoidable in the authors language of choice, does not prove anything.<p>The concept of why code does not matter, comes from development management literature. It&#x27;s not a case of actually meaning &quot;I&#x27;m ashamed of the language and the techniques I use&quot;. That&#x27;s an awfully developer-centered point of view.<p>The influential factors of a successful software project are mainly the quality of the people involved. Next product scope and from there a huge drop down to development process, and finally technology, i.e language.<p>It&#x27;s been statistically shown that barring a crazily bad technology choice (Visual Basic for the space shuttle kind of bad), language has very little influence on the success of a project.<p>That&#x27;s of course not a nice thing to hear for a developer who&#x27;s convinced his language of choice is the one true language. Regardless, it&#x27;s well established knowledge, gained years and years ago through statistical analysis of thousands of projects.
miscreant大约 11 年前
On the surface, this reasoning makes sense. Unfortunately, human coders are the ones writing code. This means the code might have bugs in it, regardless of the language you choose. While it would be great to invent a new language n+1 whenever the blame for bad code can be directed at programming language n, it is not likely that you will find coders that are willing to repeatedly take that ride.
ebbv大约 11 年前
Just use curly braces all the time. There&#x27;s nothing in C or C++ stopping you from using curly braces around single line statements. It&#x27;s just that you CAN omit them.<p>But having been bitten by this issue early on, I started always using curly braces. I think it&#x27;s the better way to write C&#x2F;C++. Frankly I think those who omit them are just lazy.
scotty79大约 11 年前
Another thing that enabled this bug is that it was a language that allows misleading indentation.<p>Programmers indent all code. By making indentation to be not meanigful in your language you are ignoring large part of how programmers read and write code and allow for many misunderstandings between programmer and compiler.
评论 #7599003 未加载
评论 #7599151 未加载
maninalift大约 11 年前
Surely the key point is that most of us read indentation first, it doesn&#x27;t matter whether you are witting C with semicolons and curlies or ruby with no semicolons and &quot;end&quot;s or lisp with parens, what the programmer really reads first is the indentation. Those other things are sometimes checked afterwards.<p>Therefore there are two reasonable courses of action to prevent this kind of problem:<p><pre><code> * use automatic code indentation * use a whitespace significant language </code></pre> The second is absolutely the better choice. You may disagree but you are wrong. This is not a matter of taste, it is a matter of programming language syntax actually reflecting what the programmer reads.
评论 #7599440 未加载
bowlofpetunias大约 11 年前
As far as I can tell (and I may not be the best judge of that, because I&#x27;ve used a dozen languages over the past 25 years and still fail to see any really significant difference other than language philosophy as in OO, functional, etc), this is not about language quality but language <i>safety</i>.<p>Those two are not necessarily the same, and some of the most elegant languages aren&#x27;t particularly safe. Conversely, unlike people like to claim based on hearsay and no longer existing features, a badly designed language like PHP is definitely not less safe than Python or Ruby.<p>By the standard for &quot;good&quot; set by the author, no dynamically typed language would make the cut.
abshack大约 11 年前
<p><pre><code> if( DoSomething() ) goto fail; else if(DoSomethingElse()) goto fail; goto fail; else if(DoSomethingOtherThanElse()) goto fail; </code></pre> You get a syntax error at the final else-if. A better way would probably be:<p><pre><code> int err = 0; if(!err) err = DoSomething(); if(!err) err = DoSomethingElse(); if(!err) err = DoSomethingOtherThanElse(); if(err) goto fail; </code></pre> I would prefer chainable commands that abstracts out the error checking though.<p><pre><code> err = Chain(DoSomething).Then(DoSomethingElse).Then(DoSomethingOtherThanElse);</code></pre>
hyperion2010大约 11 年前
My take home is this. If we are going to do everything in our power to make these systems work better, then choosing or developing a language that is intentionally designed to draw attention to common security mistakes or prevent them structurally is a damned good thing to look in to. We will also do everything else in our power, but we had bettered put choosing or making that language on the list.
Guvante大约 11 年前
Alternatively use a whitespace sensitive language. Defining how to handle tab vs space is irritating, but there are plenty of solutions to that.
ww520大约 11 年前
But Eiffel can&#x27;t prevent the bug of swapping the order of two statements accidentally; it must be a bad language!<p>Come on. Cherry picking a weak feature of a language to invalidate the whole language is just disingenuous. All languages have strength and weakness. One has to weigh the positives and the negatives and decide whether it would work.
anigbrowl大约 11 年前
I found the article interesting, but I wonder why he didn&#x27;t also discuss using &#x27;switch&#x2F;case&#x27; which would surely have been more appropriate than a succession of IF statements.<p>Of course you can screw things up with switch&#x2F;case too, but in my limited experience that usually involves a design flaw rather than just a typo.
joesmo大约 11 年前
The article&#x27;s suggestion is: &quot;make the correct deduction: use a good programming language.&quot;<p>It would be enlightening to hear what Mr. Meyer or anyone else thinks would fit that bill on the Apple&#x27;s platforms. Until the article actually provides a real solution, the article isn&#x27;t making a point at all.
peterashford大约 11 年前
Calling out Java for this issue is BS. Java doesn&#x27;t allow unreachable code. If Java had a &#x27;goto&#x27; instruction, that code wouldn&#x27;t compile because the latter code was unreachable.<p>The article is poorly researched rahrah for Eiffel. Eiffel is a good language, but not for the reasons the author states.
ef47d35620c1大约 11 年前
What language is he implying to be &quot;good&quot;?<p>It&#x27;s obvious that he thinks C, C++, C# and Java are bad (due to syntax). The world mostly runs on those, so I guess we&#x27;re all doomed. But if they are so &quot;bad&quot;, then what does he consider &quot;good&quot;? I read it, but must have missed that part.
评论 #7599934 未加载
jheriko大约 11 年前
Yet nobody is making a better c and we are stuck with performance vs safety.<p>Hit the nail on the head about if although I disagree about the fancy syntax examples - enforcing scopes is enough - every decent coding standard I&#x27;ve worked with forbids one line ifs... as does common sense acquired 15 years ago...
al2o3cr大约 11 年前
I think you wind up with problems no matter what the tooling - for instance, a language that required that every line be provably terminating would never suffer from infinite loops, but whether the <i>project</i> using said language would ever halt remains to be proven. :)
gweinberg大约 11 年前
BTW, am I the only one who thinks that duplicating a line of code is 1) not all that common in the first place and 2) something that should FUCKING JUMP OUT AT YOU IN CODE INSPECTION LIKE A BLOCK OF ALL CAPS FUCKING FILLED WITH PROFANITY?<p>srsly, this was not a subtle hard-to-find error.
hyp0大约 11 年前
That font - tiny and grey - was by far the hardest to read on Android (increasing the minimum font size to 20 pt fixed it).<p>It&#x27;s considered good practice to brace if&#x2F;loop clauses (unless on the same line) for this very reason. Not enforced, though I expect lint picks it up.
boomlinde大约 11 年前
&gt; Often, you will be told that programming languages do not matter much. What actually matters more is not clear; maybe tools, maybe methodology, maybe process.<p>In this case it could easily have been caught if they had full test coverage, whatever language was used, so yes.
jds375大约 11 年前
About the single and multiple expression if-statements, I couldn&#x27;t agree more. Everyone says I&#x27;m an idiot always assuming multiple expressions (it is ugly), but in the end it is safer.
pjmlp大约 11 年前
I wonder if Eiffel could have gotten a more widespread use, if Bertrand Meyer had gotten a major OS vendor behind it, instead of trying to cater for the enterprise.
评论 #7599207 未加载
sfk大约 11 年前
Is it possible to prevent timing attacks, control secure wiping of memory etc. in Eiffel?
评论 #7598974 未加载
brianbarker大约 11 年前
I agree that distinguishing between compound and non-compound statements is terrible. However, so is using whitespace-delimited blocks (sorry, Python). I wish he&#x27;d proposed the simple solution Go uses: require braces.
评论 #7605834 未加载
autokad大约 11 年前
i thought it was bad programming to not insert the {} even if the statement only had one line of code. is this not true?
Dewie大约 11 年前
With all the pitfalls of C, the unbraced ifs feels like a very impotent example. Are pretty printers never used? Maybe a good linter would be able to warn about this, too.
justizin大约 11 年前
blah blah blah acm blah
评论 #7599652 未加载
usumoio大约 11 年前
I think this guy might be confusing code with style. This is why I never ever let the interns not use braces. We built a style guide that is good at blocking these types of errors. Not to mention that Apple should have tested enough to catch that error... It is about the code, but maybe not in the way this guy thinks.
评论 #7599033 未加载
评论 #7599015 未加载
评论 #7599043 未加载