Swift and Objective-J

[Stephen White]

Swift does look quite similar to ES6, other than the specifics like non-nullable references and variables that cannot overflow.

The bulk of the work seems to be the implicit typing, which is available in Typescript.

This suggests that a viable approach could be to take Swift code, parse it to Typescript, then run it in the Cappuccino runtime.

--

  st...@adam.com.au

[Alexander Ljungberg]

Objective-J was designed to be a superset of JavaScript, e.g. Objective-J only adds things to JavaScript without removing anything. The result is that you can mix and match freely. 

A Swift-J wouldn’t be possible. Swift has many keywords which would “clobber” JavaScript keywords. For example, you can declare a constant with “let” in Swift, but in ES6, with the same “let", you’d be declaring a smaller scoped “var”. 

So if we were to write a Swift compiler it’d be pure Swift. It wouldn’t allow inline JS. In fact, if we were to do it I doubt there’d even be a special syntax to inline generic JS, short of calling an external JS library, for if there were many of the optimisation possibilities would immediately be lost.

Depending on where you stand this lack of Swift-J could be a huge drawback. If you come from a JS background, now your learning curve is a little higher. You can no longer just copy and paste some little snippet to do something interesting. Tons of existing code is no longer easily reusable.

On the other hand, if you don’t care about tight JavaScript interoperability, Swift would actually be good for you. The output would likely run faster since Swift is much easier to statically optimise from what I’ve seen so far. Knowing the types of everything helps.

Curiously Apple must have been in the same situation. With Swift they sacrificed the ability to include random C code and the benefits of years of software libraries of code ready for copy and paste from both C and Objective-C. But in return they got a highly optimisable language with protection against almost all the most common bugs (falling through a switch statement, dereferencing a null pointer etc). It’s not unlike the choice we’d be making when considering Swift versus Objective-J.

Alexander

--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectivej+...@googlegroups.com.
To post to this group, send email to objec...@googlegroups.com.
Visit this group at http://groups.google.com/group/objectivej.
For more options, visit https://groups.google.com/d/optout.

[Martin Carlberg]

Hi!

Some time ago you pushed that we should use Typescript to add feature to Objective-J. I said then that adding a third party compiler will not solve our problems. It is better to add those features directly to our own compiler.

It is the same if we should build a JSwift (or Swift-J as Alexander suggested) compiler. It is better to add those features directly to our own compiler to generate code that are optimized for speed and are fully compatible with Cappuccino and the runtime. Much harder to do that if we has to go thru another language and compiler.

Best regards,

- Martin

[Andrew Hankinson]

I could also see Apple declaring Swift to be a new language that runs in Safari - a replacement for JavaScript in WebKit. They have already integrated LLVM as a JavaScript optimizer (https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/). Using that to compile a Swift script would be a logical next step.

They could even use it to treat the browser like we do with Cappuccino — automatically optimizing things to use WebGL and Canvas on the rendering layer, and not worrying about HTML & CSS.

Then they could answer their critics about writing “closed” ecosystem apps. A Swift app would compile natively to iOS, but could also compile natively to a browser, just at a reduced performance level. But it could run on Android, with browser support.

Anyway, that’s just me speculating.

[Martin Carlberg]

Interesting thoughts...

But it feels highly unlikely as they can more or less dictate how Mac and iOS developments should be done but they will have a hard time changing the default standard to code JavaScript in browsers. 

I can only see one path they can walk and that is by making a Swift -> Javascript compiler. That should be good for us :) If Apple should do one it has to be 100% compatible and you can't do that without ES6 as you need weak references. Some other stuff from ES6 will help but you can generate code to bypass those issues. I think ES6 is not finalized until december and probably takes years before end users has a compatible browser in there hands.

My guess is that if we want to code Swift in the browsers we have to do the compiler ourselves...

- Martin

[Michael Bach]

Dear Cappuccinorites:

