Build Android Apps in PicoLisp Without an Android SDK(picolisp.com)
picolisp.com
Build Android Apps in PicoLisp Without an Android SDK
https://picolisp.com/wiki/?pilbox
51 comments
Out of curiosity, OP: did you fall in the same rabbit hole I fell into after reading the article about the chorded keyboard, finding the link to the picolisp wiki and seeing the snippets about showing notifications on Android via picolisp?
What’s weird is for some reason I’m seeing the chorded keyboards layout over the top of some of the images in this article.
yes :)
This is similar to how LÖVE games work on Android [1], you download the app from the store and then load a .zip file of your game and it runs inside that. You can then make it into its own app and publish it to the store.
[1] https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/FAQ...
[1] https://bitbucket.org/MartinFelis/love-android-sdl2/wiki/FAQ...
LÖVE is awesome and Android port works great. The fastest interpreted language that also happens to be elegant and easy to learn, coupled with dead-simple input/graphics/audio/physics API you can actually remember. The APK is tiny when compared to other frameworks, some 4 Mb + assets.
Kind of LambdaNative? http://www.lambdanative.org/
But LambdaNative does require installing Android SDK, no? → https://github.com/part-cw/lambdanative/wiki/Getting-Started...
A bit.
But what fills me with joy is the REPL. It's hugely helpful when trying to make use of unfamiliar APIs.
But what fills me with joy is the REPL. It's hugely helpful when trying to make use of unfamiliar APIs.
On limited input devices as tablets and phones I haven't yet found anything better than Lisping.
https://appadvice.com/app/lisping/512138518
Which appears to no longer be available.
https://appadvice.com/app/lisping/512138518
Which appears to no longer be available.
I'm slightly confused by this paragraph, what is being emulated and aren't most android devices 32 bit these days?
"It comes with PicoLisp binaries for Arm64 pre-installed. If your device has an Arm32 CPU, you can - after installing the PilBox App but before starting it - download and install the emulator version https://software-lab.de/arm32.zip. If this was done by mistake, you can revert to Arm64 binaries with..."
"It comes with PicoLisp binaries for Arm64 pre-installed. If your device has an Arm32 CPU, you can - after installing the PilBox App but before starting it - download and install the emulator version https://software-lab.de/arm32.zip. If this was done by mistake, you can revert to Arm64 binaries with..."
The 64-bit version of PicoLisp is written in a generic assembler which
is then built for target CPUs like x86-64, arm64, ppc64 or "emu". In "emu"
the target "CPU" is plain-C, and this is used if the Android device
is physically only 32 bit.
I'm confused too, how do you install the zip file?
Even one of the feedback posts mentions problem solved by "just installing the emulator version".
So I download arm32.zip in, say, firefox, and then what? Open it with PilBox just crashes. Clicking it in a file manager shows me the zip contents. Am I supposed to extract it somewhere? I'm not rooted so can't see the app dirs.
Even one of the feedback posts mentions problem solved by "just installing the emulator version".
So I download arm32.zip in, say, firefox, and then what? Open it with PilBox just crashes. Clicking it in a file manager shows me the zip contents. Am I supposed to extract it somewhere? I'm not rooted so can't see the app dirs.
The easiest way seems to be to download it with a browser, and then immediately
click on "open" in the little dialog which pops up in the browser after it
downloaded the zip. It is then passed to PilBox.
Clicking on a Zip in the Downloads app works on some devices, but other systems only offer to extract the files which does not help here.
Clicking on a Zip in the Downloads app works on some devices, but other systems only offer to extract the files which does not help here.
(1)download the zip
(2)go to the downloads folder
(3)tap/click the file
(4) choose to open with pilbox
I'm assuming the 32-bit version emulates a 64-bit ARM CPU. Most Android devices are 32-bit, but a lot of the newer ones are 64-bit.
I have a node-red instance that does a similar thing, to allow drag-n-drop programming (Including UI), and (using dnr) heterogeneous cluster processing on mobiles (ios and android).
It starts a node-red server on the device, and uses cordova to host the webview.
I'm in the process of adding an ag-grid node so you can do complex UIs in the dev environment on the phone/tablet.
https://github.com/alexisread/noreml
It starts a node-red server on the device, and uses cordova to host the webview.
I'm in the process of adding an ag-grid node so you can do complex UIs in the dev environment on the phone/tablet.
https://github.com/alexisread/noreml
tl;dr on how it works:
> The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.
I think this is a really cool project and I'm all for new (to me) lisp dialects doing their thing, but reading the main page, the tag line and copy don't seem to match, for my definition of "simple":
> [picolisp is] Programming simplified!
> PicoLisp is a programming language, or really a programming system, including a built-in database engine and a GUI system!
These two statements seem to be at odds.
That aside, I do like the idea because I'm a huge fan of the HTML/JS/CSS display paradigm for it's easy cross-platform support.
I also like reducing the "mobile app" to really just interacting with a single local "edge" (which is what people are calling client-side programs these days I think) server. Just me personally but I would love it if all frontend development was reduced to HTML/CSS/JS -- I have no desire to learn QT/GDK+/wxWidgets/whatever else (just like I don't like learning Java for Android, Swift/ObjC for iOS, Java for Blackberry, etc), and firmly believe that eventually performance will be comparable (or close enough to not matter) and support for native features will be passable.
> The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.
I think this is a really cool project and I'm all for new (to me) lisp dialects doing their thing, but reading the main page, the tag line and copy don't seem to match, for my definition of "simple":
> [picolisp is] Programming simplified!
> PicoLisp is a programming language, or really a programming system, including a built-in database engine and a GUI system!
These two statements seem to be at odds.
That aside, I do like the idea because I'm a huge fan of the HTML/JS/CSS display paradigm for it's easy cross-platform support.
I also like reducing the "mobile app" to really just interacting with a single local "edge" (which is what people are calling client-side programs these days I think) server. Just me personally but I would love it if all frontend development was reduced to HTML/CSS/JS -- I have no desire to learn QT/GDK+/wxWidgets/whatever else (just like I don't like learning Java for Android, Swift/ObjC for iOS, Java for Blackberry, etc), and firmly believe that eventually performance will be comparable (or close enough to not matter) and support for native features will be passable.
Easy cross platform at the expense of user experience.
Not to mention dev experience. JS is a horrible language that doesn’t scale beyond script kiddie nonsense.
You're right in that JS is a horrible language -- it was designed very quickly (and IMO Brendan Eich did a great job in the time he was given).
There are some things JS got right and things JS got wrong -- but I basically put it at the same level as languages like python/ruby/perl.
Another great thing about JS is that if you hate the semantics of JS, you can transpile -- pick up Typescript, Flow, Elm, Purescript. Compile-time-checking-as-an-addon, linters, transpilers, have all seen a tremendous uptick in interest partly thanks to JS's shortcomings.
Also, what in your opinion is a "good" language? because the list of innovative languages with amazing time-saving features/ground breaking research in them is very different from the list of workhorse languages people use from day to day.
There are some things JS got right and things JS got wrong -- but I basically put it at the same level as languages like python/ruby/perl.
Another great thing about JS is that if you hate the semantics of JS, you can transpile -- pick up Typescript, Flow, Elm, Purescript. Compile-time-checking-as-an-addon, linters, transpilers, have all seen a tremendous uptick in interest partly thanks to JS's shortcomings.
Also, what in your opinion is a "good" language? because the list of innovative languages with amazing time-saving features/ground breaking research in them is very different from the list of workhorse languages people use from day to day.
But but hundreds of top websites and now even unity uses js, definitely not script kiddie
Because JS has been the only browser native language.
As for Unity, I am not so sure about it.
https://blogs.unity3d.com/2017/08/11/unityscripts-long-ride-...
As for Unity, I am not so sure about it.
https://blogs.unity3d.com/2017/08/11/unityscripts-long-ride-...
This is all by unfortunate necessity, certainly not by choice.
The very raison d’etre of languages like TypeScript that transpile to JavaScript is because of the flaws of this hack language that simply found itself in the right place at the right time in history
And it's all only temporary in light of WebAssembly.
It can scale but it takes an increadible amount of care.
Everything has to have unit tests and documentation and be split out into reasonable modules. Large scale projects in C are honestly easier to work on than JavaScript.
It does scale but almost no one puts in the effort to do it.
Everything has to have unit tests and documentation and be split out into reasonable modules. Large scale projects in C are honestly easier to work on than JavaScript.
It does scale but almost no one puts in the effort to do it.
But this is one of the things that I think will disappear over time. What parts of the user experience are bad for you? Accessibility? Raw speed? Native transitions?
It's entirely possible to write a completely native app with terrible user experience. Right now making an app with great UX is hard, but I don't think it gets easier by solving it separately for different platforms, I think it's easier to build giants to stand on by focusing on one platform.
Also, people talk about UX a lot, but half of the most successful apps out there have really basic UX, and are basically websites to start with.
It's entirely possible to write a completely native app with terrible user experience. Right now making an app with great UX is hard, but I don't think it gets easier by solving it separately for different platforms, I think it's easier to build giants to stand on by focusing on one platform.
Also, people talk about UX a lot, but half of the most successful apps out there have really basic UX, and are basically websites to start with.
- Behaviour
- Sluggishness
- Not able to use OS widgets. They might look similar with lots of CSS effort, but we stay at the L, instead of L&F
- PWAs are a step in the right direction, yet ServiceWorkers feel like a hack for what native applications get for free
- As a example, writing an application that can seamless transition between mobile and desktop platforms, like Microsoft's Project Rome.
Many successful apps with lousy UX are successful, because they are the only way to access certain services.
As a consumer I only use web apps when there is no way around it.
As a developer I don't get to be picky about which projects I get to work on, but I surely make my point of view every time customers ask for something that can only be provided by proper OS integration.
- Sluggishness
- Not able to use OS widgets. They might look similar with lots of CSS effort, but we stay at the L, instead of L&F
- PWAs are a step in the right direction, yet ServiceWorkers feel like a hack for what native applications get for free
- As a example, writing an application that can seamless transition between mobile and desktop platforms, like Microsoft's Project Rome.
Many successful apps with lousy UX are successful, because they are the only way to access certain services.
As a consumer I only use web apps when there is no way around it.
As a developer I don't get to be picky about which projects I get to work on, but I surely make my point of view every time customers ask for something that can only be provided by proper OS integration.
> - Behavior
I'm not sure what this means... You mean like the propensity of web apps to open non-native modals?
> - Sluggishness
This really depends on what kind of blended app you're using. Cordova (PhoneGap) and all the webview-based things are pretty terrible for this, but newcomers (react-native, nativescript) have been doing much better with the bring-your-own-js-engine-and-render-on-separate-thread approach.
> - Not able to use OS widgets
This is completely overcome-able with sustained effort, and appropriate sharing. Flutter literally decided to draw every single pixel on the screen and was able to do it, CSS styling is easier in comparison.
Also, this isn't a problem for the hybrid frameworks like react-native or nativescript, they do use native widgets, but you lay them out, style them, and perform interactions with HTML/CSS/JS mostly, which is preferable to trying to figure out each platforms layout quirks.
> - PWAs are a step in the right direction, ...
Yeah I think I wasn't clear enough with what I wrote -- I don't mean I want the web itself to become the mobile platform, I just mean I like approaches like nativescript and react-native/vue-native much more than learning ios and android separately, and think the HTML/CSS/JS paradigm is better than those things individually.
ServiceWorkers are the only solution if you are talking about a purely web app (webview) -- you can actually shim and use native stuff if you want, OR serviceworkers, or whatever else if you take the hybrid approach, while maintaining html/css/js for most interactivity.
I'm not sure what this means... You mean like the propensity of web apps to open non-native modals?
> - Sluggishness
This really depends on what kind of blended app you're using. Cordova (PhoneGap) and all the webview-based things are pretty terrible for this, but newcomers (react-native, nativescript) have been doing much better with the bring-your-own-js-engine-and-render-on-separate-thread approach.
> - Not able to use OS widgets
This is completely overcome-able with sustained effort, and appropriate sharing. Flutter literally decided to draw every single pixel on the screen and was able to do it, CSS styling is easier in comparison.
Also, this isn't a problem for the hybrid frameworks like react-native or nativescript, they do use native widgets, but you lay them out, style them, and perform interactions with HTML/CSS/JS mostly, which is preferable to trying to figure out each platforms layout quirks.
> - PWAs are a step in the right direction, ...
Yeah I think I wasn't clear enough with what I wrote -- I don't mean I want the web itself to become the mobile platform, I just mean I like approaches like nativescript and react-native/vue-native much more than learning ios and android separately, and think the HTML/CSS/JS paradigm is better than those things individually.
ServiceWorkers are the only solution if you are talking about a purely web app (webview) -- you can actually shim and use native stuff if you want, OR serviceworkers, or whatever else if you take the hybrid approach, while maintaining html/css/js for most interactivity.
>> - Behavior
> I'm not sure what this means... You mean like the propensity of web apps to open non-native modals?
There is a reason why it is called Look and Feel, not just Look.
You can make them Look as close as possible with looks of CSS work, or even canvas drawing, but they don't Feel like native widgets.
> This is completely overcome-able with sustained effort, and appropriate sharing. Flutter literally decided to draw every single pixel on the screen and was able to do it, CSS styling is easier in comparison.
Drawing pixels is only half way there to how native widgets interact between each other, or even basic stuff like dragging content between them, in different applications.
If we take the web part of it, on native rendering side, HTML/CSS are not as powerful as native rendering. For example the visual layer in Windows 10, animations engine in iOS and Android.
HTML/CSS is kind of ok, if one only cares about CRUD applications.
> I'm not sure what this means... You mean like the propensity of web apps to open non-native modals?
There is a reason why it is called Look and Feel, not just Look.
You can make them Look as close as possible with looks of CSS work, or even canvas drawing, but they don't Feel like native widgets.
> This is completely overcome-able with sustained effort, and appropriate sharing. Flutter literally decided to draw every single pixel on the screen and was able to do it, CSS styling is easier in comparison.
Drawing pixels is only half way there to how native widgets interact between each other, or even basic stuff like dragging content between them, in different applications.
If we take the web part of it, on native rendering side, HTML/CSS are not as powerful as native rendering. For example the visual layer in Windows 10, animations engine in iOS and Android.
HTML/CSS is kind of ok, if one only cares about CRUD applications.
I wish that Armed Bear Common Lisp supported Android — that'd be awesome.
It doesn’t? To my knowledge it generates .java files, right?
It uses reflection in ways that Dalvik didn’t support last time I checked.
Dalvik is discontinued, replaced by something called the Android Runtime. Though that might also not support said reflection ways.
AFAIK PicoLisp is pretty Arc-like so this should be doubly relevant here. :-)
Yea...it uses "de" to define a function instead of "defun". People always hate on it for no macros, but macros don't make since when you only have an interpreter. I don't fully understand how, but I've heard people in the past explain how they're irrelevant in Picolisp and how you can still extend the syntax with standard functions somehow. Maybe a picolisper could give some examples?
Shout out that there are two free online books on Picolisp.
Shout out that there are two free online books on Picolisp.
You dont need macros as you have fexpr's which don't evaluate it's arguments. It fits much better into the language, and they are first class. See https://picolisp.com/wiki/?prosandcons
And https://software-lab.de/doc/refM.html#macro for the usage of macros.
More importantly it doesn't need lambda, just lists, and quote quotes all arguments not just the first one. An extremely simple and small lisp-1 interpreter, comparable to the old AutoLISP.
And https://software-lab.de/doc/refM.html#macro for the usage of macros.
More importantly it doesn't need lambda, just lists, and quote quotes all arguments not just the first one. An extremely simple and small lisp-1 interpreter, comparable to the old AutoLISP.
The wiki [0] explains fairly clearly why traditional macros can't be done, but also why Picolisp can still be as flexible.
The backtick, tilde, and def operators allow you access to the reader, and something akin to macro expansion.
You have the reader accessible, you can rewrite anything. It might just be more verbose.
[0] https://picolisp.com/wiki/?macros
The backtick, tilde, and def operators allow you access to the reader, and something akin to macro expansion.
You have the reader accessible, you can rewrite anything. It might just be more verbose.
[0] https://picolisp.com/wiki/?macros
I don't believe I've seen apps look like that since Android Cupcake. If you really want to build apps without using Java or the Android SDK you should look into Dart/Flutter.
I donnot like any lisp implemented by Java, very bad taste of developer already.
The Lisp is native. This is a Java app that coordinates a native binary running pickup to present a web server that is used by the webview.
I have a node-red instance that does a similar thing, to allow drag-n-drop programming (Including UI), and (using dnr) heterogeneous cluster processing on mobiles (ios and android).
It starts a node-red server on the device, and uses cordova to host the webview.
I'm in the process of adding an ag-grid node so you can do complex UIs in the dev environment on the phone/tablet.
https://github.com/alexisread/noreml
It starts a node-red server on the device, and uses cordova to host the webview.
I'm in the process of adding an ag-grid node so you can do complex UIs in the dev environment on the phone/tablet.
https://github.com/alexisread/noreml
Got it, understood
oops, wrote picolisp, autocorrected to pickup
Oh? Why would you say that is?
The Picolisp project has been around for ages and has been used for production work and is extremely impressive in my opinion. Generally speaking, only the APL family languages require less code (based off of looking at dozens of examples on Rosetta Code). Rebol is probably just as terse too, but not much else.
As a language it is tiny and easy to understand. It can interface to C or Java and Android. It also has a built-in prolog like system. I like many of the choices made by the creator "Alexander Burger".
As a language it is tiny and easy to understand. It can interface to C or Java and Android. It also has a built-in prolog like system. I like many of the choices made by the creator "Alexander Burger".