shawa_a_a
Joined 9 years ago
Joined 9 years ago
The BEAM's grown up along with Erlang and so the culture and optimisations are built up all around function application, list processing, recursion, and pattern matching etc.
https://github.com/llaisdy/beam_languages is a decent list of the diverse languages that have been implemented on it, but nothing quite like 'regular for and while loops'.
The BEAM itself is a plain aul register machine though, so it could be done!
It comes with some tradeoffs compared to fully client-side state, but it's a really comfortable paradigm to program in, especially if you're not from a frontend background, and really clicks with the wider Elixir/Erlang problem solving approach.
https://hexdocs.pm/phoenix_live_view/js-interop.html#handlin...
Hooks let you do things like have your DOM update live, but then layer on some JS in response.
For example you could define a custom `<chart>` component, which is inserted into the DOM with `data-points=[...]`, and have a hook then 'hydrate' it with e.g. a D3 or VegaLite plot.
Since Phoenix/LiveView is handling the state, your JS needs only be concerned about that last-mile JS integration; no need to pair it with another virtual DOM / state management system.
https://hexdocs.pm/phoenix_live_view/js-interop.html#client-...
> - Host on a piece of infrastructure that's so big that you can't effectively block it without causing a major internet outage (think: S3, Cloudflare R2, etc).
How can one bounce VPN traffic through S3? Or are you just talking about hosting client software, ingress IP address lists, etc?
Likely right up your street!
I’d definitely be really grateful for help with that! I’m not planning to publish to the Mac App Store, but it would be great to have the build step a bit more compliant with current practises.
https://docs.ankiweb.net/deck-options.html#learning-steps Details what _actually happens_ when you pick again/hard/good etc. I much prefer understanding this to the vibes-based approach of “did you pause before answering”.
Secondly turns out you can indeed very easily set up type-to-answer in a deck by editing the front template and adding
{type:Field}
where field is the answer part of the card’s data.
So… I’m actually using Anki again. I’m still very happy I did this, it was a fun little journey!
Using `midiex` for Elixir I’ve written a fully fledged driver for Ableton Push, letting me use it as essentially a 4-deck version of Pioneer’s DDJ-XP2 sub controller with Rekordbox.
It implements basic statefulness so that the rotary encoders can be used, as well as a paging system so the 64 performance pads can be mapped to different functions. It also supports track browsing and loading, which is helpful if you want to use say DVS with an external mixer and don’t want to be hunched over a laptop dragging tracks around.
It’s also got some additional capabilities which I’ve not seen on other hardware like dedicated faders for stem separation levels.
It’s been a great exercise in combing two hobbies, learning about MIDI as well as being able to personalise my setup for my own use. I haven’t open sourced any of it just yet whilst I’m still tweaking things but I’d be interested in collaborating with anyone who also has one of these devices and has programmed it. I’m looking to use the display on it next, whose protocol Ableton have some (albeit scant) documentation for.
https://youtu.be/aXfTgCCsRSg (T=4:30)
The emulating different lenses part is that with this setup you can parametrically collect specific rays bouncing off the object (presumably the angle of the mirror with respect to radius), and the resulting image will be the same as you’d get from a lens with those parameters.
Generally I’d say Elixir’s lack of “hard” static typing is more than made up for what you get from the BEAM VM, OTP, its concurrency model, supervisors etc.
That said if you’re interested in leveraging the platform whilst also programming with types I’d recommend checking out Gleam (https://gleam.run), which I believe uses an HM type system.
https://www.erlang.org/doc/apps/stdlib/ets.html
Essentially system-global state under named tables.
Have/did you consider having named `env` instances? This would allow for say, feature flags to be kept in a `features` set of relations.
You could also draw from Erlang's 'match specs' and query with a predicate over the keys.