Blind programming would be facilitated if we could have big 2D braille readers instead of the row at a time devices they currently use. An ipad sized device with thousands of bumps would be great. Nobody has figure out how to build one

I haven't used a braille monitor before. How would you use a 2d one? Would you still have to read it one line at a time, or is it reasonable to expect people to consume more than one line at once?

One of the most interesting aspects of braille is that traditionally for example when translating a magazine like playboy was they would hire Artists to make tactile versions of the Cartoons, In this way people could feel a piece of art. You can imagine some software that automatically generates a tactile version of an image, but you have to have a grid of Bumps that can be individually addressed. Outside of the lab there aren’t any two dimensional bump grid systems, most braille readers are only one row because it costs too much to make a 2d one. Braille faded away once the reading machine from Kurzweil came out. Every library in America bought a Kurzweil machine and made his reputation. However braille offers higher comprehension then listening to voice, And it is a shame they moved away from braille because it is a superior system in many ways. And I did my bachelors thesis on braille Translation by Computer, and it’s a very easy program, Braille is basically an abbreviation system, And was so well designed it has barely changed in 100 years. I think with unicode One could make the case that it’s time to increase from six bumps to nine, But really the thing holding blind Programmer’s back The lack of a 2d output device that lets them see the screens they’re drawing. There have been some very interesting patterns from Nokia and Apple relating to vibrating haptic areas on the screen to allow a person to feel something in a region, but none of these devices have ever shipped. You would need some kind of elastic surface that could be raised with electrostatic charge and a grid addressing system. Anyway if anyone is also a mechanical genius they should think about this it would be an immense value to the visually impaired. My thesis advisor was fond of telling me that blind people can do everything except sort socks.

Edward's comment blows my mind. I would really love to have a VS Code plugin that shifted ambient music knobs based on place in a codebase... It would likely help me a lot with switching programming contexts or languages more quickly.

There are many digital audio workstations for sale that have motorized sliders that Can be controlled by the computer. nowadays the industry is moving towards rotary controls Such as on the excellently designed Yamaha CP 88, where the lights around the knob allow the knob to be electronically set without a motor. However those controls don’t work for a blind person, and the CP 88 is not handicap friendly. It is a real shame that Nokia was destroyed by that Microsoft mole elop, They had been working on some really great haptic interface technologies. One of the problems with our Patent system is that you can patent things that you haven’t actually invented yet. So Companies squat on ideas. If you consider imagination invention then Jules Verne invented everything practically. That guy was unbelievable. Most people don’t realize that Jules Verne was so imaginative and so futuristic That his novels were considered by his publisher only suitable for children because they were wild fantasies, but almost everything he imagined was implemented eventually. A militant ecoterrorist vegetarian named Captain Nemo, Who made synthetic meat out of plant material And ran around interfering with the whaling industry.

https://github.com/trogdoro/xiki

https://xiki.org/

Love it! The website’s video has a clear statement about using natural language to search for what your intent is then simply select the code you desire. This is very neat! Thank you for sharing. “read a file” “send a text message” 🔥

a terrific improvement over the typical Unix shell. Am surprised that no OS maker has adopted this. So powerful.

Thanks for mentioning this. It's a very old project, and I had looked at it in its early stages but found it disappointing in many ways. Time to have another look.

yeah, it seems like development is continuing on github but the maker is struggling to monetize. and steve i had half a mind to tag you but i figured you’d see it haha

First impression is again disappointing. The installation instructions contain obvious mistakes, and then the tutorial refers to a non-existing Web page. The various videos are worth watching to get the idea, but the implementation is mostly a source of frustration. For those who tried it out: to uninstall, you need to delete ~/.xsh and ~/.xiki , both of which are created silently when you first run xsh. And you must remove the line appended to .zshrc (or its bash equivalent), which says source ~/.xsh.

I worry they might have to re-brand because people's number 1 complaint was "what happens to my app if you go bust?"

I support this decision to downsize if the people being let go can retain their stock options, otherwise they are just getting screwed

Thanks for the highlight. This is a very interesting read.

