
Call OCaml from Objective-C, run on iOS, code sample and build steps - e_d_g_a_r
http://hyegar.com/blog/2016/01/23/calling-ocaml-from-objective-c-on-the-iphone/
======
hellofunk
OCaml is a much more interesting language to me for writing iOS or any other
app than Swift is.

~~~
melling
OCaml support on iOS is really cool but it needs more tooling and a critical
mass in community size before it'll gain any kind of traction.

Many developers still won't use Swift, for instance, because they think it's
not ready for production yet. And there have been over three dozen Swift books
published in 18 months:
[http://www.h4labs.com/dev/ios/books](http://www.h4labs.com/dev/ios/books)

~~~
hellofunk
There are a number of issues with Swift, though I'm sure they will improve:

1) No backwards compatibility: developers must keep rewriting their Swift code
with each new Swift release, since syntax and features often change.

2) Swift's interaction with C++ is a non-starter, and many, many apps use C++.

3) Some C APIs are still quite difficult to use from Swift. Objective-C, being
a strict superset of C, makes it very easy to use Core Audio, for instance.
OpenGL interop can also be a bit frustrating.

4) Swift's "functional" idioms are weak and poorly implemented. If you can't
provide a true functional backdrop to these features, they probably shouldn't
even be in there. Coming from a real functional language, you're in for nasty
surprises in Swift if you casually use higher-order functions all over the
place, because there is a lot of copying going on.

5) Swift's performance is definitely not, shall I say, "swift," though
hopefully that will eventually improve.

6) Poor and confusing compiler errors.

I actually realize now that I could go on all day about this.

~~~
autoreleasepool
I'd say most of your criticisms are unimportant nitpicks from a pragmatic
perspective (i.e. from the perspective of: I work on iOS apps and I want to
get. things. done.).

 _> 1) No backwards compatibility: developers must keep rewriting their Swift
code with each new Swift release, since syntax and features often change._

Nobody cares. We are very used to this. If you program iOS apps for a living,
you know this has always been the case. Every new version of Xcode and iOS
breaks code. With Cocoa and CocoaTouch, the language can at times feel like
nothing more than a way to call the ever-changing SDK APIs.

It doesn't matter if your app is written Objective-C (a language that also
continues to change every year), Swift, Ruby-motion, whatever... it'll break
on the new Xcode. If not, you think something is wrong and pray the issue does
not arise later.

Anyways the syntactic and semantic updates to Swift are automated fairly well,
anyways, so this not really a major pain point IMO.

 _> 2) Swift's interaction with C++ is a non-starter, and many, many apps use
C++._

True, many apps use C++. While, I, personally, would _love_ to see C++ intro
arrive before Swift 4.0 or 5.0, it's a feature that for all practical purposes
is a luxury that we can live with out.

Use an Objective-C wrapper, then call it from Swift. All C++ that is called in
the UIKit layer should be wrapped in an Objective-C API's anyways
(UIViewController.mm is harmful!), so no big deal. The exception to this is,
if you were trying to write an app in pure Swift. In that case, using C++
breaks the purity anyways, so you might as well use Objective-C wrappers.

 _> 3) Some C APIs are still quite difficult to use from Swift. Objective-C,
being a strict superset of C, makes it very easy to use Core Audio, for
instance. OpenGL interop can also be a bit frustrating._

Support is definitely good enough. Again, if you need more you can (and
should) use both languages. Swift was designed to be used in an Objective-C
codebase.

 _> 4) Swift's "functional" idioms are weak and poorly implemented. If you
can't provide a true functional backdrop to these features, they probably
shouldn't even be in there. Coming from a real functional language, you're in
for nasty surprises in Swift if you casually use higher-order functions all
over the place, because there is a lot of copying going on._

I disagree. I believe the functional constructs add a ton of utility to the
language. The key is to understand how they were designed to fit into the
langauge. It helps to be a bit of a language lawyer, but the compiler can
optimize away copied value types in a way that references cannot be optimized.
WWDC spoke a lot on value types, functional programming, and their possible
design implications in Swift 2.0

see:
[https://developer.apple.com/videos/play/wwdc2015-408/](https://developer.apple.com/videos/play/wwdc2015-408/)

and:
[https://www.youtube.com/watch?v=av4i3x-aZbM](https://www.youtube.com/watch?v=av4i3x-aZbM)

and:
[https://www.youtube.com/watch?v=vgK8jaf8nlk](https://www.youtube.com/watch?v=vgK8jaf8nlk)

 _> 5) Swift's performance is definitely not, shall I say, "swift," though
hopefully that will eventually improve._

Swift is more than fast enough for applications development. Once an
alternative to ARC rises (see comments bellow), it will be a competitor for
real time systems.

ARC guarantees that there will be no pauses. With a language like go, you are
blazing fast until the GC pauses everything. With ARC trade raw execution
speed for a consistent and stable speed with no pauses or fluctuations in
performance. This is because ARC is static. The retain/release code is
injected at compile time. So while there is a performance overhead for
allocating and deleting on the heap, there is no pause. To avoid the overhead,
you can use structs instead of classes and protocol extensions for
polymorphism.

 _6) Poor and confusing compiler errors._

The language was released in 2014. The error messages are being actively
worked on. They were vastly improved with 2.0.

EDIT: to be fair, you did say "I'm sure it will improve".

~~~
cballard
> The language was released in 2014. The error messages are being actively
> worked on. They were vastly improved with 2.0.

Well, "Segmentation Fault" hasn't really improved, and it's reasonably common
when type inference in closures breaks down.

~~~
autoreleasepool
I'm unfamiliar with this situation. Is this truly a common problem? I'd love
to see a source code example to test.

~~~
cballard
Pretty consistent for me in projects that are:

\- Sufficiently large

\- Contain a closure that contains a compiler error

\- Which the compiler tries to work around via type inference, causing another
error

------
melling
Think this is related to one of Edgar's blogs that was discussed yesterday:

[https://news.ycombinator.com/item?id=10960753](https://news.ycombinator.com/item?id=10960753)

