Modified "Why MacRuby Matters"

Download as KEY, PDF

0 likes492 views

The document discusses the advantages of MacRuby, a Ruby implementation that enhances Cocoa development by providing better code reuse, safety, and syntactic abstraction compared to Objective-C. MacRuby solves multithreading issues by eliminating the global interpreter lock and offers a more readable syntax while maintaining compatibility with Cocoa frameworks. Future improvements and performance enhancements are anticipated, alongside challenges in achieving compatibility and garbage collection on iPhone.

“The effective exploitation of the
powers of abstraction must be
regarded as one of the most vital
activities of a computer
programmer.”

In Objective-C:
1. create a static, shared instance
2. initialize once and only once
3. add an sharedInstance accessor method

…for every singleton class.
Tedious.

units of behavior;
mix-in common functionality
across unrelated classes

With mixins:

class Example
include Singleton
# your methods here
end

C is powerful. (At the price of safety.)

We see Cʼs unsafeness throughout Objective-C.

creation, @try, and @throw are all expensive

mishmash of NSError**,
NSException, and error codes

1. code reuse
2. safety
3. syntactic abstraction

[NSArray arrayWithObjects: @"a", @"b", @"c", nil];

vs.

["a", "b", "c"]

[NSDictionary dictionaryWithObjectsAndKeys:
@"Chicago", @"location", @"C4", @"event", nil];

vs.

{"location" => "Chicago", "event" => "C4"}

[foo compare:bar] == NSComparisonResultAscending

vs.

foo < bar

I want a language that lets
Cocoa shine.

irb(main):001:0> "c4".class
=> NSMutableString
irb(main):002:0> [1, 2, 3].class
=> NSMutableArray
irb(main):003:0> {:tollfree => "bridging"}.class
=> NSMutableDictionary
irb(main):004:0> "/usr/local/bin".pathComponents
=> ["/", "usr", "local", "bin"]

Ruby objects Cocoa objects

irb(main):001:0> 3000.class
=> Fixnum
irb(main):002:0> 3000.is_a? NSNumber
=> true
irb(main):003:0> 3000.is_a? NSObject
=> true
irb(main):003:0> 3000.class.is_a? NSObject
=> true

Everything is an NSObject

Laurent Sansonetti

Vincent Isambart

Rich Kilmer

Eloy Duran

Ben Stiglitz

Matt Aimonetti

provides real solutions to
real-world problems

only one system thread can touch
the interpreter at any given time

So why should you, as Cocoa
developers, use MacRuby?

static int fib(int n)
{
if (n < 3) {
return 1;
} else {
return fib(n - 1) + fib(n - 2);
}
}

@implementation Fib

- (int)fib:(int)n
{
if (n < 3) {
return 1;
} else {
return [self fib:n - 1] + [self fib:n - 2];
}
}

@end

C Objective-C
4

3
execution time (s)

2

1

0
fib(40)

def fib(n)
if n < 3
1
else
fib(n-1) + fib(n-2)
end
end

C MacRuby Objective-C
4

3
execution time (s)

2

1

0
fib(40)

C MacRuby (compiled) Obj-C MacRuby (interpreted)
JRuby Ruby
9
execution time (seconds)

6

3

0
fib(35)

C MacRuby (compiled) Obj-C MacRuby (interpreted)

0.3
0.28
execution time (seconds)

0.24
0.2
0.2

0.15

0.1

0
fib(35)

Objective-C:

[obj setValue:val forKey:key]

Bridges:

obj.setValue_forKey(val, key)

READABILITY FAIL

[[NSImage alloc] initWithContentsOfFile:path];

becomes

image(:file => path)

[[NSGradient alloc]
initWithStartingColor: [NSColor greyColor]
endingColor: [NSColor blueColor]];

becomes

gradient(:start => color(:name => "grey"),
:end => color(:name => "blue"))

single inheritance
open classes
message-based object model
dynamically typed
garbage-collected