I really like Cappuccino, and I like Objective-C. And every day 2000 people are exposed to my 40+ (tiny) Cappuccino programs (illlusions). So I invested heavily.

Having said that, for me Swift is a death knoll for Cappuccino with Objective-J.

Consider: many people don't like O-C (for whatever reasons), and what motivates them to use the closely similar O-J is the rather large O-J community, driven by iOS and Mac OS. _Assuming_ that Swift will dominate, that massively raises the bar to enter the small Cappuccino developer community.

Best, Michael.
--
Prof. Michael Bach PhD, Eye Center, University of Freiburg, Killianstr. 5, 79106 Freiburg, Germany.
Michae...@uni-freiburg.de <http://michaelbach.de>

[Andrew Hankinson]

Maybe, but this *is* Apple. They wouldn’t be interested in changing the default standard to JavaScript in other browsers. They would just add it to WebKit, and expect others to follow. If they provide the same type of development environment for Swift in a web context (i.e., Xcode) others *will* follow, since devs. will want to use those tools to make cool new things, and expect the browser folks to follow.

JavaScript has overcome a lot of early problems and is actually a nice language now. But why compile Swift->JavaScript when you can bypass JavaScript altogether and just run it natively?

[Gregg Reynolds]

On Thu, Jun 5, 2014 at 8:29 AM, Martin Carlberg <mar...@oops.se> wrote:

Interesting thoughts...

But it feels highly unlikely as they can more or less dictate how Mac and iOS developments should be done but they will have a hard time changing the default standard to code JavaScript in browsers. 

I don't think Apple cares much about public standards; if they think they can gain advantage by going around them they will do so, as they have repeatedly demonstrated.  They have no problem with Mac-only desktop and mobile apps; why should Mac-only (or Safari-only) browser apps be any different?  I would not be at all surprised to see them try to extend the "Apple OS" (Mac+iOS) to the browser and every other computing platform.

A SwiftJ would be interesting but I'd be very cautious about investing time and effort on that until Apple's plans for Swift become a lot more clear.

-Gregg

... 

[Martin Carlberg]

Apple is a massive player but I don't think they will try to do what for example Microsoft tried with IE some years ago. It will fail and they know it.

Yes, Javascript has overcome a lot of early problems. But I disagree with you about it is a nice language now. It is easy to learn and play with, has some nice features, but the lack of types and type checking etc. makes it a terrible language for larger projects.

You get no help at all to find many errors caused by this. Some of these problems will get solved with ES6 but it will take years before all starts using it. And there still will be many issues that you can't get help with from ES6.

I remember when I introduced some warnings in the new Objective-J compiler and I found around 200+ potential errors in the Cappuccino frameworks. Many of them where use of global variables instead of local. We can only guess how many others are left that no one knows about...

Swift is really a nice language for larger projects as it focus very much on safety. You get help to eliminate many of the problems languages like JavaScript has. I think it should be wonderful to have Swift for Cappuccino. I think Swift and Objective-J can live happily together in the Cappuccino world. Choice is a good thing and will help the Cappuccino community.

- Martin

[Richard van Zon]

