C Is The New Assembly

February 14th, 2007

John Gruber was recently featured for a second time on Dan Benjamin’s instantly-awesome Hivelogic Podcast.

I’m glad that Jesper heard and was intrigued by some of the same comments I was, because he reminded me that I wanted to comment on a subtle but worth-repeating impression that I took away.

The comments are those pertaining to the introduction of scripting language bridges as standard developer resources in Leopard OS X 10.5. Gruber points out that for developers, the presence of these scripting language bindings will both open up the platform to a wider audience of developers, and enable selective use of scripting languages where the highest performance is not necessary.

He suggests that a typical developer will write everything in Ruby or Python, and then do performance testing. Anything that needs a speed-up can be redone in Objective-C. You know, that “slow” dynamic variant of C :)

This analysis is foreboding, because it’s exactly what programmers have always done when they switched to a higher level language. 10 years ago a programmer would be more likely to “switch to assembly” for a much-needed performance boost. Has it come to this? Are we moving to a higher plane? If you’re like me, you’ve probably become quite comfortable in your Objective-C universe, and somewhat dismissive of the scripting languages as they begin to encroach on our holy ground. But we run the risk of being like those losers who still insist on programming everything in assembly, while the higher-level code would be just as fast and easier to maintain.

Is C the new assembly?

