5 ms·
When people criticize C as a language they are usually referring to the fact that it easily and frequently allows for many classes of bugs that riddle C code. F
by flipgimble 8y ago
When people criticize C as a language they are usually referring to the fact that it easily and frequently allows for many classes of bugs that riddle C code. For decades, as an industry we've been apologizing and fixing critical exploits and bugs (ex HeartBleed), that can be traced to the fact that C allows for mistakes. If a bug is allowed, someone will perpetrate it sooner or later. Sacrificing correctness and safety for the speed and complicity of C is not a valid tradeoff for the industry in my opinion.
A major feature of Swift is that it forces you to deal with error conditions and missing values. In practice you do the right thing once and early in your code, and you can write the majority of your code with guarantees that prevent major classes of bugs. Swift is not perfect, still changing, and many complain about being forced to write safe code, but it is absolutely the right move of Apple to make for their platform.
- jmpt 8y agoIf Swift lets you override dealing with errors (think force unwrapping) then such security is pointless because "someone will perpetrate it sooner or later." In practice, what we get is an overly pedantic language that gets in the way of the developer.
- zoul 8y agoThere is a world of difference between letting bugs easily happen a letting the programmer override error handling.
- flipgimble 8y agoThe critical difference is that in swift your have to override safe behavior by using special syntax. This means you can search for it to fix it, you can have compiler/linters enforce certain rules, you can catch it easily in code reviews. No professional team I've worked on would allow forced unwrapped code except in special well documented cases. The default code you write in swift is safe. You spend less time worrying about its correctness, which means you can focus on solving higher level problem and less time debugging. When people call swift pedantic, for example, and I take time to ask for the specifics, I mostly get "not familiar to me", or "I'm used to shooting myself in the foot and unwilling to consider alternatives". So my patience has run out.
- fauigerzigerk 8y agoIf only there was a way to catch array index out of bounds.
- scarface74 8y agoI don’t know Swift, so I don’t know what you’re implying, but I only know of three ways to deal with an array out of bounds runtime issue.... 1. Don’t check for it at runtime and the runtime writes to memory that it shouldn’t like C. 2. Throw an exception and prevent memory corruption. 3. Don’t ever work with indexes and just use iterators. Is there a fourth way that it can be handled in other languages?
- saagarjha 8y agoYou could have the subscripting method check at runtime and return an Optional.
- zoul 8y agoextension Collection { subscript (safe index: Index) -> Element? { return indices.contains(index) ? self[index] : nil } } And now you have the choice: array[i] // traps for invalid indices array[safe: i] // returns nil for invalid indices
- valuearb 8y agoLol, I put that code in my last project, a 150,000 line codebase built by lazy contractors, as just one of the tools to clean up the errors from their objective c like approach to software quality.
- blub 8y agoInterestingly put, "the Objective-C approach to software quality". There's something in the psychology of a large number of C, Objective-C and C++ programmers that makes them overappreciate execution speed and underappreciate memory safety in particular, but also validation and correctness in general. One of my goals now is to outline safe ways of using C++ for various projects and I'm not too optimistic. In fact I'm unsure what we'll end up with.
- pjmlp 8y agoNot at all. There is a world between every single string, array and numeric operation being a possible source of memory corruption and being forced to explicitly write unsafe code. I have been using mostly safe languages since the 80's. They only get in the way of cowboy programming, which is a very good thing for anyone that praises quality in software development. C would no longer be around if companies got properly sued for each CVE exploit.
- hedora 8y agoPeople have written and continue to write secure C code, and insecure code in “safe” languages. I have written systems in memory safe languages. The languages that provide memory safety also incur GC pauses, which means they’re unsuitable for applications where latency matters at all. (I’ve also noticed that programs written by professionals in memory safe languages tend to have many more serious high-level bugs than those written in C/C++, but I don’t have data to back that up.)
- pjmlp 8y agoYeah, but I do have data to back up the fallacy of the perfect C programmer that writes secure C code. https://www.cvedetails.com/vulnerability-list/opmemc-1/memory-corruption.html https://www.cvedetails.com/vulnerability-list/opmemc-1/memor... Apparently reviewing code before merging into mainline isn't of much help, but lets keep this myth of secure C code alive. Σ (Logic errors in safe language) < Σ(Logic errors in C + Memory Corruption in C)
- icebraining 8y ago> The languages that provide memory safety also incur GC pauses This is incorrect, you can have memory safety without a gc. An example is Ada, and more recently Rust.
- com2kid 8y agoIIRC memory safe Ada doesn't allow for deallocation. Kinda sorta cheating. ;)
- Razengan 8y agoUp till Swift 2 that was mostly the case – getting "in the way" – but as it is now I'd say Swift forces you to think about being a better developer, while still letting you be a bad one if you really insist on it. After working exclusively in it for a while now I can't help but cringe at the practices which I see encouraged in most other languages.
- saagarjha 8y agoThis isn’t what Swift means when it says it’s safe. “Safe” doesn’t mean your program doesn’t have bugs or can’t crasg; rather, it will never have to deal with things like memory corruption and related undefined behavior. In fact, Swift considers crashing rather than allowing such errors to propagate to be an explicit design goal.
- slavapestov 8y agoRight; this is why integer operations trap on overflow by default, instead of silently wrapping, for example. Technically you’ll “crash” more but the crash occurs at the exact location of the problem and not much later in the form of corrupted data.
- valuearb 8y agoIt’s the difference between a crash pointing exactly at the cause, and spending days or weeks isolating crashes that only occur minutes after the error that caused them, or only on certain devices, or in certain memory configurations, or only on every other Sunday, etc.
- deleted 8y ago[deleted]
- kartan 8y ago> If a bug is allowed, someone will perpetrate it sooner or later. Sacrificing correctness and safety for the speed and complicity of C is not a valid tradeoff for the industry in my opinion. It depends on what you are building. For an app it is not a big deal to be slower. But you will not write a kernel in Swift as you will lose performance all over the place. Python/Javascript/Lua are used as scripting languages to create video games. But the 3D engines are written in C or C++. Each tool has its use.
- pjmlp 8y ago> But you will not write a kernel in Swift as you will lose performance all over the place. That used to be the argument against C and C++ in the 80 and 90's regarding 16 bit home computers. Any serious developer would know that Assembly was the only proper way to write software that required real performance. Yet a couple of decades later. > But the 3D engines are written in C or C++.