ok, but why not look into a solution based on Emscripten (or Duetto, http://leaningtech.com/duetto/) then?

We could connect the Foundation, AppKit etc (as the Frameworks are also used in Swift).

Yes, it’s a lot of work, but it could run next to Cappuccino using Objective-J and it’s better protected to changes Apple makes to the Swift syntax.

[Andrew Hankinson]

I was thinking of ActiveX, but I think it’s a different story now. IE (i.e., Trident) wasn’t open source, and the only people using it was Microsoft. Today, everybody and their dog uses WebKit since it’s OSS. Adding Swift to WebKit would be a different story, in that you would suddenly have most of the mobile browsers using it, and a lot of the desktop ones too. Even Chrome hasn’t forked so far that adding Swift in would cause a whole lot of problems.

[Martin Carlberg]

I think this will give us more problems then it solves. We have to use the Apples frontend Swift compiler to produce LLVM bytecode. It means we can only run on Macs and you can't compile in the browser.

- Martin

[Stephen White]

On 5 Jun 2014, at 10:14 pm, Martin Carlberg <mar...@oops.se> wrote:

It is the same if we should build a JSwift (or Swift-J as Alexander suggested) compiler. It is better to add those features directly to our own compiler to generate code that are optimized for speed and are fully compatible with Cappuccino and the runtime. Much harder to do that if we has to go thru another language and compiler.

You’d need ES6 to have a compile target, which is why I keep bringing up Typescript. If there was a compiler that could output to Typescript, it would output to ES6 too.

I’m not saying that I’m right, it’s just an interesting aspect and the discussion has been interesting. The impact of such a large change will shake out for some time to come.

--

  st...@adam.com.au

[Richard van Zon]

compiling in the browser is not necessary IMO, we can use a watch on folder that quickly compiles code. Also, normally developing in xCode for MacOS or iOS it’s build and run anyway.

Swift is probably going to be big, and there will be ports of the compiler sooner or later for all platforms, so also Linux and Windows. The glue for the frameworks would be portable. The thing is, Emscripten is cool, but it misses a real GUI-toolkit (except porting Qt, which I don’t think is the way, as it’s way too big and slow) other than tech-demos. 

Using Objective-C or Swift with Cappuccino’s AppKit and such just makes sense to me. It would be amazing to use Objective-C (and in time Swift) and xCode for the web, and make it really hybrid with your native iOS and MacOS apps, like Xamarin does with C#; don’t make one app that runs everywhere, but use the same language and make them share code with each other. Also think about server-development using Node…sigh. What a world this would be. ;)

[Alexander Ljungberg]

There are situations where compiling in the browser is very nice. objj_eval is nice for debugging, plus you can make good development IDEs with a bit of code insight.

That said, if there were open source Swift to LLVM IR compilers freely available, they could be compiled to run in the browser with Emscripten themselves. It’s a clunky solution but it’s there.

Alexander

[Ingwie Phoenix]

[totally SharingThisDream:YES];

:)

[david.ri...@enquora.com]

Swift provides an opportunity (and perhaps a need), imho, to re-evaluate Cappuccino's mission statement.

My own view is that Cappuccino has provided two principal benefits which have been unique or nearly so for the last half decade:

1. A time-tested structure for delivering large-scale apps in the web browser. This is primarily a function of Cocoa rather than the implementation language. I'm partial to late-bound dynamic dispatch languages and like the syntax of Objective-C/J, but this is an implementation detail. What is more important is the wealth of open-source code and tutorial material available for Cocoa that is trivially converted for use in the browser.
2. A minimal cognitive burden when shifting from iOS development to web development. Our own apps are distributed across heterogenous clients and require both. I don't see the point in mobile usage of Cappuccino - the burden in iOS development is in learning Cocoa, not the implementation language. Cross-platform mobile delivery has already been addressed by other frameworks/libraries that are lighter on their feet and have been eagerly adopted by those with less complex application needs who value language familiarity above user experience.

 Swift probably requires another year of refinement before the non-adventuresome will adopt it, but it seems a certainty that Objective-C is deprecated in the Apple ecosystem. As uptake increases, it's worth re-focusing on where Cappuccino fits in the world. We have a window to do this, but the landscape has clearly changed dramatically since Capp was first released. Focus is essential to maintaining a healthy project.

[david.ri...@enquora.com]

To elaborate my post, there now exist multiple framework/library/compile-to-javascript projects that are suitable for large-scale in-browser apps. They are mostly reactive UIs combined with functional languages, don't have well-developed UI modules available, and are lest well developed, but Cappuccino is not longer unique in this space.

If the advantage of a strong backing ecosystem for Objective-C/J fades, it is worth re-focusing the project's mission statement. imho.