Objective-C is C with the Smalltalk
object model attached.

Ruby is Smalltalk with C syntax.

itʼs fully integrated with the
Cocoa toolchain

itʼs 100% compatible with every
Cocoa framework

BridgeSupport lets you call any
C-based API from MacRuby

queue = Dispatch::Queue.concurrent

queue.dispatch do
puts "Asynchronous dispatch FTW!"
end

it provides features that
Objective-C lacks

regular expressions,
tail-call optimization,
namespaces,
mixins,
operator overloading,
runtime evaluation…

What do you lose when going
from Objective-C to MacRuby?

nightly builds for 10.6 at
macruby.icoretech.org

Last summer I had an internship at Apple.
My views here, however, represent that of an open-source contributor,
and not an Apple employee. Any speculations on the future of MacRuby
are entirely mine and are in no way representative of any plans, attitudes,
or future directions that Apple may take. This presentation is neither
sponsored nor endorsed by Apple.

Apple: please donʼt sue me.

restricted mode:
no eval(), no interpreter

compliant with Appleʼs restrictions
on interpreters in iPhone apps

we need garbage collection on
the iPhone

Stay Informed
@lrz
@importantshock
@benstiglitz
@MacRuby @vincentisambart
@mattaimonetti
@alloy

Modified "Why MacRuby Matters"

1. Why MacRuby Matters Patrick Thomson C4[3] September 2009

3. Edsger Dijkstra

4. “Go To Statement Considered Harmful”

5. Dijkstraʼs Algorithm

6. “The effective exploitation of the powers of abstraction must be regarded as one of the most vital activities of a computer programmer.”

7. Objective-C

8. insufﬁciently powerful abstraction

9. What does Objective-C lack?

10. 1. code reuse

11. inheritance alone is not enough

12. singletons

13. inheritance

14. In Objective-C: 1. create a static, shared instance 2. initialize once and only once 3. add an sharedInstance accessor method …for every singleton class. Tedious.

15. tedium sucks

16. mixins

17. units of behavior; mix-in common functionality across unrelated classes

18. With mixins: class Example include Singleton # your methods here end

19. foo = Example.instance

20. not a new idea

21. Symbolics Lisp

22. 1980

23. 1. code reuse 2. safety

24. C is powerful.

25. C is powerful. (At the price of safety.)

26. We see Cʼs unsafeness throughout Objective-C.

27. raw pointers: bad news.

28. easily-confusable garbage collection

29. exceptions

30. creation, @try, and @throw are all expensive

31. Cocoa isnʼt exception-safe.

32. mishmash of NSError**, NSException, and error codes

33. 1. code reuse 2. safety 3. syntactic abstraction

34. [NSArray arrayWithObjects: @"a", @"b", @"c", nil]; vs. ["a", "b", "c"]

35. [NSDictionary dictionaryWithObjectsAndKeys: @"Chicago", @"location", @"C4", @"event", nil]; vs. {"location" => "Chicago", "event" => "C4"}

36. [foo compare:bar] == NSComparisonResultAscending vs. foo < bar

37. I want a language that lets Cocoa shine.

38. MacRuby.

39. new Ruby implementation

40. + powered by LLVM

41. + + on top of CoreFoundation

42. irb(main):001:0> "c4".class => NSMutableString irb(main):002:0> [1, 2, 3].class => NSMutableArray irb(main):003:0> {:tollfree => "bridging"}.class => NSMutableDictionary irb(main):004:0> "/usr/local/bin".pathComponents => ["/", "usr", "local", "bin"] Ruby objects Cocoa objects

43. irb(main):001:0> 3000.class => Fixnum irb(main):002:0> 3000.is_a? NSNumber => true irb(main):003:0> 3000.is_a? NSObject => true irb(main):003:0> 3000.class.is_a? NSObject => true Everything is an NSObject

