Have you considered picking a particular machine and only targeting that? It would simplify the hardware stuff.

The beginning of the thread of work that leads to Go's concurrency model was Pike and Cardelli trying to make multi-device interfaces nicer to build, specifically dealing with concurrency while supporting the mouse. Maybe it would be fun to harvest some of those ideas in the context of Mu?

http://doc.cat-v.org/bell_labs/squeak/

I gave up not because it's impossible to build (I was almost there) but because it's impossible to explain to anyone

If this community had a giant corkboard wall where we pinned up beloved quotes, this would now be on that wall.

Chris Knott I've been reluctant to do that because it feels like it limits the number of people who can try Mu out, and therefore who I can collaborate with.

I've been counting on my fingers when I hear from someone who seems to have actually tried to run Mu. In spite of all my efforts to keep it accessible, I'm not out of fingers yet. So I'm loath to add new constraints. At some point it must make sense to just consider this path over-constrained and go do something else. (Or maybe it means I haven't found the right vein of potential collaborators to tap yet? Hmm, perhaps the right machine would help there.)

There is one option I'm reluctantly starting to focus on: virtio. This is apparently a driver that only works atop an emulator or hypervisor. Programs within the VM get a nice interface, and the VM translates it to real-world hardware (perhaps using a mainstream OS). If I go this route you'd need a cloud computer to run Mu 😬

Hmm yeah. The only thing I could think of would maybe be a Raspberry Pi because while it is a tiny audience in some respects, you are more likely to get traction with it.

After reading this, I can start to understand why Alan Kay would say that "people who are really serious about software should make their own hardware". It seems like hardware is even more heavily "accreted" than software, which makes sense given how inflexible the medium is, and how commodified it has become as a result.

I had the same thought about constraining to given hardware. But, regarding your fingers (!), I believe I am one of them, and for me the constraint was that it wouldn't run in WSL on windows with 64 bit.

Perhaps constraining the software environment would help - to a docker container maybe?

Chris Maughan Thank you! Does WSL have Qemu? I wonder if baremetal would work for you.

Edit: I'm out of fingers! 11 people have tried to run Mu. I'm probably missing a couple of other people like you as well.

Thanks @Florian Cäsar! Main idea for now is paid hosting, yes, although we are also open to other possibilities - one idea being building paid products on top, like visual editor.

@Florian Cäsar I didn't know about Mailchimp rejecting protonmail domains! Too bad, but I am gald http://pm.com worked.

Interesting, yeah, hosting seems obvious. Do you see Wasp being mainly as a solution for smaller projects, where you eventually work with the compiled output directly complexity rises?

We see that as an option at the beginning, but main idea is to make it flexible enough to stay with you the whole journey.

Cool, that could be really useful. Good luck!

Awesome, thanks @Florian Cäsar :)!

Oh, just one level down 😂

Still very cool.

I can make it infinite, but I have to clone the inception entity at each level so it gets a new id and doesn't introduce a loop

I do the first level by hand to prove the point 😄

since the second level isn't changed it points to the root, and that's how the loop happens

infinite entities may generate some problems with GC 😛

Very cool! Which global state library do you use? I just finished a big refactoring myself to move from redux to zustand to get more control also to be able to use my own flow project within itself.

there's not much global state, just the entry point of the graph and the graph itself, it's my own library

that's how inception works, I clone the entry node and add a reference to it in the graph

I like the analogy. I think it nicely suggests the human elements that are (should be) in api design. I think there's an important piece of the story missing, though: how do you learn? You called it out yourself: if you don't know how le nix works, you walk out in disgust (and more than likely embarrassment). Anybody can walk into Smilies and end up eating the food they want. I think there's a number of dimensions to this as well. What does this learning mean? Is it about the developer community? The documentation? A cs degree vs. a bootcamp? Formally educated vs. self-taught?

By the time I got to the final section I had a different conclusion than you.

In every activity you have to decide who your audience is. Restaurants are for users, so we should make them more like Smilies. It's only when we make things for programmers that we should make them more like Unix. More amenable to composition in larger, unanticipated aggregations.

This feels a lot more nuanced than your conclusion, "It turns out, the most important user of a program is not a human using a program." I don't think that's always true. It depends on what the program is.

Yeah, true, but I think programs still win out 99% of the time because 99% of the functionality can live outside of the GUI which means the user of that code is code.

The fact that macOS, iOS, and Android, all of which are GUI dominant are unix under the hood is really hard to argue with IMO

A program which is made for other programs can be lifted into a GUI, but the other way doesn't seem so

1. If a program is intended to be lifted into a GUI, its stdout is often hidden. It doesn't matter if it's silent or not. Often there are debuggability benefits to being verbose.

