Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Friday May 08 2015, @09:01PM   Printer-friendly
from the off-with-its-head dept.

Ladies and gentlemen, the C programming language. It’s a classic. It is blindingly, quicksilver fast, because it’s about as close to the bone of the machine as you can get. It is time-tested and ubiquitous. And it is terrifyingly dangerous.

The author's biggest issue with the C language seems to be security holes:

If you write code in C, you have to be careful not to introduce subtle bugs that can turn into massive security holes — and as anyone who ever wrote software knows, you cannot be perfectly careful all of the time.

The author claims that the Rust language is a modern answer to these issues and should replace C (and C++). It does look that Rust can run C code, so it looks like an interesting proposition. What do Soylent's coders think about this?

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by CirclesInSand on Saturday May 09 2015, @11:09AM

    by CirclesInSand (2899) on Saturday May 09 2015, @11:09AM (#180712)

    Here’s a C program which will simply double all the input it’s given:

    int double_input(int input) {
                    return input * 2;
    }

    No it isn't. That's the problem with C and almost every other language. It is a function that returns twice of any integer that is between some minimum and some maximum, and it won't give you an error if you screw it up and give bad inputs. That causes things to crash.

    Any language that confuses the concept of "integer" and "word" is on my bad side. Any language that confuses "float" and "real" is on my bad side. Any language the confuses "array" and "vector" is on my bad side. Any language that confuses "byte" , "bytes", and "character/glyph" is on my bad side. Any language that confuses "procedure" and "function" is on my bad side. Any language that confuses "assignment" and "definition" is on my bad side. I could go on for days.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 0) by Anonymous Coward on Saturday May 09 2015, @12:30PM

    by Anonymous Coward on Saturday May 09 2015, @12:30PM (#180733)

    So anyone that uses terminology in a way that you don't like, even if it is perfectly valid for that language, is on your bad side?

    • (Score: 0) by Anonymous Coward on Saturday May 09 2015, @01:26PM

      by Anonymous Coward on Saturday May 09 2015, @01:26PM (#180744)

      This has nothing to do with personal preference. It's not about "likes".

      When it comes to technical matters, including programming languages and related concepts, words have very, very specific meanings. Misuse of such terminology will cause technical problems.

      If you misuse the terminology, confusion will arise. Confusion in programming language design leads to language flaws and bugs.

      Rust uses established, well-defined terminology incorrectly. That's one of the reasons why people don't like Rust. "fn" should be "function". "mod" should be "module". When they use gibberish abbreviations, people will get the wrong impression. "mod", for example, is ambiguous with the "modulus" operation.

  • (Score: 2) by Common Joe on Tuesday May 12 2015, @02:29AM

    by Common Joe (33) <{common.joe.0101} {at} {gmail.com}> on Tuesday May 12 2015, @02:29AM (#181759) Journal

    Any language that confuses "procedure" and "function" is on my bad side.

    You just hit upon something near and dear to me. I find no difference between real world procedures, functions, methods, and subroutines. Granted, I don't really use functional languages (which is a different beast), but the procedural and OOP languages make these all the same. It is the implementation by the programmer which makes them different. And although nice in theory, I have found it impractical to draw a hard line between functions (return single value, no side effects) and procedures (no return value, side effects). I find the TryParse [microsoft.com] in C# to be a good example.

    As for functional languages, I find them lacking, overly wordy, and a bit unwieldy for projects that don't deal with finances. Side effects can be a good thing.

    What languages aren't on your bad side?

    • (Score: 2) by CirclesInSand on Tuesday May 12 2015, @08:35AM

      by CirclesInSand (2899) on Tuesday May 12 2015, @08:35AM (#181862)

      You just hit upon something near and dear to me. I find no difference between real world procedures, functions, methods, and subroutines.

      Well we're in good company then, if we both appreciate these things. A few things:

      A function need not be computable. If you are reasoning about programs, then distinguishing between computable and general functions is essential.

      Functions (both kinds) are easier to reason about than procedures in most cases.

      Procedures don't necessarily have side effects. That is more of a global/local declaration issue.

      Conceptually they are very different as well. Procedures are for doing things. Functions are for saying things.

      What languages aren't on your bad side?

      I may mess around a bit, but I'm still holding out for true love.