Sorry if I'm missing something, but in what sense is the article a classic? At this writing it says it was posted 8 hours ago. Has it appeared earlier at a different location?

sorry 😕 I meant ‘classic’ as in the classic point people always make about replacing Excel with individual apps

Gotcha. That's true. It is a very good presentation of that point. :)

In their newsletter they shared this 3D display from Sony https://www.youtube.com/watch?v=KrLMnQM0_Ps

And this article https://debugger.medium.com/why-our-brains-love-physical-buttons-5dc203a9014d that I haven't read yet

Add a new channel only if you want to have fewer people seeing what you post 🙂 I'd say keep it here where it'll have more discussion.

I've been watching David Attenborough describe a watering hole where otherwise solitary animals come to socialize: https://en.wikipedia.org/wiki/Mbeli_Bai

I have one of the original leap motion devices. It is terrible, constantly looses the track, but I always thought it had a lot of potential. I was quite sad when they shifted away from consumer facing products. It's ironic because the hand tracking built into the Oculus Quest is very similar, and much more robust.

I'll second that Quest tracking is good enough for the main menu: when I pop on the headset to download updates or whatever before beginning a serious session.

Ray Imber did you find any interesting usages for the leap motion?

@William Taysom is the tracking in Quest good for something else beyond the main menu?

Not that I've tried. The API was first experimental and still new.

I found the experience very hit and miss. the API was...limited... as I said before, the tracking algorithm lost fingers often enough that the experience was frustrating to use. And you couldn't get at the underlying data to tweak anything. You only got access to the final gesture detection or a limited ik hand model.

I did a few internal toys, like using my hands to drive a presentation at the job I was in at the time. I also tried to use it for surface tracking instead of full 3D tracking, but unfortunately, I wasn't very successful there either. The unreliability made it a nice parlor trick, but impractical. This was about 4 years ago, bear in mind.

I haven't given up on the concept of hand tracking. The algorithms continue to improve, and I think we will see a lot more cool stuff in this space in the future: https://youtu.be/MbZ0ld1ShFo

Thanks for the video Ray Imber, it’s really cool. We just need that the technology gets from 10min/frame to real-time 😆

Ivan Reese I love your interviewing style! I noticed after thinking "what a good questions" too many times

We've been keeping it semi-quiet for a couple of days while I clean up the transcript 🙂 But yes it's public.

Maybe there should be a channel dedicated to the podcast (announcement and discussion related to each episode)

Cat's out of the bag!

In the podcast service I use, there's a "public" setting and an "unlisted" setting. I had thought "unlisted" would just allow the episode to be streamed if you had a link, but it also sent the episode out to all subscribers. So.. that sort of blew our cover.

Kartik has very kindly, very masochistically, very kindly offered to take a crack at cleaning up the transcript, since that's something I used to do that I'm https://futureofcoding.slack.com/archives/CEXED56UR/p1612408693044100 going to be doing in the future.

So yeah, I was just giving him a bit of time to do that before posting an announcement. At the same time, I figured someone would probably say something. So it was just a matter of time. No sweat!

Thanks for the kind words. To be honest, listening back to it a year after the fact (this interview was recorded in Jan 2020), I keep thinking "How the fuck did I come up with such good questions? This doesn't feel like me." So.. chances are good that I blow it on the next one, but it was a good run while it lasted :P

<3

As for new channels — Kartik https://futureofcoding.slack.com/archives/C5U3SEW6A/p1615396290117900?thread_ts=1615395714.117000&cid=C5U3SEW6Ahttps://futureofcoding.slack.com/archives/C5U3SEW6A/p1615396290117900?thread_ts=1615395714.117000&cid=C5U3SEW6Ahttps://futureofcoding.slack.com/archives/C5U3SEW6A/p1615396290117900?thread_ts=1615395714.117000&cid=C5U3SEW6A in the thread right above this one.

That’s why I’ve stopped posting in #of-logic-programming about things that are related to it 😬

Because the channel didn’t reach critical mass 😅