[Alexander Ljungberg]

I tend to agree but we’ll need to watch the Swift situation. Even if this becomes important for us, it’s not a small nor easy addition.

Alexander

On 9 June 2014 at 19:44:00, david.ri...@enquora.com (david.ri...@enquora.com) wrote:

To elaborate my post, there now exist multiple framework/library/compile-to-javascript projects that are suitable for large-scale in-browser apps. They are mostly reactive UIs combined with functional languages, don't have well-developed UI modules available, and are lest well developed, but Cappuccino is not longer unique in this space.

If the advantage of a strong backing ecosystem for Objective-C/J fades, it is worth re-focusing the project's mission statement. imho.

[Stephen White]

On 10 Jun 2014, at 5:21 am, Alexander Ljungberg <stil...@gmail.com> wrote:

I tend to agree but we’ll need to watch the Swift situation. Even if this becomes important for us, it’s not a small nor easy addition.

With the LLVM backend, perhaps Swift syntax could compile to Javascript? Then the work is only in stitching up to the Cappuccino backend.

--

  st...@adam.com.au

[Aparajita Fishman]

With the LLVM backend, perhaps Swift syntax could compile to Javascript? Then the work is only in stitching up to the Cappuccino backend.

Any time someone says "only" or "just" in relation to software, I get scared, especially when that person may not be planning to do the work themselves.

Let's try to think this through a little more deeply:

- Someone would "only" have to rewrite all of Cappuccino in Swift. This is far more than just translating the syntax. Swift is a strongly typed language, which means we would "only" have to rewrite all of the code that relies on the loose typing of Javascript.

- Then someone would "only" have to write an LLVM -> Javascript translator that generates the correct Javascript code for use with Cappuccino. emscripten may not work for us.

- Then someone would "only" have to essentially write a linker that would modify the generated Javascript code to insert the DOM-specific code that glues Cappuccino to the browser.

As a colleague used to say, hey, it's "only" typing.

I agree that Swift is ultimately the future. But lets not get too far ahead of ourselves, it is still in beta and Apple said they cannot even guarantee code compabitility in the short term as it evolves.

[Aparajita Fishman]

I should add that one of the major things I have been working on is debugging in the browser using the original Cappuccino source files. This can be done with the use of source maps. If we go the LLVM -> Javascript route, we lose that ability, unless someone writes a Swift source map generator.

[Gregg Reynolds]

On Tue, Jun 10, 2014 at 10:01 AM, Aparajita Fishman <apar...@aparajitaworld.com> wrote:

With the LLVM backend, perhaps Swift syntax could compile to Javascript? Then the work is only in stitching up to the Cappuccino backend.

Any time someone says "only" or "just" in relation to software, I get scared, especially when that person may not be planning to do the work themselves.

Let's try to think this through a little more deeply:

- Someone would "only" have to rewrite all of Cappuccino in Swift. This is far more than just translating the syntax. Swift is a strongly typed language, which means we would "only" have to rewrite all of the code that relies on the loose typing of Javascript.

- Then someone would "only" have to write an LLVM -> Javascript translator that generates the correct Javascript code for use with Cappuccino. emscripten may not work for us.

- Then someone would "only" have to essentially write a linker that would modify the generated Javascript code to insert the DOM-specific code that glues Cappuccino to the browser.

As a colleague used to say, hey, it's "only" typing.

What could possibly go wrong?

;) 

[Aparajita Fishman]

What could possibly go wrong?

;) 

I have a better question: who could possibly have the time or money to do all that?

[Aparajita Fishman]

And one more thing: if we use a LLVM -> Javascript approach, we will no longer be able to mix actual Javascript code with Swift code, which is necessary if you are using a third party Javascript library.

In other words, the only practical solution to using Swift with Cappuccino is to write our own Swift compiler. Hey, it's only typing!  ;-)

[Richard van Zon]

