@ttarabbia Hey, following up on the discussion about Google Sheets. I have a subset of the code I use to extract from GS in the repo I shared above. Specifically, this function: https://github.com/mlimotte/tryion/blob/main/src/tryion/common/gsheetsx.clj#L177
Thanks!
@camdez did you say you were going to share some of your code? Is there a repository?
Iām sorry this took foreeeeever, but the code is up now: https://github.com/camdez/launchpad
Sam had asked me to add links and slides to the Meetup discussion. But iām not seeing that on https://www.meetup.com/austin-clojure-meetup/events/dwggbtyfcdbrb/. Anyone know where i can add my stuff?
hereās that blocking repl that creates the temp namespace with locals in it.
I meant the comments section, sorry about the confusion. If you go the page for this months meetup and scroll down it is after the Photoās section.
The comments donāt hold formatting I just found out, so never mind.
Somehow I thought the meetup was at 6:30. Hanging at the bar if anyone else happens to be here!
I'm on my way
I had mentioned the MIDI input for Apple Motion so I thought Iād add the link here: https://support.apple.com/guide/motion/midi-behavior-motn13744f3c/mac Here is the Orbit Behavior in Motion as well. https://support.apple.com/guide/motion/orbit-around-behavior-motn1374562e/mac
Thanks for all of the links! Iām looking forward to checking them out.
This shows the other Behavior objects too. https://support.apple.com/guide/motion/intro-to-behaviors-motn13748883/mac
This was cool too. https://www.youtube.com/watch?v=rYt0ERbWLrY
https://www.midi.org/midi-articles/our-apple-watch-and-soon-siri-into-a-midi-controller
This shows a cool demo of using a Apple Pencil to control MIDI https://www.youtube.com/watch?v=Qx9e-xlwBGI
https://www.midi.org/component/zoo/item/musikraken?Itemid=1423
A Japanese MIDI and Motion Example
This looks cool too https://hexler.net/touchosc
A French demo of MIDI and Motion https://www.youtube.com/watch?v=arD_oK05pw0
Iāve always been fascinated by Datomicās ability to āholdā and execute code. Seems like you could do a really interesting ālambdaā like model there. Not sure if Ions is that b/c thereās a lot of black box. I think a simpler, lower level approach is warranted.
What are the things youāre trying to accomplish? Is https://blog.datomic.com/2012/10/codeq.html relevant?
thanks @camdez. You and mark killed it as well. Sorry i had to run i didnāt expect it to run 2 hours and hadnāt eaten dinner before.
@mlimotte Sorry for the super late responseā¦
I donāt have a single, well-defined aim. Iām generally just annoyed at the state of computing, and if I had the resources (time / funding), itās something Iād seriously consider spending the majority of my time on.
Itās just all so bad. The Lisp machines from the 70s were better in scores of ways.
We have structured data, but we operate in text most of the time because weāre so traumatized by shitty, non-extensible non-text tools that weāve convinced ourselves as a community that we canāt do better.
But we can do (at least) 10x better.
Like, for how long are we going to read stupid line-oriented diffs that generate a massive patch because we introduced a single when statement around something? Itās basically a single tree edit (see https://github.com/Wilfred/difftastic for a better approach), and I have better things to do with my time than trying to make sense of this noise.
Iām also just annoyed every time I search from something in a (lossy) text-based way when I know I should be searching for a structural pattern (CodeQ is relevant here, as is Grape (https://github.com/bfontaine/grape). Or browse large data structures as text (`tap>` and Portal and friends have improved this story a lot).
Increasingly I think code-as-text is just wrong. I should be able to open a namespace and have caller and callee functions as easily visible as in-namespace functions. I shouldnāt have to think about ordering and declare to appease the single pass compiler. Tests should be visible and (often) run automatically. Project-specific tooling should be eminently at-hand (āadd a route for this handlerā, ārestart the systemā, āupgrade this dependencyā)ācontext-aware tooling. UI components should render live as UI. It should be possible to store large amounts of metadata without cluttering up the visual presentation. Logging should all be structured, and easily filtered. Code should be edited entirely structurally and indentation shouldnāt be something we think about.
This kind of stuff. Most of it exists in some form, but itās all disparate tools, and it takes a lot of work to get everything set up, and things donāt play nicely together.
Somewhere along the way we settled into this shitty Unix local maxima and got Stockholm-syndromed into thinking itās OK. And I say that not as someone who struggles with Unix tooling, but as someone who has done it for 25 years and is pretty decent at it.
I meanā¦my CPU can do 2.2 billion operations per second, but my terminal canāt be bothered to help me figure out what the next CLI argument when I forget for a second? (I know, I knowā¦Fish shell, etc. But none of that measures up to what we would consider baseline acceptable UI for a consumer application). It canāt display images? WTF. (I know, Hyper terminal exists, blah blah). It shouldnāt take an experienced programmer to be able to draw a circle on the screen.
The foundational Unix assumption that programs should speak unstructured text to each other is just stupid (in the same way SQL was a bad idea that has led to innumerable amounts of exploits and concomitant financial loss). Clearly programs should speak data to each other. Itās absolutely absurd that I ask ps for a process list and it dumps that as text and then I have to write an ad hoc parser with awk so I can get the field I want. Thatās called map. Yes, ps should check if itās outputting to a terminal and format for me if it is, but if not, it should speak EDN. With a frigging data type specifier. And that data should probably be transferred without serializing / deserializing it at every pipe.
These things are the reason I use Emacs. Composition of data-manipulation tools (in sketchy Elispā¦) paired with (sketchy) display capabilities. But itās almost all worse than a real Lisp machine from 1970.
We need to go back and start over, and the damn cobblerās kids need to get themselves some decent shoes.
Thanks for coming to my TED talk.
Hereās a shell that is doing a few things right: https://www.nushell.sh/book/quick_tour.html Still need a decent programming language at the core of it, but itās a step in the right direction. š
Unfortunately Clojure doesnāt work great for this application because (as far as I can tell) the JVM only supports cooperative concurrency and you really need preemption for proper job control, in my non-expert opinion. I was researching how Erlang does this over the weekend. It drives me bananas that when you have a runaway thread on the JVM (say you start a stuartsierra/component system with a webserver and lose the handle to it), thereās no sanctioned / reliable way to list and kill the thread(s).
Sorry I missed most of your presentation. And that we both ran well over our 10 minutes. Norman didnāt even get a chance to do his presentation this time.
@dpsutton We should talk more about Clojure forms in a graph database. I have a bunch research / talk material / experiments Iāve done on how I think Clojurians should lean in way more to homoiconicity, esp. w.r.t. code transformations and (Lisp) form-based search and I think there are some interesting ways that graphs could help. I really want to bring back / normalize capabilities of Lisp machines and Iām dabbling in Smalltalk-esque non-file-oriented ways of storing code and I would love to bounce some ideas off of you guys.