Sounds nice, thanks. Do you also have experience in other live coding languages? Can you share your thoughts about advantages/disadvantages of Lisp compared to others?
Hey, thanks for taking a look! I have messed around with Clojure (Overtone) and Sonic Pi (Ruby dialect) and normally prefer lisps for anything fun :)
Regarding advantages/disadvantages, Lisp is always very terse which helps and with structural editing juggling parens becomes a non-issue. Dev environment being fiddly and fragile is the biggest con, you need to put some effort upfront in that.
I'm still not sure on which composition language to focus on. I definitely don't like languages where a lot of the syntax is "hidden" in strings (such as e.g. in Tidal). Lisp has aspects which fit to music intuitively, but as soon as you try to represent the full information expected by Midi the code gets messy. Interestingly, Common Music and Nyquist went away from Lisp towards SAL because composers apparently preferred a Pascal like infix syntax over the Lisp way.
I think macros can help when the syntax seems messy, that is where lisp shines the most. Have a look at extempore lang (https://extemporelang.github.io/) you might like it. Macros written by others can feel like magic, but a DSL you create might still feel the most intuitive. I get your point about hidden syntax though.
I'm aware of Extempore and its predecessor, but I think they pretty much have the same problem, with no elegant solution (at least I didn't see one when studying the docs and thesis). Maybe the trick is indeed - as you say - to implement a "sublanguage" with macros to cover the more complex music representation. Forth is an interesting language, but I think it has even more issues to represent musical information.
At $work we are evaluating different IPC strategies in Rust. My colleague expanded upon 3tilley's work, they have updated benchmarks with iceoryx2 included here[0]. I suppose the current release should perform even better.
I'm curious about the benchmark. In my own for another network IPC library (https://GitHub.com/ossia/libossia) Unix sockets were consistently faster than the alternatives when sending the same payloads.
the linux results are for a vm running on macos. not sure how useful that is. i certainly wouldn't draw any wider conclusions from them without trying to reproduce yourself. pretty sure they will be very different on bare metal.
i couldn't resist reproducing on bare metal linux (8th gen core i5, ubuntu 22.04):
cargo run --release -- -n 1000000 --method unixstream
cargo run --release -- -n 1000000 --method tcp
~9μs/op for unixstream, ~14μs/op for TCP.
unixstream utilizes two cores at ~78% each core, tcp only utilizes ~58% of each core. so there is also something wrong in the benchmarks where blocking is happening and cores are not being fully utilized.
Thanks! I am updating the benchmarks to take into account the different payload sizes as we speak, maybe we can discuss the difference in our methodologies and results then? I'll drop you a mail once updated.
Great blog. The author, incidentally, is a youngish historian named Ben Schmidt. I feel like it's a natural fit with an HN audience given how data-driven his work is, but as you say, it doesn't break through very much.
I have used both Jupyter Notebooks and org mode with org-babel extensively and I agree with the OP regrading the fact that the org-babel workflow is vastly superior, OP did point out a few features which org mode workflow has and Jupyter Notebooks don't but I will try and provide a comprehensive list:
1. Plain text format, git and git diffs work
2. You can combine many languages in a single document, and every code block can be part of a separate session, as an analogy to Jupyter Notebooks, you can have multiple kernels backing a single notebook and you can decide what kernel you want the current code block to run in.
3. You can edit a code block in the major mode for that language, i.e. you get all the features of Emacs while editing code: documentation, auto-complete, snippets and anything Emacs can do, and Emacs can do a lot :)
4. You can have internal and external links to any part of the document (or any other org-mode file) within the editor which get exported as links in the HTML file too. Want to refer to a code block you used before, just name it and drop a link. Extremely useful in binding the whole document together.
5. Literate Programming support -- You can decide the order the concepts are introduced in according to the human reader, not according to the execution order the machine demands it to be in:
#+NAME: named_code_block :eval no
function_not_defined_yet()
#NAME: complete_code_block
def function_not_defined_yet():
print("nice function innit?")
<<named_code_block>>
The <<named_code_block>> gets expanded to whatever you defined it and you control the way you want to structure the document to be the most readable. You can keep working backed by a REPL in the initial stages and then extract(tangle in literate programming speak) to a file, again in the order you want using the <<named_code_block>> (NOWEB syntax). So one org-mode can generate your whole project if you wish so.
6. With the internal and external links and <<named_code_block>> (NOWEB syntax) the org-mode file is closer to being a hypertext file than Jupyter Notebook even though Jupyter Notebook is the one running in a browser.
I have covered only the major features of org-babel, I haven't even covered all the features. I love Jupyter Notebooks too, but org-babel is something else. I am currently working on a toy ray tracer in Clojure in literate programming style and loving every moment :)
I will try to run a org-mode to ipynb converter, so thanks to your suggestion! I just wish there was an Emacs version that wasn't to differnt from everything else so other people could look past the stigma of Emacs. So thank you for the feature run down, and to be cyrstal clear I want more options, but I will only be able to run org-mode/babel myself. Requiring Emacs is just too big of an hurdle for anything bigger than a two man team.
It hurts to hear stigma and Emacs together in a sentence but I guess you are referring to the arcane keybindings of Emacs. In that case I use native keybindings for editing in Emacs i.e. the old Cntrl-C, Cntrl-V, Cntrl-A, Cntrl-Z, Cntrl-S and vim keybindings for executing commands i.e. for things like running code. This is a great setup for beginners so do contact me if you need Emacs to be used with native keybindings :)
Just to give an example of what can be done using org-mode, this is the project I am using to grok Literate Programming -- http://ray_tracer.surge.sh/
I'd add that you can also benefit from other aspects of org, such as project management functionality, outline editing, table editing, tables with formulas, direct git integration via Magit, etc., etc.
I agree that getting people on Emacs is a non-minor issue, but using something like Spacemacs with CUA-mode enabled could go a long way towards acceptance.
I would love discussing the literate ray tracer I have been working on and the literate programming workflow I have made for it. Couldn't find your email in the profile, mine is abhirag@outlook.com, would be great to discuss if I can improve my workflow further :)
but haven't been able to find any other motivation to buy them. Also I have never printed the Common Lisp Quick Reference(http://clqr.boundp.org/clqr-a4-booklet-all.pdf) because I always imagine it having a really pretty cover, and everything I try just falls short.
Oh, we used the Art of Prolog in my sw engineering course. It's a good book, although it doesn't cover the newer features of Prolog interpreters, like Constraint Logic Programming, IIRC.
Remote: Yes
Willing to relocate: Yes
Technologies: Rust (Tokio, Axum, Pingora), RocksDB, Python, Kubernetes, AWS/GCP, OpenTelemetry, NATS
Résumé/CV: https://abhirag.com/resume.pdf
Email: hey@abhirag.com
Systems engineer, ~5 years of Rust in production. Most recently:
- Helped build a distributed notification engine (3.3B notifications/day at 300k/sec, 99.9999% dispatch reliability)
- Feature store serving 60M daily requests at p99 < 5ms
- Pingora based L7 reverse proxy
- DBSP based stream analytics engine processing 3.3M events/sec on a single node
Open to anything interesting, especially where Rust is the primary language. Happy to chat!
reply