2. GUIs are programs too! Extremely complex programs. Often the most complex part of a program.

I should say that you're totally feeding my biases here. I've spent the last 5 years arguing that programs should focus on programmers, and that people should go out of their comfort zones to understand computers. (Because the alternative cedes too much power.)

But focusing on programmers can sometimes involve providing lots of information so that a run is more intelligible. One of my favorite tricks is emitting facts deduced to a log, and having tests make assertions on the log (http://akkartik.name/post/tracing-tests). So I still think you're over-generalizing from Unix here. All we can conclude in general is that programs should probably provide a silent mode and a verbose mode, and which one you operate in depends on the situation. That's a lot less interesting for a blog post, though 🙂

• Oh it totallly does matter because if you use that program in non-gui mode then stdout is the way you interact with it. Otherwise you're repurposing stdout as a logging output. Logging output is valuable but then just log to a file.
• They are programs and should be the simplest part of the program because they're so hard to compose with other programs

-v to verbose say things other than what's surprising is a common unix option but that's opt in, not opt out.

Are you assuming an architecture where the GUI shell for a program is always in a separately runnable process? I can imagine it's always a good idea to make it a separate library (MVC) but process separation has costs.

You sound like a bigger UNIX head than the creators of UNIX 🙂 That might be a compliment.

Otherwise you're repurposing stdout as a logging output. Logging output is valuable but then just log to a file.

There is such a thing as stderr. Unix has it for a reason.

-v to verbose say things other than what's surprising is a common unix option but that's opt in, not opt out.

I'm claiming that there are situations where the right default is a little more verbose than complete silence. Imagine a server where the default log level to stdout is INFO. I've found that handy at times. The real interaction happens in another window, and that frees this one up to be verbose.

haha, I'm flattered but I hold them in too much esteem to consider myself more of a unix head than them. The Art Of Unix Programming completely changed my view of eng design.

I'm imagining an architecture where the GUI can be modularized out. It doesn't need to be a separate process or anything. I'm imagining a layer of code which has API/TUI entry points and that the GUI is built on top of. Then everything below the GUI is easily composable with other programs (esp testing), and the GUI happens to be a nice way to make it easy to interact with the program.

I'm not sure why it matters if there are exceptions to the rule. If you're going to hold a simple rule, it's better to err on the side of silence than on the side of noise. Should you hold a simple rule? I believe so because I've found there's bigger fish to fry.

Not sure what you mean by bigger fish to fry. The first question that leads to for me is: why bother writing this, then?

If you call something a rule and never mention exceptions, then the reader will assume you don't intend exceptions.

I don't think what I'm pointing out are narrow exceptions to a rule at all. Rather this Unix 'rule' (and, indeed, the rest of https://en.wikipedia.org/wiki/Unix_philosophy) only applies in a very narrow domain: interactive programming in shell. Not even shell scripts, let alone well-designed GUI and web frameworks. Unix has had ample decades to demonstrate good examples in those areas, and it has failed.

Did you see Glance? https://github.com/rgleichman/glance

Whacky! And neat! Thanks for the pointer!

Are you targeting "hardcore" programmers as the initial audience? The emphasis on Haskell sends that message to me.

Some parts talk to the "hardcore programmer" like this ones:

Haskell programming language



Haskell package published on Hackage



fully-scoped names



pure Functional Reactive Programming UI framework is a first-class citizen



reactive primitives



lift and fold



persistent behaviors

and some parts are much more inclusive, like this ones:

an app to empower you to make apps from your phone



a new kind of spreadsheet, but where each cell packs a lot more punch



Every cell you create in Compose is similarly re-usable anywhere and by anyone



you'll be able to build an entire social app (think: Twitter, Facebook, Instagram, Messenger, Whatsapp, Medium, Slack, Discord, Signal, etc) without leaving your phone



Ever had an idea for an app for your friends or community? Now's your chance to make it real



enables many teeny-tiny programs to be composed and re-composed like lego blocks

Exciting! I can't wait to see what you come up with.

just to be clear, I understand it's the first announcement and the people that will read this will be technical enough, just to know if that was your intention 🙂

Yeah definitely targeting people who already know and love Haskell for v1

I’m really looking forward to seeing how your hypothesis of short words for programming on mobile will work out!

And hoping to making it more accessible to beginners over time

Exciting! Can't wait to see this evolve. We need more mobile/touch first projects.

Looking forward to seeing what you do! 🙂

Congrats on starting the project, especially in Haskell (I am biased) 😄!

Similar to what Mariano Guerra asked, who is the audience? On one hand they need to know Haskell, but on the other hand they want to build an app from their mobile phone? That doesn't sound like a same person. I am in general confused about building an app from phone - I can hardly imagine somebody wanting to do that compared to doing from their PC, unless it is drag and drop maybe, but this doesn't sound like it? Or maybe I am getting the whole thing wrong?

It would be really interesting if you could describe the problem in more details -> in which situation might somebody want to use Compose. Or what would usage look like, through a story.

Martin Sosic here are 3 existing apps to build apps/games on the phone:

https://www.fancade.com/

https://www.gethopscotch.com/

http://castle.xyz/

Great questions Martin Sosic! I'm not quite ready to show mockups. (they're too ugly!) But the idea is that we're really leveraging Haskell's composability, particularly the point-free, arrowized style, to make lots of tiny programs that you can recompose into bigger ones. I want it to feel a bit like writing an essay as a twitter thread

i love the global namespace idea, sounds really interesting. I was thinking about something similar when i first heard about unison function hashing

If you are focusing on hardcore programmers to start with, why the focus on mobile ? I’d expect average programmer would prefer working on their desktop, ideally within their preferred env

Thanks! I think there's a subset of Haskell users (such as myself) who would love a mobile Haskell experience. Maybe I'm the only one 🤷‍♂️

My thesis is that the reason people don't program on the phone is that they can't, not that they don't want to or wouldn't if it was good. This thesis seems to have held up for almost any computer activity so far

Fair, i guess that’s your chance to invent the future 😉 Definitely a fun challenge to tackle

I’d be very excited to see someone finally crack the phone thing - we tried experiments for years and never found something satisfactory. Composition is certainly a very important part of the equation though 🙂

From a business perspective, I’d wager there are maybe 10's of thousands to 100's of thousands of serious haskell programmers. Of those, I’d expect the intersection of “interested in programming on a phone” to be 100s, maybe 1000s. Prices for phone apps are quite low, I suspect you might be able to charge $20-50 with a very narrow audience. Even if we assume it is 1000s and $50, I’m not sure how you’d sustain a business with multiple employees. I’ve seen lots of folks come up with something great and then not have a real path to sustainability, so I’d really think hard about that if building a business is an important part of the endeavor.

Thanks Chris Granger! Yeah the business only works if we can drastically increase the number of Haskell programmers (in the way Rails did for Ruby). That's why it's so risky: 1) can we get 100 Haskell programmers to love it? and then 2) can we get 100k non-Haskell programmers to learn Haskell on the platform? I'm optimistic on both counts but regardless stacked risks multiply and that's no bueno.

