Mariano Guerra 2021-10-11 11:52:55 I propose a "Share your old work" week 🙂 share things you did in the past, Q&A in thread, next two messages are two previous attempts at solving the same problem I'm trying to solve now
Mariano Guerra 2021-10-11 11:54:26 nicolas decoster 2021-10-15 05:00:51 I like this idea of having an environment with several ways to view and manipulate programming stuff. And here you have three major ones for this: blocks, nodes'n wires and widgets canvas.
George Campbell 2021-10-11 16:22:32 I was a core contributor for many years on RxJava 1 & 2. My largest impact was to identify and pushing Erik Meijer and Ben Christensen to incorporate back pressure in to RxJava 2 which influenced reactive streams and eventually JDK 9+ Flow.
George Campbell 2021-10-11 16:34:00 One of the ways Observable are defined is as the dual of Iterable.
Iterable -> Observable
calling iter.next() -> having onNext() called
throwing an error from iter.hasNext() -> having onError() called
hasNext() returning false -> having onComplete() called
George Campbell 2021-10-11 16:41:55 the insight on reactive or async programming is the dual of debugging. With synchronous paradigms it is When something goes wrong a bad thing happens but for all reactive paradigms the dual is When something goes wrong a good thing doesn't happen
Sophie Smithburg 🕰️ 2021-10-08 14:22:46 think i'm close to a docker container with everything prepped for symbolic execution of ruby (in a real hacky minimalist way, but, it's a start, yknow)
Sophie Smithburg 2021-10-13 13:11:32 looks like this is gonna be blocked on glibc support for llvm (which is on the way apparently!!!) or me doing a lot of custom patches in ruby that might not even fix anything, so, delayed for now. perhaps worth a blog post to explain why it's stuck and what i've done so far? would that be of interest to any? fairly effortful writeup, but i'd love to share if others care.
Ivan Reese 2021-10-14 20:47:32 I saw this illustration of a node-wire visual programming language in an App Store "featured app" story. The app looked pretty bad, but this totally unrelated illustration is quietly brilliant. I couldn't stop thinking about it, so I decided to "review" this fake-ass programming system. It's full of stuff that (A) is totally fake, (B) would totally work, and (C) is better than any other node-wire programming tool I've ever seen.
Here's my review: https://github.com/ivanreese/visual-programming-codex/blob/main/impressions/app-store-illustration.md
nicolas decoster 2021-10-15 05:28:51 Maybe someone can hire the artist to design a new node's wire environment?
Ivan Reese 2021-10-15 06:09:48 I wish Apple put bylines and credits on their editorial / illustration. Sadly, they don't.
Paul Tarvydas 2021-10-15 14:28:10 We should be able to split tasks - let the Designers create GUI layouts, let the language experts create languages and then plug the components together, but - due to a mind virus - we can’t, hence, we expect GUI designers to tangle language creation into their work and we expect language creators to tangle GUI design into their work.
We get uneven results. Some languages have better GUIs and some have better programmability, but never both.
Andrew F 2021-10-15 22:47:35 Speaking of things that are totally fake but would totally work, guitar-defined radio sounds alarmingly doable. Every fret a switch, perhaps...
Andrew F 2021-10-15 22:52:13 Partial disagree about leaving disconnected wires around. I agree that you should be able to have one end loose, but if you can fully disconnect them I worry they'll clutter the workspace. I can imagine myself hooking a nearby wire end to a node and wondering why it doesn't work, forgetting that I also disconnected the other end some other time (maybe a visual indicator of the other end's status would be good enough?). So I would rather wires be disposable commodities, but that would clash with your idea of annotations/comments etc on wires. Thoughts on this?
Ivan Reese 2021-10-16 20:28:52 I'm on the side of "give people good tools". Let people choose when their stuff should be deleted. Give them a tool for "select all fully-disconnected wires" (something like Illustrator's pathfinder, perhaps). Make the "automatic" behaviour be something people can ask for, not something forced on them. Also, keeping wires around opens up so many new design possibilities.
Paul Tarvydas 2021-10-17 13:24:09 re: ‘any links to ones with good GUIs?’
short answer: no
longer answer: IMO, H2H and H2C should not be combined together (human-to-human communication, human-to-computer communication, resp.) ; IMO the “best” GUI is a whiteboard (or pencil and paper), H2Cs should compile to code ; “good” H2C guis = Drakon, Statecharts, FBP, SVG (rects + ellipses + lines + text), ?TBD?, (notable exception: most GPLs); I am currently reduced to compiling .drawio files to code ; draw.io has many warts but allows free-standing arrows ; .drawio files can be decoded to mxGraph format and compiled to code ; what you (@Ivan) are talking about is H2H which is VERY different from H2C ; ATM I ignore H2H (which is your complaint, in general :-)
Andrew F 2021-10-17 17:27:13 Ah, "select all fully-disconnected wires" helps a lot. I'd still want auto deletion for any model where wires are trivial (I'll just create a new one by dragging from a node, so keeping them feels like the computer is making me do its job), but otherwise I like your plan.