You can use external libraries in the end-result. Just like WebGL,  is supported for example. It just ust needs some glue ;-)

On 10 juni 2014 at 17:51:55, Aparajita Fishman (apar...@aparajitaworld.com) wrote:

And one more thing: if we use a LLVM -> Javascript approach, we will no longer be able to mix actual Javascript code with Swift code, which is necessary if you are using a third party Javascript library.

In other words, the only practical solution to using Swift with Cappuccino is to write our own Swift compiler. Hey, it's only typing!  ;-)

[Mathieu Monney]

What about separating ObjJ and Swift this way:

- .j files would be compiled using the current ObjJ compiler and would contain only ObjJ code or Javascript

- .s file would be compiler with LLVM to Javascript. 

At the end everything is javascript. 

This is highly similar to the Apple, if I am not mistaken, approach where you would be able to mix C/C++ code with ObjC but you wouldn't be able to do it with Swift. However at the end, all object code is linked together making the approach viable.

Mathieu

Le 10 juin 2014 à 17:51, Aparajita Fishman <apar...@aparajitaworld.com> a écrit :

And one more thing: if we use a LLVM -> Javascript approach, we will no longer be able to mix actual Javascript code with Swift code, which is necessary if you are using a third party Javascript library.

In other words, the only practical solution to using Swift with Cappuccino is to write our own Swift compiler. Hey, it's only typing!  ;-)

--

[Richard van Zon]

Exactly, that's the glue I am talking about. This is how Emscripten projects work.

I was also thinking, because Swift is kinda similar to javascript at some points. Maybe it's an idea to do everything in JavaScript. So, add classes, maybe even types( or use TypeScript). And have something like:

Var button = CPButton(CGRectMake(0, 0, 50, 50))

self.view.addSubview(button)

This is almost Swift. We can use the existing Obj-J code (kinda how Apple does it). We have javascript with an awesome UI toolkit. We have interface builder. Heck, maybe even we get JavaScript developers onboard! ;)

[Stephen White]

On 11 Jun 2014, at 12:31 am, Aparajita Fishman <apar...@aparajitaworld.com> wrote:
>> Any time someone says "only" or "just" in relation to software, I get scared, especially when that person may not be planning to do the work themselves.

Good point. :)

> Let's try to think this through a little more deeply:
>
> - Someone would "only" have to rewrite all of Cappuccino in Swift. This is far more than just translating the syntax. Swift is a strongly typed language, which means we would "only" have to rewrite all of the code that relies on the loose typing of Javascript.

No, wait… at least understand the idea before it is dismissed, especially in light of the above good point!

LLVM can output to Javascript, so as a language Swift should already be available in the browser. The same as cross compiling a C++ game engine or using emscripten. (this bit of the fantasy isn’t real yet!)

The original source code is written for Cappuccino, not Cocoa. There is no expectation of trying to have cross-platform code. So the Javascript emitted from LLVM/emscriptenish (should) (just) make the same Cappuccino calls as now.

> - Then someone would "only" have to essentially write a linker that would modify the generated Javascript code to insert the DOM-specific code that glues Cappuccino to the browser.

Cappuccino has the DOM specific code, so at the language level it’s (just) how to convert the Swift calls to existing Objective-J methods. Swift as a language was designed for maximum compatibility with Objective-C and yet is standalone. Most of the code would emit to Javascript that (just) runs what was written in Swift.

So the vague line in the sand would be when Swift can emit to Javascript, then initialising Cappuccino and awaiting the objj_msgSend calls. If it’s more work than that, then I’m not seriously proposing it because of that above good point you made. But at least I’m not proposing a massive effort! :)

> I agree that Swift is ultimately the future. But lets not get too far ahead of ourselves, it is still in beta and Apple said they cannot even guarantee code compabitility in the short term as it evolves.

And that’s the bit that is a fantasy… but the rest (should) just work!

--
st...@adam.com.au