I think what I like so much about this is that the interface is plainly in the user’s control. We tend to create such a firm divide between the app and the rest of the computer (or the app’s contents), but I think we can gain a lot by relaxing that. Obvious objections: The user can ruin the ui, and an inexperienced user is almost guaranteed to ruin their ui! Can you have both? Is it enough to have good undo?

i really, really like this video. i’m glad to see it pop up again—i had completely forgotten about it! there’s a clear through line with this and dynamicland among other things, and the use of visual recursion is soo pleasurable to watch

Jared Windover ruining my image was definitely a concern from my time in Smalltalk. Undo and some sensible process isolation go a long way. Comfort comes from being able to answer: would clicking this break anything? One fun dynamic way to tell is to speculatively execute the actions available from a given state recording their effects. Then you can indicate which is which: does it change the view, the document, a broader model.

Hi Maeliza it's pretty disheartening that such biased(/racist) search results are still evidently the total norm. quick check of google which while better on a gender basis, is still very racially biased...

Repost from last month but so relevant to this topic, and again sad how little has changed since it's publishing... https://en.wikipedia.org/wiki/Algorithms_of_Oppression

appreciate your link getting into the details of the actual methods/processes/techniques which at a code level contribute to/enact/actualize the bias... it's quite easy to accept the general idea that the biases of 'we the makers' enter the product, but harder to see exactly/tangibly how...

Yes that's true. We should go for a chane one dataset at the time. I know that Google implemented the gender swapping technic to mitigate gender bias at scale in translation. For the race bias they tag the identified 'race' to provide more balanced output of images request

(by the way, I missed the post you shared!)

🙂 https://futureofcoding.slack.com/archives/C5T9GPWFL/p1591498636036100

Thanks !

"Is it something cool, or is it another IFTTT or Airtable clone?", I find myself thinking as I load the page.

Sigh.

Microsoft must be concerned at Google promoting a product that sells well above the list price of Excel. I can see that MS will have to respond to this kind of product. Seems very poorly documented, so strange that an organization with unlimited resources would do such a slapdash documentation effort.

Edward de Jong — Not sure what the relationship to MS and G is here. This is an Amazon thing.

Oops. Amazon's tentacles grow every day.

microsoft has this since a while, never heard anyone mention it or use it anywhere, it may be that it's targeted at the enterprise: https://powerapps.microsoft.com/

google bought https://www.appsheet.com/ in january

Any in particular to recommend?

Stefan Lesser the take away for me is the attention on translation and Siri. Apple is investing more into these categories as they know the interaction with computers (phones, laptops, etc.) will be more and more voice driven in the coming years. Many, including myself, believe that over 50% of our interaction with computers will be voice-driven by the end of the decade (2030). That trend and how it’s related to the FoC is most interesting to me.

I'm following it very closely. Still waiting for the other AR shoe to drop.

Steve Peak Interesting. May I ask which platforms/devices you use on a daily basis today?

Ivan Reese Two more years. First we get Macs with FaceID and “Air Gestures” to once and for all settle that touch screen debate. ;-)

