Debug 30: Casey Liss on C# and .Net

Debug 30: Casey Liss on C# and .Net

Casey Liss of the Accidental Tech Podcast (ATP) tries to sell Guy on the advantages of Microsoft’s C# programming language and the .NET frameworks.

Show notes

Guests

Hosts

Feedback

Yell at us on Twitter or leave a comment below.

Rene Ritchie

Editor-in-Chief of iMore, co-host of Iterate, Debug, Review, Vector, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts

 

0
loading...
0
loading...
50
loading...
0
loading...

← Previously

This is how CarPlay will work in your new Mercedes-Benz

Next up →

Ferrari shows off CarPlay with awful resistive touchscreen

Reader comments

Debug 30: Casey Liss on C# and .Net

5 Comments

You guys suggested it's hard to embed a scripting language like python into obj-c. I disagree,

For example CoScript (https://github.com/ccgus/CocoaScript/) combines JavaScript Core with obj-c square brace syntax with Apple's scripting bridge. Anything you can do in obj-c/javascript/applescript can be done with CoScript, it's really powerful.

For example here's some CoScript that pops up an NSWindow with some controls, tells NSApp to run modal until the user clicks something, and then processes the response, interacting with some objects in the host application*: https://gist.github.com/abhibeckert/68d19048734dd95bed54

It even supports anonymous functions in javascript, which are converted into blocks in obj-c. Notice how the okButton tells NSApp to exit the modal state, resuming normal execution of the script.

* the host application is my text editor, duxapp.com

Hi there,

 This is Guy writing. I'm not sure how it'll appear in the UI because I'm awful at not reading the comments enough. Sorry about that.

I agree with you completely that the Objective-C runtime makes it possible to arbitrarily bridge scripting languages. I've actually shipped products that were widely deployed that leveraged exactly the kind of flexibility you're pointing out.

The thing about those bridges though is that you do need to know if the parameter is a floating point variable or not -- calling into native code requires the ABI (Application Binary Interface) to be honoured. Which means the code that you call (or jump to) will expect the parameters to be placed correctly. In order to bridge Lua or JavaScript or whatever a major part of the bridge involves mapping the parameters from the scripting language space to the layout expected by the native code.

CoScript is very cool. Gus is a pal and we share a lot of interests. Graphics and scripting bridges and high on the list. Honestly, I think CoScript is a great way to move beyond AppleScript. It's powerful, it reads well, and it more closely matches reality. I'm all for CoScript.

All of that said the magic of the CLR (the Common Language Runtime) that C# runs on is that there is no need for the juggling of parameters from one set of expectations to another. No bridge code is required. A VisualBasic procedure can call a C# method that in turn executes some LINQ of even invokes some F# code. The friction is greatly reduced.

We've recoded a show already that goes into more detail about this kind of stuff. We pretty much went right to the source. I think it turned out well and I hope you enjoy it. It should be up next week.

best, Guy

My good god. This web site is the worst pos I have ever seen. Did anyone test it on mobile! You can't even scroll on an ipad! Anyhow, I digress. I'm digging Debug. This was another interesting one. Casey is sharp and gracious.