Hacker News Reader

Comment by pavlov | Hacker News Reader

Chris Lattner writes:

”One of the best and most annoying things about Objective-C is that it has C in it. This has been hugely important for Objective-C in practice, because if you run into a performance problem with objc_msgSend, you can always rewrite that algorithm in C. That’s really, really, really important for Objective-C being successful in both in the days of NeXT on 16 MHz processors and also today for the low-level code that people are writing.”

This is indeed a great thing about Objective-C: it’s an improved C with a tight set of runtime features that help build interactive applications.

There’s a need for such a language, and I’m sad that so much of the rhetoric from Apple and the Swift community is working on the assumption that Obj-C should be completely replaced by Swift.

Swift is not a compact language like Objective-C. It’s more like C++ in how it tries to incorporate every programming paradigm that can possibly fit. The heavy focus on complex upfront typing is not necessarily the best choice for iterative app development.

Swift is useful in many places, but personally I found Objective-C’s “Smalltalk-flavored C” to hit a sweet spot for my GUI needs where integrating with C and C++ libraries is usually required all over the place.

View on HN

Yeah, but you forgot to copy the other relevant part.

> The fundamental problem was Objective-C was built on top of C. C inherently has pointers. It has uninitialized variables. It has array overflows. It has all these problems that even if you have full control of your compiler and tool stack, you just can’t fix. To fix dangling pointers, you would have to fix lifetime issues, and C doesn’t have a framework to reason about that, and retrofitting that into a compatible way into the system just wouldn’t really work.

If you took away C from Objective-C, you couldn’t use C arrays on the stack, for example. And if you couldn’t do that, there’s entire classes of applications where the performance just wouldn’t be acceptable. We went around, around, around. We said the only way that this can make sense in terms of the cost of the disruption to the community is if we make it a safe programming language: not “safe” as in “you can have no bugs,” but “safe” in terms of memory safety while also providing high performance and moving the programming model forward.

That’s a good reason to create a new language. But all the C code in the world isn’t suddenly going to go away, and so the need for an improved C still remains.

Language design graveyard is full of improved C attempts, because the problem is not technical, rather it can only be properly solved through change of generations.

Microsoft, Apple, Google have the luxury to impose moving away from C on their platforms.

On other platforms you have developers that won't touch any kind of Safe C even at gun point.

That’s why LLVM is such a great idea - any llvm language can interoperate with any other, within the same binary, with no overhead. Apple isn’t throwing away their C code any time soon either. LLVM provides a smooth upgrade path via mixed language binaries.

I suspect that the move to swift would never have happened without LLVM. And I wouldn’t be surprised if llvm’s cross language compatibility was specifically attractive to Apple because it let them have their cake and eat it too - write a new language but keep legacy C code whenever that’s the best option.

> That’s why LLVM is such a great idea - any llvm language can interoperate with any other, within the same binary, with no overhead.

I don't believe LLVM provides a stable cross language ABI, and AFAIK languages just use regular FFI (via the C ABI) to communicate with one another, regardless of them being implemented on LLVM or not.

> I don't believe LLVM provides a stable cross language ABI, and AFAIK languages just use regular FFI (via the C ABI) to communicate with one another

Provided the compilers generate compatible versions of LLVM IR, then cross-language calls can be done at the IR level. See github.com/Keno/Cxx.jl

IIUC Swift already uses clang to load module maps in order to expose and call Objective-C, and they plan to do something similar with C++ (no link handy but I think there is an issue or enhancement proposal about it).

Yeah, Swift’s C interop goes further than most typical FFIs because it actually calls into Clang internals to read headers, lay out structs and form calls. C and Objective-C types, functions and methods are mapped to Swift definitions, by directly looking at the Clang AST.

> C ABI

Is there really such a thing? I thought the ABI was dependent on the operating system and compiler.

I agree that C is unique in it's ability to generate programs that can be interfaced with from any language. This also seems to apply to older languages like Fortran and Pascal, for some reason. Higher level languages are an ABI nightmare; seriously doubt anyone will ever dynamically link against a C++ library at runtime and call a method on a C++ object from any language that isn't C++.

1. As someone says, LLVM does not have a cross-language ABI, so no, it's not as easy as you think. It makes some things nicer, some things harder.

2. Prior to LLVM, there were much more complete attempts at this (that were even more successful, actually!)