84 Responses to “C Is The New Assembly”

  1. Daniel Jalkut Says:

    Jim: Haha! The bad news is I haven’t really looked at lisp since I hobbled my way through a Scheme class in college. The good news is, “learn lisp” has been near the top of my programming self-improvement list for a few years now. And I think it’s on a lot of our lists :)

  2. Bret Says:

    >> you’ll be AMAZED at how good the source code output is.

    No, actually, I wouldn’t – theoretically, if the CPU can do it, somebody can figure out what’s going on. My point wasn’t that “it’s not possible to reverse engineer bytecode” – because it most certainly is. It’s also possible to do similar things with compiler-generated machine code.

    No – the point is, “Will the PHB veto this?” — and for uncompiled languages, I think the answer is “Yes!”. The perception of vulnerability is just too high (regardless of the facts).

    But, like I said above, throw in a compiler, and I think the perception issue can be surmounted, as it now looks to the PHB just like any other toolchain.

    >> In any case, I disagree that using “scripting” languages for commercial app development will fail due to it being easily decompiled (or reverse engineered in other ways for that matter).

    As far as the PHB is concerned, reverse engineering != trivial copy and paste.

  3. Bret Says:

    >> I prefer Obj-C code, I find it infinitely more readable than any other language I’ve seen.

    Me too. I like verbosity. And with code-completion, I’m still not doing all that much typing. Sticking to patterns helps also (and there’s also the issue of egronomics – if your keyboard is driving you nuts, anything that makes you use it is also going to drive you nuts. I have a pile of different one’s that I’ve tried, just to find a good one – I’ve probably spent maybe 500 bucks over the years on input devices.)

  4. Jake Says:

    Dear Deity,
    Please forgive these folk that jump on bandwagons and talk utter rubbish for they know not what they do.
    When You created PHP and Ruby they had a Purpose, and that Purpose was not to be trumpeted as THE NEXT BIG THING, but as an addition/improvement to the tools already available.

    Too many people call themselves “programmers” because they have dabbled – you know the ones, people who use Dreamweaver or something similar and then mess around with PHP for a bit and then think they are l337.

    There are a million reasons for not using Ruby, Python or scripting languages – they will not always be the best tools for the job. IMHO they arent often the best tools for the job, but then we all have our own opinions. If you’re writing something in Ruby and having to use C to “hack” it to make it faster then you’re going wrong from step 1.

  5. Michael Says:

    Worth noting, if just as an aside, that there is a world full of systems developers out there for whom C is high level, and Assembly is still a day-to-day language. Our company produces network switches and host adapters. In such an environment, you need a real-time language (read: no GC threads interrupting deterministic behavior), and often need the ability to drop to Assembly for controlling various types of CPUs and microcontrollers. Of course, there’s always the OS kernel as an ever popular example, too. C++ is a systems language, but sys devs aren’t particularly aware of OOP principles, and much driver and embedded code doesn’t map well to objects anyway (interrupts and kernel hooks and such). (keep an eye on D though… )

    Point being that in some circles, Assembly is still very much alive and C is still thought of as high level. Lets all take a moment and thank the embedded programmers ’round the world for allowing app devs to think of C as Assembly 2.0.

  6. Joe Goh Says:

    Michael: Hear hear! I totally agree with you, in the midst of all this talk of C as assembly, there’s a whole world of embedded programmers being forgotten.

    I remember helping to debug a bug in some custom firmware when I was still in my previous job with a firmware programmer and starting at the ASM listings and then thinking of how incredibly high-level C seems at that time. After that experience, I learned to never take the reliability of hardware or firmware for granted.

    But then again, there are those even that will see ASM as high level, like CPU designers.

    So i’m with Michael, let’s forget about squabbling over which language is on a higher level than other languages, its just going to go nowhere. Let’s just use whatever gets the job done for us and thank all the fellow engineers and developers out there, sweating over the things that we depend on for our work daily.

    BTW, never take your compiler for granted (i’m feeling the pain now, as i’m currently struggling with a bug in my app that’s possibly due to a compiler bug). What a coincidence to run into this sort of thing just as this is becoming a hot topic eh?

  7. Reinier Zwitserloot Says:

    C? Sure. Has been for some time now.

    Objective C with the Cocoa libraries and Core*… not really.

  8. Paul Says:

    Where C shines as the “new assembly” is as an intermediate language. Most exotic (particularly functional) languages that offer native code actually compile to C and then call gcc internally to produce a binary.

    This has lots of advantages: it’s much easier to generate C than any machine language and it gives instant, optiized support for just about every CPU there is (yes, ghc does a heck of a lot more of its own.) Such generated programs tend to be larger than programmer-written C, but often faster as well.

    One huge time saver in C is the ability to inline assembly code: my ideal system would allow inlining C/C++ directly into a high level language, to be copied more or less directly into the generated code, with special macros to provide direct access to data in the “real” language. This could allow direct calls to external libraries (avoid the need to create / learn a GUI bridge at all for those so inclined) and allow small bottlenecks to be addressed with snippets rather than the agony and misery and overhead of interfacing a separate external library of complete functions. In principle there’s no reason why any number of straight C files couldn’t be linked into such a program and called directly (the run time libraries usually are.) This, for me, is the sole interesting idea behind MS’s .NET and CLR, though implemented differently.

    I understand Ruby has this ability to some extent. It seems like a very highly desirable way to go.

  9. Mike Medvinsky Says:

    Although I share the authors view, I am not sure that the problem is exactly within a language representational form but is within a runtime. The question is not weather the language is C or Python or Ruby but how the semantics of the language yield themselves to the optimization as the code is compiled from AST to a machine executable state machine.
    Ruby, for example, because of its dynamic structure and flexibility will be very difficult to automatically compile into an optimal state machine that the native hardware can efficiently execute. Java is a bit more structured, but the general memory management solution and inability to deal with pointer arithmetic directly puts a cup on performance of is runtime as well.
    Generally I would say that performance of a language depends on 3 major things. One How well does its structural semantics coexists with optimization algorithms, two the level of isolation from hardware and three how is memory management dealt with.
    It should be perfectly possible to convert a Ruby program into C code and even generate general purpose assembly out of it, but will the dynamic nature of Ruby permit for real optimizations to take place? Think about how would you implement closure in assembly… and will it be fast?


  10. Anders Says:

    Jim Thompson:

    Have to agree with that statement. C has long been my language of choice, but Lisp has captured that position now. And that’s despite having used Ruby and Python a fair deal.

  11. bogdan77 Says:

    Um… what about AppleScript? As a dabbler in AS, I have to say I like its syntax a lot, but I wonder why Apple isn’t making it more powerful, with all kind of operations on lists (remove duplicates, for example), and regular expressions included in AS. Why not, Apple?

    I’m working to extend TextEdit for my needs, to grep styled text with AppleScript, but I have to resort to do shell script constructions, which for even one page of text is slowing things down terribly.

    —–Sorry if this is off-topic for you real programmers. I just feel there is big potential in AppleScript if it would be made even more easy to work with :^)

  12. Paul Says:

    > Um… what about AppleScript? As a dabbler in AS, I have to say
    >I like its syntax a lot, but I wonder why Apple isn’t making it more

    AS is a better language than people give it credit for. A high % (I suspect) aren’t aware of all it can do besides automate programs. Automation is actually not its greatest strength: historically most developers don’t make the (enormous, even with PowerPlant) effort to make programs usefully scriptable. AS is heavily used with specific programs whose makers invested in the effort and documented how to do it (Quark scriptability has long helped Apple hold onto desktop publishing.)

    I once wrote a quicksort in AS to alphabetize icons in a Finder window while preserving layout: getting the notoriously buggy, unpredictable, and undocumented Finder to cooperate was by far the hardest part. VBS, while a royal pain in its own right, is at least reproducible most of the time.

    Extending AS is hideously difficult (at least as of a few years ago), largely due to the complex interface and near total absence of documentation. It’s no accident that most third party AS tools come from companies started by ex-Apple engineers.

    Apple’s own efforts (AS Studio) notwithstanding, I’m very leery of their commitment to any technology, including AS, if anything comes along that looks like a viable replacement (and there are some, for Cocoa programs) and can be called a “standard” in ad copy. I was lucky enough not to get burned too badly by QuickDraw3D or OpenDoc, mostly because I trusted my instincts and not the press releases.

  13. Jim Thompson Says:


  14. init.six Says:

    C is to Assembly as Perl is to Python

  15. Sid Millspaugh Says:

    I use C/C++ on a daily basis, what do I do? Game Development, and while I use C# as a scripting language for many things (mostly gameplay code) lower level languages just can’t be beat for the core technology.

  16. Juan Sebastian Says:

    C, OS X, SLACKWARE and EMACS FTW….!!!!!:D:D:D:D:D:D

  17. Rudi Cilibrasi Says:

    For my scientific software (linked) CompLearn, I use a combination of C and Ruby just the way you hypothesize. As a scientist I have been using this pair of languages together to good effect for rapid prototyping and easy experiments. You can see (and download C and Ruby) the results on the website. It is also nice to be able to profile and replace the innermost loops with C as needed. I recommend it wholeheartedly as a strategy moving forward.

  18. Ned Baldessin Says:

    About spam filtering on the iPhone : this is when server-based filtering becomes necessary. I’ve switched my email hosting over to Google, and the spam filtering is great, I get less than one spam per week, and best of all, I don’t have to download all the spam messages.

    Maybe this will push the trend of hosted email infrastructure.

  19. wikepedist Says:

    “while the higher-level code would be just as fast and easier to maintain.”
    I find that false in both ways:
    1. Higher level code ( python,perl ) isn’t anywere near the speed C can bring.
    2. Higher level code would be much easier to maitain.

  20. John Says:

    Oh hmm, my first attemp was eaten :(

    So again, there’s not only C or ObjectiveC, there’s also object pascal 32/64bit and this compiler is also multiplatform, more info at http://www.freepascal.org

    Oh and small example program (Photoshop? hint!hint!): http://www.kanzelsberger.com

  21. Patrick Coston Says:

    What you need is a language that combines the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python.

    Oh wait … it already exists! It’s called D!


    Java, C#, Python, Ruby and D all derive from a C so its very easy to jump from C to these other C-like languages unlike trying to learn Lisp.

  22. William Woody Says:

    C, the new assembly?

    Sure. But C was always the new assembly. The C language was designed so that each statement translated into a few machine language instructions–often just one–and has been referred to for years as a ‘low level language’ because in many ways it’s as much a portable macro assembler language without the assembly as it was a ‘high level language.’

    A good C programmer familar with the ABI of the platform he’s writing code for should be able to intuitively know what the assembly output will be for his C code. And while C had the advantage of being a portable language, in this case, “portability” is limited by a few dozen rules that all have to do with the target architecture of the system he is writing code for. (For example, is ‘-3 % 4’ a positive or negative number? Well, that depends on the target architecture.)

    The only reason why we can now talk about C as the new assembly language is because computers have become powerful enough that we can talk about writing performance sensitive code in a high level language such as Ruby. And it’s also one of the reasons why I hate C++ templates: because it violates the rule that C (and C++ without templates or exceptions) should translate everything you write into a few (and intuitively easy to divine) machine language instructions.

  23. Belig Donner Says:

    “C has libraries.”


  24. guitarm Says:

    I’m an old fart trying to cope with the new technologies and I must say…I’m all for trying to abstract away alot of the “old” stuff.
    But…and this is (my) big butt…
    Who will want to understand the underlying things of it all…misunderstand me the right way here…I’m not saying everyone should understand kernel stuff in assembler. What I’m saying is the more experience you have…be it high, or low abstraction stuff, it’s always a benefit if you get “the whole picture”

  25. kokorozashi Says:

    You want the big picture? Try this on for size:All languages in common use today are done. Clock speeds have stopped increasing and the future is about parallelism. None of today’s languages is up to the task of expressing parallel notions, which, for the sake of clarity, are more difficult than threads, which are already difficult enough. It’s going to be an interesting ride. Eventually, the C of parallelism will appear. It isn’t going to be any of these dynamically typed scripting languages which scale terribly and are really just ways to aggregate extensions written in C. Most people won’t have expected it, but suddenly it will be here after Pixar reveals it divided the rendering time of their latest feature by ten.We now return you to your regularly scheduled complacency. :-)

  26. Kevin Kitching Says:

    Even when I learned programming in ’89, assembly was something you learned because you might still need it, but avoided if you could…mostly because even then tightly written C could do most things nearly as fast, and with 1/10th the coding time.

    That’s not to say that one of my class projects, a programmer’s text editor, didn’t contain alot of assembly … we were required to use only modules we developed ourselves. And some of the base functionality … pop-up menus and the like … had to be written in assembly. But the top level stuff, linked lists and file system stuff…no way. I’d still be banging away at the keyboard of that XT today trying to get it right.

    Assembly’s still a good club to have in your bag, if for nothing other than background.

  27. Paul Says:

    >And it’s also one of the reasons why I hate C++ templates:
    >because it violates the rule that C (and C++ without
    >templates or exceptions) should translate everything
    >you write into a few (and intuitively easy to divine)
    >machine language instructions.

    I’ve been saying for years that C++ has lost its way: the standards committee is besotted with trying to make C++ something it was never meant to be, by bolting on one kludge after another. The best example of that is boost.org, which does things in C++ that seem impossible, at the expense of long compiles, unreadable, unmaintainable, and especially undebuggable code that’s a few lines shorter but takes longer to write.

    (I do respect the the inventors of template metaprogramming, Design Patterns, and Processes, though: they’re the ones who saw the future early and created new territory to be highly paid gurus of, or tenured teachers of.)

    What comes out of this discussion that’s hopeful is that a lot of people seem to realize that, and are looking for something better.

  28. Robert Says:

    You still need Assembly when you work with micro controllers with 1kb of memory or so :)

  29. Jon Says:

    Looking for something better (than C, C++, …) could start here http://www.ffconsultancy.com/free/ocaml/

  30. Scott Andrew Says:

    We use C++ and C for commercial Windows UI development. On the mac we have Objective C and C++. We have looked at things like XAML/C# for Windows and the problem with those languages are two fold, at least in our programs. Our engine is all crossplatform C++ for video encoding and such. In a higher level language you have to write a wrapper which adds overhead and performance cost if you are moving over that boundry repeatedly.

    These langauges are also in effecient with memory. C# will keep eating memory until it can’t then garbage collect. There is something about having control over my foot print and being able to clear memory as needed that is nice. XAML has huge overhead on the windows side and is fairly slow. Quite a few things were hacked on XP from what i understand. We’ll take our C++ WTL based framework right now over C# 3.0 and XAML for high end apps.

    As far as is C++ I think yes it is to a point. It also has its place when doing basic applications if you are looking for crossplatform support. Our engine is all crossplatform C++. I can take any of our components in the engine and complie it for windows/mac/linux/bsd… C++ won’t go the way of the dinosaur, interpretive languages have their place, but they aren’t efficent enough for large scale commercial applications yet, I don’t think.

  31. L Says:

    To the guy who praised AppleScript’s syntax:

    lol k

  32. Coders2020 Says:

    Some amazing informative comments here. Post bookmarked and I am glad that I come here. And as already pointed out, C can be an alternative not a replaement. You will still need assembly when you work at microcontroller level

  33. Aakash Sharma Says:

    Can anybody tell me that in which microprocessor 8086 or 8088 a far procedure call will execute faster and why???

    Send me reply @ akkuf117@gmail.com

  34. agnosticj Says:

    The 8086 has a 16bit bus, much larger than the 8088’s 2-nibble bus. All things being equal (same code), the 8086 will do it faster.

Comments are closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.