Did you guys implement proper message passing and proxying, or are they ad-hoc method calls?
An interview with 280 North on Objective-J and Cappuccino
11–17 of 17 posts
Re: An interview with 280 North on Objective-J and Cappuccino
#12Does it work on the iPhone?
Short answer: yes. Long answer: There's still some work to do.
Re: An interview with 280 North on Objective-J and Cappuccino
#13Did you guys implement proper message passing and proxying, or are they ad-hoc method calls?
We do indeed do dynamic dispatch, just like Objective-C.
Re: An interview with 280 North on Objective-J and Cappuccino
#14Guys, great job! I have a question about timelines... how long was Obj-J in development and how long did it take you to develop 280slides? I remember reading that you started in 2005...
[deleted]
Re: An interview with 280 North on Objective-J and Cappuccino
#15Guys, great job! I have a question about timelines... how long was Obj-J in development and how long did it take you to develop 280slides? I remember reading that you started in 2005...
Thanks. Yes, Obj-J/Cappuccino was started while we were in college in 2005, but was put on hold for awhile when we had other jobs. 280 Slides was written in about 5 months, concurrently with some work on Cappuccino.
Re: An interview with 280 North on Objective-J and Cappuccino
#16Why did you chose to do Objective-J -> JS processing in the browers? For sake of speed, wouldn't it be a good idea to do it server-side and then just serve the JS?
The main advantage of doing it in the browser is for the developer: you don't need the explicit compile step: just write code, save it, refresh the browser. It also enables neat things like a REPL. That said, the nice thing about writing the preprocessor in JavaScript was we can do preprocessing ahead of time on the server, if we need to. However, doing it client-side is not as slow as you would expect. edit: Ross be…
It also seems that you can easily have a "testing mode" where you run the preprocessing client side when you are just building the app, and then when you deploy like "for real", run the preprocessing server side to keep things fast(er).
If the site gets too hammered, then you could even have it switch, where an overloaded server tells clients to preprocess for themselves while the server catches up. This would be an interesting way to handle spikes in usage (like now for example)
Re: An interview with 280 North on Objective-J and Cappuccino
#17Earlier quoted context omitted.
The main advantage of doing it in the browser is for the developer: you don't need the explicit compile step: just write code, save it, refresh the browser. It also enables neat things like a REPL. That said, the nice thing about writing the preprocessor in JavaScript was we can do preprocessing ahead of time on the server, if we need to. However, doing it client-side is not as slow as you would expect. edit: Ross be…
It also seems that you can easily have a "testing mode" where you run the preprocessing client side when you are just building the app, and then when you deploy like "for real", run the preprocessing server side to keep things fast(er). If the site gets too hammered, then you could even have it switch, where an overloaded server tells clients to preprocess for themselves while the server catches up. This would be an…
Presumably the code doesn't change very often, so we actually just preprocess it once per revision and serve up the static files, so there's no extra load on the server or the client.