Cocoa with Love

"Does need extra work in some cases" is an understatement. With type 'inference' that's unidirectional, like in C and C++, you only need to look at each expression once. Thus, in most cases, the whole job is O(n) in the number of expressions.

Admittedly, there are exceptions. For example, it's possible in C++ to create humongous types:

auto p1 = std::make_pair(0, 0); // pair<int, int>
auto p2 = std::make_pair(p1, p1); // pair<pair<int, int>, pair<int, int>>
auto p3 = std::make_pair(p2, p2); // pair<pair<pair<int, int>, pair<int, int>>, pair<pair<int, int>, pair<int, int>>>
auto p4 = std::make_pair(p3, p3); // ...

Also, since templates are Turing complete, it's possible to create situations where type checking a single expression takes arbitrarily long.

But neither of those are situations you're likely to run into by accident. In most real C++ programs, all the types in the program are reasonably simple, and the template system isn't used to do anything especially clever, so the O(n) bound should hold.

On the other hand, full type inference, at least in a language like Swift that allows arbitrary overloads, is inherently a process of exhaustive search over an exponential number of possibilities. Now, as described in this post[1], it ought to be possible in most cases to reduce that exhaustive search to something much simpler – and I actually agree that the Swift compiler could be much, much better at doing so (although it has improved over time). …

Neat, good to know! And it does seem my mental model of event loop was broken. Accessibility related interactions don't have any related NSEvent.

They are handled as part of the "conceptual" run loop, but they seem to be dispatched internally by AXRuntime library from a callback off some mach port. And because of this, the call to nextEventMatchingEventMask in the main -[NSApplication run] loop never even sees any such NSEvent.

-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] (in AppKit)
_DPSNextEvent (in AppKit)
_BlockUntilNextEventMatchingListInModeWithFilter (in HIToolbox)
ReceiveNextEventCommon (in HIToolbox)
RunCurrentEventLoopInMode (in HIToolbox)
CFRunLoopRunSpecific (in CoreFoundation)
__CFRunLoopRun (in CoreFoundation)
__CFRunLoopDoSource1 (in CoreFoundation)
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ (in CoreFoundation)
mshMIGPerform (in HIServices)
_XPerformAction (in HIServices)
_AXXMIGPerformAction (in HIServices)

In some sense this is sort of similar to apple events, which are also "hidden" from the caller of nextEventMatchingEventMask. From what I can see those are handled by DPSNextEvent, which sorts based on the raw carbon EventRef. aevt types have `AEProcessAppleEvent` called on them, then the…

Haha I just had to post this. When I went to read about core dumps in iOS:

http://stackoverflow.com/questions/7353024/when-an-app-crashes-in-ios-does-it-create-a-core-dump-anywhere

I got a StackOverflow core dump, of sorts, similar to this:

http://img215.imageshack.us/img215/2886/picturezb.png

Currently I am using an uncaught exception handler based on this:

http://www.cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html

But unfortunately it doesn't give very descriptive stack traces, even with debugger symbols turned on in the project settings. I'm really looking for something that shows me a full view of the program's state just like if I was in the debugger. It may be possible to extrapolate from the core dump, but I’m having a hard time figuring it out. This post summarizes how to do it with gdb:

http://stackoverflow.com/questions/5115613/core-dump-file-analysis/5115653#5115653

But I’m thinking a huge opportunity has been lost here. This should be built into IDEs and especially for mobile apps, there should be a standard way of sending core dumps back to the developer when apps crash, especially for ad hoc builds during testing.

Here are some great resources for learning iOS:

[1] Online courses:

http://www.hackrocket.com

http://teamtreehouse.com/

http://www.lynda.com/iOS-tutorials/iOS-SDK-Essential-Training/92179-2C.html

http://itunes.apple.com/itunes-u/ipad-iphone-application-development/id473757255

http://codelesson.com/courses/tag/Mobile

[2] Blogs/tutorials:

http://developer.apple.com/library/ios/#referencelibrary/GettingStarted/RoadMapiOS/Introduction/Introduction.html

http://www.raywenderlich.com/

http://cocoawithlove.com/

http://mattgemmell.com/

http://mobile.tutsplus.com

[3] Books:

Objective-C Programming: The Big Nerd Ranch Guide

iPhone Programming : The Big Nerd Ranch Guide

Cocoa Design Patterns

iPhone App Development : The Missing Manual

The iOS Developer's Cookbook

Cocoa Design Patterns

Beginning iPhone Development: Exploring the iPhone SDK

[4] Forums/Q&A

http://stackoverflow.com

http://www.iphonedevsdk.com/forum/

[5] Videos

http://www.youtube.com/user/MilmersXcode?ob=0&feature=results_main

[6] Email newsletters

http://tinyletter.com/hackrocket

http://iosdevweekly.com/

http://iosdesign.co/

When I learned Objective-C I remember being flabbergasted at all the method and argument names that were exceedingly wordy. At some point I read a blog post[0] that said while this is out of the ordinary when it comes to most code having long, descriptive names helps when reading code.

Some people complain that it involves too much typing or takes up too much space.
In reality, we spend much more time reading code than we do writing it, so names that provide context, direction, and fore-shadowing are really useful.

I still tend to write method names and important variable names like that to this day in pretty much any language I use. IMHO, its a great hack.

An extreme example is in the NSBitmapImageRep class [1]

[0]: https://www.cocoawithlove.com/2009/06/method-names-in-objective-c.html

[1]: https://developer.apple.com/documentation/appkit/nsbitmapimagerep/1395538-init

Actually, even very basic code can cause it. The type system of Swift has issues.

https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

let a: Double = -(1 + 2) + -(3 + 4) + -(5)

Still fails on a very recent version of Swift, Swift 6.1.2, if my test works.

Chris Lattner mentions something about him being more of an engineer than a mathematician, but a responsible and competent computer science engineer that is designing programming languages with complex type systems, absolutely has to at least be proficient in university-level mathematics and relevant theory, or delegate out and get computer scientists to find and triple-check any relevant aspects of the budding programing language.