Hm. Pine64 is making a bone conduction headphone set which is in some sense open hardware. https://pine64.org/2024/03/17/march-update-making-waves/
(They are soliciting suggestions on a name.)
Briefly around 2010 I got a chance to try out one of the final-version Google Glass units, and although the Google Glass itself was fucking terrible, it convinced me that a covert bone conduction headphone clipped to your glasses and paired to your phone, which you send commands/queries to by tapping in Morse code either on the surface of your phone or on some sort of smart ring and which responds by TTS in the bonephone, would be really cool
@mcc I have a setup kind of like this! xReal Air Pro 2 glasses for the display, AfterSkohz OpenMove bone conduction headphones for audio, and a Tap XR for input. I don't have TTS set up yet, but I was thinking that's the next step. The thing that's holding me back on that is that I don't have a great TTS-compatible way to navigate and edit code. I should try setting it up for something easier like texting, though.
@mauve @mcc It's an awesome device, but I have the same problem. It's made for English text entry and using it for programming requires just way too many keys to be available. I'm developing a custom key mapping, but really it needs some changes to the firmware to be practical. However, I think the fault really lies in the way we write and edit code and not the input methodology. We should be working on making programming more like natural text input and less on enabling esoteric key combos.
@mcc @mauve Uiua would be an excellent choice for the future of programming. It uses weird glyphs for display, making the code easy to view on a small screen like a phone, but you can enter them by spelling out the function name using only letters. You could also use neovim for text editing using only letters (and ESC). Now I just need a TTS plugin for neomvim, and a job that lets me write Uiua professionally! 😂
@brandon What sort of stuff are you thinking of using it for? I was worried about whether it's speed of execution can keep up with how expressive it is. It feels like it'd be way to easy to make really expensive computations and I'm not sure if it is paralellizing enough of the execution out of the box. Would regular APL not suffice?
@mauve The code I usually write at work encompasses a lot of different areas from embedded microcontroller code, Linux servers, mobile apps on iOS and Android, VPNs, network protocols, encryption, steganography, radio drivers, to machine learning.
@brandon Oof yeah. I think that's the main thing that keeps me from fun languages. The availability of libraries and APIs ends up influencing whether a project is feasible to undertake within budget constraints or not. :( I end up having to sidecar stuff into separate processes and talk via IPC when there's a mismatch in languages. E.g. Agregore Mobile has Go,C++, and Java all jumbled together.
@mauve What I've been doing to get around this problem is an initiative called Omni-Platform. It's a set of libraries available for each platform that has the same API across platforms. It makes porting code between platforms easier, and also opens the way for automatic transpilation. I think of it kind of like a virtual machine that you can run on top of each OS, but where the focus is on a consistent menu of effects instead of a consistent set of computations like in a traditional VM.
@brandon That's great! Is there code published for it which I may read? I do a lot of cross platform stuff and that's something I've wanted for a while. I assume graphics isn't within the set of APIs?
@mauve Sure, the main OmniPlatform stuff is here: https://github.com/OperatorFoundation/OmniPlatform and then I also have a separate project for microcontrollers that is more at the conceptual stage here: https://github.com/blanu/Ultraviolet - it's a big project with lots of parts, so much of it is not far along yet. The most mature parts are Transmission, our networking library, and Keychain, our encryption library. These are used in multiple cross-platform projects that are currently in production.
@mauve I'm not too worried about execution speed. Both APL and Forth are very fast. What likely makes it impractical for use at work is the lack of a sufficiently robust multi-platform runtime to talk to the OS APIs. On Linux, a C FFI is sufficient, but on iOS and Android, some of the OS services are exposed to the Swift and Java runtimes, respectively. Until someone comes up with a workable FFI bridge for these languages, I think we're stuck with transpilation as the only pragmatic option.