As the siblings have mentioned, llvm doesn't really do this. What does, though, are the jvm and .net, although those aren't really oriented towards low-level c programming.

It is a great idea, but not an innovative one, already PL/8 for IBM RISC research used a similar approach.

My guess is that a lot of the C hold-outs will never switch to another language. C represents the siren's call for them: the best performance, requires skilled handling, no seatbelts, stable definition.

A lot of C's endurance is related to programmer psychology, so it would be futile to design a better C.

C++, Rust, Go, Java will continue to drain the pool of C developers until it's only used for maintenance of existing projects.

This is why it's extremely irksome to see people recommend mixing C and e.g. Python for speed, or other such Frankenstein's monsters - it's just prolonging the agony of whoever will maintain that.

C still represents the closest approximation of what is happening on a chip, quasi-atomic operations acting on finite resources like registers, memory, and I/O. Even if you don't know assembly, you can reasonably understand what various chips will do with your C code, especially low level C code that occasionally dips into assembly (e.g., handling interrupts or chip-level atomic operations).

Rust, Go, and Java, with their memory management and cross-platform portability, and general non-determinism may eat away at the edge of C, but can never replace it.

I could see them fully replacing C if features like garbage collection and byte-code interpretation were handled at the chip-level, so languages would not have to necessarily deal with them. Could also see it happening if a chip's out-of-order execution was exposed at the language level. That would not necessarily make C worse, but Java may be more adept at handling it.

You've made several points...

1. C is no closer than C++, or Rust (including unsafe) and they're all surprisingly pretty far from the hardware these days... this is visible the most in multi-threading, where high-level C statements are re-ordered by the compiler and even simple C statements like an integer assignment can be split into multiple instructions. Inlining and register allocation is also quite opaque and perhaps best left to the compiler, unless one uses non-standard code to force specific behaviour.

2. Well put: Go and Java were/are eating at the edge of C. Java took serious bites in the past, nowadays they're not really competing much. Today, what might have been a small Linux C program could be a Go program, especially if the performance constraints aren't too tight. Technically speaking, Rust can replace C almost everywhere, it's just that it's a significantly more complex language.

Regarding #1, disagree. In C, a function call is just a request to send the instruction pointer to another point in the memory space. In C, code is treated as data, which is how it's treated in hardware.

C++ introduces virtual functions, and when you make a function call, you're no longer going to a single place in memory, you go to where the class's virtual function table tells you to go, effectively jumping to a memory pointer. This is pretty helpful, but it's an incredibly different way to think about code. A function is no longer a set of instructions in memory, it's a logical representation of functionality.

And yes, I know in C, you can set a variable to a function location, and then jump there, but it's painful to do and you have to do it explicitly, so it doesn't really create an abstraction.

Regarding 2.

I am fully convinced that if Java and .NET had a proper AOT toolchain from day 1, meaning beyond dynamic linking (NGEN) or commercial offerings from 3rd party JDKs, C's influence on FOSS world would have been much less than it achieved to be.

And we would already have achieved an UNIX like stack closer to what Inferno/Limbo was all about.

> you couldn’t use C arrays on the stack, for example. And if you couldn’t do that, there’s entire classes of applications where the performance just wouldn’t be acceptable

Would you mind naming a few such classes?

Why would arena allocation, or evrn good generational GC fail to deliver the performance when quick allocation / deallocation of (large) arrays is required?

Generally one feature GCd languages lack is strong support for value types. Cache thrashing due to pointer chasing is an issue, and even if you can allocate large numbers of small objects quickly, the indirection will kill you. In Swift, many small allocations are avoided entirely by storing the value as part of some other object. For example, imagine you want to store an array of points; it’s usually much better if you can have an array of structs of floats where everything is represented as one flat allocation.

Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel, Common Lisp, Modula-2+, Modula-3, CLU, C#, D all have strong support for value types.

Java just made a couple of wrong decisions regarding AOT and value types that are now taking years to correct course, while avoid breaking backwards compatibility.

If something like Modula-3 had been granted Java's success story, we wouldn't be talking about how GC languages don't have good support for value types.

I think we have different definitions of value types - in all Common Lisp implementations I’m aware of values have a uniform representation as a (tagged) pointer.

Also I think C# structs do not have mutable fields, but I could be wrong.

Edit: it looks like C# structs are mutable, my mistake.

Common Lisp is just one example among 11 programming languages that I have listed.

Maybe take some time to check the other ones?