Ivan Reese I have to second Mariano Guerra: your questions are all on point! @Ravi Chugh good job handling them. So glad to hear that Sketch-n-Sketch is so alive and well. I'm eager to take another look starting with the transcript of the interview.

Ashamed that I've forgotten having watching this.

Wow. And that's a demo from 2010. What has happened since then?

Ah, the famous “Minority Report” interface. This is a great example of technology (demos) designed to make an impression but which lacks substance.

I’m torn between thinking that such demos do provide a benefit in that they can show us crazy possibilities, even if they don’t work out that way in the end, but also that such demos might cause more harm because they normalize wrong incentives: just have something cool to demo (and figure out good use cases for it later).

I love a good demo as much as everyone else. But please impress us with your rigor to have figured out a good solution to a problem. Unless you work in Hollywood. Then keep doing your thing and make sure that each depiction of a futuristic computer interface is as ridiculous as you can make it — I am certainly entertained by that.

I’m not sure how his optimism make me feel. He mentions that computers will have all those capabilities in 2015. I don’t particularly feel that this kind of interface would be useful for my day to day interaction with a computer, but on the other hand, not much has evolved in the last 10 years 😞

Konrad Hinsen He founded a company that sold into various sectors and recently left that company to work on new FoC ideas that have more in common with Ivan Reese's Hest than this interface. I'll hopefully get to share some things here soon.

Stefan Lesser I suppose you don't like Bret's work either, then.

Jack Rusher What makes you think so? I specifically chose the word “substance” over words like, e.g. “product”. That said, I like Bret’s work much more than his (early) demos.

Stefan Lesser I find positive visions of potential futures important, which is why I don't have much sympathy for criticisms of Bret's early output as "just demos". Inspiration has tremendous value! Same for John's work here. This is also one of the (many) reasons I think artists are so important to the future of tech. As an example, consider John's "let's move this work item between screens" demo in the above video to what French digital artist Cyril Diagne is doing here:

https://twitter.com/cyrildiagne/status/1256916982764646402

I guess what I really mean is much harder to convey. Maybe a better approach is: look for people who are not immediately impressed by flashy demos, and can see a difference between designing to impress vs. designing to solve a problem. Then work with the latter kind.

Jack Rusher Are you suggesting the demo above is of the same class as the demos in Inventing on principle?

Or do you see a difference?

I think I understand what you're saying, though -- of course -- https://www.youtube.com/watch?v=vOa--Dhu11M. I will just give one more lens to maybe help you see what I'm getting at: when I do science, I'm driven by curiosity. I want to find something out, scratch an itch, imagine a possibility and chase it down. When I do engineering, I look around for the parts that I can assemble to solve a problem in the sense you seem to be indicating here. Often, the things I use in an engineering context are things that were invented in the course of working in the scientific mode. The artistic mode and the scientific one are exactly the same for me in my own practice, and they both benefit the engineering mode by providing these possibilities.

(I should add that quite often an engineering problem is what prompts the curiosity that leads me to chase something in the scientific mode. The above schematic is an imperfect map to the phenomenological territory, but it serves to convey my support for all these modes of action and their outputs.)

Jack Rusher I think we are closer than it seems. I can totally get behind what you are saying. But there is something about the demo above that triggers me.

The demo above looks like pure theater to me. Oh, you can sort these images by color in a fancy moving animation? Why? And when he calls his colleagues on stage and they do… what… exactly? His hand movements are overly expressive, more than they need to be, even for 2010 technology. (Which is important for what Tom Cruise does in the movie! It would be boring to watch otherwise.) That looks like theater to me. It feels staged for impact without having a real message.

Bret’s demos some would also consider staged. If they are, then they are staged (well) for making a point. And impressively so. I can get behind that!

Jack Rusher What you say about artistic/scientific is interesting. And you say it about your own work yourself: for you these are the same. Because the substance is there.

Both artists and scientists, when they do real work, work for something. They have substance. Or at least they strive for it.

I don’t get that from the demo. That smells more like “we built this cool thing for this movie, now let’s sell the hell out of it” to me.