45. Laurent Sansonetti Vincent Isambart Rich Kilmer Eloy Duran Ben Stiglitz Matt Aimonetti

46. MacRuby isnʼt…

47. a bridge

48. MacRuby != RubyCocoa

49. a toy

50. provides real solutions to real-world problems

51. example: threading

52. Global Interpreter Locks

53. only one system thread can touch the interpreter at any given time

54. prevents true multithreading

55. MacRuby has no GIL!

56. So why should you, as Cocoa developers, use MacRuby?

57. itʼs fast

58. historically slow

59. fib(40)

60. static int fib(int n) { if (n < 3) { return 1; } else { return fib(n - 1) + fib(n - 2); } }

61. @implementation Fib - (int)fib:(int)n { if (n < 3) { return 1; } else { return [self fib:n - 1] + [self fib:n - 2]; } } @end

62. C Objective-C 4 3 execution time (s) 2 1 0 fib(40)

63. def fib(n) if n < 3 1 else fib(n-1) + fib(n-2) end end

64. C MacRuby Objective-C 4 3 execution time (s) 2 1 0 fib(40)

65. Faster than Objective-C‽

66. macruby --compile

67. ﬁrst ahead-of-time compiler for Ruby

68. C MacRuby (compiled) Obj-C MacRuby (interpreted) JRuby Ruby 9 execution time (seconds) 6 3 0 fib(35)

69. C MacRuby (compiled) Obj-C MacRuby (interpreted) 0.3 0.28 execution time (seconds) 0.24 0.2 0.2 0.15 0.1 0 fib(35)

70. itʼs beautiful

71. Objective-C: [obj setValue:val forKey:key]

72. Bridges: obj.setValue_forKey(val, key) READABILITY FAIL

73. no_underscores_plz_k_thx

74. MacRuby: obj.setValue(val, forKey:key)

75. HotCocoa

76. mapping Cocoa to idiomatic Ruby

77. [[NSImage alloc] initWithContentsOfFile:path]; becomes image(:file => path)

78. [[NSGradient alloc] initWithStartingColor: [NSColor greyColor] endingColor: [NSColor blueColor]]; becomes gradient(:start => color(:name => "grey"), :end => color(:name => "blue"))

79. a real, robust macro system

80. itʼs conceptually sound

81. single inheritance open classes message-based object model dynamically typed garbage-collected

82. Objective-C is C with the Smalltalk object model attached. Ruby is Smalltalk with C syntax.

83. itʼs fully integrated with the Cocoa toolchain

84. Yeah, We Got That

85. itʼs 100% compatible with every Cocoa framework

86. BridgeSupport lets you call any C-based API from MacRuby

87. CFStringGetLength("hello C4") => 8

88. queue = Dispatch::Queue.concurrent queue.dispatch do puts "Asynchronous dispatch FTW!" end

90. it provides features that Objective-C lacks

91. regular expressions, tail-call optimization, namespaces, mixins, operator overloading, runtime evaluation…

92. What do you lose when going from Objective-C to MacRuby?

93. static typing

94. JVM : Scala Cocoa : ?

95. Where are we now?

96. almost 0.5

97. SVN trunk is stable (macruby.org)

98. nightly builds for 10.6 at macruby.icoretech.org

99. What does the future hold?

100. Last summer I had an internship at Apple. My views here, however, represent that of an open-source contributor, and not an Apple employee. Any speculations on the future of MacRuby are entirely mine and are in no way representative of any plans, attitudes, or future directions that Apple may take. This presentation is neither sponsored nor endorsed by Apple. Apple: please donʼt sue me.

101. performance improvements

102. compatibility

104. not yet

106. Possible? Yes. Certain? No

107. ahead-of-time compiler

108. MacRuby → x86/ARM machine code

109. full mode: packed with interpreter

110. restricted mode: no eval(), no interpreter

111. compliant with Appleʼs restrictions on interpreters in iPhone apps

112. we need garbage collection on the iPhone

