A dynamic I see playing out again and again when it comes to software is the tension between incrementalism and radical change. On the one hand, there is a justified sense, backed by a lot of experience, that just tweaking what we have really doesn't cut it, that it's just rearranging the deck chairs on the Titanic. We obviously need radical change.
On the other hand, radical change that assumes we need to throw away what we (think we) know doesn't really cut it either, and the problem of all
that existing software and the techniques and technology we used to create it isn't just the pragmatics of the situation, with huge investments
in code and know-how. The fact that we are actually capable of creating all this software means that the radical position of "throw it all away, it's
wrong" isn't really tenable. Yes, there is something wrong with it, but it cannot actually be completely wrong.
So we are faced with a dilemma: incremental change and radical change are both obviously right and both obviously wrong. And so we get a lot
of shouting at each other, a lot of "change", but not a whole lot of progress.
The only way out I see is that change has to be both radical while also including the status quo, and the only way I can see of achieving that is if
it is a generalisation, sort of like quantum mechanics generalised classical mechanics, superseding classical mechanics but still including it as a special case. (Or how circles were generalised to ellipses etc.)
One of the features that can be confusing about Objective-Smalltalk is that it actually has several
parts that are each significant on their own, so frequently will focus on just one of these (which is fine!), but without realising
that the other parts also exist, which is unfortunate as they are all valuable and complement each other. In fact, they can
be described as stages that are (logically) built on top of each other.
1. WebScript 2 / "Shasta"
Objective-C has always had great integration with other languages, particularly with a plethora of scripting languages, from Tcl to Python and
Ruby to Lisp and Scheme and their variants etc. This is due not just to the fact that the runtime is dynamic, but also that it is simple
and C-based not just in terms of being implemented in C, but being a peer to C.
However, all of these suffer from having two somewhat disparate languages, with competing object models, runtimes, storage strategies etc.
One language that did not have these issues was WebScript, part of WebObjects and essentially Objective-C-Script. The language was
interpreted, a peer in which you could even implement categories on existing Objective-C objects, and so syntactically compatible that often
you could just copy-paste code between the two. So close to the ideal scripting language for that environment.
However, the fact that Objective-C is already a hybrid with some ugly compromises means that these compromises often no longer make sense
at all in the WebScript environment. For example, Objective-C strings need an added "@" character because plain double quotes are already
taken by C strings, but there are no C strings in WebScripts. Primitive types like int can be declared, but are really objects,
the declaration is a dummy, a NOP. Square brackets for message sends
are needed in Objective-C to distinguish messages from the rest of the C syntax, but the that's also irrelevant in WebScript. And so on.
So the first stage of Objective-Smalltalk was/is to have all the good aspects of WebScript, but without the syntactic weirdness needed to
match the syntactic weirdness of Objective-C that was needed because Objective-C was jammed into C. I am not the only one who figured
out the obvious fact that such a language is, essentially, a variant of Smalltalk, and I do believe this pretty much matches what
Brent Simmons called Shasta.
Implementation-wise, this works very similarly to WebScript in that everything in the language is an object and gets converted to/from
primitives when sending or receiving messages as needed.
This is great for a much more interactive programming model than what we have/had (and the one we have seems to be deteriorating as we speak):
And not just for isolated fragments, but for interacting with and tweaking full applications as they are running:
2. Objective-C without the C
Of course, getting rid of the (syntactic) weirdnesses of Objective-C in our scripting language means that it is no longer (syntactically)
compatible with Objective-C. Which is a shame.
It is a shame because this syntactic equivalence between Objective-C and WebScript
meant that you could easily move code between them. Have a script that has become
stable and you want to reuse it? Copy and paste that code into an Objective-C
file and you're good to go. Need it faster? Same. Have some Objective-C code that
you want to explore, create variants of etc? Paste it into WebScript. Such a
smooth integration between scripting and "programming" is rare and valuable.
The "obvious" solution is to have a native AOT-compiled version of this scripting language and use it to replace Objective-C. Many if not
all other scripting languages have struggled mightily with becoming a compiled language, either not getting there at all or requiring JIT compilers of
enormous size, complexity, engineering effort and attack surface.
Since the semantic model of our scripting language ist just Objective-C, we know that we can AOT-compile this language with a fairly
straightforward compiler, probably a lot simpler than even the C/Objective-C compilers currently used, and plugging into the existing
toolchain. Which is nice.
The idea seems so obvious, but apparently it wasn't.
Everything so far would, taken together, make for a really nice replacement for Objective-C with a much more productive and, let's face it, fun
developer experience. However, even given the
advantages of a simpler language, smoothly integrated scripting/programming and instant builds, it's not really clear that yet another OO language is really sufficient, for example the Etoilé project
or the eero language never went anywhere, despite both being very nice.
3. Beyond just Objects: Architecture Oriented Programming
Ever since my Diplomarbeit, Approaches to Composition and Refinement in Object-Oriented Design back in 1997, I've been interested in Software Architecture
and Architecture Description Languages (ADLs) as a way of overcoming the problems we have when constructing larger pieces of software.
One thing I noticed very early is that the elements of an ADL closely match up with and generalise the elements of a programming language,
for example an object-oriented language: object generalises to component, message to connector. So it seemed that any specific pogramming
language is just a specialisation or instantiation of a more general "architecture language".
To explore this idea, I needed a language that was amenable to experimentation, by being both malleable enough as to allow a metasystem that
can abstract away from objects and messages and simple/small enough to make experimentation feasible.
A simple variant of Smalltalk would do the trick. More mature variants tend to push you towards building with what is there, rather
than abstracting from it, they "...eat their young" (Alan Kay).
So Objective-Smalltalk fits the bill perfectly as a substrate for architecture-oriented programming. In fact, its being built on/with
Objective-C, which came into being largely to connect the C/Unix world with the Smalltalk world, means it is already off to a good start.
What to build? How about not reinventing the wheel and simply picking the (arguably) 3 most successful/popular architectural styles:
OO (subsuming the other call/return styles)
Unix Pipes and Filters
REST
Again, surprisingly, at least to me, even these specific styles appear to align reasonably well with the elements we have in a programming language. OO is
already well-developed in (Objective-)Smalltalk, dataflow maps to Smalltalk's assignment operator, which needed to be made polymorphic anyway,
and REST at least partially maps to non-message identifiers, which also are not polymorphic in Smalltalk.
Having now built all of these abstractions into Objective-Smalltalk, I have to admit again to my surprise how well they work and work
together. Yes, it was my thesis, and yes, I can now see confirmation bias everywhere, but it was also a bit of a long-shot.
4. Architecture Oriented Metaprogramming
The architectural styles described above are implemented in frameworks and their interfaces hard-coded into the language implementation.
However, with three examples , it should now
be feasible to create linguistic support for defining the architectural styles in the language itself, allowing users to
define and refine their own architectural styles. This is ongoing work.
What now?
One of the key takeaways from this is that each stage is already quite useful, and probably a worthy project all by itself, it just gets Even Better™ with the addition of later stages. Another is that I need to get back to getting stage ready, as it wasn't actually needed for stage 3, at
least not initially.
2019 has been the year that I have started really talking about Objective-Smalltalk in earnest, because enough of the original vision is now
in place.
My first talk was at the European Smalltalk User Group's (ESUG) annual
conference in my old hometown
of Cologne: (pdf)
This year's ESUG was was my first since Essen in 2001, and it almost seemed like a bit of a
timewarp. Although more than half the talks were about Pharo, the subjects seemed mostly the
same as back when: a bit of TDD, a bit of trying to deal with native threads (exactly the same
issues I struggled with when I was doing the CocoaSqueak VM), a bit of 3D graphics that
weren't any better than 3D graphics in other environments, but in Smalltalk.
One big topic was getting large (and very profitable) Smalltalk code-bases running on
mobile devices such as iPhones. The top method was transpiling to JavaScript, another
translating the VM code to JavaScript and then having that run off-the-shelf images.
Objective-Smalltalk can also be put in this class, with a mix of interpretation
and native compilation.
My second talk, I was at Germany's oldest Mac conference, Macoun in Frankfurt. The videos
from there usually take a while, but here was a reaction:
Anyway, one aspect of those talks that I didn't dwell on is that the presentations
themselves were implemented in Objective-Smalltalk, in fact the definitions were
Objective-Smalltalk expressions, complex object literals to be precise.
What follows is an abridged version of the ESUG presentation:
controller := #ASCPresentationViewController{
#Name : 'ESUG Demo'.
#Slides : #(
#ASCChapterSlide {
#text : 'Objective-SmallTalk'.
#subtitle : 'Marcel Weiher (@mpweiher)'
} ,
#ASCBulletSlide{
#title : 'Objective-SmallTalk'.
#bullets : #(
'Embeddable SmallTalk language (Mac, iOS, Linux, Windows)',
'Objective-C framework (peer/interop)',
'Generalizes Objects+Messages to Components+Connectors',
'Enable composition by solving Architectural Mismatch',
)
} ,
#ASCBulletSlide{
#title : 'The Gentle Tyranny of Call/Return'.
#bullets : #(
'Feymnan: we name everything just a little wrong',
'Multiparadigm: Procedural, OO and FP!',
"Guy Steele: it's no longer about completion",
"Oscar Nierstrasz: we were told we could just model the domain",
"Andrew Black: good OO students antropmorphise the objects",
)
} ,
#ProgramVsSystem {
#lightIntensities : #( 0.2 , 0.7 )
} ,
#ASCSlideWithFigure{
#delayInSeconds : 5.0.
#title : 'Objects and Messages'.
#bullets : #(
'Objective-C compatible semantics',
'Interpreted and native-compiled',
'"C" using type annotations',
'Higher Order Messaging',
'Framework-oriented development',
'Full platform integration',
)
} ,
#ASCBulletSlide{
#title : 'Pipes and Filters'.
#bullets : #(
'Polymorphic Write Streams (DLS ''19)',
'#writeObject:anObject',
'Triple Dispatch + Message chaining',
'Asynchrony-agnostic',
'Streaming / de-materialized objects',
'Serialisation, PDF/PS (Squeak), Wunderlist, MS , To Do',
'Outlook: filters generalise methods?',
)
} ,
#ASCBulletSlide{
#title : 'In-Process REST'.
#bullets : #(
'What real large-scale networks use',
'Polymorphic Identifiers',
'Stores',
'Storage Combinators',
'Used in a number of applications',
)
} ,
#ASCBulletSlide{
#title : 'Polymorphic Identifiers'.
#bullets : #(
'All identifiers are URIs',
"var:hello := 'World!",
'file:{env:HOME}/Downloads/site := http://objective.st',
'slider setValueHolder: ref:var:celsius',
)
} ,
#ASCBulletSlide{
#title : 'Storage Combinators'.
#bullets : #(
'Onward! ''19',
'Combinator exposes + consumes REST interfaces',
'Uniform interface (REST) enables pluggability',
'Narrow, semantically tight interface enables intermediaries',
'10x productivity/code improvments',
)
} ,
#ImageSlide{
#text : 'Simple Composed Store'.
#imageURL : '/Users/marcel/Documents/Writing/Dissertation/Papers/StorageCombinators/disk-cache-json-aligned.png'.
#xOffset : 2.0 .
#imageScale : 0.8
} ,
#ASCBulletSlide{
#title : 'Outlook'.
#bullets : #(
'Port Stores and Polymorphic Write Streams',
'Documentation / Sample Code',
'Improve native compiler',
'Tooling (Debugger)',
'You! (http://objective.st)',
)
} ,
#ASCChapterSlide {
#text : 'Q&A http://objective.st'.
#subtitle : 'Marcel Weiher (@mpweiher)'
} ,
)
}.
There are a number of things going on here:
Complex object literals
A 3D presentation framework
Custom behavior via custom classes
Framework-oriented programming
Let's look at these in turn.
Complex object literals
Objective-Smalltalk has literals for arrays (really: ordered collections) and dictionaries, like
many other languages now. Array literals are taken from Smalltalk, with a hash and round
braces: #(). Unlike other Smalltalks, entries are separated via commas, so
#( 1,2,3) rather than #( 1 2 3 ). For dictionaries, I borrowed
the curly braces from Objective-C, so #{}.
This gives us the ability to specify complex property lists directly in code. A common
idiom in Mac/iOS development circles is to initialize objects from property lists, so
something like the following:
All complex object literals really do is add a little bit of syntactic support for this
idiom, by noticing that the two respective character at the start of array and dictionay literals
give us a space to put a name, a class name, between those two characters:
presentation := #MyPresentation{ ... };
This will parse the text between the curly brackets as a dictionary and then initialize
a MyPresentation object with that dictionary using the exact -initWithDictionary: message given above.
This may seem like a very minor convenience, and it is, but it actually makes it
possible to simply write down objects, rather than having to write code that
constructs objects. The difference is subtle but significant.
The benefit becomes more obvious once you have nested structures. A normal
plist contains no specific class information, just arrays, dictionaries numbers
and strings, and in the Objective-C example, that class
information is provided externally, by passing the generic plist to a specific
class instance.
(JSON has a similar problem, which is why I still prefer XML for object encoding.)
So either that knowledge must also be provided externally, for example by the
implicit knowledge that all substructure is uniform, or custom mechanisms must
be devised to encode that information inside the dictionaries or arrays.
Ad hoc. Every single time.
Complex object identifiers create a common mechanism for this: each subdictionary
or sub-array can be tagged with the class of the object to create, and there
is a convenient and distinct syntax to do it.
A 3D presentation framework
One of the really cool wow! effects of Alan Kay's Squeak demos is always
when he breaks through the expected boundaries of a presentation with slides and
starts live programming and interactive sketching on the slide. The effect is verey
similar to when characters break the "fourth wall", and tends
to be strongest on the very jaded, who were previously dismissive of the whole
presentation.
Alas, a drawback is that those presentations in Squeak tend to look a bit
amateurish and cartoonish, not at all polished.
Along came the Apple SceneKit Team's presentations, which were done as Cocoa/SceneKit
applications. Which is totally amazing, as it allows arbitrary programmability and integration
with custom code, just like Alan's demos, but with a lot more polish.
Of course, an application like that isn't reusable, the effort is pretty high and
interactivity low.
I wonder what we could do about that?
First: turn the presentation application into a framework (Slides3D). Second, drive that
framework interactively with Objective-Smalltalk from my Workspace-like
"Smalltalk" application: presentation.txt.
After a bit of setup such as loading the framework (framework:Slides3D load.)
and defining a few custom slide classes, it goes on to define the presentation using the
literal shown above and then starts the presentation by telling the presentation
controller to display itself in a window.
Voilà: highly polished, programmatically driven presentations that I can edit
interactively and with a somewhat convenient format. Of course, this is not
a one-off for presentations: the same mechanism can be used to define other
object hierarchise, including but not limited to interactive GUIs.
Framework-oriented programming
Which brings us to the method behind all this madness: the concept I call framework-oriented programming.
The concept is worth at least another article or two, but at its most basic boils down to:
for goodness sake, put the bulk of your code in frameworks, not in an application. Even if
all you are building is an application. One app that does this right is Xcode. On my
machine, the entire app bundle is close to 10GB. But the actual Xcode
binary in /Applications/Xcode.app/Contents/MacOS? 41KB. Yes, Kilobytes.
And most of that is bookkeeping and boilerplate, it really just contains a C
main() function, which I presume largely matches the one that Xcode
generates.
Why?
Simple: an Apple framework (i.e.: a .framework bundle)
is at least superficially composable, but a .app bundle is not. You can
compose frameworks into bigger frameworks, and you can take a framework and use
it in a different app. This is difficult to impossible with apps (and no, kludged-together
AppleScript concoctions don't count).
And doing it is completely trivial: after you create an app project, just create a framework
target alongside the app target, add that framework to the app and then add all code and
resources to the framework target instead of to the app target. Except for the main() function. If you already have an app, just move the code to the framework target, making
adjustments to bundle loading code (the relevant bundle is now the framework and no longer
the app/main bundle). This is
what I did to derive Slides3D from the WWDC 2013 SceneKit App.
What I've described so fa is just code packaging.
If you also organize the actual code as an object-oriented
framework, you will notice that with time it will evolve into a black-box framework, with
objects that are created, configured and composed. This is somewhat tedious to do in
the base language (see: creating Views programmatically), so the final evolutionary
step is considered a DSL (Hello, SwiftUI!). However, most of this DSL tends to be just
creating, configuring and connecting objects. In other words: complex object literals.
One of the anonymous reviewers of my recently published Storage Combinators paper (pdf)
complained that hiding disk-based, remote, and local abstractions behind a common interface
was a bad idea, citing Jim Waldo's A Note on Distributed Computing.
Having read both this and the related 8 Fallacies of Distributed Computing a while back,
I didn't see how this would apply, and re-reading confirmed my vague recollections: these
are about the problems of scaling things up from the local case to the distributed
case, whereas Storage Combinators and In-Process REST are about scaling
things down from the distributed case to the local case. Particularly the Waldo
paper is also
very specifically about objects and messages, REST is a different beast.
And of course scaling things down happens to be time-honored tradtition with a pretty
good track record:
In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing "computer stuff" into things each less strong than the whole—like data structures, procedures, and functions which are the usual paraphernalia of programming languages—each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network.
Mind you, I think this is absolutely brilliant: in order to get something that will
scale up, you simply start with something large and then scale it down!.
But of course, this actually did not happen. As we all experienced
scaling local objects and messaging up to the distributed case did not (CORBA, SOAP,...), and as Waldo explains, cannot, in fact, work.
What gives?
My guess is that the method described wasn't actually used: when Alan came up with his version
of objects, there were no networks with thousands of computers. And so Alan could not
actually look at how they communicated, he had to imagine it, it was a Gedankenexperiment. And thus objects and messages were not a
scaled-down version of an actual larger thing, they were a scaled down version of an imagined
larger thing.
Today, we do have a large network of computers, with not just thousands but
billions of nodes. And they communicate via HTTP using the REST architectural style,
not via distributed objects and messages.
So maybe if we took that communication model and scaled it down, we might be able to
do even better than objects and messages, which already did pretty brilliantly. Hence
In-Process REST, Polymorphic Identifiers and Storage Combinators, and yes, the results
look pretty good so far!
The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
is all about (and it's something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word -- ma -- for "that which
is in between" -- perhaps the nearest English equivalent is "interstitial".
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be. Think of the internet -- to live, it (a) has to allow
many different kinds of ideas and realizations that are beyond any single
standard and (b) to allow varying degrees of safe interoperability between
these ideas.
So of course Alan is right after all, just not about objects and messages, which are
too specific: "ma", or "interstitialness" or "connector" is the big idea,
messaging is just one incarnation of that idea.
One of the goals I am aiming for in Objective-Smalltalk is instant builds and
effective live programming.
A month ago, I got a package from an old school friend: my old Apple ][+, which I thought I had given as a gift, but he insisted had been a long-term loan. That machine featured 48KB of DRAM and a 1 MHz, 8 bit 6502 processor that took multiple
cycles for even the simplest instructions, had no multiply instructions and almost no registers. Yet, when I turn it on it becomes interactive faster than the CRT warms up, and the programming experience remains fully interactive after that. I type something in, it executes. I change the program, type "RUN" and off it goes.
Of course, you can also get that experience with more complex systems, Smalltalk comes to mind, but the point is that
it doesn't take the most advanced technology or heroic effort to make systems interactive, what it takes is making it a priority.
Didn't the build time continuous increase over the year? Build time at my work jump 2.5x to almost an hour in 3 years (Granted, it's a 2014 Mac mini, but still) Even a iMac Pro takes 8 minutes now 🤦♂️
Now Swift is only one example of this, it's a current trend, and of course these systems do claim that they
provide benefits that are worth the wait. From optimizations to static type-checking with type-inference,
so that "once it compiles, it works". This is deemed to be (a) 100% worthwhile despite the fact that there
is no scientific evidence backing up these claims (a paper which claimed that it had the evidence was just
shredded at this year's OOPSLA) and (b) essentially cost-free. But of course it isn't cost free:
Minimum Viable Program:
"A running program, even if not correct, feels closer to working than a program that doesn't run at all"
So when everyone zigs, I zag, it's my contrarian nature. Where Swift's message was, essentially "there is
too much Smalltalk in Objective-C", my contention is that there is too little Smalltalk
in Objective-C (and also that there is too little "Objective" in Smalltalk, but that's a different
topic).
Smalltalk was perfectly interactive in its own environment on high end late 70s and early 80s
hardware. With today's monsters of computation, there is no good reason, or excuse
for that matter, to not be interactive
even when taken into the slightly more demanding Unix/macOS/iOS development
world. That doesn't mean there aren't loads of reasons, they're just not any good.
So Objective-Smalltalk will be fast, it will be live or near-live at all times,
and it will have instant builds. This isn't going to be rocket science, mostly, the ingredients are as follows:
An interpreter
Late binding
Separate compilation
A fast and simple native compiler
Let's look at these in detail.
An interpreter
The basic implementation of Objective-Smalltalk is an AST-walking interpreter. No JIT, not even a
simple bytecode interpreter. Which is about as
pessimal as possible, but our machines are so incredibly fast, and a lot of our tasks simple enough or computational steering enough that it actually does a decent enough job
for many of those tasks. (For more on this dynamic, see The Death of Optimizing Compilers by
Daniel J. Bernstein)
And because it is just an interpreter, it has no problems doing its thing on iOS:
(Yes, this is in the simulator, but it works the same on an actual device)
Late Binding
Late binding nicely decouples the parts of our software. This means that the compiler has very little
information about what happens and can't help a lot in terms of optimization or checking, something
that always drove the compiler folks a little nuts ("but we want to help and there's so much we could
do"). It enables strong modularity and separate compilation.
Objective-Smalltalk is as late-bound in its messaging as Objective-C or Smalltalk are, but goes beyond
them by also late-binding identifiers, storage and dataflow with Polymorphic Identifiers (ACM, pdf), Storage
Combinators (ACM, pdf) and Polymorphic Write Streams (ACM, pdf).
Allowing this level of flexibility while still not requiring a Graal-level Helden-JIT to burn
away all the abstractions at runtime will require careful design of the meta-level boundaries,
but I think the technically desirable boundaries align very well with the conceptually desirable
boundaries: use meta-level facilities to define the language you want to program in, then write
your program.
It's not making these boundaries clear and freely mixing meta-level and base-level programming
that gets us in not just conceptual trouble, but also into the kinds of technical trouble
that the Heldencompilers and Helden-JITs have to bail us out of.
Separate Compilation
When you have good module boundaries, you can get separate compilation, meaning a change in file
(or other code-containing entity if you don't like files) does not require changes to other files.
Smalltalk had this. Unix-style C programming had this, and the concept of binary libraries (with
the generalization to frameworks on macOS etc.). For some reason, this has taken more and more
of a back-seat in macOS and iOS development, with full source inclusion and full builds becoming
the norm in the community (see CocoaPods) and for a long time being enforced by Apple by not
allowing user-define dynamic libraries on iOS.
While Swift allows separate compilation, this can have such severe negative effects on both performance
and compile times that compiling everything on any change has become a "best practice". In fact, we
now have a build option "whole module optimization with optimizations turned off" for debugging. I
kid you not.
Objective-Smalltalk is designed to enable "Framework-oriented-programming", so separate compilation
is and will remain a top priority.
A fast and simple native compiler
However, even with an interpreter for interactive adjustments, separate compilation due to
good modularity and late binding, you sometimes want to do a full build, or need to rebuild
a large part of the codebase.
Even that shouldn't take forever, and in fact it doesn't need to. I am totally with Jonathan
Blow on this subject when he says that compiling a medium size project shouldn't really more
than a second or so.
My current approach for getting there is using TinyCC's backend as the starting point of the backend for Objective-Smalltalk. After all, the semantics are (mostly) Objective-C and Objective-C's semantics are just C. What I really like about tcc is that it goes so brutally directly to outputting
CPU opcode as binary bytes.
No layers of malloc()ed intermediate representations here! This aligns very nicely with
the streaming/messaging approach to high-performance I've taken elsewhere with
Polymorphic Write Streams (see above), so I am pretty confident I can make this (a) work
and (b) simple/elegant while keeping it (c) fast.
How fast? I obviously don't know yet, but tcc is a fantastic starting point. The following is the current (=wrong) ObjectiveTcc code to drive tcc to build a function that sends a single message:
How often can I do this in one second? On my 2018 high spec but 13" MBP: 300,000 times.
Including in-memory linking (though not much of that happening in this example), not including Mach-O generation as that's not implemented yet and writing the whole shebang to disk. I don't
anticipate either of these taking appreciably additional time.
If we consider this 2 "lines" of code, one for the function/method header and one for the message, then we can generate binary for 600KLOC/s.
So having a medium size program compile and link in about a second or so seems eminently doable,
even if I manage to slow the raw Tcc performance down by about an order of magnitude.
(For comparison: the Swift code base that motivated the Rome caching system for Carthage was
clocking in at around 60 lines per second with the then Swift compiler. So even with an
anticipated order of magnitude slowdown we'd still be 1000x faster. 1000x is good enough,
it's the difference between 3 seconds and an hour.)
What's the downside? Tcc doesn't do a lot of optimization. But that's OK as (a) the
sorts of optimizations C compilers and backends like LLVM do aren't much use for
highly polymorphic and late-bound code and (b) the basics get you around 80% of the
way (c) most code doesn't need that much optimization (see above) and (d) machines
have become really fast.
And it helps that we aren't doing crazy things like initially allocating function-local
variables on the heap or doing function argument copying via vtables that require
require leaning on the optimizer to get adequate performance (as in: not 100x slower..).
Defense in Depth
While any of these techniques might be adequate some of the time, it's the combination
that I think will make the Objective-Smalltalk tooling a refreshing, pleasant and
highly productive alternative to existing toolchains, because it will be
reliably fast under all circumstances.
And it doesn't really take (much) rocket science, just a willingness to make this
aspect a priority.
Last month I expressed my surprise at the fact that Objective-C was recovering its rankings in the TIOBE index, not quite
to the lofty #3 spot it enjoyed a while ago, but to a solid 10, once again surpassing Swift, which had dropped to #17.
This month, Swift has dropped to #19 almost looking like it's going to fall out of the top 20 altogether.
The example is a set of commands for moving a robot:
-moveNorth.
-moveSouth.
-moveWest.
-moveEast.
Although the duplication is annoying, the bigger problem is that there are two things, the verb "move" and a
direction argument, mushed together into the message name. And that can cause further problems down the road:
"It’s awkward to work with this kind of interface because you can’t pass around, store or perform calculations on the direction at all."
He argues, convincingly IMHO, that the combined messages should be replaced by a single move: message
with a separate direction argument. The current fashion would be to make direction an enum, but he (wisely, IMHO) turns it into a class that can encode different directions:
-move:direction.
class Direction {
...
}
So far so good. However...
...we have this message obsessions at a massively larger scale with accessors.
-attribute.
-setAttribute:newValue.
Every single attribute of every single class gets its own accessor or accessor pair, again with the action
(get/set) mushed together with the name of the attribute to work on. The solution is the same as for
the directions in Nat's example: there are
only two actual messages, with reified identifiers.
-get:identifier.
-set:identifier to:value.
These, of course, correspond to the GET and PUT HTTP verbs. Properties, now available in a number of mainstream
languages, are supposed to address this issue, but they only really address to 2:1 problem (getter and setter for
an attribute). The much bigger N:2 problem (method pair for every attribute) remains unaddressed, and particularly
you also cannot pass around, store or perform calculations on the identifier.
And it turns out that passing those identifiers around performing calculations on them is tremendously powerful, even if you don't have
language support. Without language support, the interface between
the world of reified identifiers and objects can be a bit awkward.