As far as why I'm optimistic on people learning Haskell... I had my head exploded when I went to a Tidal Cycles meetup at @Jack's suggestion: it was a room full of people using do-notation (and other complex FP ideas) to make music that had never heard the term "monad"!

I think that may be a trick, I may use it if the benefits of haskell make the experience so good that I want to use it

like so many people learning ruby because of rails

in that case I wouldn't focus on "hey use this, it's haskell!" and more on "hey, use this, it gives you the superpowers that until now where only available in advanced programming languages, and it's really easy/fun to use!"

I don't want to generalize, but the reason why many programmers are against visual programming and other new technologies like visual basic and scripting languages is that it undermines their status, so it may happen that haskell programmers reject it because now it makes their secret weapon more accessible

the intersection is small to begin with, I basically wouldn’t worry about anyone in the Haskell community who doesn’t love it relatively quickly. The bulk of your users won’t come from there.

The competition for this is going to be something like https://www.createwithplay.com/ or https://onuniverse.com/

rails succeeded because it had the killer app of building websites very quickly when the business world was rapidly coming online. There really isn’t a good trend to attach to right now for “on the phone.” The best I can imagine is like what they’re pitching - quickly build phone apps on device.

Yeah definitely! I'm a big fan of Universe and agree they are more my what I'm going after. I've never seen Play before -- amazing! Thanks for the pointer

Play is pretty awesome, I’d definitely dig into them.