As for value types in Common Lisp, even if one bit is lost for tagging, it doesn't make arrays, structs and primitive values, less of value types.

C# had value types from day one.

Yeah, its one of the few that does. Even then, C# value types are immutable, and there are no value type collections (not a collection of value types, but a collection that is itself a value type). The lack of these two features means it’s not as generally useful as you might like.

An array of value types (including structs) in .NET (not just C#) is laid out contiguously in memory and stored in-place like an array of C/C++ structs would be. The problem of chasing pointers does not exist if you use structs (and don't use non-value types such as strings within those structs). And .NET value types are mutable, of course.

Right, but the array itself has reference semantics.

Not when you allocate it on the stack via stackalloc, as of C# 7 also allowed in safe code.

And ....

ARC in objective-c has almost fully solved this issue in practice.

Nope. I still found many ways to crash my objective C apps while using ARC. Because Swift is memory safe I no longer have to give up days or weeks of my life tracking down obscure bugs caused by overwriting memory I should not have.

Could you please give some concrete examples of how memory corruption has affected you in modern Objective-C? NSArray has range checks, delegates can't dangle anymore because they're weak references now. I think that leaves interaction with C APIs, but don't Swift users have to deal with UnsafeMutablePointer to use them - which isn't memory safe either?

The easiest way to cause memory issues is to access mutable collections from multiple threads. I really wish NSMutableArray and friends were thread safe...

Unfortunately, Swift doesn't fix that AFAIK.

No no no. That is a one-way trip to hell. There is no ”good for all threading scenarios” thread safe mutable array design.

I’ve debugged too much java code where the programmers thought that ”thread-safe” meant ”no need to think about threading issues”.

Thanks for having the patience to put all these Obj-C myths to rest.

The Obj-C community (or what's left of it) is trying to make a martyr of an error-prone, cumbersome programming language.

Try to use ARC with C APIs.

That's like saying try to use Java JNI with C APIs. Think of direct C API access in Objective-C a bonus, not a design pattern :)

Completly different, ARC only works with APIs that follow Cocoa retain/release patterns, which aren't the only APIs that one needs to use, e.g. CoreGraphics.

And unlike JNI they aren't protected by a VM wall.

I can understand the need to create a new programming langauge, but as the previous poster wrote, they rather recreated all the complexity of C++, instead of a more lean language. Also, Swift seems to suffer from overly static typing in its object oriented approach - which defeats the idea of object oriented programming.

> they rather recreated all the complexity of C++

I find that this assertion holds about as much water for Swift as it does for Rust, Swift is not even remotely close to C++'s in terms of complexity, and that's with building in mechanisms for performant memory safety, a concept which C++ literally just shits on to this day and for the foreseeable future.

Swift is a really approachable language, it’s core features are simple and the code is very readable. You can write any app without having to use generics, extensions, protocols, more esoteric enum features, etc, etc.

But once you learn to use the more advanced features, your code just gets easier to write and maintain. I enjoy that I can pickup new language features in Swift one at a time, figuring out where each adds its best value, and occasionally refactoring to take advantage as part of my ongoing efforts to minimize code debt.

It’s hard to take seriously the idea that swift and c++ have equivalent complexity if you have delivered products using both languages.

It’s not even close. Swift is (still) minimalist by comparison to C++.

Swift is complex, but it is not C++-complex. C++ is in the completely different league.

That's extremely hyperbolic. I've worked on multiple C++ FEs and it's orders of magnitude more complex than Swift.

As an embedded engineer I can’t agree that C “has problems” because it treats you like a big boy with your big boy pants on. :)

I work almost exclusively in embedded C and even I can’t agree with this. Just for starters, those two statements are not mutually exclusive.

Which is a problem for developers who simply want to write code without having to reason about whether it’s safe to dereference something, and without having to worry about a simple oversight resulting in the programmatic equivalent of summoning Cthulhu.

>a problem for developers who simply want to write code without having to reason

Still not seeing the problem.

Pointers aren’t magic and aren’t hard.

Pointers, conceptually speaking, are not hard.

Pointers, in practice, are hard. Even C-family compilers cannot safely reason about them in many (most) cases.

Oh boy, trying to debug some miscompile because of a subtlety in aliasing rules would make me disagree.

As a C compiler engineer I can assure you it has problems.

Did I say C didn’t have problems? Or did a say it’s not a problem that C might allow you to do unsafe things?

I think so?

“As an embedded engineer I can’t agree that C “has problems” because it treats you like a big boy with your big boy pants on. :)”