[Aparajita Fishman]

Using external libraries wasn't my point. Objective-J is a superset of Javascript, which allows one to freely mix Objective-J and Javascript in the same file. How will that will be possible using the LLVM->Javascript approach? And if not, then you are forcing developers to segregate all native Javascript code into separate files, which of course is possible but will not be greeted with enthusiasm.

[Todd Freese]

Let me add to Aparajita's points that all of this would need to run on Windows and Linux! Developing with Capp needs to be just as easy on Windows as on a Mac for the market share to grow. 

T

[Martin Carlberg]

I can only fill in that it is very important to be able to run on all platforms. There is nothing available today that will help us include Swift to the Cappucino world. Emscripten will not help as we have to make a frontend compiler and bridge the end result to the Cappuccino runtime. That solution will take more time to implement and will also be much slower. The only reasonable solution today is to make our own Swift compiler. As Aparajita said, someone just has to start typing...

- Martin

10 jun 2014 kl. 20:06 skrev Todd Freese <to...@filmworkers.com>:

Let me add to Aparajita's points that all of this would need to run on Windows and Linux! Developing with Capp needs to be just as easy on Windows as on a Mac for the market share to grow. 

T

[Alexander Ljungberg]

Swift-J would not be a superset of JavaScript. It’s just not possible due to syntax name clashes.

It’s probably fine. Objective-C was a superset of C and we managed to make Objective-J a superset of JS correspondingly. But Swift is not a superset of C so neither should Swift-J be a superset of JS.

In any scenario where we make a Swift compiler, any JS code would have to be separate pure JS functions/files.

Also, I don’t think we should even consider rewriting Cappuccino itself (any time soon). It’s enough to write the compiler and let it send messages to the existing code. In fact rewriting Cappuccino itself would still require it to be used ‘in API form’, if not by Swift code then by legacy Objective-J code.

To support strong typing we can use our existing type info or require the user to cast all the results appropriately. We’ll need to watch how this plays out with Swift in Apple land — e.g. when you call a Cocoa method with a fuzzy ‘id’ return type in Swift, what do you need to do with regards to its type?

Even with this limited scope though writing such a compiler is a significant undertaking.

Alexander

On 10 June 2014 at 19:36:19, Aparajita Fishman (apar...@aparajitaworld.com) wrote:

Using external libraries wasn't my point. Objective-J is a superset of Javascript, which allows one to freely mix Objective-J and Javascript in the same file. How will that will be possible using the LLVM->Javascript approach? And if not, then you are forcing developers to segregate all native Javascript code into separate files, which of course is possible but will not be greeted with enthusiasm.

[Stephen White]

On 11 Jun 2014, at 4:38 pm, Alexander Ljungberg <stil...@gmail.com> wrote:

Even with this limited scope though writing such a compiler is a significant undertaking.

So the key point of this LLVM proposal is to wait for Apple to make the compiler available as part of the LLVM toolchain, and then it will run on Linux and Windows too.

If Apple does not make Swift available, then ignore the proposal. I’m just pointing out that if it was available, then gluing LLVM to the existing Cappuccino would work.

--

  st...@adam.com.au

[Martin Carlberg]

I think this is not an alternative even if Apple makes the Swift compiler available as part of the LLVM toolchain. We are moving towards a Javascript only environment. We don't want tools that are not Javascript. We want to be able to compile in the browser or in a nodeJS only environment. And it will be to slow...

- Martin

[Alexander Ljungberg]

Well, LLVM is available as JavaScript so that’s not necessarily a barrier.

What could be a barrier would be complexity and size. 

I’m open to go either way, a home brew transpiler could be faster and simpler. On the other hand, there’s a lot to gain from avoiding the ‘not build here’ syndrome too. LLVM is pretty good software.

Alexander

[Carl Mathisen]

Have you guys seen ShiftJS? Swift to JavaScript transpiler. Still in development.