Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> The parts that make C dangerous, particularly strings and other raw pointer accesses are abstracted away behind safe NSString, NSArray, NSData and friends.

True, and just like in C++, the C tribe that came into the language just ends up using char * most of the time, instead of the safe variants.



I have jumped into several badly written ObjC projects and I skimmed the source code of every CocoaPod that I've used, and I have never seen ObjC code that used C string/memory handling "most of the time". Not even when ObjC required manual reference counting.

Except for a couple of malloc'd C arrays (as an optimization over using NSArray<NSValue>), most of it was for interop with C libraries, the same code where in Swift you'd have to use UnsafeMutablePointer.


What can I say, lucky you.

Now try the same with a couple of offshored projects from some famous consulting companies.


Fair enough, but I also don't see why we should judge languages based on the absolute worst projects written in them.

For example, the offshore Swift programmers I've encountered will add "?? 0", "?? []" etc. into expressions involving optionals until they compile. That doesn't mean that Swift's nullability is pointless, it's still a great tool for diligent programmers.


I agree in principle, but that doesn't change the fact that such kind of code might land on an application I depend on for some reason.

Hence why I always advocate for better industry regulation, as I get to see how the sausage is made, and would like everyone gets more healthier.

Most managements don't care about diligent programmers, only delivery.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: