Kartik Agaram great! Were there any points that really stuck? Or warrant further explanation?

Aha's for me:

• the borrow checker is incomplete

• It conflates type parameters

• It conflates array indices (makes sense once I think about it)

• Your checklist of questions on existing an error message.

• The need for teaching ownership-based reasoning.

• How perverse the bag of tricks can be.

• How more complex analysis has the unanticipated drawback of reducing opportunities for learning.

Maybe we need multiple analysis engines that can be swapped out?

Here is a bit of context. I have a very small Rust experience. As small as reading half of "Programming Rust" from O'Reilly, start coding in Rust, trying to replicate other languages habits, struggle with lot's of compiler error messages, finally actually understand the hard way that habits must change, unperfectly change them, implement some basic toy CRDT algorithm in Rust (which target WebAssembly for use in the browser), forget about all of this (it was one year ago and I didn't use Rust again since).

For your first question:

Does the process of interpreting a type error make sense? Does it ring true to your own experience (in Rust or other languages?)Yes, completely. And especially with Rust. Even if my memory of Rust is a bit... rusty (sorry for the bad pun...) and even if I didn't catch very well all your code examples (maybe I read it too fast too) reading the discussion totally makes sense and resonates with what I have experienced. To be precise on one point: I didn't write any unsafe code, even if there were several cases where it can be a solution. But as I was learning, and it strongly feels against the Rust idea, and that it seems complicated to write (and need to learn new things like you point in the article), I didn't do it.

And for the other question:

Did you learn something new? Does this paper help you understand/frame the usability challenges about Rust specifically, or potentially a different language?Totally, it is a kind of global 'aha' moment too for me. All your points are like I felt them during my Rust experience but didn't really grasp or "put a name" on it. Especially, it wasn't clear to me that some compiler errors were due to incompletness, and I feel like knowing this would have been of great help in the way to manage the compiler and its messages, and knowing it now will definitely helps me in my future Rust experience (if any).

The paper was an interesting read, thanks! I particularly appreciated the examples showing how users of Rust have to understand the internals of the borrow checker.

I did some user studies of a language I designed that uses ownership, and I managed to get most participants to work successfully with ownership. However, the ownership system was substantially simpler than Rust’s.

@Michael Coblenz ah that’s right, I will need to revisit the Obsidian studies!

I’ll email you a more up-to-date draft.

Currently, we work with OpenGL. Skia already supports Metal, but we just didn’t adopt it yet. We will in the near future.

So, currently, if you have OpenGL context, you can just draw to texture and we display it as is. For now, if you want to try Metal, it would require an extra step of going from a texture to a pixel buffer. But, when we will be on Metal, that extra step will not be needed anymore.

Does your approach have an advantage over the following declarative approach:

rectangle

filled = blue

length = 50

height = 30

x = 200

y = 300

circle

outlined = red

radius = 20

x = 100

y = 100

Well, that's a great declarative API too! I guess you're saying that in your case of this API, you don't need the distinction between Stencils and Pictures, because you can just use the 'outlined' or 'filled' field, right?

It's useful to have this distinction, because you sometimes want to make a stencil from two objects, for example a rectangle and a circle on top of each other, and then outline that once.

So that'd be something like:

outlined "red"

  (superimposedStencils

    [ circle 20

    , rectangle 100 100

    ]

  )

And even if you don't need to be able to superimpose stencils, you'd still want to check that either 'outlined' or 'filled' is set at compile time. Presumably using types. And wrapping is then just another way of adding parameters.

I'll be writing more about that soon, though. So stay tuned 🙂

if you haven't seen it @Philipp Krüger: https://medium.com/@stevekrouse/types-are-shapes-d6af1e83192f

In this arrangement

outlined "red"

  (superimposedStencils

    [ circle 20

    , rectangle 100 100

    ]

  )

What determines which object is on top of the other? If it's the order in which circle and rectangle appear from top to bottom, then it's mostly declarative but a bit imperative, too?

Dan Swirsky It's the order of elements in the list argument of superimposedStencils .

That's still declarative, I'd say, but we're getting into weird-terminology-park here. I'd rather think about what benefit does this API have over another? I know I resort to using 'imperative' and 'declarative' sometimes, but in this case these APIs look and behave the same.

So, going a little bit on a stretch: Declarative and imperative aren't opposites. Declarative APIs can be implemented with declarative code.

You mean implemented with imperative code?

The PL I'm designing mixes both as well, but I use a 'layer' property to control object overlap

@Ricardo A. Medina Oh, I've seen that one, but just noticed it was written by @Steve Krouse! Yeah, that article has lots of overlap 🙂

Interesting article, @Philipp Krüger! 🙂

I like your declarative language for vector graphics, and the way it seems to be good at composition: you can combine stencils in more complex stencils, and only after that applying some style to it. I like that you explicitly focus on "shape" first (your "stencil", nice name) a concept that come before how it is rendered. First time I see it. I guess there are some other languages for graphics that use the same kind of model.

I also like the way you illustrate the type checking with Scratch like blocks. And even if you write in the article that it is just for illustration, I find this is a good example of that sometime visual languages can be more expressive than text. In that case it is visually obvious that you are not allowed to put a "rectangle" block in a "moved" one, with text programming you have to figure it yourself, or the editor linter or compiler can tell you are doing something wrong, but only after doing it, in the visual I don't even try to do it.

Nice! I'm particularly fond of declarative + functional for this sort of thing, for example check out the (mostly student authored) gallery for the online teaching tool we built to support https://clojurebridge.org a couple years ago: https://www.maria.cloud/gallery?eval=true

(One can modify and re-evaluate any code cell by typing Command-Enter -- Control-Enter on Windows/Linux -- with the keyboard focus in that cell.)

@Jack Rusher I love myself some declarative graphics APIs 🙂 This one reminds me of racket's picts (they've been an inspiration to me since forever), but you've gone amazingly far with that one, amazing. I've never seen maria cloud, too. Also, nice fernsehturm 😄