113. Stay Informed @lrz @importantshock @benstiglitz @MacRuby @vincentisambart @mattaimonetti @alloy

Editor's Notes

#2: Introductions. Thank Wolf. Banter.
#3: Many of you may recognize this person.
#5: contributions to structured programming
#6: revolutionary graph-search algorithm that powers just about every network routing protocol
#7: this quote of Dijkstra&#x2019;s draws attention to a central conundrum facing Cocoa programmers today
#8: the conundrum is this: Objective-C, the language we all know and love&#x2026;
#9: &#x2026;provides us with an insufficiently powerful level of abstraction. We build the best desktop apps out there, but we do it in spite of ObjC.
#10: So, as a language, what does ObjC lack?
#11: I submit that perhaps the most fundamental problem with ObjC is its lack of support for code reuse. At the Objective-C level of abstraction, effective code reuse is like pulling teeth.
#12: And sure, inheritance provides a good measure of code reuse. But for many use cases, it simply doesn&#x2019;t apply.
#13: Consider the singleton. It&#x2019;s a great example of a common Objective-C pattern which cannot be abstracted out, forcing us to resort to boilerplate code.
#14: Every singleton class needs its own static, shared instance. Single inheritance can&#x2019;t solve the problem, and it&#x2019;s questionable that multiple inheritance is the right solution in this case.
#15: So, creating a singleton in Objective-C is really tedious. Add to the fact that very few people agree on the right way to go about this tedium - should you synchronize on sharedInstance, or init? Should you check for NULL or use pthread_once or dispatch_once? - and ensuring proper behavior seems hardly worth the trouble. It&#x2019;s too tedious.
#16: And tedium sucks.
#17: A sufficiently powerful language would provide us with a code reuse mechanism like mixins.
#18: Mixins, for those who haven&#x2019;t heard of them, provide another level of abstraction into class definitions. Like classes, you define them and define method implementations in them; however, instead of including them in the class hierarchy, you mix them into classes - the resulting class copies the methods you defined in your mixin.
#19: Here&#x2019;s an example. In this language, the &#x201C;include&#x201D; keyword mixes a mixin into a class. By including the Singleton mixin in this class, it defines initialization and accessor methods as well as setting aside a static, shared instance.
#20: Now we can access the shared instance. Easy.
#21: And sure, I understand that the Objective-C language designers held off on implementing New and Fancy Ideas. And I agree with them.
#22: But mixins have been around since Symbolics Lisp. Anyone remember that? I don&#x2019;t. I wasn&#x2019;t even born yet.
#23: That was a while ago. And we, as Mac programmers, should ask more from our development tools.
#24: Though Objective-C has a huge advantage in that it&#x2019;s based on C, it also has a huge disadvantage - that it&#x2019;s based on C.
#25: Being a representation of a Von Neumann machine, C can solve any computable problem. But what&#x2019;s interesting is that C is actually pretty expressive, even when you need to do fancy, comp-sci-sexy things. You&#x2019;ve got a reasonable approximation of continuations with setjmp, of exceptions with sigsetjmp, and first-class functions with function pointers.
#26: But all of these things are hideously unsafe. We&#x2019;re programmers, not superheroes - if our tools allow us to make a mistake, we will make it.
#27: And C&#x2019;s unsafeness is visible in almost every part Objective-C.
#28: We program in a high-level language. Why do we still have the ability to shoot ourselves so profoundly in the foot with raw pointers? You, or the library functions you call, can stomp all over memory silently and watch as you drown in bizarre and irreproducible behavior.
#29: C&#x2019;s ability to treat just about anything as a memory address means that you can bamboozle the hell out of the garbage collector.
#30: Nowhere is the unsafe and backwards nature of C - and consequently, Objective-C - more apparent than exceptions. C really doesn&#x2019;t play nice with the notion of exceptions at all, and has therefore hobbled ObjC exception support throughout ObjC&#x2019;s lifetime.
#31: ObjC exception handling is horrifically inefficient. Since on 32-bit exceptions are based on setjmp and longjmp, pretty much everything about them are expensive. Exception creation and try-blocks got much faster with 64-bit C++-compatible exceptions, but throwing them got even slower.
#32: And the kicker is that the vast majority of Cocoa frameworks aren&#x2019;t exception-safe. So there is absolutely no guarantee that objects will be cleaned up or finalized properly if you throw an exception.
#33: So thanks to this, nobody ever checks for exceptions - honestly, when was the last time you checked for alloc throwing an NSMallocException? - and we make do with functions that take pointers to NSErrors and some functions that return either Carbon, Cocoa, POSIX, or Mach error codes.
#34: Go ahead. Call me lazy.
#35: But I&#x2019;m tired of creating arrays manually. I want a language that has sufficient syntactic abstraction so that I can just create arrays inline. I mean, imagine if we had to do this to create NSStrings - it would be endlessly tedious!
#36: And don&#x2019;t even get me started on how tedious NSDictionary creation is. These may seem like syntactic quibbles to some of you, but I know that in the past I&#x2019;ve avoided using dictionaries in favor of long if-else statements, just because creating dictionaries is so tedious!
#37: Similarly, I want operator overloading, because it lets me say what I mean. I want the less-than sign to be transformed into a call to compare - and let&#x2019;s be frank, operator overloading is never going to come to Objective-C.
#38: Basically, I want a language that&#x2019;s as well-designed as Cocoa.
#39: And so far, the closest I have come to that ideal is when I write code in MacRuby.
#40: For those of you that haven&#x2019;t heard of it, MacRuby is a new implementation of Ruby, a scripting language from Japan.
#41: MacRuby differs from the standard implementation of Ruby 1.9 in that its its virtual machine, optimization routines, bytecode generation, and just-in-time compilation are all implemented on top of LLVM, the Low-Level Virtual Machine project. LLVM is already blazingly fast, and I&#x2019;m confident that its performance will only continue to improve.
#42: In addition to replacing the Ruby 1.9 VM with the LLVM one, we also reimplemented the standard Ruby data structures on top of CoreFoundation. In addition to providing us with a set of memory-efficient, fast, and mature set of data structures, implementing MacRuby on top of Core Foundation also ensured that&#x2026;
#43: &#x2026;Ruby objects are absolutely indistinguishable from Cocoa objects - they even respond to the same API calls! NS/CFStrings are Ruby strings, NS/CFArrays are Ruby arrays, NS/CFDictionaries are Ruby hashes.
#44: But we go beyond what Objective-C offers, and return to a Smalltalk heritage where there are no primitive types. Everything descends from NSObject, even floats and integers.
#45: Though MacRuby is an Apple-supported project, it is released under the Ruby license so you can embed it into your commercial applications.
#46: The MacRuby team is one of the smartest and most focused I&#x2019;ve ever seen. Laurent Sansonetti, an employee at Apple, started MacRuby just as an experiment to see how well Ruby would run on top of the Objective-C runtime and garbage collector. Yet in its current form, I truly believe that it&#x2019;s stable enough
#47: Clarification!
#48: Bridges, as Tim pointed out in C4[1], are unreliable, difficult, and tend to be slow.
#49: Explain the differences.
#51: not a toy!
#52: everyone has to deal with it sooner or later
#53: explain what they are, what systems (Python, Ruby, Lua) use them
#54: explain how much they suck
#55: green threads suck
#57: So. The big question.
#58: MacRuby is fast. Not just Fast Enough, but fast.
#59: This may surprise many of you, as most people know Ruby as &#x201C;that weird, slow, Japanese space-Perl.&#x201D; And the conception that Ruby is slower than other comparable languages has been true - up until now.
#60: A good example of the speed boosts that we aim for is the Fibonacci sequence.
#61: Take na&#xEF;ve implementations of the Fibonacci sequence, using recursion, in C&#x2026;
#62: and in Objective-C (using ObjC message sending),
#63: and, predictably, C is going to be a lot faster. And trying to get MacRuby faster than C for everything is beyond the scope of this project.
#64: But take the same Fibonacci implementation in Ruby, run it under MacRuby&#x2026;
#65: and we see that MacRuby is, in this benchmark, faster than Objective-C.
#67: The answer lies in the --compile flag. MacRuby can compile Ruby source down to Mach-O x86 executables.
#68: This is hugely exciting. Nobody else has done this before. And up until now, shipping a closed-source desktop application written in Ruby has been a Bad Idea - but now you can hide your source code from prying eyes.
#69: For completeness, let&#x2019;s compare the C, compiled MacRuby and Objective-C performance and interpreted MacRuby, JRuby, and the stock OS X 10.6.1 ruby interpreter. OK... ouch. I dialed back from fib(40) to fib(35) because otherwise the stock ruby interpreter would still be calculating. JRuby&#x2019;s better but still no competition for MacRuby (interpreted or compiled).
#70: So let&#x2019;s throw out the stock ruby and JRuby data to get a better look at MacRuby (compiled and interpreted) vs. C and Objective-C.
#72: keyword syntax is readable.
#73: worst of both worlds: verbosity of keyword syntax and unreadability of ALGOL-style syntax
#75: syntactic extensions to make ObjC calls look gorgeous.
#76: optional set of layers
#78: to make common idioms concise
#79: nestable, elegant, yet completely optional
#80: like in Lisp and Scheme
#81: Ruby and Objective-C are almost absurdly similar - how similar, you ask?
#82: look at these features!
#83: practically cousins
#84: first-class environment
#85: xcode templates, interface builder integration, instruments templates, dtrace scripts
#86: leave nothing behind
#87: mention that Laurent wrote it
#88: contrived example, but talk about CoreImage, CoreGraphics, PDF documents
#89: hooray for my GCD layer
#90: talk about how things just work, and plug topfunky&#x2019;s MacRuby screencast
#91: hooray
#92: whine about all of these features
#93: be honest!
#94: Though one can obviously treat Objective-C like a dynamic language, and give the &#x2018;id&#x2019; type to everything, well-written and idiomatic Objective-C code takes advantage of static typing to catch errors before they happen. And because Ruby is a duck-typed language, you&#x2019;re going to lose some power.
#95: And rather than viewing this as a problem for MacRuby, I think this is a great opportunity for another language to come in and apply all the innovations in the world of static typing - type inference, currying, existential types - to the world of Cocoa. So, uh, someone get on that.
#97: The 0.5 release of MacRuby is almost upon us. This release will be the first one based on the new virtual machine.
#98: If you want to play with the new features now, I recommend checking out the source from MacRuby.org
#99: or get builds for Snowy.
#101: DISCLAIMER! I&#x2019;m here to talk about what is TECHNICALLY POSSIBLE, not what&#x2019;s *going* to happen.
#102: we want to be the fastest Ruby implementation around
#103: we still need continuations, fibers, and to make all C exts compatible
#104: The first thing people usually ask about MacRuby is &#x201C;Does it run Rails yet?&#x201D;
#105: No. It doesn&#x2019;t. And though we&#x2019;d like to have it run Rails in the future, there&#x2019;s still a lot of work to be done in that direction - revamping the sockets interface, improving IO speed and flexibility, and making sure that MacRuby supports all the maddening little metaprogramming quirks of which Rails takes advantage.
#106: Much more interesting to me is the question of whether or not
#107: it&#x2019;s up to the lawyers
#108: i mentioned this already
#110: for metaprogramming and eval
#113: hopefully that will come soon

Modified "Why MacRuby Matters"

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Modified "Why MacRuby Matters" (20)

Recently uploaded (20)

Modified "Why MacRuby Matters"

Editor's Notes