Do you know what “because” in that sentence means?

Edit: Nah, that’s OK. Just downvote and scamper on. Make HN more like Reddit, that’s what this place needs!

Could you please stop posting unsubstantive comments to Hacker News?

Well I took it to mean that because you think it treats you as a "big boy" you don't think it has problems.

Oh and I have no idea how to downvote on HN. Not that I care, but I don't see any downvote buttons.

There is no such thing as "big boys" in software engineering, there's only humans which have certain cognitive weaknesses.

C is really good at exploiting those, while at the same time giving programmers a feeling of power.

So providing a feeling of power over the language and it's abilities is not a legitimate advantage of the language?

Isn't that why everyone loves python, solving a complex problem in a handful of easily readable lines of code?

The feeling of power is nice for the programmer, but it doesn't influence the technical capabilities of the language, which are deplorable safety-wise.

Did you see the smiley face in my post that’s implied I’m kinda joking.

Also... I’m a little concerned that your post has “we’re all equal” social justice vibe to it... which is silly. C is more powerful than because “safety features” aren’t there.... deplorable... LOL.

You try going a day without using something programmed in C.

Oh boy, how I wish I could have at least one day without something programmed in C. I'm so sick of all the vulnerabilities...

No social justice vibe was meant. I was trying to say that we're all bad at dealing with the kind of errors which appear in a typical C or (perhaps to a lesser extent) C++ program.

I know that some people are able to do this more successfully than others because of skill, etc, but it's not just about certain individuals. As a whole, the C community has a really poor track record at security and safety and that has a lot to do with the language itself.

Tone is a tough thing to get right, and I'd say your initial post came off pretty condescending to a lot of people, regardless of whether you meant it or not. It's not even a C thing either, I've seen the same thing where someone declares functional programming as the only "serious programming" and category theory is easy, so everyone else is wasting time with imperative languages. So, it's a bit off-putting.

Every single day back when I was developing software for ZX Spectrum, Amiga and MS-DOS, before UNIX's influence took over the industry and forced us into dealing with C.

Thankfully there was already C++ for those of us that wouldn't move into such a limited language versus what something like Turbo Pascal 6.0 for MS-DOS was already capable of, feature wise.

Ok... so if I’m getting the idea here... C is more limited, but also dangerous because it gives direct access to memory and pointers making it dangerous.

Man... to listen to hackernews tell it... no one should use C!

I wonder how many comments describing how bad C is are from people on Linux machines?

The problem is not direct access to memory and pointers as such, every systems programming language needs to provide such features.

The problem with C, versus other systems programming languages it that it its pointers, implicit conversions of array into pointers, integer operations, string and array bounds don't have any kind of validation.

On other systems languages disabling such validations is explicit.

C is like JavaScript in the browser, we have to put up with it because UNIX clones won the market of commodity OSes.

C on its own without UNIX, would have failed in the market.

On the desktop world it was already being replaced by C++, Smalltalk, VB, Delphi and 4GL before FOSS based on UNIX and C started to be widespread.

Unfortunately it is impossible to convince people on pure UNIX based OSes to use something else.

Fortunately, Apple, Microsoft, Google, Sony, Nintendo are able to set which programming languages one is allowed to use on their platforms and C is on the way out on their SDKs.

LOL yea, C is going away alright. Just as soon as every company you mentioned and everyone else in the world stops making embedded electronics!

I have used Objective-C since 1997 when I worked with WebObjects back then and I don't miss it for a second. When I have to touch our one codebase with Objective-C I have to groan. It was amazing for its day and I did enjoy it despite its shortcomings. But I can write way more highly functional code faster in Swift than I ever could in Objective-C due to real type safety and other modern features. I also spent years doing regular C and C++ and Java (not at the same time) and all 3 languages seem clunky to me now. Preferring Objective-C over Swift is wishing for the golden oldie days kind of thinking and I'm one with almost 4 decades of programming experience. Swift is still young and growing and sometimes thats a bit challenging to adapt, but its the one language I truly enjoy now.

I’m the opposite. When I see Swift I just groan. It’s so much hard and slower to write more highly functional code (not to mention going back to ready it) than Objective-C. Part of that is lots of things about Swift are backwards (variable definition) or overly expressive (var/let/func).

