Crusty here, I just saw that my young friend Dave Abrahams gave a talk that was based on a little keyboard session we had just a short while ago. Really sharp
fellow, you know, I am sure he'll go far someday, but that's the problem with young folk these days: they
go rushing out telling everyone what they've learned when the lesson is only one third of the way through.
You see, I was trying to impart some wisdom on the fellow using the old Hegelian dialectic: thesis, antithesis,
synthesis. And yes, I admit I wasn't completely honest with him, but I swear it was just a little white lie
for a good educational cause. You see, I presented ADT (Abstract Data Type) programming to him and called
it OOP. It's a little ruse I use from time to time, and decades of Java, C++ and C# have gone a long way
to making it an easy one.
Thesis
So the thesis was simple: we don't need all that fancy shmancy OOP stuff, we can just use old fashioned
structs 90% of the time. In fact, I was going to show him how easy things look in MC68K assembly
language, with a few macros for dispatch, but then thought better of it, because he might have seen
through my little educational ploy.
Of course, a lot of what I told him was nonsense, for example OOP isn't at all about subclassing, for
example the guy who coined the term, Alan I think, wrote: "So I decided to leave out inheritance as a built-in feature until I understood it better." So not only isn't inheritance not the defining feature of OOP as I let on, it actually
wasn't even in the original conception of the thing that was first called "object-oriented programming".
Absolute reliance on inheritance and therefore structural relationships is, in fact, a defining feature
of ADT-oriented programming, particularly when strong type systems are involved. But more on that later.
In fact, OOP best practices have always (since the late 80ies and early 90ies) called for composition
to be used for known axes of customization, with inheritance used for refinement, when a component needs
to be adapted in a more ad-hoc fashion. If that knowledge had filtered down to young turks writing
their master's thesis back in what, 1997,
you can rest assured that the distinction was well known and not exactly rocket science.
Anyway, I kept all that from Dave in order to really get him excited about the idea I was peddling to
him, and it looks like I succeeded. Well, a bit too well, maybe.
Antithesis
Because the idea was really to first get him all excited about not needing OOP, and then turn around
and show him that all the things I had just shown him in fact were OOP. And still are,
as a matter of fact. Always have been. It's that sort of confusion of conflicting truth seeming
ideas that gets the gray matter going. You know, "sound of one hand clapping" kind of stuff.
The reason I worked with him on a little graphics context example was, of course, that I had written
a graphics context wrapper on top of CoreGraphics a good three years ago. In Objective-C. With a protocol
defining the, er, protocol. It's called MPWDrawingContext
and live on github, but I also wrote about it, showed how protocols combine with blocks to make CoreGraphics patterns
easy and intuitive to use and how to combine this type of drawing context with a more advanced
OO language to make live coding/drawing possible.
And of course this is real live programming, not the "not-quite-instant replay" programming that
is all that Swift playgrounds can provide.
The simple fact is that actual Object Oriented Programming is Protocol Oriented Programming,
where Protocol means a set of messages that an object understands. In a true and pure object
oriented language like Smalltalk, it is all that can be, because the only way to interact with an
object is to send messages. Even if you do simple metaprogramming like checking the class, you are
still sending a message. Checking for object identity? Sending a message. Doing more intrusive
metaprogramming like "directly" accessing instance variables? Message. Control structures like
if and while? Message. Creating ranges? Message. Iterating? Message.
Comparing object hierarchies? I think you get the drift.
So all interacting is via messages, and the set of messages is a protocol. What does that make
OO? Say it together: Protocol Oriented Programming.
Synthesis
So we don't need objects when we have POP, but at the same time POP is OOP. Confused? Well,
that's kind of the point of a good dialectic argument.
One possible solution to the conflict could be that we don't need any of this stuff. C, FORTRAN
and assembly were good enough for me, they should be good enough for you. And that's true to
a large extent. Excellent software was written using these tools (and ones that are much, much
worse!), and tooling is not the biggest factor determining success or failure of software projects.
On the other hand, if you want to look beyond what OOP has to offer, statically typed ADT programming
is not the answer. It is the question that OOP answered. And statically typed ADT programming
is not Protocol Oriented Programming, OOP is POP. Repeat after me: OOP is POP, POP is OOP.
To go beyond OOP, we actually need to go beyond it, not step back in time to the early 90ies, forget
all we learned in the meantime and declare victory. My personal take is that our biggest challenges
are in "the big", meaning programming in the large. How to connect components together in a meaningful,
tractable and understandable fashion. Programming the components is, by and large, a solved problem,
making it a tiny bit better may make us feel better, but it won't move the needle on productivity.
Making architecture malleable, user-definable and thus a first class citizen of our programming
notation, now that is a worthwhile goal and challenge.
While we're on the subject of terminological disasters, Facebook's react.native seems to be doing a good job of muddling the waters.
While some parts make use of native infrastructure, a lot do not:
uses views as drawing results, rather than as drawing sources, has a
parallel component hierarchy,
ListView isn't UITableView (and from what I read, can't be),
even buttons aren't UIButton instances,
doesn't use responder chain, but implements something "similar", and finally,
oh yes, JavaScript
None of this is necessarily bad, but whatever it is, it sure ain't "native".
What's more, the rationale given for React and the Components framework that was also just released
echoes the misunderstandings Apple shows about the MVC pattern:
Just as a reminder: what's shown here with controllers pushing data to view at any time is not MVC, unless you use that to mean "Massive View Controller".
In Components and react.native, this "pushing of mutable state to the UI" is supposed to be replaced by "a (pure) function of the model".
That's what a View (UIView or NSView) is, and what drawRect:: does. So next time you
are annoyed by pushing data to views, instead of creating a whole new framework, just drag a Custom View
from the palette into your UI and then implement the drawRect::. Creating views as a result
of drawing (and/or turning components into view state mutations) is more stateful than drawRect::,
not less.
Again, that doesn't mean it's bad or useless, it just means it isn't what it says on the tin. And that's
a problem. From what I've heard so far, the most enthusiastic response to react.native has come from
web developers who can finally code "native" apps without learning Objective-C/Swift or Java. That may
or may not be useful (past experience suggests not), but it's something completely different from what
the claims are.
Oh and finally, the "react" part seems to refer to "one-way reactive data flow", an even bigger
terminological disaster that I will examine in a future post.
One of the many things that's been puzzling me for a long time is why operator overloading
appears to be at the same time problematic and attractive in languages such as C++ and
now Swift. I know I certainly feel the same way, it's somehow very cool to massage the
language that way, but at the same time the thought of having everything redefined underneath
me fills me with horror, and what little I've seen and heard of C++ with heavy overloading
confirms that horror, except for very limited domains. What's really puzzling is that
binary messages in Smalltalk, which are effectively the same feature (special characters like *,+ etc. can be used as message names taking
a single argument), do not seem to not have
either of these effects: they are neither particularly attractive to Smalltalk programmers,
nor are their effects particularly worrisome. Odd.
Of course we simply don't have that problem in C or Objective-C: operators are built-in
parts of the language, and neither the C part nor the Objective part has a comparable
facility, which is a large part of the reason we don't have a useful number/magnitude
hierarchy in Objective-C and numeric/array libraries are't that popular: writing
[number1 multipliedBy:number2] is just too painful.
Some recent articles and talks that dealt with operator overloading in Apple's new
Swift language just heightened my confusion. But as is often the case, that
heightened confusion seems to have been the last bit of resistance that pushed through
an insight.
Anyway, here is an example from NSHipster Matt Thompson's excellent post on Swift Operators,
an operator for exponentiation wrapping the pow() function:
This is introduced as "the arithmetic operator found in many programming languages, but missing in Swift [is **]".
Here is an example of the difference:
pow( left, right )
left ** right
pow( 2, 3 )
2 ** 3
How come this is seen as an improvement (and to me it does)? There are two candidates for what the difference
might be: the fact that the operation is now written in infix notation and that it's using
special characters. Do these two factors contribute evenly or is one more important than
the other. Let's look at the same example in Smalltalk syntax, first with a normal keyword
message and then with a binary message (Smalltalk uses raisedTo:, but let's stick
with pow: here to make the comparison similar):
left pow: right.
left ** right.
2 pow: 3.
2 ** 3.
To my eyes at least, the binary-message version is no improvement over the keyword message,
in fact it seems somewhat worse to me. So the attractiveness of infix notation appears to
be a strong candidate for why operator overloading is desirable. Of course, having to use
operator overloading to get infix notation is problematic, because special characters generally
do not convey the meaning of the operation nearly as well as names, conventional arithmetic
aside.
Note that dot notation for message sends/method calls does not really seem to have the same effect, even though it could technically also be considered
an infix notation:
left.pow( right)
left ** right
2.pow( 3 )
2 ** 3
There is more anecdotal evidence. In Chris Eidhof's talk on functional swift, scrub to around the 10 minute mark. There you'll find the
following code with some nested and curried function calls:
let result = colorOverlay( overlayColor)(blur(blurRadius)(image))
"This does not look to nice [..] it gets a bit unreadable, it's hard to see what's going on" is the quote.
let result = colorOverlay( overlayColor)(blur(blurRadius)(image))
Having a special compose function doesn't actually make it better
let myFilter = composeFilters(blur(blurRadius),colorOverlay(overlayColor))
let result = myFilter(image)
Infix to the rescue! Using the |>operator:
let myFilter = blur(blurRadius) |> colorOverlay(overlayColor)
let result = myFilter(image)
Chris is very fair-minded about this, he mentions that due to the special characters involved,
you can't really infer what |> means from looking at the code, you have to know, and having
many of these sorts of operators makes code effectively incomprehensible. Or as one twitter
use put it:
Every time I pick up Scala I think I'm being trolled. How many different possible meanings of _=>.+->_ can one language have??
Like most things
in engineering, it's a trade-off, though my guess is the trade-off would shift if we had
infix without requiring non-sensical characters.
Built in
I do believe that there is another factor involved, one that is more psychologically subtle
having to do with the idea of language as a (pre-defined) thing vs. a mechanism for building
your own abstractions that I mentioned in my previous post on Swift performance.
In that post, I mentioned BASIC as the primary example of the former, a language as a
collection of built-in features, with C and Pascal as (early) examples of the latter,
languages as generic mechanisms for building your own features. However, those
latter languages don't treat all constructs equally. Specifically, all the operators
are built-in, not user-definable over -overridable. They also correspond closely
to those operations that are built into the underlying hardware and map to
single instructions in assembly language. In short: even in languages with
a strong "user-defined" component, there is a hard line between "user-defined"
and "built-in", and that line just happens to map almost 1:1 to the operator/function
boundary.
Hackers don't like boundaries. Or rather: they love boundaries, the overcoming of.
I'd say that overloaded operators are particularly attractive (to hacker mentalities,
but that's probably most of us) in languages where this boundary between user-defined
and built-in stuff exists, and therefore those overloaded operators let you cross
that boundary and do things normally reserved for language implementors.
If you think this idea is too crazy, listen to John Siracusa, Guy English and Rene Ritchie
discussing Swift language features and operator overloading on Debug Podcast Number 49, Siracusa Round 2, starting at 45:45. I've transcribed a bit
below, but I really recommend you listen to the podcast, it's very good:
45:45 Swift is a damning comment on C++ [benefits without the craziness]
46:06 You can't do what Swift did [putting basic types in the standard library]
without operator overloading. [That's actually not true, because in Swift the operators are just syntax -> but it is exactly the idea I talked about earlier]
47:50 If you're going to add something like regular expressions to the language ...
they should have some operators of their own. That's a perfect opportunity for
operator overloading
48:07 If you're going to add features to the language, like regular expressions or so [..]
there is well-established syntax for this from other languages.
48:40 ...or range operators. Lots of languages have range operators these days.
Really it's just a function call with two different operands. [..]
You're not trying to be clever
All you're trying
to do is make it natural to use features that exist in many of other languages.
The thing about Swift is you don't have to add syntax to the language to do it.
Because it's so malleable.
If you're not adding a feature, like I'm adding regular expressions to the language.
If you're not doing that, don't try to get clever. Consider the features as existing
for the benefit of the expansion of the language, so that future features look natural
in it
and not bolted on even though technically everything is in a library. Don't think of
it as in my end user code I'm going to come up with symbols that combine my types in
novel ways, because what are you even doing there?
50:17 if you have a language like this, you need new syntax and new behavior to
make it feel natural. [new behavior strings array] and it has the whole struct thing. The
basics of the language, the most basic things you can do, have to be different,
look different and behave different for a modern language.
51:52 "using operator overloading to add features to the language" [again, not actually true]
The interesting thing about this idea of a boundary between "language things" and "user things" is
that it does not align with the "operators" and "named operators" in Swift, but apparently it still
feels like it does, so we "extending the language" is seen as roughly equivalent to "adding
some operators", with all the sound caveats that apply.
In fact, going back to Matt Thompson's article from above, it is kind of odd that he talks
about exponentiation operator as missing from the language, when if fact the operation is
available in the language. So if the operation crosses the boundary from function to
operator, then and only then does it become part of the language.
In Smalltalk, on the other hand, the boundary has disappeared from view. It still exists in the
form of primitives, but those are well hidden all over the class hierarchy and not something
that is visible to the developer. So in addition to having infix notation available for
named operations, Smalltalk doesn't have the notion of something being "part of the language"
rather than "just the library" just because it uses non-sensical characters. Everything
is part of the library, the library is the language and you can use names or special
characters as appropriate, not because of asymmetries in the language.
And that's why operator overloading is a a thing even in languages like Swift, whereas it
is a non-event in Smalltalk.
I recently stumbled on Rob Napier's explanation of the map
function in Swift. So I am reading along yadda yadda when suddenly I wake up and
my eyes do a double take:
After years of begging for a map function in Cocoa [...]
Huh? I rub my eyes, probably just a slip up, but no, he continues:
In a generic language like Swift, “pattern” means there’s a probably a function hiding in there, so let’s pull out the part that doesn’t change and call it map:
Not sure what he means with a "generic language", but here's how we would implement a map function in Objective-C.
#import <Foundation/Foundation.h>
typedef id (*mappingfun)( id arg );
static id makeurl( NSString *domain ) {
return [[[NSURL alloc] initWithScheme:@"http" host:domain path:@"/"] autorelease];
}
NSArray *map( NSArray *array, mappingfun theFun )
{
NSMutableArray *result=[NSMutableArray array];
for ( id object in array ) {
id objresult=theFun( object );
if ( objresult ) {
[result addObject:objresult];
}
}
return result;
}
int main(int argc, char *argv[]) {
NSArray *source=@[ @"apple.com", @"objective.st", @"metaobject.com" ];
NSLog(@"%@",map(source, makeurl ));
}
This is less than 7 non-empty lines of code for the mapping function, and took me less
than 10 minutes to write in its entirety, including a trip to the kitchen for an
extra cookie, recompiling 3 times and looking at the qsort(3) manpage
because I just can't remember C function pointer declaration syntax (though it took
me less time than usual, maybe I am learning?). So really, years of "begging" for
something any mildly competent coder could whip up between bathroom breaks or
during a lull in their twitter feed?
Or maybe we want a version with blocks instead? Another 2 minutes, because I am a klutz:
#import <Foundation/Foundation.h>
typedef id (^mappingblock)( id arg );
NSArray *map( NSArray *array, mappingblock theBlock )
{
NSMutableArray *result=[NSMutableArray array];
for ( id object in array ) {
id objresult=theBlock( object );
if ( objresult ) {
[result addObject:objresult];
}
}
return result;
}
int main(int argc, char *argv[]) {
NSArray *source=@[ @"apple.com", @"objective.st", @"metaobject.com" ];
NSLog(@"%@",map(source, ^id ( id domain ) {
return [[[NSURL alloc] initWithScheme:@"http" host:domain path:@"/"] autorelease];
}));
}
Of course, we've also had collect for a good decadeorso, which turns the client code into the following,
much more readable version (Objective-Smalltalk syntax):
NSURL collect URLWithScheme:'http' host:#('objective.st' 'metaobject.com') each path:'/'.
As I wrote in my previous post, we seem to be regressing to a mindset about computer
languages that harkens back to the days of BASIC, where everything was baked into the
language, and things not baked into the language or provided by the language vendor do not exist.
Rob goes on the write "The mapping could be performed in parallel [..]", for example like parcollect? And then "This is the heart of good functional programming." No. This is the heart of good programming.
Having processed that shock, I fly over a discussion of filter (select) and stumble over
the next whopper:
It’s all about the types
Again...huh?? Our map implementation certainly didn't need (static) types for the list, and
all the Smalltalkers and LISPers that have been gleefully using higher order
techniques for 40-50 years without static types must also not have gotten the memo.
We [..] started to think about the power of functions to separate intent from implementation. [..] Soon we’ll explore some more of these transforming functions and see what they can do for us. Until then, stop mutating. Evolve.
All modern programming separates intent from implementation. Functions are a
fairly limited and primitive way of doing so. Limiting power in this fashion can be
useful, but please don't confuse the power of higher order programming with the
limitations of functional programming, they are quite distinct.
I just took my car to its biennial TüV inspection and apart from the tires that had simply
worn out everything was A-OK, nothing wrong at all. Kind of surprising for a 7 year old
mechanical device that has been used: daily commute from Mountain View to Oakland, tight
cornering in the foothills, shipped across the Atlantic twice and now that it is back in its
native country, occasional and sometimes prolonged sprints at 200 km/h. All that with not all
that much maintenance, because the owner is not exactly a car nut.
Cars used to not be nearly this reliable, and getting there wasn't easy, it took the
industry both plenty of time and a lot of effort. It's not that the engineers
didn't know how to build reliable cars, but making them reliable and keeping them
affordable and still allowing car companies to turn a profit, that
was hard.
One particular component is the alternator belt, which had to be changed so frequently
that engine compartments were specially designed to make the belt easily accessible.
That's no longer the case, and the characteristic screeching sound of a worn belt
is one that I haven't heard in a long time.
My late dad, who was in the business, told me how it went down, at least at Volkswagen.
As other problems had been whittled away over the decades, alternator belts were becoming
a real issue on the reliability reports compiled by motoring magazines, and the engineers
were tasked with the job of fixing the problem. And fix it they did: they came up with
a design that would "never" break or wear out, and no I don't know the details of how
that was supposed to work.
Problem was: it was a tad expensive. Much more expensive than the existing solution
and simply too expensive for the price bracket they were aiming for (this may seem
odd to outsiders considering the total cost of a car, but pennies matter). Which of course
was one reason why they had put up with unreliable belts for so long. Then word came in that
the Japanese had solved the problem as well, and were offering it on their cheap(er)
models. Next auto-show, they went to the both of one of those Japanese companies
and popped the hood.
The engineers scoffed: the design the Japanese was cheaper because it was much, much
more primitive than the one they had come up with, and it would, in fact, also wear
out much more quickly. But exactly how much more quickly would it wear out? In other
words, what was the expected lifetime of this cheaper, inferior alternator belt design?
About the expected lifetime of the car.
Ahh. As far as I can tell, the Japanese design or variants thereof conquered the world. I can't
recall the last time I heard the screech of a worn out belt, engine compartments
these days are not designed with accessibility in mind and cars are still affordable,
although changing the belt if it does break will cost more in labor because of the
less accessible placement.
What do alternator belts have to do with software development? Probably nothing, but
to me at least, the situation reminds me of the one I write about in The Safyness of Static Typing. I am actually with those commenters who scoffed at the idea that the safety
benefit of static typing is only around 2%, because theoretically having a tight specification
of possible values checked at compile-time absolutely should bring a greater
benefit.
For example, when static typing and protocols were introduced to Objective-C, I absolutely
expected them to catch my errors, so I was quite surprised when it turned out that in practice they didn't: because
I could actually compile/run/test my code without having to specify static types, by the time
I added static types the code simply no longer had type errors, because the vast majority
of those were caught by running it. The dynamic safety also
helped, because instead of a random crash, I got a nice clean error message
"object abc doesn't understand message xyz".
My suspicion is that although dynamic typing and the practices that go with it may only be,
let's say, 50% as good at catching type errors as a good static type system, they are
actually 98% effective at catching real world type errors. So if static type systems
are twice as good, they would be 196% effective at catching real world type errors, which
just like the perfect, german-engineered alternator belts, is simply more than is
actually needed (96% more with my hypothetical numbers).
There are obviously other factors at play, but I think this may account for a good part of
the perceived discrepancy.
What do you think? Comments welcome here or on Hacker News.
Objective-Smalltalk is now getting into a very nice virtuous cycle of
being more useful, therefore being used more and therefore motivating changes
to make it even more useful. One of the recent additions was autocomplete,
for both the tty-based and the GUI based REPLs.
I modeled the autocomplete after the one in bash and other Unix shells:
it will insert partial completions without asking up the point that they
become ambiguous. If there is no unambiguous partial completion, it
displays the alternatives. So a usual sequence is <TAB> -> something
is inserted <TAB> again -> list is displayed, type one character to disambiguate, <TAB> again and so on. I find that I get to my
desired result much quicker and with fewer backtracks than with the
mechanism Xcode uses.
Fortunately, I was able to wrestle NSTextView's
completion mechanism (in ShellView borrowed from
the excellent FSCript) to provide these semantics rather than the
built in ones.
Another cool thing about the autocomplete is that it is very precise,
unlike for example FScript which as far as I can tell just offers all
possible symbols.
How can this be, when Objective-Smalltalk is (currently) dynamically
typed and we all know that good autocomplete requires static types?
The reason is simply that there is one thing that's even better
than having the static types available: having the actual objects
themselves available!
The two REPLs aren't just syntax-aware, they also evaluate the
expression as much as needed and possible to figure out what
a good completion might be. So instead of having to figure
out the type of the object, we can just ask the object what
messages it understands. This was very easy to implement,
almost comically trivial compared to a full blown static type-system.
So while static types are good for this purpose, live objects are
even better! The Self team made a similar discovery when they
were working on their optimizing compiler, trying both static
type inference and dynamic type feedback. Type feedback was
both simpler and performed vastly better and is currently used
even for optimizing statically typed languages such as Java.
Finally, autocomplete also works with Polymorphic Identifiers, for
example file:./a<TAB> will autocomplete files
in the current directory starting with the letter 'a' (and just
fi<TAB> will autocomplete to the file:
scheme). Completion is scheme-specific, so any schemes you add
can provide their own completion logic.
Like all of Objective-Smalltalk, this is still a work in progress:
not all syntactic constructs support completions, for example
Polymorphic Identifiers don't support complex paths and there
is no bracket matching. However, just like Objective-Smalltalk,
what is there is quite useful and often already better what else
is out there in small areas.
Let me explain: even though you might assume that all those objects are actually going to be DataPoint objects, there’s no actual guarantee that they will actual be DataPoint objects at runtime. Casting them only satisfies your hunger for type safety, but nothing else really.
More importantly, it only seems to satisfy your hunger for type safety,
it doesn't actually provide any. It's less nutritious than sugar water in
that respect, not even calories, never mind the protein, fiber, vitamins and
other goodness. More like a pacifier, really, or the product of a
cargo cult.
In my recent post on Cargo Cult Typing, I mentioned a
concept I called the id subset. Briefly, it is the subset of
Objective-C that deals only with object pointers, or id's.
There has been some misunderstanding that I am opposed to types. I am
not, but more on that another time.
One of the many nice properties of the (transitive) id subset is that it
is dynamically (memory) safe, just like Smalltalk. That is, as long as all arguments and return values
of your message are objects, you can never dereference a pointer incorrectly,
the worst that can happen is that you get a "Message not understood" that can
be caught and handled by the object in question or raised as an exception.
The reason this is safe is that objc_msgSend() will make sure that methods
will only ever be invoked on objects of the correct class, no matter what the
(possibly incorrect, or unavailable) static type says.
So no de-referencing an incorrect pointer, no scribbling over random bits
of memory.
In fact, this is the vaunted "pointer safety" that John Siracusa says requires
ditching native compiled languages like Objective-C for VM based languages. The idea
that a VM with an interpreter or a JIT was required for pointer safety
was never true, of course, and it's interesting that both Google and
Microsoft are turning to Ahead of Time (AOT) compilation in their newest
SDKs, for performance reasons.
Did someone mention "performance"? :-)
Another nice aspect of the id subset is that it makes reflective code
a lot simpler. And simplicity usually also translates to speed. How
much speed? Apple's NSInvocation class has to deal with
interpreting C type information at runtime to then construct proper stack
frames dynamically for all possible C types. I think it uses libffi, though
it may be some equivalent library. This is slow, around 340.1ns
per message send on my 13" MBPR. By restricting itself to the id subset,
my own MPWFastInvocation class's dispatch is
much simpler, just a switch invoking objc_msgSend() with
a different number of arguments.
The simplicity of MPWFastInvocation also pays off in
speed: 6.2ns per message-send on the same machine. That's 50 times
faster than NSInvocation and only 2-3x slower than
a normal message send. In fact, once you're that close, things like
IMP-caching (4 ns) start to make sense, especially since they can
be hidden behind a nice interface. Using a C Macro and the IMP
stashed in a public instance var takes the time down to 3 ns, making
the reflective call via an object effectively as fast as the
non-reflective code emitted by the compiler. Which is nice, because
it makes reflective techniques much more feasible for wider varieties
of code, which would be a good thing.
The speed improvement is not because MPWFastInvocation is better
than NSInvocation, it is decidedly not, it is because it is solving
a much, much simpler problem. By sticking to the safe id subset.
I like bindings. I also like Key Value Observing. What they do is undeniably cool: you do some initial setup, and presto: magic! You change a value over here, and another
value over there changes as well. Action at a distance. Power.
What they do is also undeniably valuable. I'd venture that nobody actually
likes writing state
maintenance and update code such as the following: when the user clicks this button, or finishes entering
text in that textfield, take the value and put it over here. If the underlying
value changes, update the textfield. If I modify this value, notify
these clients that the value has changed so they can update themselves accordingly.
That's boring. There is no glory in state maintenance code, just potential for
failure when you screw up something this simple.
Finally, their implementation is also undeniably cool: observing an attribute
of a generic
object creates a private subclass for that object (who says we can't do
prototype-based programming in Objective-C?), swizzles the object's
class pointer to that private subclass and then replaces the attribute's
(KVO-compliant) accessor methods with new ones that hook into the
KVO system.
Despite these positives, I have actively removed bindings code from
projects I have worked on, don't use either KVO or bindings myself and
generally recommend staying away from them. Why on earth would I
do that?
Excursion: Constraint Solvers
Before I can answer that question, I have to go back a little and talk about
constraint solvers.
The idea of setting up relationships once and then having the system maintain them
without manually shoveling values back and forth is not exactly new, the first variant
I am aware of was Sketchpad,
Ivan Sutherland's PhD Thesis from 1961/63 (here with narration by Alan Kay):
I still love Ivan's answer to the question as to how he could invent computer graphics,
object orientation and constraint solving in one fell swoop: "I didn't know it was hard".
The first system I am aware of that integrated constraint solving with an object-oriented
programming language was ThingLab, implemented on top of Smalltalk by Alan Borning at Xerox PARC around 1978 (where else...):
While the definition
of a paths is simple, the idea behind it has proved quite powerful and has been essential
in allowing constraint- and object-oriented metaphors to be integrated. [..] The notion
of a path helps strengthen [the distinction between inside and outside of an object] by
providing a protected way for an object to provide external reference to its parts and
subparts.
Yes, that's a better version of KVC. From 1981.
Alan Borning's group at the University of Washington continued working on constraint solvers
for many years, with the final result being the Cassowary linear constraint solver (based on the simplex
algorithm) that was picked up by Apple for Autolayout. The papers on Cassowary and
constraint hierarchies should help with understanding why Autolayout does what it does.
A simpler form of constraints are one-way dataflow constraints.
A one-way, dataflow constraint is an equation of the form y = f(x1,...,xn) in which the formula on the right side
is automatically re-evaluated and assigned to the variable y whenever any variable xi.
If y is modified from
outside the constraint, the equation is left temporarily unsatisfied, hence the attribute “one-way”. Dataflow constraints are recognized as a powerful programming methodology in a variety of contexts because of their versatility and simplicity. The most widespread application of dataflow constraints is perhaps embodied by spreadsheets.
The most important lessons they found were the following:
constraints should be allowed to contain arbitrary code that is written in the underlying toolkit language and does not require any annotations, such as parameter declarations
constraints are difficult to debug and better debugging tools are needed
programmers will readily use one-way constraints to specify the graphical layout of an application, but must be carefully and time-consumingly trained to use them for other purposes.
However, these really are just the headlines, and particularly for Cocoa programmers
the actual reports are well worth reading as they contain many useful pieces of
information that aren't included in the summaries.
Back to KVO and Cocoa Bindings
So what does this history lesson about constraint programming have to do with KVO
and Bindings? You probably already figured it out: bindings are one-way
dataflow constraints, specifically with the equation limited to y = x1.
more complex equations can be obtained by using NSValueTransformers. KVO
is more of an implicit invocation
mechanism that is used primarily to build ad-hoc dataflow constraints.
The specific problems of the API and the implementation have been documented
elsewhere, for example by Soroush Khanlou and Mike Ash, who not only suggested and
implemented improvements back in 2008, but even followed up on them in 2012. All
these problems and workarounds
demonstrate that KVO and Bindings are very sophisticated, complex and error prone
technologies for solving what is a simple and straightforward task: keeping
data in sync.
To these implementation problems, I would add performance: even
just adding the willChangeValueForKey: and didChangeValueForKey:
message sends in your setter (these are usually added automagically for you) without triggering any notifications makes that setter 30 times slower (from 5ns to
150ns on my computer) than a simple setter that just sets and retains the object.
Actually having that access trigger a notification takes the penalty to a factor of over 100
( 5ns vs over 540ns), even when there is only a single observer. I am pretty sure
it gets worse when there are lots of observers (there used to be an O(n^3)
algorithm in there, that was fortunately fixed a while ago). While 500ns may
not seem a lot when dealing with UI code, KVO tends to be implemented at
the model layer in such a way that a significant number of model data accesses
incur at least the base penalties. For example KVO notifications were one of the primary
reasons for NSOperationQueue's somewhat anemic performance back when
we measured it for the Leopard release.
Not only is the constraint graph not available at run time, there is also no
direct representation at coding time. All there is either code or IB settings
that construct such a graph indirectly, so the programmer has to infer the
graph from what is there and keep it in her head. There are also no formulae, the best
we can do are ValueTransformers and
keyPathsForValuesAffectingValueForKey.
As best as I can tell, the reason for this state of affairs is that there simply
wasn't any awareness of the decades of
research and practical experience with constraint solvers at the time (How
do I know? I asked, the answer was "Huh?").
Anyway, when you add it all up, my conclusion is that while I would really,
really, really like a good constraint solving system (at least for spreadsheet
constraints), KVO and Bindings are not it. They are too simplistic, too
fragile and solve too little of the actual problem to be worth the trouble.
It is easier to just write that damn state maintenance code, and infinitely
easier to debug it.
I think one of the main communication problems between advocates for and
critics of KVO/Bindings is that the advocates are advocating more for
the concept of constraint solving, whereas critics are critical of the
implementation. How can these critics not see that despite a few flaws,
this approach is obviously
The Right Thing™? How can the advocates not see the
obvious flaws?
Functional Reactive Programming
As far as I can tell, Functional Reactive Programming (FRP) in general and Reactive
Cocoa in particular are another way of scratching the same itch.
[..] is an integration of declarative [..] and imperative object-oriented programming. The primary goal of this integration is to use constraints to express relations among objects explicitly -- relations that were implicit in the code in previous languages.
Sounds like FRP, right? Well, the first "[..]" part is actually "Constraint Imperative Programming" and the second is "constraints",
from the abstract of a 1994 paper. Similarly, I've seen it stated that FRP is like a spreadsheet.
The connection between functional programming and constraint programming is also well
known and documented in the literature, for example the experience report above states the
following:
Since constraints are simply functional programming dressed up with syntactic sugar, it should not be surprising that 1) programmers do not think of using constraints for most programming tasks and, 2) programmers require extensive training to overcome their procedural instincts so that they will use constraints.
However, you wouldn't be able to tell that there's a relationship there from reading
the FRP literature, which focuses exclusively on the connection to functional
programming via functional reactive animations and Microsoft's Rx extensions. Explaining and particularly motivating FRP this way has the
fundamental problem that whereas functional programming, which is per definition
static/timeless/non-reactive, really needs something to become interactive,
reactivity is already inherent in OO. In fact, reactivity is the quintessence of
objects: all computation is modeled as objects reacting to messages.
So adding reactivity to an object-oriented language is, at first blush, non-sensical
and certainly causesconfusion when explained this way.
I was certainly confused, because until I found this one
paper on reactive imperative programming,
which adds constraints to C++ in a very cool and general way,
none of the documentation, references or papers made the connection that seemed so
blindingly obvious to me. I was starting to question my own sanity.
Architecture
Additionally, one-way dataflow constraints creating relationships between program variables
can, as far as I can tell, always be replaced by a formulation where the dependent
variable is simply replaced by a method that computes the value on-demand. So
instead of setting up a constraint between point1.x and point2.x,
you implement point2.x as a method that uses point1.x to
compute its value and never stores that value. Although this may evaluate more
often than necessary rather than memoizing the value and computing just once, the
additional cost of managing constraint evaluation is such that the two probably
balance.
However, such an implementation creates permanent coupling and requires dedicated
classes for each relationship. Constraints thus become more of an architectural
feature, allowing existing, usually stateful components to be used together without
having to adapt each component for each individual ensemble it is a part of.
Panta Rhei
Everything flows, so they say. As far as I can tell, two different
communities, the F(R)P people and the OO people came up with very similar
solutions based on data flow. The FP people wanted to become more reactive/interactive,
and achieved this by modeling time as sequence numbers in streams of values, sort
of like Lucid or other dataflow languages.
The OO people wanted to be able to specify relationships declaratively and have
their system figure out the best way to satisfy those constraints, with
a large and useful subset of those constraints falling into the category of
the one-way dataflow constraints that, at least to my eye, are equivalent
to FRP. In fact, this sort of state maintenance and update-propagation
pops up in lots of different places, for example makefiles or other
build systems, web-server generators, publication workflows etc. ("this
OmniGraffle diagram embedded as a PDF into this LaTeX document that
in turn becomes a PDF document" -> the final PDF should update
automatically when I change the diagram, instead of me having to
save the diagram, export it to PDF and then re-run LaTeX).
What's kind of funny is that these two groups seem to have converged
in essentially the same space, but they seem to not be aware of
each other, maybe they are phase-shifted with respect to each other?
Part of that phase-shift is, again, communication. The FP guys
couch everything in must destroy all humans er state rethoric,
which doesn't do much to convince OO guys who know that for most
of their programs, state isn't an implementation detail but fundamental
to their applications. Also practical experience does not support the
idea that the FP approach is obvious:
Unfortunately, given the considerable amount of time required to train students to use constraints in a non-graphical manner, it does not seem reasonable to expect that constraints will ever be widely used for purposes other than graphical layout. In retrospect this result should not have been surprising. Business people readily use constraints in spreadsheets because constraints match their mental model of the world. Similarly, we have found that students readily use constraints for graphical layout since constraints match their mental model of the world, both because they use constraints, such as left align or center, to align objects in drawing editors, and because they use constraints to specify the layout of objects in precision paper sketches, such as blueprints. However, in their everyday lives, students are much more accustomed to accomplishing tasks using an imperative set of actions rather than using a declarative set of actions.
Of course there are other groups hanging out in this convergence zone, for example the
Unix folk with their pipes and filters. That is also not too surprising if
you look at the history:
So, we were all ready. Because it was so easy to compose processes with shell scripts. We were already doing that. But, when you have to decorate or invent the name of intermediate files and every function has to say put your file there. And the next one say get your input from there. The clarity of composition of function, which you perceived in your mind when you wrote the program, is lost in the program. Whereas the piping symbol keeps it. It's the old thing about notations are important.
I think the familiarity with Unix pipes also increases the itch: why can't I have
that sort of thing in my general purpose programming language? Especially when
it can lead to very concise programs, such as the Quartz-like graphics subsystem
Gezira written in
under 400 lines of code using the Nile dataflow language.
Moving Forward
I too have heard the siren sing.
I also think that a more spreadsheet-like programming model would not just make my life
as a developer easier, it might also make software more approachable for end-user adaptation and tinkering,
contributing to a more meaningful version of open source. But how do we get there?
Apart from a reasonable implementation and better debuggingsupport, a new system would need much tighter
language integration. Preferably there would be a direct syntax for expressing constraints
such as that available in constraint imperative programming languages or constraint extensions to existing
languages like
Ruby or JavaScript.
This language support should be unified as much as
possible between different constraint systems, not one mechanism for Autolayout and a
completely different one for Bindings.
Supporting constraint programming has always been one of the goals of my Objective-Smalltalk project, and so far that has informed the
PolymorphicIdentifiers that support a uniform interface for data backed by different types of
stores, including one or more constraint stores supporting cooperating solvers, filesystems or web-sites. More needs
to be done, such as extending the data-flow connector hierarchy to conceptually integrate
constraints. The idea is to create a language that does not actually include constraints
in its core, but rather provides sufficient conceptual, expressive and implementation
flexibility to allow users to add such a facility in a non-ad-hoc way so that it is
fully integrated into the language once added. I am not there yet, but all the results
so far are very promising. The architectural focus of Objective-Smalltalk also ties
in well with the architectural interpretation of constraints.
There is a lot to do, but on the other hand I think the payback is huge, and there is
also a large body of existing theoretical,
practical and empirical groundwork to fall back on, so I think the task is doable.
Your feedback, help and pull requests would be very much appreciated!
After thinking about the id subset and being pointed to WebScript, Brent Simmons imagines a scripting language. I have to admit I have been imagining pretty much the same language...and at some
time decided to stop imagining and start building Objective-Smalltalk:
Peer of Objective-C: objects are Objective-C objects, methods are Objective-C methods,
added to the runtime and indistinguishable from the outside.
"You can subclass UIViewController, or write a category on it."
The example is from the site, it was copied
from an actual program. As you can see, interoperability with the C parts of
Objective-C is still necessary, but not bothersome.
This example was also copied from an actual small educational game that was
ported over from Flash.
You also get Higher Order Messaging, Polymorpic Identifiers etc.
Works with the toolchain: this is a a little more tricky, but I've made
some progress...part of that is an llvm based native compiler, part is
tooling that enables some level of integration with Xcode, part is
a separate toolset that has comparable or better capabilities.
While Objective-Smalltalk would not require shipping source code with your applications,
due to the native compiler, it would certainly allow it, and in fact my own
BookLightning imposition program
has been shipping with part of its Objective-Smalltalk source hidden its Resources
folder for about a decade or so. Go ahead, download it, crack it open and have
a look! I'll wait here while you do.
Did you have a look?
The part that is in Smalltalk is the distilled (but very simple) imposition algorithm
shown here.
What this means is that any user of BookLightning could adapt it to suit their needs,
though I am pretty sure that none have done so to this date. This is partly due to
the fact that this imposition algorithm is too limited to allow for much variation,
and partly due to the fact that the feature is well hidden and completely unexpected.
There are two ideas behind this:
Open Source should be more about being able to tinker with well-made
apps in useful ways, rather than downloading and compiling gargantuan and
incomprehensible tarballs of C/C++ code.
There is no hard distinction between programming and scripting. A
higher level scripting/programming language would not just make developer's
jobs easier, it could also enable the sort of tinkering and adaptation that
Open Source should be about.
I don't think the code samples shown above are quite at the level needed to really
enable tinkering, but maybe they can be a useful contribution to the discussion.
The feedback was, effectively: "This code is incorrect, it is missing a return type". Of course, the code isn't incorrect in the least bit, the return type is id, because that is the default type, and in fact, you will see this style in both Brad Cox's book:
and the early NeXTStep documentation:
Having a default type for objects isn't entirely surprising, because at that time id was not just the default type, it was the only type available for objects, the optional static typing for objects wasn't introduced into Objective-C until later. In addition the template for Objective-C's object system was Smalltalk, which doesn't use static types, you just use variable names.
Cargo-cult typing
So while it is possible (and apparently common) to write -(id)objectAtIndex:(NSUInteger)anIndex, it certainly isn't any more correct. In fact, it's
worse, because it is just syntactic noise [1][2], although it is arguably even worse than what Fowler describes because it isn't actually mandated by
the language, the noise is inflicted needlessly.
And while we could debate as to whether it is better or not to write things that are redundant
syntactic noise, we could also not, as that was settled almost 800 years ago: entia non sunt multiplicanda praeter necessitatem. You could also say KISS or "when in doubt, leave it out", all of which just
say the the burden of proof is on whoever wants to add the redundant pieces.
What's really odd about this phenomenon is that we really don't gain anything from typing
out these explicit types, the code certainly doesn't become more readable. It's as if
we think that by following the ritual of explicitly typing out a type, we made the
proper sacrifice to the gods of type-safety and they will reward us with correctness.
But just like those Pacific islanders that built wooden planes, radios and control
towers, the ritual is empty, because it conveys no information to the type system,
or the reader.
The id subset
Now, I personally don't really care whether you put in a redundant (id)
or not, I certainly have been reading over it (and not even really noticing) for
my last two decades of Objective-C coding. However, the mistaken belief that it
has to be there, rather than this is a personal choice you make, does worry me.
I think the problem goes a little deeper than just slightly odd coding styles, because it seems to be part and parcel of a drive towards making Objective-C look like an explicitly statically typed language along the lines of C++ or maybe Java,
with one of the types being id. That's not the case: Objective-C
is an optionally statically typed language. This means that you
may specify type information if you want to, but you generally
don't have to. I also want the emphasize that you can at best get Objective-C
to look like such a language, the holes in the type system are way too big for
this to actually gain much safety.
Properties started this trend, and now the ARC variant of the language turns what used to be warnings about unknown selectors needlessly into hard compiler errors.
Of course, there are some who plausibly argue that this always should have been an error,
or actually, that it always was an error, we just didn't know about it.
That's hogwash, of course. There is a subset of the language, which I'd like
to call the id subset, where all the arguments and returns are object
pointers, and for this it was always safe to not have additional type information,
to the point where the compiler didn't actually have that additional type information.
You could also call it the Smalltalk subset.
Another thing that's odd about this move to rigidify Objective-C in the face of
success of more dynamic languages is that we actually have been moving into the
right direction at the language base-level (disregarding the type-system): in general programming style, with new syntax support
for object literals and subscripting, SmallInteger style NSNumbers modern
Objective-C consists much more of pure objects than was traditionally the case.
And as long as we are dealing with pure objects, we are in the id subset.
A dynamic language
What's great about the id subset is that it makes incremental, explorative
programming very easy and lots of fun, much like other dynamic languages
such as Smalltalk, Python or Ruby.
(Not entirely like them, due to the need to compile to native code, but compilers are fast these
days and there are possible fixes such as Objective-Smalltalk.)
The newly enforced rigidity is starting to make explorative programming in Objective-C much
harder, and a lot less fun. In fact, it feels much more like C++ or Java and much less
like the dynamic language that it is, and in my opinion is the wrong direction: we should
be making our language more dynamic, and of course that's what I've been doing. So while I wouldn't agree with that tradeoff even if
it were true, the fact is that we aren't actually
getting static type safety, we are just getting a wood prop that will not fly.
Discussion on Hacker News.
UPDATE: Inserted a little clarification that I don't care about bike-shedding your code
with regard to (id). The problem is that people's mistaken belief both that and why it has to be there is symptomatic of that deeper trend I wrote about.
Actually: no it isn't, Transact-SQL got the honors. Apart from the obvious question, "Transact-Who?", it really should have been Objetive-C, because Tiobe readjusted the index mid-year in a way that resulted in a drop of 0.5% for the popular languages, which is fine, but without readjusting the historical data! Which is...not...especially if you make judgements based on relative performance.
In this case, Transact-SQL beat Objective-C by 0.17%, far less than the roughly 0.5% drop suffered by Objective-C mid-year. So Objective-C would have easily done the
hat-trick, but I guess Tiobe didn't want that and rigged the game to make sure
it doesn't happen.
Not that it matters...
UPDATE: I contacted Tiobe and they confirmed, both the lack of rebaselining and that Objective-C would likely have won an unprecedented third time in a row.
It's been a little over half a year since I first made my pleasant Objective-C drawing contextpublic, and I haven't been idle. In the process
of retrofitting my own code to use MPWDrawingContext and adding more and more graphics (for example,
I now do my icons in code), I've discovered a lot about making drawing with code a more pleasant
experience.
Blocks
Blocks seem to be a really wonderful match for a graphics context, and most of the changes involve
blocks in some way.
Bracketing operations such as gsave/grestore now have block versions, so the Objective-C block structure reflects the nesting:
This is somewhat more compact than the plain code, which for correctness should also have a @try/@finally block wrapped around the basic drawing so exceptions don't mess up the graphics state stack.
Again, this seems a little clearer than having to explicitly set and unset, makes it harder to miss the end of the bracket when moving code around and remains exception-safe.
You can create an object for later drawing by sending the -laterWithSize:(NSSize)size content:(DrawingBlock)commands message. For example, here is a simple diamond shape:
We can now draw this anywhere we want, and at any scale or orientation, using the -drawImage: message.
[context drawImage:diamond];
You also have layerWitSize:content: and bitmapWithSize:content: messages if you want to specifically use
CGLayer or CGImage instead, but using laterWithSize:content: preserves maximum quality, and it
will automatically switch to a CGLayer when rendering to a PDF context in order to minimize
PDF file size.
Patterns
I talked about patterns earlier. What I didn't mention then was that this is just the ability to use a
stored set of drawing commands (see previous section) as a color:
[context setColor:diamond];
I am not going to post the comparison to plain CG here, you can read it in the original Apple documentation.
I should note that this currently works for colored patterns, not for uncolored patterns, due to the
fact that I haven't yet exposed color spaces. The basic process will be very similar.
Polymorphic object arguments
Path construction and graphics state messages with point arguments are now available in a version that
takes a single object argument, in addition to the format with anonymous float arguments (moveto:(float)x :(float)y).
moveto:
lineto:
translate:
scale:
The single argument can be an Objective-C array:
[context moveto:@[ @10, @20]];
Alternatively, any custom object that responds to count and either objectAtIndex:, (float)realAtIndex: or getReals:(float*)buffer length:(int)maxLen can be used. The scale: message can also take a single NSNumber and will treat that as uniform x and y scale.
Linecap parameters
Linecap parameters can now be set using distinct message:
setlinecapRound
setlinecapButt
setlinecapSquare
Having multiple messages rather than a single message with a parameter probably seems odd, but it actually
reduces the number of names involved, and these names are nicely scoped to this context. The constant strings or enums that are typically used have global scope and therefore tend to need ugly and hard-to-remember
prefixes:
[context setlinecapRound];
vs.
[context setLinecap: kCGContextLinecapRound];
Future
Another reason to be as purely message-based as possible is that it makes bridging to other
languages easier, for example for interactive drawing environments: Creating a badge (youtube).
I've also started experimenting with other outputs, for example creating a version of the same badge
composed of CALayer objects using the same drawing commands. Other output should follow, for
example web with SVG or HTML 5 Canvas or direct OpenGL textures.
I also want to finally add image processing operations both stand-alone and as chained drawing
contexts, as well as getting more complex text layout options in there.
The TIOBE Index shows
Objective-C as "Language of the year 2012". As it also won the honor in 2011, this now makes it only the 2nd language to
win the award twice (Python won 2007 and barely edged out Objective-C in 2010), and the only one to win it twice in a row.
Although this surge in popularity is certainly largely due to the popularity of the iOS ecosystem
(iPhone, iPad, AppStore), the fact that it continues despite Apple loosening its policies and
alternatives popping up suggests that there may be more going on: maybe developers are discovering
that Objective-C is a pretty fun and productive language, warts and all?
It'll be interesting to see wether Objective-C has now peaked, as Tiobe predicts, or wether it
manages to expand back into other areas that could benefitfromitsqualities.
As last year, table and graphic reproduced here because Tiobe doesn't appear to keep an archive:
