1. 1

    I use this around the luajit / lua cli so much. :D

    1. 2

      vscode terminal but w/ WSL shell is actually p fast on Windows.

      1. 23

        It surprised me to learn that “#[cfg(unix)] was historically defined as #[cfg(not(windows))] so that having two configurations of #[cfg(windows)] and #[cfg(unix)] would “technically” cover all the targets.” Rust shouldn’t assume that all OSs in the universe are either Unix or Windows, and Fuchsia is as good a place as any to stop making that assumption.

        1. 21

          It used to, it doesn’t any more. Redox (OS written in Rust) support is upstream in Rust and Redox is marked as neither Unix nor Windows, as it should. The proposal here is to do the same to Fuchsia.

          1. 6

            Redox has no target_family:

            I laughed when I saw this. That’s awesome.

            1. 2

              If you interpret it as ‘POSIX-compliant’ vs ‘not POSIX-compliant’ it makes plenty of sense. Operating systems either conform to the portable operating system standard or they don’t.

              1. 12

                Why should you do that? There’s a lot more beyond just Unix or even POSIX if you insist on that. Assuming non-POSIX means Windows, Fuchsia, Redox and all the operating systems that have, do and shall exist are “basically the same” is peak *nix-arogance (along with calling it the portable operating system standard).

                1. 1

                  And just because you implement a lot of POSIX doesn’t make you a POSIX system, especially if there’s key differences; i.e, VMS and i, which implement large swathes of POSIX but not fork, for example.

                  1. -1

                    peak *nix-arogance (along with calling it the portable operating system standard).

                    It’s not arrogance any more than it’s arrogance to suggest a C compiler should conform to the C standard. Operating systems should conform to the operating system standard. If they don’t, they’re non-compliant, and that is its own category. That doesn’t mean they’re all the same.

                    1. 19

                      C is a particular language and thus can have “the” standard for it. Operating systems are a category of software and POSIX is just one standard for them, it’s not “the” standard. Similar to how there is no standard for “programming languages” in general.

                      1. 4

                        That doesn’t mean they’re all the same.

                        My rust is rusty but from what I see cfg is something like #ifdef __unix__, #ifdef _WIN32, etc. If all the distinctions are “this is unix, so I can assume following behaviour” or “this isn’t unix” then there’s really not a lot you can do in the latter case.

                        But settings that aside, POSIX has an obvious *nix inclination. If I were to implement a totally different system like CLOSOS or a real-time, embedded OS, requiring it to “conform to ‘the’ operating system standard” would be absurd. What if I don’t want files or byte-stream pipes? What if I don’t want to use fork(2) for process creation? What if I don’t want the shell to be the primary UI/UX? What if I don’t want to use C? – There are so many possibilities what not-POSIX could look like, just like not-the number one has quite a few different variations.

                        This is all just even more absurd when considering that it obviously hasn’t been an issue to just add more operating systems to cfg. It’s an absolute non-issue.

                        1. 4

                          Fuchsia actually checks two of your lists. Fuchsia doesn’t use fork and doesn’t specify ABI in terms of C.

                    2. 1

                      The linked article explains that Fuchsia is not POSIX-compliant and it never will be. So it makes sense to mark Fuchsia “not unix”.

                      1. 1

                        Yes, if anything the distinction should be ‘unix’ vs ‘not unix’ rather than ‘windows’ vs ‘not windows i.e. unix’.

                  1. 2

                    So the benchmarks show that everything is faster with Chez Scheme, except VM startup is slower? That seems to be the prevailing trend in VMs.

                    Python 3 is the same way now – everything is faster than Python 2, except startup. There was a good PyCon talk showing this, but this message also gives some numbers [1].

                    I have a prototype of a shell solution to this here:

                    Shell Protocol Designs http://www.oilshell.org/blog/2018/12/05.html#toc_2

                    https://github.com/oilshell/shell-protocols/tree/master/coprocess

                    It requires around 100 lines of code in the VM or application, assuming the application can make the dup2() libc call and such. If anyone wants to help prove the protocol, let me know :)

                    [1] https://mail.python.org/pipermail/python-dev/2017-July/148656.html

                    1. 3

                      So the benchmarks show that everything is faster with Chez Scheme, except VM startup is slower? That seems to be the prevailing trend in VMs.

                      Not at all; the benchmarks show a good number non-startup things which are faster on the old Racket.

                      1. 3

                        Yeah I skimmed the first few rows of the graphics and misinterpreted. I think it would be easier to read if they had overlaid them somehow in a vertical format, or maybe provided a summary.

                      2. 2

                        The LuaJIT VM starts up pretty quickly.

                      1. 3

                        Pretty neat! Code is well-organized too (directory hierarchy is a bit deep haha)!

                        Could do a mobile version w/ React Native and share a good amount of the code potentially 🤔🤔. Another interesting thing would be having the codemirror elements be executable JS; to the point of rendering components that they are the source of. Or even making various notes modules each other can import. So it becomes a literate code note taking app 🤔🤔.

                        1. 1

                          Yes mobile apps are definitely missing, there could be a good amount of code sharing between the platforms, ideally I’d like to have as close to a single codebase as possible.

                          I’m not sure what you’re suggesting codemirror-wise, but feel free to open an issue about that on GitHub.

                        1. 2

                          I find scratch.mit.edu to be somewhat good at this. There is also a paper somewhere in the vissoft2014 publications that shows using types to prevent blocks that don’t fit in a place from appearing there.

                          One thing to note is that often – I am trying to do an edit that is internediately not an AST, till I get to one. This is often the case when group editing many lines with a regex or such. One clearer variant of it is – intermittently doesn’t typecheck, then will. We need to be careful about which states we let the UI let the user put themselves in and which they don’t; or make it clear how they can express how much they want at each moment.

                          1. 2

                            Piggy-backing on your comment, as its second part conveys more or less what I wanted to reply. I think it’s not my own intuition, that I’ve read it somewhere (probably HN): that there may actually be a reason why people seem to stick to text editors in the end. And it may be that the AST editors are too strict for expressing programmer’s thoughts, which may start on the more vague and imprecise side. For example when writing something, I may want to be able to start by “drafting” the code, to put down a sketch of my general idea, and only then run a compiler and syntax-check or even type-check it, and start molding it to fit into the rigid requirements of code. (Quite often this phase may invalidate some of my initial assumptions and force me to rethink parts of my solution, of the “thesis” expressed in code words.) In other words, I may be ignoring even syntax errors on purpose when writing the initial draft.

                            On the other hand, this phase could arguably be done in comment blocks / inline comments.

                            Interestingly to me, this idea seems to have some consequence for me when trying to use the luna-lang.org GUI. On one hand, they seem to be somewhat aware of this dynamic, as the GUI allows adding invalid nodes, and composing them together in correct way only later. On the other hand, I seem to recall that when trying to use it, I had this weird feeling that I still wanted to first sketch the overall structure of a function on a sheet of paper, before trying to “draw” it in the Luna GUI. Though this may as well have been purely because of the slowness of the GUI as of its current iteration. (Keeping my fingers crossed for the new GUI they want to release in the new year — hopefully they manage to push it out the door earlier than later.)


                            Also, on a more or less related note to the OP, the recent announcement of the “Tree Sitter” approach to parsing may or may not be somewhat relevant here (HN, lobste.rs).

                            1. 1

                              As you point it out, the sweet spot would be for a tree editor to allow unconstrained editing (ie. no enforcing of schema/grammar) as well as constrained editing. Taking the analogy of XML, you could very well edit a tree with multiple namespaces weaved into the document, one validated by a schema, and the other one only loosely validated.

                              Speaking of GUIs, I think that part of the reason tree editors are still pretty much a research topic is the lack of supporting infrastructure. Programming is very text-centric and so are the tools (starting with UNIX, the shell, etc). Most GUI toolkits lack the flexibility required by interactive, user-friendly tree-editing – it’s only in the past few years that the DOM, CSS and the Web APIs have evolved to a point where this is feasible with good interactivity and reasonable performance (although, as you point out, performance is still an issue for some).

                              And when you think about it, it make sense: the Web is built on the notion of trees combining pieces of heterogeneous data together. With XML you have XSLT (transformations), XPath (queries) and XML-Schema (grammar). With CSS you can style the presentation and control the interaction with JavaScript.

                              For me, the takeaway of Tree Sitter is that we’re starting to realize that incremental transformation is the way to go for programming languages tools (parsers, compilers, etc). When you’re editing a live AST, you have the ability to stream tree deltas (patches) directly instead of re-processing the whole thing. All you need is a compiler/interpreter that is able to translate these changes into changes to the output (binary/UI).

                              With so many programming languages out there and LLVM becoming the de-facto substrate, I feel we’re on the right track to start rethinking syntax and free it from the shackles of a given textual representation.

                          1. 2

                            Awesome! Just curious, what changed between your comment on the previous “Rust and WASM” story and now?

                            1. 6

                              the biggest things were mobile browser GPU support (this was hard), the upload/browse/restore backend, and a few new elements + tweaking to many of their behaviors

                              1. 2

                                what were the issues with mobile browser gpu support?

                                1. 5

                                  The two main issues were:

                                  The texture types they support (the fluid sim is in floats, but on phone browsers I could only take data in or out of the shaders via unsigned byte textures, required some munging)

                                  There’s also a maximum # of bound texture units of 8, and I had to plug a lot of gaps in my knowledge of how OpenGL works in order to correctly bind textures for each program and stay under that limit.

                                  all of this was made more complicated by the fact my only phone is an iphone and I don’t own a macbook. Apple only allows you to connect to the safari devtools from a mac >:’( So i was debugging somewhat blind.

                                  1. 1

                                    Apple requires developers to both own a mac to build and also pay them a yearly fee to be able to offer even free apps on their app store. This kinda sucks, but on the other hand the hardware + macOS is okay.

                            1. 2

                              How has Rust solved the callback problem of async/await? To explain what I mean, imagine you have an array of URLs and you want to open each of them in turn, download their contents, then do something with those contents. If you wanted to iterate over an array normally you’d do something like urls.foreach(|url| process(url.get()));.

                              But what happens when that get is async? Don’t you have to duplicate all your functions to take async functions? You need an async_foreach that takes an async function, etc. etc.

                              Now I know that in Rust, iterators are used, but essentially the same problem still exists, just a little swapped around. In most ‘async/await’ systems you can’t call async functions from normal functions. I would assume the same is true of Rust.

                              To compare to a system like Go’s, where there aren’t special ‘async’ functions, and you don’t need to rewrite every bit of code that takes a callback to also have a version that takes an async callback and calls the callback asynchronously.

                              1. 3

                                Depends on whether you want to fetch each url in parallel or in series.

                                Go does it in series ‘by default’ and provides goroutines to do it in parallel.

                                From my understanding, you can do something like foreach process(await url.get()) to run in series, or join(foreach(|url| await process_async(url.get()))) to do it in parallel (where process_async accepts a future and returns another).

                                This is also how javascript does it. You don’t need a special version of foreach since futures are just another type.

                                You should also be able to generate a future-ized version of a function automatically with macros (eg automatically converting a function of type PageHtml => Result type into Future<PageHtml> => Future<Result>

                                1. 2

                                  But you still need a process and process_async?

                                  If so, this post illustrates the problem: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ .

                                  Go avoids it by having a high level m:n userspace thread scheduler so there’s no need for separate versions of each function. (basically everything is async) It’s not a zero-cost abstraction though so wouldn’t make sense for Rust. (its a lot like a garbage collector in that regard)

                                  I’m not sure what a better solution would be. At least async/await cleans up the code.

                                  1. 1

                                    If zero-cost abstraction is the goal, would it be possible (in any reasonable time) to make everything async-by-default but have the compiler remove asynchronity where it’s not needed?

                                    Go’s approach seems quite brilliant as an actual real-world, existing & working solution. I think Crystal follows its lead on this.

                                    1. 2

                                      I don’t think it can be done without introducing a custom scheduler. Channel, network and time operations can be handled intelligently (described in more detail here: https://dave.cheney.net/2015/08/08/performance-without-the-event-loop)

                                      So blocking a thread might be a normal OS thread wait, or it might be put into a network event loop (kqueue, epoll, etc) so the code looks uniform, but there’s a lot of magic behind the scenes.

                                      It’s very clever, but there are costs. Occasionally there have been major performance issues from unexpected edge cases. I’m not sure how often people run into those anymore, but it can happen. And there is definitely overhead and less control when it comes to the scheduling. Though in theory the scheduler will probably do a better job scheduling than whatever the vast majority of programmers would come up with.

                                      I think using futures with async/await allows you to do something very similar if you use an async io library: https://manishearth.github.io/blog/2018/01/10/whats-tokio-and-async-io-all-about/

                                      Though the part I don’t understand is how you do selection

                                      1. 1

                                        Interesting thought (making things async by default) but I guess one would need to be more specific. If done manually, unnecessary async should be optimized away. Rust with the current proposals, of course, distinguishes between future construction and execution which is sometimes nice.

                                      2. 1

                                        You write a process function, and use a macro to future-ize it when you pass it to foreach.

                                        1. 1

                                          You need process_async if processing itself needs asynchronous calls. Yes, that also means that if you have to abstract and one of the implementations uses async calls, the interface also needs to be async. That said, it will be incredibly easy to implement an async interface with sync code.

                                          The only time this is a problem is when you have a sync integration point in a library that you do not control and you need to do async calls. You can still, of course, simply block the calling thread until your processing is done.

                                          What you get in rust is: really nice guarantees that you do not have in go, less overhead, easy cancelation. That said, as GC, the go model makes some things more uniform and even more easily composable; and you have stack traces, awesome (I mean it)! Rusts to avoid a (larger) runtime and manages to have more safety guarantees nevertheless. Quite a feat.

                                      3. 2

                                        You need async_foreach bc each variant is literally different. Parallel, sequential, fire and forget vs. collect and wait; are all different semantics and all valid. So it’s not accidental complexity that which variant you want must be specified when choosing the foreach since it evaluates to the result.

                                        On the other hand – an intresting way around this is to use coroutines and explicit scheduling (like in Lua) (so you do schedule(function() process(...) end)). You do have to explicitly wait after the foreach if you want waiting semantics.

                                        1. 1

                                          When get is async, it returns a future that must be polled to completion (or cancelled, though I’m not sure what the cancellation story is for Rust futures). This can be done one at a time, blocking the current thread, or each can be registered on an Executor, such as an epoll-backed thread pool.

                                          If using async/await, then you can call your example inside an asyc function, and either await each url or select between the ready ones.

                                          Disclaimer: this is my current understanding, but it may be incomplete or inaccurate, as I’ve spent very little time with Rust futures.

                                        1. 2

                                          Lua + LÖVE is also a great option. Lua has a very simple stack and has ‘eval’ (load(...)()) built-in with no code transformation etc. required. And is super fast with LuaJIT. Is very easy to bind more C++ stuff too if you want to.

                                          1. 6

                                            Working on a high level API to make multiplayer games easier to write. Is on a Love based engine with lua-enet. https://github.com/expo/ghost-multi/blob/master/example_triangle_warz.lua <– example game using this. Will make another example and maybe write a tutorial. The lib itseld is the ‘sync.lua’ sibling file of that file.

                                            The library automatically synchronizes objects (you need to mark them for sync so it doesn’f sync too many) from an authoritative server instance to client replicas and allows clients to make calls back through “controllers” (one per client). Clients can do local logic on their replicas for predictive stuff.

                                            1. 1

                                              Wow didn’t think lobste.rs would be the place to discover a VST! Gonna give this a shot. Really digging your OpenGL UI lib too, the code looks neat. Really good work! :)

                                              1. 16

                                                As a junior developer doing my best to learn as much as I can, both technically and in terms of engineering maturity, I’d love to hear what some of the veterans here have found useful in their own careers for getting the most out of their jobs, projects, and time.

                                                Anything from specific techniques as in this post to general mindset and approach would be most welcome.

                                                1. 34

                                                  Several essentials have made a disproportionate benefit on my career. In no order:

                                                  • find a job with lots of flexibility and challenging work
                                                  • find a job where your coworkers continuously improve themselves as much (or more) than you
                                                  • start writing a monthly blog of things you learn and have strong opinions on
                                                  • learn to be political (it’ll help you stay with good challenging work). Being political isn’t slimy, it is wise. Be confident in this.
                                                  • read programming books/blogs and develop a strong philosophy
                                                  • start a habit of programming to learn for 15 minutes a day, every day
                                                  • come to terms with the fact that you will see a diminishing return on new programing skills, and an increasing return on “doing the correct/fastest thing” skills. (e.g. knowing what to work on, knowing what corners to cut, knowing how to communicate with business people so you only solve their problems and not just chase their imagined solutions, etc). Lean into this, and practice this skill as often as you can.

                                                  These have had an immense effect on my abilities. They’ve helped me navigate away from burnout and cultivated a strong intrinsic motivation that has lasted over ten years.

                                                  1. 5

                                                    Thank you for these suggestions!

                                                    Would you mind expanding on the ‘be political’ point? Do you mean to be involved in the ‘organizational politics’ where you work? Or in terms of advocating for your own advancement, ensuring that you properly get credit for what you work on, etc?

                                                    1. 13

                                                      Being political is all about everything that happens outside the editor. Working with people, “managing up”, figuring out the “real requirements’, those are all political.

                                                      Being political is always ensuring you do one-on-ones, because employees who do them are more likely to get higher raises. It’s understanding that marketing is often reality, and you are your only marketing department.

                                                      This doesn’t mean put anyone else down, but be your best you, and make sure decision makers know it.

                                                      1. 12

                                                        Basically, politics means having visibility in the company and making sure you’re managing your reputation and image.

                                                        A few more random bits:

                                                    2. 1

                                                      start a habit of programming to learn for 15 minutes a day, every day

                                                      Can you give an example? So many days I sit down after work or before in front of my computer. I want to do something, but my mind is like, “What should I program right now?”

                                                      As you can probably guess nothing gets programmed. Sigh. I’m hopeless.

                                                      1. 1

                                                        Having a plan before you sit down is crucial. If you sit and putter, you’ll not actually improve, you’ll do what’s easy.

                                                        I love courses and books. I also love picking a topic to research and writing about it.

                                                        Some of my favorite courses:

                                                        1. 2

                                                          I’ve actually started SICP and even bought the hard copy a couple weeks ago. I’ve read the first chapter and started the problems. I’m on 1.11 at the moment. I also started the Stanford 193P course as something a bit easier and “fun” to keep variety.

                                                    3. 14

                                                      One thing that I’ve applied in my career is that saying, “never be the smartest person in the room.” When things get too easy/routine, I try to switch roles. I’ve been lucky enough to work at a small company that grew very big, so I had the opportunity to work on a variety of things; backend services, desktop clients, mobile clients, embedded libraries. I was very scared every time I asked, because I felt like I was in over my head. I guess change is always a bit scary. But every time, it put some fun back into my job, and I learned a lot from working with people with entirely different skill sets and expertise.

                                                      1. 11

                                                        I don’t have much experience either but to me the best choice that I felt in the last year was stop worrying about how good a programmer I was and focus on how to enjoy life.

                                                        We have one life don’t let anxieties come into play, even if you intellectually think working more should help you.

                                                        1. 9

                                                          This isn’t exactly what you’re asking for, but, something to consider. Someone who knows how to code reasonably well and something else are more valuable than someone who just codes. You become less interchangeable, and therefore less replaceable. There’s tons of work that people who purely code don’t want to do, but find very valuable. For me, that’s documentation. I got my current job because people love having docs, but hate writing docs. I’ve never found myself without multiple options every time I’ve ever looked for work. I know someone else who did this, but it was “be fluent In Japanese.” Japanese companies love people who are bilingual with English. It made his resume stand out.

                                                          1. 1

                                                            . I got my current job because people love having docs, but hate writing docs.

                                                            Your greatest skill in my eyes is how you interact with people online as a community lead. You have a great style for it. Docs are certainly important, too. I’d have guessed they hired you for the first set of skills rather than docs, though. So, that’s a surprise for me. Did you use one to pivot into the other or what?

                                                            1. 7

                                                              Thanks. It’s been a long road; I used to be a pretty major asshole to be honest.

                                                              My job description is 100% docs. The community stuff is just a thing I do. It’s not a part of my deliverables at all. I’ve just been commenting on the internet for a very long time; I had a five digit slashdot ID, etc etc. Writing comments on tech-oriented forums is just a part of who I am at this point.

                                                              1. 2

                                                                Wow. Double unexpected. Thanks for the details. :)

                                                          2. 7

                                                            Four things:

                                                            1. People will remember you for your big projects (whether successful or not) as well as tiny projects that scratch an itch. Make room for the tiny fixes that are bothering everyone; the resulting lift in mood will energize the whole team. I once had a very senior engineer tell me my entire business trip to Paris was worth it because I made a one-line git fix to a CI system that was bothering the team out there. A cron job I wrote in an afternoon at an internship ended up dwarfing my ‘real’ project in terms of usefulness to the company and won me extra contract work after the internship ended.

                                                            2. Pay attention to the people who are effective at ‘leaving their work at work.’ The people best able to handle the persistent, creeping stress of knowledge work are the ones who transform as soon as the workday is done. It’s helpful to see this in person, especially seeing a deeply frustrated person stand up and cheerfully go “okay! That’ll have to wait for tomorrow.” Trust that your subconscious will take care of any lingering hard problems, and learn to be okay leaving a work in progress to enjoy yourself.

                                                            3. Having a variety of backgrounds is extremely useful for an engineering team. I studied electrical engineering in college and the resulting knowledge of probability and signal processing helped me in environments where the rest of the team had a more traditional CS background. This applies to backgrounds in fields outside engineering as well: art, history, literature, etc will give you different perspectives and abilities that you can use to your advantage. I once saw a presentation about using art critique principles to guide your code reviews. Inspiration can come from anywhere; the more viewpoints you have in your toolbelt the better.

                                                            4. Learn about the concept of the ‘asshole filter’ (safe for work). In a nutshell, if you give people who violate your boundaries special treatment (e.g. a coworker who texts you on your vacation to fix a noncritical problem gets their problem fixed) then you are training people to violate your boundaries. You need to make sure that people who do things ‘the right way’ (in this case, waiting for when you get back or finding someone else to fix it) get priority, so that over time people you train people to respect you and your boundaries.

                                                            1. 3

                                                              I once saw a presentation about using art critique principles to guide your code reviews. Inspiration can come from anywhere; the more viewpoints you have in your toolbelt the better.

                                                              The methodology from that talk is here: http://codecrit.com/methodology.html

                                                              I would change “If the code doesn’t work, we shouldn’t be reviewing it”. There is a place for code review of not-done work, of the form “this is the direction I’m starting to go in…what do you think”. This can save a lot of wasted effort.

                                                            2. 3

                                                              The biggest mistake I see junior (and senior) developers make is key mashing. Slow down, understand a problem, untangle the dependent systems, and don’t just guess at what the problem is. Read the code, understand it. Read the code of the underlying systems that you’re interacting with, and understand it. Only then, make an attempt at fixing the bug.

                                                              Stabs in the dark are easy. They may even work around problems. But clean, correct, and easy to understand fixes require understanding.

                                                              1. 3

                                                                Another thing that helps is the willingness to dig into something you’re obsessed with even if it is deemed not super important by everyone around you. eg. if you find a library / language / project you find fun and seem to get obsessed with, that’s great, keep going at it and don’t let the existential “should i be here” or other “is everyone around me doing this too / recommending this” questions slow you down. You’ll probably get on some interesting adventures.

                                                                1. 3

                                                                  Never pass up a chance to be social with your team/other coworkers. Those relationships you build can benefit you as much as your work output.

                                                                  (This doesn’t mean you compromise your values in any way, of course. But the social element is vitally important!)

                                                                1. 13

                                                                  Not much has changed since 2012 when this was published, Rust & Go (released in 2009/10) still don’t have any GUI libraries anywhere near as simple as REBOL, instead wrapping an older GUI system or using XML. In fact, most programming languages seem to expect you to make the GUI in HTML/JavaScript/CSS now, 6 years after this post. Even visual programming languages like Scratch rely on replicating textual elements with graphical puzzle pieces. Once you get into Piet or pureData, the language is visual, but I wouldn’t recommend trying to write a GUI app with an esolang like Piet, pureData, on the other hand, lets you create a simple or more complex GUI but it’s nothing you would traditionally consider code.

                                                                  1. 3

                                                                    Have you tried / what do you think of something like ImGui (especially when exposed to a “scripting” language)?

                                                                    1. 1

                                                                      Haven’t seen it before – looks good – and it’s been ported to Rust/Go & Javascript… https://github.com/ocornut/imgui

                                                                    2. 1

                                                                      I think that the we are still far away from the ideal library the article mentioned.

                                                                      Electron (for all it’s flaws) get’s fairly close. It’s not as descriptive, but HTML paired with a good CSS framework can get fairly close.

                                                                      There’s nothing that’s true native that comes even close though. I wonder how long it’ll take. Maybe with the advent of UIKit for macOS/iOS we’ll get another paradigm shift?

                                                                    1. 4

                                                                      This has a lot of overlap with ideas I’ve been working on independently (like small computing, composable GUIs, implicit over-the-network message passing on cluster computers, and stack based languages with visible state). Presumably Don & I have both been paying a lot of attention to Alan Kay :). Glad there are fellow-travelers around – for a long time it was easy to believe I was the only Xanadu/Smalltalk/ZUI guy around!

                                                                      1. 5

                                                                        I really like the “tentative guidelines for composable uis” post. Going to save and reflect on that a bit.

                                                                        I’ve been working on a live-codeable interactive environment inspired by Self/Smalltalk etc., but using a Lua prototype-inherited scopes system (where code is “eval’d” in reified environments that can inherit from each other). After some iteration on such things I’ve realized it helps to have a concrete use case (allows testing, motivation, and empathizable communication with other people), but at the same time the choice of good use cases is important: if I choose a “make boring CRUD apps” use case, it basically involves porting existing libs + concepts and limits experimentation – so I went with a ‘generative art tool’ use case. This seems to let folks that look at it challenge their current ways of thinking about “software development.” It can evolve from static to animated art, then simulations (thus allowing games) and eventually hoping for network collaboration etc. Here are some videos:

                                                                        https://www.youtube.com/watch?v=zDGzEUJscYE (making an art sketch)

                                                                        https://www.youtube.com/watch?v=5-mxbhHBFOw (making another sketch)

                                                                        https://www.youtube.com/watch?v=rRMeOGc1JLQ (slightly older, using it on the phone, you can see the browsing / inheritance here)

                                                                        As you may have noticed, here too there is a concept of ‘sending messages’ to the scopes – all a message is is some code to eval at the scope, and that’s how you program objects to begin with anyways.

                                                                        Some of the ‘composable UI’ stuff I’ve explored here is that like the .__tostring(...) metatable function Lua datatypes can support, the ‘console’ window will call a .__toui(...) metatable function on values you try to print in it (if defined), so that objects can provide their own renderers, you can set custom renderers for slots that you add to scopes (going to explore this soon for color picker widgets), …

                                                                        I’m trying to use terminology like ‘perform’ etc. and more other art/human oriented words to move this tool away from “software engineering as a career choice” style orientation, as I think some of your blog posts also touch on. ‘Mindstorms’ by Seymour Papert along with some other readings are fun to explore here…

                                                                        1. 2

                                                                          This is fantastic!

                                                                          Some of my earlier experiments in the composable-UI vein used Lua, but I found that it was easy to run up against both coroutine problems (lack of preemption) & limitations in the maximum number of identifiers in the global namespace. Your work here looks a lot more advanced than mine ever got.

                                                                          (My current prototype is in Io, but I discovered that I would essentially need to rewrite Io to get a working system, because it stopped being maintained years ago & has problems with its speculative execution based thread planning.)

                                                                          1. 3

                                                                            Yeah def. understand the global identifiers thing – in my prototype above globals are by default written to the ‘current object’ and scopes can inherit, so it sort of works like process environments in UNIX. You can really bend Lua to your will a lot – I do it by setting the metatable of the environment that code is eval’d in.

                                                                            Thanks for the nice words. :) I really like your writings so will be digging in there more. Definitely feels like you’ve thought about this stuff a lot and there’s good overlap. Will update you as I make more progress on this. Let me know if / when you have any more sources for me to grok!

                                                                            1. 2

                                                                              There’s a group of people interested in the subject of composable UIs, hypertext, and utopian attempts to fix what’s broken about computing as a whole, over on mastodon. Most of my discussion happens there, & a lot of what I write on Medium is a refined version of discussions I have there. You might find that stimulating – I don’t represent the views of the whole community, which overlaps with the generative art scene.

                                                                            2. 1

                                                                              (My current prototype is in Io, but I discovered that I would essentially need to rewrite Io to get a working system, because it stopped being maintained years ago & has problems with its speculative execution based thread planning.)

                                                                              I didn’t realize Io wasn’t maintained anymore! That makes me sad. By happenstance, I’d looked recently and found the repo itself to be quite active, but it does mostly look like keep-it-going maintenance, not heavy work. Ah well. I recall it having its own pretty cool UI toolkit back in the day, too.

                                                                              That said, would you mind explaining a bit about the speculative thread planning? I was just an undergrad last I used it, and I’d thought Io had a pretty normal cooperative threading system; this makes it sound like I really misunderstood something pretty cool, but I can’t find much (any?) info about this on the language site. (All I could find was the note, “The Scheduler object is responsible for resuming coroutines that are yielding. The current scheduling system uses a simple first-in-first-out policy with no priorities.”)

                                                                              1. 1

                                                                                There’s some kind of complicated heuristic for determining whether or not coroutines have already exited, when determining whether or not to transfer control to them. I ran into false positives with regard to that behavior, which were not entirely reproducible. I asked about the behavior in the irc channel, & was told that this was a known bug with the scheduler system, and one of the reasons active development was halted – the author didn’t think he could get the behavior right in C, if I understand the history correctly.

                                                                                I started implementing a new version in Go (a language I don’t know, but one that has support for channels and real multithreading built-in). This should allow me to more easily make it support a smalltalk-style image-based format with a history & support for transactions & rolling back execution, too, so it’s a general win. (Plus, since I don’t need to keep full compatibility with Io, I can break that compatibility if it makes it easier to make my composable UI system – the important bits are message passing, multi-threading, a prototype-based object system, and a simple syntax with few keywords to memorize, all of which can be preserved.)

                                                                          2. 2

                                                                            Hell yes on composable components! Great articles, thanks!

                                                                            Here’s the money shot from an HN article I just posted about that:

                                                                            Valerie Landau interviewed by Martin Wasserman

                                                                            Q: Do you have any last minute comments or observations about him to finish up. Or a good anecdote?

                                                                            A: I think – I wanted to say one thing that Doug told me many years ago. And this is really for the software developers out there. Once, this was in the 90’s. And I said, Doug, Doug, I’m just started to get involved with software development, and we have this really cool tool we’re working on. Do you have any advice, about … for a young software developer. He looked at me and said:

                                                                            “Yes. Make sure that whatever you do is very modular. Make everything as module as possible. Because you know that some of your ideas are going to endure, and some are not. The problem is you don’t know which one will, and which one won’t. So you want to be able to separate the pieces so that those pieces can carry on and move forward.”

                                                                            https://news.ycombinator.com/item?id=17121629

                                                                          1. 4

                                                                            Working on a graphics live-coding Smalltalk/Self-inspired system that’s been tested so far on macOS, Windows, iOS (iPhone + iPad) but should work on Linux and Android too: https://youtu.be/rRMeOGc1JLQ Working on tablets is a main goal to allow for live drawing and fun educational applications.

                                                                            Has all of love2d.org and uses ImGui for UI. Uses a multiple-prototype-inheritance-oriented object system I made in Lua where the global scope of code you write is itself the object’s members with inheritance. “methods” have ‘call next method’ in the topological sort of the ancestor DAG. The main primitive involves “send”ing a scope code to eval. The hope is for it to make sense to do network sends.

                                                                            It’s in basic stages; hoping to work on error handling this week (idea: the send primitive itself notifies an error method on the object and inspectors can show logs) and try making a demo generative art painting app.

                                                                            1. 3

                                                                              Nice! I’ve been hacking on a Smalltalky (more Selfy tbh) system in Lua + LOVE — https://youtu.be/rRMeOGc1JLQ. Will be fun to dig into yours. Is there capability for actual textual scripting or only visual?

                                                                              1. 1

                                                                                very cool! Yes there is an object inspector and a class inspector, see the “hacking” document. If you release this open source do let me know I always like to read the code of live environments.

                                                                                1. 1

                                                                                  Will do! Currently still mucking about closed source :) but I’m hoping to open source it eventually.