a cross-platform development day-dream

95 views
Skip to first unread message

Raoul Duke

unread,
Dec 8, 2014, 8:31:05 PM12/8/14
to augmented-programming, PiLuD
* I write my code in some HLL like Haxe or Shen where the HLL has
already been ported to the N languages/hosts I want to target. (iOS
Objective-C, Android Java or C++, Desktop Javascript HTM5, embedded
PIC C code, et. al.)

* When I need something 'concrete' that isn't in the HLL I can write
an escape-into-native-ffi-code type construct.

* The IDE helps me with code completion / guidance / whatever in
making the HLL interface to the 'native' stuff.

* It also gives me a great UI/UX wrt writing and managing the N
different implementations i'll have to write of said 'native' stuff.

* It manages the underlying project similarly, so that things are,
from the get-go, kept clean and sane and not all jumbled or inlined
nastily in any way (at least in terms of the source, if not in terms
of the final result).

* It also somehow helps me upload/download/integrate these 'native'
things with other people's repos of similar 'native' things.

¿or if you think that sounds utterly in vain and silly and dumb, do
you have thoughts about how best to day-dream about a great way to
really develop cross-platform stuff?

Paul Tarvydas

unread,
Dec 9, 2014, 9:43:31 AM12/9/14
to pi...@googlegroups.com
See "Doug shows Thrust" for possible ideas for a portable UI...

http://lispwiki.inaimathi.ca/2014%20December%20Meeting

and

https://github.com/breach/thrust

David Barbour

unread,
Dec 9, 2014, 2:05:43 PM12/9/14
to pi...@googlegroups.com
My own thoughts on cross-platform development: 

My intuition is that that calling out to lots of platform-specific libraries is a bad idea, because it requires understanding lots of potential configurations to understand the behavior of the application. To the extent we have platform-specific content, it should ideally be externalized, separated from the application's behavior description. 

This separation might be achieved using dependency injection (provide capabilities to the application using a staged model), but that sort of staging causes its own issues - e.g. you cannot easily persist and restore the application, nor readily mobilize it from the user's tablet to the desktop. A potentially better approach is to externalize the adaptation itself, e.g. using something like the adapter pattern or a monad transformer.

To support external adapters, the first thing we need to do is abandon the `public static void main(args)` model for applications. That particular 'type' of application forces us to use adapters based on 'calling out' to platform-specific content. We need a type that is more sophisticated, that has enough features that we can wrap something around it rather than only tweak it internally. The 'type' of an application should thus be an object, or even a pure function. I am especially interested in purely functional objects, i.e. functions without side-effects of types like:

    type Object = (Method → (Object, Result)).

This idea is available in more sophisticated varieties, e.g. based on which 'common methods' we want to support, and whether we want to model side-effects using algebraic effects or similar. A more mature option is the 'machines' model presented by Rúnar Óli Bjarnason [1] and implemented as a haskell library by Edward Kmett [2].

This isn't a new idea. The WAI application [3] is a concrete example of an application 'type' oriented towards web servers, and implemented for many 'platforms' like Warp and FastCGI. WAI focuses on HTTP requests and responses. Other application 'types' might focus on user input and display. I think it would only take a handful of application types to cover all the common scenarios from various user applications to services to robotic control and home automation.


The general principle:

Instead of internal adapters to different platform-types, 
external adapters to different application-types. 


We never 'escape' to write native code. But we might gradually evolve new application types, and perhaps leverage algebraic effects.

Besides being portable and cross-platform, an advantage of a sophisticated application 'type' is that applications themselves become more readily composable into larger applications and systems. It's easy to combine a record of WAI apps into a larger app with many URL directories. In comparison, it's stupidly difficult to directly compose `int main(args)` in a useful manner.

For the other features I mentioned (mobility, persistence), I'll need the ability to serialize my function-objects. In the above example, the function is slowly developed over time: each 'Method' results in a new 'Object' function, which might have slightly different code. For this purpose, a bytecode seems more appropriate than either a high level language or an 'in-memory only representation' that cannot consistently be serialized. All values would also need to be serializable.

A bytecode should be trivial to interpret, so at least we can get inefficient cross-platform adapters very easily. It should also be easy to compile. Cross-compilation can target stuff like LLVM or C for a quick boost, but will take a lot longer to mature. A concept of 'bytecode resources' - e.g. based on a secure hash of bytecode to download resources from a distributed hashtable or content distribution network [4] - could even support separate compilation and caching without involving the installation and integration overheads and security issues of applications today.

Usefully, if we have bytecode that is easily distributed and easily compiled for different platforms, we can more readily create interesting applications that 'shard' into lots of small pieces and distributed objects for different platforms. I think addressing this distributed programming story is a very good future direction for programming.

Awelon Bytecode (ABC), a bytecode I've been developing, is created with the above vision of cross-platform support in mind. I would consider it a primary candidate for the above approach. But I'm sure others can be made to work.

[1] https://dl.dropboxusercontent.com/u/4588997/Machines.pdf

Raoul Duke

unread,
Dec 9, 2014, 2:08:24 PM12/9/14
to PiLuD
Thanks for the thoughts and insights. I'd very happily be a Beta
tester! :-) And will try to leverage this all as food for thought when
I'm mucking around with my own mucky code and apps. Looking forward to
Awelon's success.
Reply all
Reply to author
Forward
0 new messages