I just cannot enjoy Swift at all. When I go back to Objective-C its just such a joy to write.

Developer productivity is far less determined by how fast you can write code, than by how many bugs you create, and how hard it is to fix them. The vast majority of time is spent debugging and maintaining code.

And I feel like I can write in Swift nearly as fast as Objective C. Objective C was always so baroque, when I define a method or variable and declare the exact same thing in a header file? Properties syntax?

I actually switched when Swift 1.0 came out (just after writing a twenty thousand line simulation engine in Objective C). It was so lightly baked I was starting to regret my decision for a couple months until version 1.2 released, only then could I ship my app commercially. Since then every release has only gotten better, and the rough edges are entirely gone. The only thing I miss from Objective C is compile time, and now just barely given how much faster the compiles have gotten.

> The vast majority of time is spent debugging and maintaining code.

Not all programming is the same. I've seen a lot more code churn in frontend projects than in the backend, where the actual logic and persistence happens. That makes the speed of (re)writing code relatively more important (at least for the iOS apps I've worked on, YMMV).

But even when I had to clean up legacy code, I spent most of my debugging time on on incorrect threading (typically using UIKit or Core Data from the wrong thread), AutoLayout errors, Apple framework bugs, storyboards/NIBs out of sync with code, performance degradations, or anything else where Swift doesn't help much.

In my experience, Objective-C programmers aren't allergic to safety or brevity. We love ARC! It's just that Swift has taken away too much productivity, mostly through terrible tooling and by dividing the community, for very little gain.

> Objective C was always so baroque, when I define a method or variable and declare the exact same thing in a header file

When I helped out on a Java project, I noticed that my coworkers religiously created interfaces for every single class they wrote. They couldn't really explain it beyond it being a "best practice", but I suspect they enjoyed being able to look at a short file that only contained the interface plus JavaDoc, instead of opening the full implementation every time. They basically re-invented header files :P

I don't think people would mind headers as much if Xcode was a better IDE, and we didn't have to copy declarations around manually.

> They couldn't really explain it beyond it being a "best practice", but I suspect they enjoyed being able to look at a short file that only contained the interface plus JavaDoc, instead of opening the full implementation every time. They basically re-invented header files :P

Then they should have known better.

That makes sense for unit testing, in cases where mock classes would be required.

All Java IDEs have object browsers no need for header files.

Mockability was the official reason until we started using Mockito 2. I hope everyone on the team was aware of the object browser. And yet they felt better with interfaces everywhere. It might have been a simple case of cargo-culting, though.

I'm surprised that anyone could find Objective-C a better language than Swift. I'm just waiting for iOS to move completely to Swift to start developing on that platform. It's a much better language.

Not everyone wants features. Go is an extremely simple language, it doesn't even have generics. People use it widely anyway.

> Part of that is lots of things about Swift are backwards (variable definition) or overly expressive (var/let/func).

Is this a joke? This sounds like "the language is wrong because it didn't completely ape C"

Objective-C in 1997 and in 2017 are almost two different languages. Between ARC and generics, auto-synthesized ivars, and blocks, there's not much missing from being a modern C#/Java-like language.

I love Objective-C, but calling it (close to) a modern language is a long stretch. The “generics” are a joke, for example. The whole type system is miles from what can be expressed (and guaranteed!) by a modern language. We got an immense amount of fun out of it considering its age, but it’s time to move on.

Totally agree that generics in objective c are very bare. And that's what frustrates me the most. Apple/Lattner could have improved them, but chose not to, by focusing all their energy on Swift.

"Simple" things I want from generics:

1. Carry over generic information from header files to .m files, and not force us to drop all type information by having to use "id".

2. A compiler flag to enforce that the generic type must be specified at usage.

3. Where clauses in generics: Foo <T where T : NSCopying, MyProtocol>>

4. Generics on protocols, ideally with all the other features.

I know some of these are not trivial to implement, but they are mostly new syntax and hence don't have backward compatibility issues (except #2 which is why I asked for a compiler flag).

I wan't to ask in all seriousness, or in all ignorance—I don't mind, so please take your pick—why generics are so important. Let's say, in the first case, you have an NSArray in Objective-C. The object in the array is of type id. Now, in the second case, you have an NSArray, but you've declared that it will only hold types of NSString. Why is the second any better?

I ask, because the only way I could see it being better is if you're taking that array—that data structure—and passing it all over the program and using it everywhere. (Note to the literal-minded: this is hyperbole.) If that's what you're doing, that's not Object-Oriented Programming.