The impressive thing about the Minority Report demo is that all the evidence is immediately to hand, so he can pull it together, compare and contrast etc. The motion controls are a complete red herring, it would be equally as effective with keyboard and mouse.

For me:

• Art provokes.
• Science systematizes.
• Engineering actualizes.

Now Chris Knott, if your interaction maps well onto 3D translations and rotations, motion controls are much better than mouse and keyboard. 2D translations play best with mouse. Then keys/buttons for discrete events. This should all be obvious, but with the newness of motion controls, their utility at their best is really remarkable.

Yeah I agree there are definitely areas where motion controls are not a gimmick. These things need to be seen as complementary. One example is voice control which is currently only use as a sole input device. In the real world voice is very often paired with pointing. I'd like to be able to speak to my IDE to do those jobs like refactoring which are buried away in menus, but primarily I'm going to be on kb+m.

When I delivered https://www.youtube.com/watch?v=TeXCvh5X5w0 a couple years ago, there was someone backstage afterwards who criticized the way I'd done the talk — getting the audience involved, having them clap for the artwork they liked, and so on — because it contained too much showmanship. As someone else in the conversation pointed out, many would consider a bit of stagecraft an improvement after a day of presenters mumbling through dry presentations featuring illegible slides. I think it's important to keep in mind that different audiences need to hear things said in different ways, and that what seems like hollow showmanship to you might be exactly what inspiration looks like for someone else.

So, with that in mind, perhaps this video featuring smaller gestures and a wand interface might be more to your taste. 🙂

https://vimeo.com/174223351

I’m in no position to criticize John Underkoffler’s work. Yet I did. That was wrong.

The demos are impressive, no doubt. And I can see how many will find them inspiring. I loved that scene in Minority Report, and I thoroughly enjoy any weird HID visions that show up in all kinds of movies, from science fiction space operas to later James Bonds.

I also enjoyed your talk, Jack Rusher, you linked above. You combine showmanship with interesting content in an entertaining way. You show off great work, provide helpful information, and tell an interesting story.

Stefan Lesser surely what you saw with Underkoffler’s talk matched unfavorably against your prior experience. It happens.

@William Taysom Yup, you’re absolutely right. I came to that exact same conclusion and am thankful that Jack Rusher was stubborn enough to take several attempts at giving me a chance to see the value in such an approach.

Very slick yes.

During the drawing of the rhombus, I was wondering how it was going to enforce that the sides were the same length. I was imagining some kind of slightly clumsy thing where they were tied together with shift+drag or something.

The actual solution is that it infers it from the fact that they are equal length.

I think this is actually a really keen insight into how normal people think vs programmers.

Interesting that the same technique was not used for the colours. Wouldn't it also be a safe assumption that colours that are the same in your "example" drawing are meant to be the same in the definition? When you have an explicit, editable, textual definition right there I feel like the bar is raised right up for making these kind of assumptions.

It also has this nice side effect, a little bit like unit testing, where it forces the user to draw the most generic version of the object, where nothing happens to be the same, only things are defined to be the same

That bit wasn't clear to me either. How does it avoid fixating on small differences in length?

See also http://petrinet.org, an interactive explanation of Petri Nets built using Statebox.

Great work by @Paul Shen! 🙂

thanks Jack Rusher and Nicolas Decoster!

Hmm, the first things that come to mind with similar themes are MVC, the https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design , and Model View View-Model.

Given it's emphasis on OO (either OOP or Kay OO), it doesn't seem like something that I would personally gravitate towards in comparison to patterns more compatible with data-oriented programming (often found in Rust) or functional programming.

There is quite a bit of overlap with these ideas and the big picture of the software I've written. Things like microservices feel like they embody Kay OOP and the OO that Reenskaug describes here. I feel that we can see an advantage to OOP as something which enables a stricter separation of responsibilities, which is essentially what many architectures are currently built around. For example, a Third Party data sync integration is one object, while the browser client is one object, and some auth gateway is another object.

DCI have similarities with MVC because both were created by Trygve! 😄 https://folk.universitetetioslo.no/trygver/index.html