Yeah, I'd say it's not (or shouldn't be) about "Haskell", but a very easy and direct way to build pieces of programs. The fact that you discovered some of the properties which enable that, to be baked into Haskell, is incidental.

I've always wanted to get into Haskell more, so I'm squarely in the target audience (rarely has a pitch felt so focused just on me). The risk this has me worrying about is the error experience. How you give good error messages tailored to a small screen without having to fork a Haskell compiler. Or do y'all plan to fork?

The fact that anyone is asking "who'd want to use a phone?" is rather telling of a problem with programming & technology (which Steve is working to solve, here).

Imagine a slightly different status quo: Who'd want to use a computer? If you really want to be productive, you're going to need a whole laboratory and your own factory, and your own biodome and space suit.

My goodness! How badly has programming and technology evolved, that you can't use simple tools to compose logical components in a simple and straightforward way?

It used to be unthinkable to browse the web or do MANY things, that are now mostly done from "phones" now.

Still, there does seem to be a big difference between browsing and creating. Writing programs often involves doing multiple things at the same time: research (browser), coding (IDE), running/looking at logs(terminal). It is intensive activity, because problems we are solving are hard, so having proper equipment (multiple displays, keyboard, mouse) does make a difference. That said, maybe I am just old fashioned and future is on the phone who knows! Although, if future woudl be really be on the phone, I would expect some novel kind of interface (like projected screen or keyboard and similar) that enhance both output and input capacity, but then it comes back to being a computer. Don't mind me too much, just thinking out loud. For the context I am Haskell developer.

Fair points! I'm sure heavy duty intensive development will stay as you say; but the scope of all software development by anyone (e.g. as a new kind of literacy and/or thinking tool), can expand far beyond that. You certainly wouldn't write a thesis on your phone, but look at all this discussion we are having from my phone! It might have been hard to predict decades ago that people would "casually" "type up" thing after thing with just their thumbs, but the context for that didn't used to exist (and we have tools and context for this that would have been hard to predict). But certainly, that hasn't become the "new" way of sitting down and writing a serious paper. I think the same could apply for creating the "stuff" of software. That might not be called "programming" though, just like this here is not "writing a document" in the sense that that used to (and even still) connotates.

Martin Sosic Programming is many things. If you restrict your definition to current industrial professional practice, you'll miss many opportunities. Personally, I would love to be able to quickly build interactions on my phone, especially if it let me script away some annoyances in the stock UI.

To echo what others have said here, I assume your Compose page here Steve is targeted at Haskellers who, on clicking through on Reflex, say, "being able to make use of something like that without setup and ceremony sounds great. Sign me up!"

Comparing to Rails, this announcement comes well before the first public presentation and fifteen minute demo. Let me add that at Ruby Conf 2004, maybe 3/50 were using Ruby professionally, and the first question to DHH after his presentation was "What editor is that?" Second question was "Can we get a copy?"

If you want a Compose demo to attract Haskell people, Explorable Explanations of some classic Haskell papers? FRP, STM, and Parsec come to mind.

I don't know about programming on phones, but iPads sound good.

I've tried Fancade with my son for a few hours. It's pretty cool. Pretty powerful. And fairly inscrutable with terrible documentation to boot.

Really want to see an app in which you (and by you I mean my economist wife) can do non-trivial equation manipulation (calculus, differential equation stuff) and charting.

@Dan Cook Jack Rusher You are right, I was approaching this from the standpoint of classical professional software development, and not so much from the view point of "democratizing" development for others by making it really smooth and simple on your phone! I am interested to see what is the response on this and what is the right type of experience that can trigger this new kind of behaviour (development on phone), certainly an exciting experiment! Business side sounds somewhat tough, but there is always time to explore that further if usage is there.

It's rough, but I think it's worth pushing for a better status quo. Personally, the more overlap I see with others here, the more reassured and validated I am about my own intuition about what needs to change, how, and how important it is. Also, it speaks to an increased likelihood that such changes will come from somewhere. I'll take a look at your work, but regardless, keep up the good effort!

I've only watched the first video so far, but I'm going to share some feedback that totally diverges from your explicit area of interest:

Your production values are fantastic. I so appreciate your attention to framing, sound quality, preparation, editing, and other aspects of communication. Irrespective of the content itself (which is great, but you'll hear that from a ton of other members I'm sure), you need to know that the effort you've put into the quality and clarity of your expression is not lost on this audience, and is in fact exemplary.

Just to clarify: If my choice of words made it sound like overlap feels discouraging to me, I chose the wrong words. Overlap is super encouraging, I agree with Dan! I meant it as an explanation of why my initial videos show relatively minor ideas, compared to the more lofty goals this community is aiming towards. I share the lofty goals too, but I didn't prioritize them - we'll see if I can contribute anything more than "+1" there, later.

Ivan, thanks so much! This kind of feedback, while tangential, is lovely to hear. 😊:partying_face: It's true that I put in a lot of effort, and I'm glad that it seems to help the message get across. I guess I got somewhat burned when early attempts at sharing my ideas IRL, with improvised elevator pitches and sloppy sketches on napkins, mainly caused yawns, misunderstandings and shallow dismissals. These experiences made me realize that I needed to work on my delivery! Also, a former colleague was a successful Youtuber (FunFunFunction) and although I have zero desire to become a Youtuber, I guess I can't resist striving towards that quality bar in the videos.