Big Sir (as I've self-amusingly taken to calling it) seems awfully touch-friendly all of a sudden. But you're thinking.. what.. they'll do some Magic Leap sort of hand tracking?

Yeah, that’s my theory. You’ll keep your hands mainly on the keyboard and touchpad, but can lift them up for gestures. There could also be something with attention and where you look at the screen. They could’ve added FaceID already, but I think they wanted to wait for having a Neural Engine and they’re going to put it to use for sure.

That would be a nice stepping stone to some gestural interface for AR which surely doesn’t have a surface to touch anymore. Apart from all the exciting stuff that’s going to happen with integrating all the displays you’ll have with you already: watch, phone, tablet.

Stefan Lesser TBH I’m not very impressed by Siri/Alex as it is today, but I do strongly believe in their future. Right now, the HCI with voice AI is mostly mono-directional (you to computer) as the interface of computer to you is pretty poor IMO, yet getting better. The devices I use are: Alexa at home, and rarely Siri on my iPhone. Alexa has been far more accurate while Siri frustrates me when it gets it wrong, the problem again is that it’s not bi-directional communication.

Yeah, I was disappointed to not see HomePod get more of an update this year. That device (like AirPods) is a good test case for them to work on all-voice interfaces.

A small thing but I like how they’re showing pasteboard API accesses to the user. Feels like the system’s behavior is just slightly more visible to the user.

Shortcuts is definitely more interactive and available now - feels like that's still Apple's big FoC investment • More interactivity via notifications • First-class widgets • Copy/paste blocks • Available on Apple Watch

I think SwiftUI’s improvements/expansion are very interesting — the syntax is so terse that some bananas things can be accomplished in next to no-code.

For instance, ```﹫main struct EditorApp: App { ﹫AppStorage("text") var text = ""

var body: some Scene { WindowGroup { TextEditor(text: $text).padding() } } }``` That is a fully functioning plain text editor

that has made it akin to something like html’s <input> fields

I’ve got my gripes about Swift, for sure, but am excited to see where it lands in 3 or so more years

Voice is fine for accessibility or when you want to trigger a shortcut or dictate a message while driving, ok, but I honestly can’t understand how people have so much confidence in voice. Have you never been on a call with your bank? Doesn’t even matter if you talk to a robot or a real person there, is that an enjoyable interaction? What would an enjoyable voice interaction with a computer be like? Don’t we need AGI for that?

SwiftUI is very interesting. I was hoping someone would bring it up, because it does look like a FoC to me.

Eli Mellen What are your gripes with Swift?

Really, my gripes about swift are about the tooling and ecosystem more than the language itself. I’m no fan of Xcode 😐

wrt. voice interfaces...

S: "Would you like to reply?" I: [not talking to siri] S: "Okay. What would you like to say?" I: "Hey Siri, stop." S: "Okay. Your message says: 'Hey Siri, stop'"

Sigh.

Ivan Reese ^^ ripe for innovation. I do 💯 agree that current voice interfaces are disappointing. This is perfect, just where I personally want them.

What part of this is potentially NP Hard? Working out optimal routes for the wires? What sort of goals do you have in mind? Minimizing crossing? Minimizing distance? The constraints on physical PCBs are very different from the constraints on graphical interfaces.

Also — blueprints is what I'd call a "patcher" or "node-and-wire" editor. I'd use the term "block-based" to describe something like Scratch. Hopefully that helps your search.

Also — do you have any sketches or references for what you'd like the result to look like? I might be able to point to approaches people have used in the past.

My goal is to hybridize a few tried-and-true styles of visual programming. I'm starting simple with something in the ballpark of patch based or block based programming, although I'm not being very disciplined about fitting myself into an existing category.

Attached is a mock up I've been using as reference material for the last few weeks.

My plan is to draw the entire layout, then progressively replace variable references with arrows. I don't want the arrows to ever cross. The idea is to use a jump if two lines would ever have to cross, like you see with 'constant z' and 'ref z' (although its not a realistic example because you could easily draw a line to replace the ref).

I think drawing any single arrow is easy (it should just be pathfinding), but drawing the arrows in aggregate can become hard or impossible as they begin to cut each other off. Potentially being able to re-order blocks to prevent wires from overlapping also introduces a feedback loop between drawing wires and laying out blocks that smells tricky.

By allows 'ref's I always give myself an out, but I'd rather show as many arrows as possible, for clarity's sake.

Yeah, this sounds amenable to a progressive refinement / iterative approximation approach. You could even make it somewhat interactive, where the programmer can put edges roughly where they want them, and then the system can sort of tidy up the layout.

Of course, with these sorts of approaches, you usually have to give up determinism, and naive implementations can be quite slow. You can probably do better than NP, though, since you can take advantage of spatial locality, just like collision detection systems in games.

(I'm personally of the total opposite opinion — that the programmer should have total manual control over the layout of their graph — so I don't have a good collection of references for ways that people have handled auto-layout. Others here might.)

I've been thinking of formatting like linting in a text based langauge, so what you're saying makes total sense to me. In addition to locality, I'm hoping good code hygiene will encourage fairly clean wires.

My dream is to support pluggable editors so users can view each block in their program in a different way. So, you could have most of your code automatically laid out, but the inside of your loop manually laid out or in a text editor. The dream is that each library would provide an editor that made sense for its contents. So, if you make a spreadsheet library, you would provide an editor that lets you manipulate the content of the spreadsheet, and if you write a GUI library, you provide a wysiwig widget editor.

I though this editor was a fun place to start, though.

Oh! I forgot to ask, what is it that you like about manually laying out patch based code? Do you have a particular example of an environment where that's a satisfying experience?

I'm used to graphics programs (2d and 3d), video editors, DAWs, and other environments where the arrangement of elements has an effect on the outcome. When it comes to code, I also prefer laying out my own code, rather than using a linter. I dislike the auto-layout feature of Max/MSP (though I think they could do a ton to improve their GUI regardless).

If you’re working in web frontend, https://github.com/projectstorm/react-diagrams may simplify things a bit for you

This is a pivot from your original ask, but there’s also a generic JS lib for making things that look like scratch, the insides may give you some ideas about “fill in the blanks” programming: https://developers.google.com/blockly

This is one of several "functional programming" features I've been seeing creep into imperative languages over the last few years. I think over time, the really good features of FP and imperative programming wind up crossing the fence until it's almost everywhere.

https://janet-lang.org/docs/peg.html

I’m not a language geek, but is this similar to PEG that I spotted in Janet recently?

Heh, I was just looking at PEP 622. First I was excited, then thought it's very messy and confusing. There's a new 'pattern grammar' which doesn't quite look or work like usual Python. Maybe it will make sense to me at some point.

It's not exactly like PEG. It's a language feature that lets you match objects against a pattern and also extract some matched parts into variables.

So PEGs (and regexes) are matchers for text. This is a built in language syntax to make a matcher for object trees, if that makes any sense.

Shalabh Chaturvedi I'm curious, what makes you say "doesn't quite look or work like usual Python"?

Hehe do we really want to get into PEP 622 here? Mainly it's because the meaning of whatever follows case is surprising if you know Python. It's not regular Python, it looks regular but is designed to work as a structure matching (and name binding language). Consider: case 123: - matches the value 123. so far so good

abc = 123 case abc: - matches 123? No, it matches any value because abc is a name pattern (will capture any value). What if you really wanted to match the value in the variable abc? Well now there's a brand new syntax (which only works inside case): case .abc.

Then there's the class patterns, which look like calls but actually capture values from an existing structure: case Point(x, y) - creates/sets x and y, if the object is a Point.

Anyway the PEP is still being worked on so lets see what it looks like eventually.

Thanks for going into the details. I don't want to hijack this Slack/thread with programming language minutia, but I'm a PL nerd so I'm always curious to see what new features there are in various languages.

I'm writing Scala for my day job and I've also used Haskell, Standard ML and Erlang for personal projects. They all have pattern matching constructs and pretty much all of them expose the same set of features you're talking about, with slight variations of course. From this point of view, at least, this PEP follows "industry standards".

This type of complex domain specific language with all of its tricks and traps is probably a mistake. For those rare instances when it would be used, you have now added 50 pages in the reference manual to explain all the subtleties. This type of feature is exactly the kind of thing Guido was constantly refusing to add. Now that he has left his position as BDFL, the complexification committee will take care of ruining Python. That's okay, i designed my Beads language as the evolution of Python by simplification, it can only help me.

If anything, this feature is in general abused, rather than seldomly used. I quite like it to be honest, but I find it more useful in a language with static typing.

Strangely, Guido is one of the PEP authors 😄 Also there is resistance to the PEP from some core Python folk, so lets see where this goes.

I like the idea of pattern matching too. Having it from the start in a language means other features were designed with it in mind. In Python it is being added later so it's going to be more complex to make it seem to fit. Consider the except E as e syntax - it's already kind of a pattern match using just isinstance. Would we not want matching to work identically in that syntax as well? IIRC you can have destructuring assignment in Erlang and put constants on the left, roughly "red", a = f() - this only matches and binds iff f() returns "red" as the first item in a pair. There's no such thing in Python, but you can have only free variables on the left that always get bound. Should that also work now, given the unpacking pattern can use case ["red", a] ?

My first impression is much like Shalabh Chaturvedi's: this is going to add a lot of complexity to Python, and is likely to become a nightmare for Python teachers. To add a criticism to Shalabh Chaturvedi's list: Point(x, y) not only looks like a constructor but isn't, it also interprets arguments in a different way from a constructor. Sure, one would expect Python programmers to ensure that a class' __init__ and __match__ are semantically compatible, but I bet we will see many classes whose __init__ allows more variations than __match__ . And I also bet that people will try to use class(**args) as a pattern and expect class to be bound to the class object.

I think a fundamental limitation is also you can only match over a key/value like structure. E.g. you can't match case Regex('a.*b') - the inner pattern is not sent to the class, but the class is supposed to return a 'static data field like' structure. So this also will cause problems if you have a few expensive computed properties - are you know supposed to generate and return all of them? What if the caller is only matching one?

BTW, this discussion made me think of this paper which basically says that destructuring or pattern-matching objects makes no sense at all. TL;DR: Objects expose only their behavior (via methods), but not their internal data structures.

Shalabh Chaturvedi for your regex example, it might be possible to do something like:

pattern = Regex('a.*b') match 'aaaab': case pattern(matched, capturingGroup1, etc): pass Regarding your other point, about expensive computations, the PEP says this:

There is no requirement that the attributes on the proxy object be the same type or value as the attributes of the original object; one envisioned use case is for expensive-to-compute properties to be computed lazily on the proxy object via property getters. Also, your concerns about pattern matching for exceptions and assignments are well founded, but it seems to me that they can add these capabilities later.

Konrad Hinsen that's a good paper, but pattern matching does not preclude data abstraction, just as using lists and dictionaries does not preclude it. At some point we have to inspect data and patttern matching helps there. Without this, we'd have to ban return or yield and write our programs in a completely continuation-passing style, which would be quite hard to understand.

I feel that once you'll be able to play with it, you'll like it more, unless you've already used pattern matching in some other language and decided it was a bad idea there.

Ionuț G. Stan that seems quite a roundabout way to do regexes, consider if you had multiple cases, you wouldn't be able to write literal regexes inline and have to alias them via new variable names. The PEP also says __match__ should be a class or static method, so we'll be creating one class per regex.

May main issue though is the seeming arbitrary mixing of 'capture variables' (lvalues) and variables as references. E.g. a = f() is clear and a.b = f() kinda follows. But case a is totally different from case a.b - in the latter case it's a reference, the the former case a is a name to be bound.

Honestly if all lvalues were tagged or separated, this would be much more acceptable to me. e.g. case Point as x,y or case Point(?x, ?y)

I guess you can tag the other case, although it's not enforced: case .a.b would work instead of case a.b. And I get your point, but on the other hand, the main purpose of pattern matching is to introduce new bindings, so the main use case should introduce as little syntax as possible, I think.

Also, regarding regexes. I haven't seen any language that supports both passing arguments and binding values in a pattern. That would be interesting.

I guess you could tag the other case.

I also think these are warts: in places where both x and x() are valid, the x part means the same exact thing. But here one is a new name and one is a reference. What if I wanted to match a specific point at a known x,y? case Point(x, y) wont work, but I feel it should work, given I can do case "hello" and have the value match. Literals and predefined constants get special features here.

enlightening thread

Not to be confused with another Enso, which seems dead now: http://enso-lang.org/ They seem to share the etymology, though.

For example, the GUI was slow, based on SVGs, and integrated with the Atom editor. It would be difficult, if not impossible, to get the performance we wanted building on that foundation.

This feels like a dodge. You can do wickedly complex stuff with SVG and maintain buttery 60. So I'm thinking this has more to do with their architecture (building on Atom instead of just Electron?) than the underlying tech.

https://twitter.com/pcwalton/status/1266049915848777730

https://twitter.com/pcwalton/status/1250557429189763073

it will eventually ship on firefox

Right, but that's a GPU SVG implementation. If you're making something that looks like Luna/Enso, you can go super fast just by being slightly clever about how you touch the DOM. No need for GPU, vdom, etc.

Anyways, this is OT.

For Enso, I like the look of their UI for ports around the nodes. Hard to tell from the GIFs on my phone, but it looks like you can't see variable declarations in the graph, just in the text view. That feels like a weakness, but I'm sure they have a plan in mind. Glad to hear they'll be posting regular updates!

https://twitter.com/enso_org/status/1276550780347179010

In the immortal words of Fred Brooks, "plan to throw one away". However, they must have burned some capital working for the last 2 years on this project. Doing it in Poland instead of SV means probably only 1/3rd the cost, but 5 people at 40k/year for 2 years is an estimated $400K USD. Red/Rebol is to my knowledge the best funded project on the FoC project list, they are concentrating on Crypto smart contract programming as their "home" domain.

Enso is now going down a tunnel where their system requires them to build the entire stack including editor, debugger, etc. That means more work and an even bigger project. I have some concerns about projects which don't build programs and projects and then work backwards from a project to figure out the best tool to make that project. Trying to design in a single direction is fraught with peril IMHO. All ladders connect two points in space, and one is typically looking for least complex connection between A and B, so one must go back and forth between A and B to optimize the path. This shuttling approach is very expensive in time and effort, but I think product design always works this way. I just saw the Ford F150 announcement, and they had a team of people going camping with their customers, and visiting jobsites, so that they could add in the features that were wanted and needed. The new F150 announcement underwhelmed people, because it was incremental, but in terms of ergonomics they really moved forward solidly towards a product that was more useful to their customers. They even considered the issue of the controls surfaces being usable by people with gloves on. So the knobs and controls are huge. I am helping a friend who is designing a hearing assistive device that is both hardware and software, and you have to make the controls extra big for seniors. I have always made my controls extra big and occasionally gotten hate mail from young punks who ridiculed the jumbo size. That's one thing i am a bit concerned about in the node and wire visual programming world is that they often expect high acuity in order to distinguish the tiny spatial differences between output #1 and output #2.

Wouldn't it depend on what language you built your own language in?

Would a general GUI library help?

It would depend, but I assume most of the suggestions would be web libraries/frameworks, which could probably be made to work with any language

GUI libraries are typically still native, due to performance concerns. Maybe that will change in future.

Agreed GUI libraries are native.

But it sounds like you are trying to describe a polyglot Visual Basic ?

Which language are you using Spencer?

well, my implementation is in Python right now, but really I'm just looking for a good implementation technology for such a UI - nothing about being polyglot

like, I can define some serializable protocol for discovering methods and objects and introspecting to find out the possible arguments, and implement that on my implementation side - but I don't know what would be a good way to implement the front-end of that

(And of course it would probably be nicer if I didn't have to send that data through a serializable protocol at all, but instead the front-end just got it as structured data through function calls, but that seems unlikely, so I can just bite that bullet)

Spencer Baugh whenever you’re talking about User interface libraries, Inevitably you will ask for a text entry field. The text entry field is the most complicated part of every operating system. To render text in a box and handle text entry, that is over 1 million lines of code more than your typical project. There are not even 100 people alive in the world who know the truetype language that underlies text rendering. The text editing library code is therefore deeply tied to either the operating system vendor or one of the few companies that has spent millions of dollars to understand it. So Google, Adobe, Apple, Microsoft, and a few Japanese companies and Samsung, Are among the few places where this technology has been mastered. Text entry is incredibly complicated when you get to Asian languages or right to left languages like Hebrew and Arabic. Haven’t you ever wondered why the PDF file format took over as the World standard for documents? It’s because it was the only file format that allowed font embedding, and had missing font fail over technology. Nowadays with soft keyboards on mobile devices the world has gotten very concentrated into just two operating systems. iOS and android, and the market is split between those two about 80/20 Although the economic value of the Apple platform is about 50% due to their more well heeled customer base.

a Console based Product in python can be very platform independent, but the minute you ask for Graphics and the black box of a text entry field you are now tied to an operating system or a platform technology like Adobe Air which offers platform independent text entry fields and font rendering. I am pretty sure that Unity has a cross platform input field technology as well, but I have not used it. The Google Flutter library is an attempt to make a cross platform technology which is powerful, and there is also QT which has been around long enough to cover all sorts of stuff. There are very few Python libraries which delve into font rendering and text entry fields in their full glory. In Photoshop, when you are putting in text, you have the ability to select 5 different rendering styles ("soft", "hard", "sharp", etc.), and you can massage the font rendering process very finely. MS went though a big effort to render fonts on LCD screens more beautifully by doing sub-pixel rendering, i think they called it "Clear Type". This is a very deep area and affects output quality very noticeably. Apple has always had terrific rendering, why artists overwhelmingly prefer OSX over Windows. Human languages are really complicated and supporting them is a huge task. English with its lack of accented letters and very simple structure is pretty much the easiest language on earth. Japanese is actually the most difficult language on earth to handle properly. So the benchmark for most technologies, is how well does it handle Japanese? Korean and Chinese are tough but more uniform than Japanese. calligraphic Arabic is basically impossible. But all the right to left languages present very tricky rendering problems because people intermix left to right and right to left sections in the same sentence.

If you can avoid having a text entry field Like most game machines have a grade of alphabetic characters you type with, then it becomes a great deal easier and now you’re back to simple polygons and bezier splines and there are dozens of libraries that do those. Python has a huge library set.

So the decision point in your library selection process will revolve around, are you going to be doing text entry? And will you have user added fonts in your universe? A lot of GPU graphics libraries start to fizzle out when you get into text entry and fonts. Many a game has been built using bitmaps of letters, Arranged in spritesheets so that the GPU you can draw text quickly. The game machine companies spend big money in their OS to handle the intricacies of text so the game programmers don't duplicate a lot of effort.

anyway you have touched on a deep subject that does not permit a simple answer. I spent much of my career making Japanese software and so this area was of great interest to me

Ok so it is python. Does this mean python on the server and HTML /JavaScript on the client ?

https://wiki.python.org/moin/GuiProgramming might be a starting point.

via google: 'cross-platform python gui'

https://python-gtk-3-tutorial.readthedocs.io/en/latest/drag_and_drop.html

Sorry I think I was misleading in my question - I'm talking about good libraries that one could use to make a visual/interactive programming environments. The "OOP" in my question was about the user experience, not about the implementation. I'm indifferent to implementation language, like I said.

Of course any UI toolkit or library is capable of doing that (such as GTK), I'm just wondering if anyone has thoughts on ones which are particularly good at it

Not to my knowledge. Just the low-level GUI has a lot of trade-offs (some discussed above), and language developers unfortunately don't seem to be a large enough market for a yacc-style GUI tool.

I suggest you look into https://www.qt.io/qt-for-python, at least they support Python. Unity favors C++ or JS. Adobe AIR requires Haxe or AS3, OSX requires Swift or ObjectiveC and Android is primarily programmed in Java. Python being interpreted is not typically used to build graphical interactive software. Python has weak module support, so not well suited for large projects. If the reason you like Python is because you prefer indentation significant languages, you can always try my Beads language which is very similar to Python.

you might want to look at game engines—a lot of UI libraries for HTML/etc are directed at basically form input—if you want to do something more adventurous game engines are usually more amenable without a lot of custom work

Yeah, if you want graphical interactivity then game engines give you a ton of leverage at a very low learning cost.

You mean like https://stackoverflow.com/questions/41332861/click-and-drag-a-rectangle-with-pygame?

If you want to use a html/javascript library, then you can take a look at konva https://konvajs.org/ .. it has drag and drop support for shapes. I use it myself actually, together with react