If you're instead doing real OOP, you're designing an object that will perform a clearly circumscribed bit of work for you by responding to a set of messages. The NSArray may live inside that object—in other words, the object is composed in part by using an NSArray—but that array is hidden from the rest of the program.

Generics are no big whoop-di-do in that case, because there is no client-programmer that has to worry about them; or, to put it another way, you—the original programmer—only have to worry about that NSArray with respect to the programming of that one object. In that case, the data type the array holds is not a big deal to keep track of.

So, again—seriously—what is so great about generics? The whole point of Objective-C, originally, was that it was late-binding—which, if you ask Alan Kay, was the point of OOP in the first place. If you're worrying about types all over the place, you're doing something wrong, no?

Your array of NSString example has little to do with generics. Instead think of a class that contains an NSArray, and has methods to do specific things to the array items, for example a sort() method. Using generics you can define the array values to match the type given when the class is created. So the same class could contain NSStrings, UImages, UIControls, etc, etc, and sort accordingly.

Alan Kay’s ideas are very interesting and Smalltalk introduced many groundbreaking ideas that still inspire programmers today. But there’s no fundamental law of nature that says dynamic message passing OOP is the “right” way to approach OOP, or even that OOP is the best paradigm for many coding problems developers face today.

Okay, the context of the reply to which I was initially replying to was about how the implementation of generics in Objective-C was "very bare." I'm beginning with this point, because though I agree with your second point about OOP perhaps not being necessarily "the best paradigm for coding problems developers face today," I don't quite see where that point fits in. We're talking about Objective-C, which means we're talking about OOP. If you want to explore some other kind of programming paradigm and insist that generics are needed there, I have no quarrel with you. My point was that I didn't see why generics were needed in OOP.

But that brings us to your first point: namely, what is the "right" way to approach OOP.

When I bring up Alan Kay, I'm bringing up a guy who was there at the start, and who set his stamp on OOP. Granted, "OOP" has been done in different ways. You'll note, however, my use of scare quotes. Allow me to explain.

When OOP had the misfortune to become a managerial buzz, somewhere back in the 1990's, and thus became a "must-have," what happened was a lot of procedural programmers simply took their procedural programming, wrapped in in C++, compiled it with a C++ compiler, nodded to the boss and assured him that they were doing OOP—and went along on their happy way.

Likewise, when college professors—set in their ways, as is their want—were told that they had to start teaching OOP, they largely did the same thing.

The result is that we have lots and lots of people out in the world "doing OOP"—who actually aren't. They're writing procedural programs, with the trappings of classes and sub-classing and what not. But all over in their programs, they are digging into the internals of their classes—and, sometimes, you see them digging in many layers deep.

And they're "doing OOP."

As I understand him, Kay is saying that you send a message to an object, on the understanding that the object will handle the message, the sender not having to worry about the ultimate who or how. If there's another kind of OOP other than that—or other than the travesty I described above—what is it?

But, that's another question, entirely. My original question was: why are generics such a big deal in OOP? I don't believe that's been answered.

And even Smalltalk had many ideas from FP, like blocks (closures) and the collection messages similar to what modern developers know as LINQ.

For me, the big deal about generics is that they allow the type system to cover a much bigger part of my design. Without generics, any parametrized API will erase your types and then the compiler is blind. With generics the type information is preserved and when I specify a parameter type, somewhere several API layers away a type is suddenly fixed, too. That gives me a warm feeling (and code completion, too). And since expressive static type systems seem to be the right way to go, allowing the type system better insight into your code is a big win.

I don’t understand how you think this should be implemented. Many classes informally conform to protocols or in some cases the conformance can only be checked at runtime with a respondsToSelector: check. So any generics at compile time stricter than what we currently have will just not work or be useful.

Not useful as I’d rather find that mistake when a customer reports the crash, instead of having the compiler tell me?

The point I'm making is that the compiler can't tell you this, since conventional Objective-C code does generics checking at runtime. There's just not enough information available for this to be reliably diagnosed.

A fundamental problem with Objective-C generics that cannot be addressed in an additive manner is that generic parameters just desugar to ‘id’; you cannot use Objective-C generics with C types and you still pay the performance and memory use cost of trafficking exclusively in class instances. This of course was the right trade off, since it allowed generics to be layered on top of existing types like NSArray without either changing their implementation or breaking existing client code. However, when designing a new language with generics built in from the start you can make much better design decisions.