IMO the most interesting idea in DCI is about making the compile path equal to the runtime path. I hate having to play computer every time I read code.

Every concept that you mentioned above lacks this.

Very familiar, have built a few systems in DCI – also familiar with Jim's book, which is a pretty good dive into DCI but relies on some custom libraries. In my mind, DCI should be doable with language convention alone. Dynamic languages (or langs that support dynamic invocation) are best suited, as method chains will be overridden. DCI also prefers true object-based languages, vs class-based (though Trygve's collaborator Jim Coplien has built DCI systems in C++ and Java, too – and has defined a custom DCI language charmingly called trygve).

The idea of DCI is essentially that a model can have a "role" snapped onto it as needed, which provides behavior for the model. When you need the system to do something (ie, a use case), you have a use case object load data models, snap roles on them, and the roles provide new functions – run the functions, then release everything (data model objects go back to being plain vanilla without particular role behaviors).

What this does is deconstruct & relieve the pressure put on traditional objects (at least the 90s-00s notions of objects) to be all things for all use cases. Instead, a model primarily becomes just Data (the D in DCI) that can perform different Interactions in different Contexts.

It cleans up a codebase because what you primarily see are use cases (context object definitions), and then the models and roles that fulfill the use cases. It's easy to learn what a system can do, and the code reveals in a straightforward way how behavior is implemented.

I haven't used it outside of database-oriented projects (tables are nice forcing functions to define models). It worked perfectly in rails. I'm not sure how I'd use it in a strongly-typed language. I think it has a lot of untapped potential.

Thanks for the explantion Christopher Galtenberg!

It's easy to learn what a system can do, and the code reveals in a straightforward way how behavior is implemented.^ This is the part about DCI that I'm interested the most. Do you have en example a bit more involved than the classic TransferMoney?

I'm looking into introducing DCI to Ruby/Rails codebase 🙂

Another question, do you have thoughts about having DCI in a frontend-end framework, e.g. React, Elm, Vue, or even vanilla js?

Sure... In one system, which provided an infrastructure service, a useful model was a NetworkInterface, that represented fields like eth0, mac address, local IP.

It also had enough data that we could assign it a role as a SwitchPort, with functions that could communicate directly to switch firmware.

One use case was to ChangeSubnet, to move a machine NIC to a different network. The ChangeSubnet object could load the NetworkInterface(s) required for the request, add the SwitchPort role to the NetworkInterface, call a SwitchPort function to essentially change to a new switch port, and then update the NetworkInterface model fields accordingly. So in the end, the machine ended up on a new network, and the state of the row of the NetworkInterface table was properly kept up-to-date.

In our top level folder, there's a ChangeSubnet ruby file. You look into it to see how the business is done, and how the SwitchPort role is defined.

Do you ever need to share Roles/methods between Contexts? Is duplication the way to go?

Almost never – we kept roles as a folder of modules, but we could have just done it the recommended way of keeping the definitions in the context file

a model primarily becomes just Data (the D in DCI) that can perform different Interactions in different Contexts.

The idea sounds similar to what you mentioned @Cole Lawrence:

I would personally gravitate towards in comparison to patterns more compatible with data-oriented programming (often found in Rust) Do have any resources about data-oriented programming?

As we leverage data oriented programming at Storyscript (which I am defining as a strict separation between the data being defined separate from the business logic). Rust is good at this because it has enum types (ADTs / variant types) which make it quite a bit easier to embed business rules and object states into the data directly.

We base much of our code around variant types with https://en.m.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel in the frontend TypeScript and an https://en.m.wikipedia.org/wiki/Entity_component_system#Characteristics in the editing engine in Rust.

Daniel Garcia it sounds like our solutions are more focused on a different approach and need overall, though, since all this code is currently solely being used on a per user basis (one engine instance per document). Our engine's architecture is designed to scale well as additional complexity is added over time (such as parsing to type checking to suggestions based on type checking to personalized suggestions based on multiple sources of suggestions)

To my knowledge, it feels like Kay object orientation at the isolated service level is unavoidable (at least I haven't seen an API that wasn't basically a Kay object to pass messages back and forth with)