Thanks, @Philipp Krüger. Racket's quick introduction using the picture language, along with the chapter of SICP that uses the same language, was a big influence on our intro curriculum ("Learn Clojure with Shapes"): https://www.maria.cloud/intro

BTW, for those interested in CS history in general and representation in particular: the heritage of applying functional programming to geometry starts with Peter Henderson's https://eprints.soton.ac.uk/257577/1/funcgeo2.pdf, the implementation for which was written by his grad student http://www.cse.chalmers.se/~ms/ who went on to be a fine researcher in functional programming, especially using functional languages to design hardware. It was ported to scheme for the class that became SICP by https://www.mona.uwi.edu/compsci/prof-daniel-n-coore who had been one of the top academic performers of his generation in Jamaica before attending MIT. Mike Sperber ported it to PLT scheme, from whence the Racket version.

@Jack Rusher maria.cloud is a really nice learning environment, I was impressed when I first saw it, cool to see that you were involved

Every time I read about GT I come away determined to look more deeply into it, but so far I'm stymied each time. Just thinking aloud on some ways you may be able to help me help myself..

1. Do you happen to have any blog posts or screencasts about using GT to work with a non-smalltalk codebase? You pointed me at the Java capabilities over a year ago, but sadly it hasn't "stuck".

2. As someone who isn't embedded in the Smalltalk world, many of the nouns in GT blog posts are not clear to me. For example, this quote seems really profound:

Smalltalk is famous for the ability to program in the Debugger, in the presence of live objects. With GT, we are perfecting programming in the Inspector.

However, I don't have a good grasp of the distinction between the Smalltalk Debugger and Inspector, so I fear I'm not fully grokking the idea yet.

i would kill to see a video walkthrough of using GT for one task from start to finish with an explain-like-i’m-five level of detail about what’s going on. i support the mission and the vision and the interface 1000% but very badly need a getting started guide that introduces basic concepts, especially for people who aren’t used to working in even the live environments like the one that vanilla pharo provides. i really think gtoolkit could be the killer app for smalltalk in the same way that rails was the killer app for ruby—but that requires an introduction for non-smalltalkers, just like rails required guides directed at people who didn’t originally use ruby (only more so, because the leap in expressiveness is much larger)

Thanks both for these kind words. How about we organize a public 2h session in which I demo and you can ask questions?

In the meantime, Kartik Agaram one of the important application areas of GT is software assessment. You can find a set of links to two longer tutorial-like blog posts here: https://gtoolkit.com/usecases/software-assessment/

Kartik Agaram

As someone who isn’t embedded in the Smalltalk world, many of the nouns in GT blog posts are not clear to me. For example, this quote seems really profoundIndeed, we do think this is rather significant. At the same time, we are still catching up with explaining these implications in ways that do not require prior Smalltalk knowledge. That is why specific questions or challenges do help us a lot.

i will gladly make myself available to be publicly ignorant of smalltalk in any way that’s helpful