[racket] Dr. Racket for iOS

Hi Neil,

I can't get past the idea that tablets are a terrible environment to
do development.
- screen to small & made smaller by on-screen keyboard
- limited resources(ram/flash/mhz/cores) compared to a cheap laptop

As for developing for tablets Whalesong is impressive.
'raphael-demo.html [src] Uses features of the JavaScript FFI to access
theRaphaelJS vector graphics library.' -
http://hashcollision.org/whalesong/
I'll be having a look at doing the same thing with d3 (http://d3js.org/ ).

LambdaNative is really interesting, but I wish it was the Racket, with
the JIT rather than gambit because I like Racket. Alas a fork is
beyond my skills. (and the Racket JIT would probably flatten the
battery of a tablet)

http://download.racket-lang.org/docs/5.1/html/raco/ext.html
LambdaNative
'LambdaNative is a cross-platform development environment written in
Scheme, supporting Android, iOS, BlackBerry 10, OS X, Linux, Windows,
OpenBSD, NetBSD and OpenWrt.' -- http://www.lambdanative.org


Kind regards,

Stephen

--
Stephen De Gabrielle
stephen.degabrielle at acm.org
Telephone +44 (0)20 85670911
Mobile        +44 (0)79 85189045
http://www.degabrielle.name/stephen


On Mon, Apr 7, 2014 at 10:29 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
> Rather than iOS-specific and Android-specific apps (either JVM-ish or native
> code), I'd like to suggest focusing instead on targeting *HTML5 offline
> apps*.
>
> I'm working successfully on HTML5 offline apps for technical software right
> now, and I think HTML5 is a good way to go to get device independence, at
> the same time as making the apps not necessarily cloud-lock-in/spyware (like
> most mobile apps and services right now have become).
>
> On the impractical side, JavaScript is simply an awful language for app
> development, for no good reason.  (JavaScript was better as a tiny script
> language for hooking up Java applets in Web pages, and it hasn't evolved as
> well as it could've.)
>
> So I'm seeing a few different ways that Racket could fit with offline HTML5
> apps:
>
> * Just doing the app in HTML5 and JS, but use Racket on the server.
>
> * Like #1, but use Racket as a compilation step to add something more like
> macro facilities to HTML and JS.
>
> * Write key app algorithms in Racket and have translated to JS. (Note: This
> is for nontrivial algorithms.  Practical JS is so intertwined with DOM
> manipulation, and working with libraries/frameworks oriented towards JS
> dumbness, that I'm not seeing benefit trying to generate all the JS code
> from Racket, only select pieces.)  (Incidentally, this might also give you
> obfuscation, which sometimes you might want if the copyright owner doesn't
> want to share source and give away rights to copy&paste 'derivative works'
> and such.  But the main benefit is to write algorithms in a real language
> rather than a scripting language.)
>
> * Write entire app in Racket, forgetting about existing HTML5 frameworks,
> using Racket UI facilities (perhaps the same MrEd GUI and eventspace stuff
> as used by DrRacket et al.).  Have this compiled to JS or a JS-implemented
> VM, together with DOM/CSS/canvas/etc. for the UI.  You could implement a
> large persistent filesystem that DrRacket sees using HTML5 IndexedDB (and
> Web SQL on iOS, until they decide to join everyone else with IndexedDB).
> Then you might be able to get the existing DrRacket source to compile to
> this HTML5, and then run on all the modern tablets in browsers and as
> offline apps, maybe with OK performance.
>
> I think Danny Yoo's Whalesong(?) might have much of the same idea as the
> last option, but I haven't looked at it, and don't know how much of his
> implementation could be reused for this somewhat different purpose.
>
> Neil V.
>