That’s a real stretch. As someone who previously wrote Obj-C and currently writes Swift full time, whenever I revisit and work on old Obj-C code I constantly have “oh right, Obj-C doesn’t have that” moments and either have to pull in some third-party library that does what I need or settle for a less than satisfactory (and usually dramatically longer) solution.

I do have times when writing Swift where I miss some bit of Obj-C, but those are rare and are becoming fewer as the language develops.

Other than safety, that is.

Meh, I think that is overrated.

It boils down to the self discipline of individual developers. If you’re meticulous in making sure you’ve dotted your I’s and crossed your T’s and haven’t let too many of those insidious cast statements slip in, you can write reasonably safe Obj-C, but during my career as an iOS dev I have yet to encounter an Obj-C codebase that was fully written by such developers. They’ve all been riddled with gratuitous casting, erroneous type assumptions, and other bad practices (that aren’t possible in Swift) to the point that it’s a wonder that they ever functioned as intended.

Personally though, I’ve found that even when I’m keeping a close guard on things when writing Obj-C and am sure to avoid all the obvious pitfalls, bugs slip through in the most unexpected places, so I’m quite happy to have the Swift compiler double checking everything for me.

I’ve never understood this opinion, and always wonder if it’s a professional developer espousing it. Because most of your time as a commercial developer is spent debugging, and Swift makes it far easier to write correct code, and to find bugs when you write incorrect code.

On a positive note, at least you're just writing buggy programs and not killing your patients somewhere or causing industrial accidents.

Unfortunately, as software continues disrupting various industries, it's less and leas certain that even buggy programs written by someone who thinks that safety is overrated will remain harmless.

Only because software is a special snowflake where companies aren't held responsible for shitty software.

I'm glad for you, but everything you said is completely subjective.

I believe the parent was subjective as well. I am curious as to why you appear to label just this comment. HN is for opinions as well as facts and I deeply value all of them. Particularly the opinions that politely challenge me.

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.

> 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.

> 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++.

If 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.

Not 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.

People 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.)

> 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.

And Swift, which uses automatic reference counting instead of GC. This is not a “zero-overhead” design like what Rust aims for; sometimes it has quite a lot of overhead. But it is free from the phenomenon of GC pauses.

> But it is free from the phenomenon of GC pauses.

Not really. RC algorithms can lead to stop the world in cascade deletion of highly nested data structures, and even cause stack overflow due to destructors being called.

Well, in that regard, so is Python; the GC is only used to resolve cycles, and can be disabled.

IIRC memory safe Ada doesn't allow for deallocation.

Kinda sorta cheating. ;)

It does via memory pools, RAII (aka controlled types) and dynamic stack allocation.

It isn't truly safe like Rust, as Ada can still have dangling pointers laying around, the free function is called "Unchecked_Deallocation", not sure if newer Ada has any mechanisms for better ownership semantics.

> People have written and continue to write secure C code, and insecure code in “safe” languages.

No. It's the inverse. People who are very good with C continue to have vulnerabilities in their code. Why? Because C.

Yeah, 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/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)

The 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.

If only there was a way to catch array index out of bounds.

  extension 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

I always have a choice if I'm the one writing the code.

But what I want is a way to catch all errors that others may have introduced in code I have no control over. That includes arithmetic overflow as well.

What would you do? If the ordinary array subscript produced an optional value, people would simply fall into the habit of force-unwrapping it, since the hassle of handling the spreading optionals would be too big. And throwing an unchecked exception would lead to empty catch blocks everywhere, just as in Java. And then the execution would continue in God only knows what state. I simply don’t think that the type system can solve the question of trusting your dependencies for you.

What I want to do is to wrap a piece of code running in its own thread in a catch block so I can respond gracefully to any errors without killing the entire process.

What gracefully means depends entirely on the application. Often it means to log the error or display a meaningful error message if it's an interactive app, then maybe do other kinds of cleanup and shut the thread down.

It can also mean to retry later. Array out of bounds errors are quite often just a result of not properly handling an earlier temporary error.

Whether or not errors leave the rest of the application in an inconsistent state depends entirely on the design of the application.

I'm not saying that letting an app crash on buggy code is never the right thing to do. I just want the option to handle it differently where appropriate and possible (it's not always possible anyway).