angleofrepose

This is cool. I enjoy seeing these kinds of projects, thanks for sharing it and thanks for making it.

There has been so much innovation over the years around transpilers/compilers to JS, it makes me wonder what a programming paradigm of à la carte first class language functionality could look like and how it might interoperate. A system in which I might grab Haskell type syntax, Clojure list comprehensions and JS arrow functions, all together, and all working just fine.

Probably want to break up files into more granular chunks, probably more like next gen polyglot notebooks beyond a cell per language and more like custom languages composed of features in any given cell.

The system could be made to translate between functionality based on editor preference. Like python list comprehensions? Read my Clojure comprehension in that syntax.

I know this would not perfectly map, as some language functionality is more powerful than others. Still interesting to think about.

I hear that, it seems a common observation. Maybe a fundamental truth of enterprise.

> until you have the full factory going you won't be able to fully estimate your actual numbers, much less come up with all the sequential small improvements that build on each other.

Why not? Is there a theory or school of management or industry that establishes this foundational principle that seems so commonly invoked? It feels true, but I don't really know why it might be true. There must also be great examples of counterpoints in this too!

Maybe it goes back to learn by doing: it's a common refrain in outdoor recreation that safety rules are written in blood; that many of our guidelines directly follow from bad things that happened. But certainly we can also design safety rules by thinking critically about our activities. Learn by doing vs theory.

Right! Good points for optimism here, and acknowledging broken mental models.

We have silicon solar modules in the 1950s, Moore's law in the 1960s. Another take on the question then: today we use Moore's law to describe progress in solar modules, to what extent was that realization possible in the 1960s from the fundamentals, or "first principles"?

If it was clear, why did we not see rapid prioritization of solar and energy storage technology research? Or did we and I don't know the actual history? Or what influences am I undervaluing or not recognizing?

If it wasn't clear, why not? Gaming out many positive impacts of solar technology feels easy today in a way it appears was not easy in the past. Why wasn't it clear in the past?

Indeed. You widen the conversation here, and remind me of the idea that moneyed influence is underrepresented in analysis and understanding of the world. Maybe the most appropriate way to understand big questions is who is funding the various players.

I like to think about "learn by doing". While I have of course lived it, I try to think of counterpoints. It seems clear that solar owes it's growth to Germany and California policies which subsidized the global solar industry with taxes on their economies, most disproportionately placed on individual ratepayers. But why couldn't solar research have been long-term funded based on it's fundamental value? Talk about national security, or geopolitical stability -- especially post 1970s! Skip the intermediate and expensive buildouts of the 2000s, failed companies heavily subsidized and fund research instead to hopefully bring the late 2010s forward in time?

What's a good model here, or concrete example? We see the same side of the history in electric vehicles. I think Tesla and Rivian, to pick two, both lost money on every sale in early years. Why not skip that expensive step in company history, and develop better products to sell at a profit from the beginning of mass manufacturing? Are there industries or technologies where this expensive/slow process went the other way?

Sure, that makes sense. This is where I'm coming from with my interest in history:

I heard an interesting argument somewhere that solar cells are an ideal manufactured good. Whether you are building a module for a calculator or a GW scale plant, the modules are the same. This is fundamentally different for steam turbines. On the "concrete-internal combustion engine" spectrum of complexity, solar modules are closer to concrete and turbines are closer to ICEs.

Shouldn't this have led to a special interest in advancing solar module research? Or widespread understanding that eventually the unique set of attributes that define a solar module would lead to it's takeover of a significant portion of global energy generation? Shouldn't that have been apparent from the earliest days of photovoltaic research as a sort of philosophical truth before the advances in material science, extraction or manufacturing of the last fifty years?

Thank you and other commenters for the great rundowns here. I'm interested in a related question and I wonder if you or others could point me in the right direction: why was the mainstream consensus around solar power (and/or batteries) apparently so wrong for so long? More specifically -- and maybe a better question -- why didn't progress in solar and batteries happen sooner?

I'm less interested in blame than in a systems analysis of how in the last half century powerful players seem to have missed the opportunity to start earlier investment in solar and battery technology. Solar and batteries are unique in energy infrastructure, as even any casual observer knows by now, and is certain to change many aspects of politics, industry and culture. It seems an inevitability that energy infrastructure will evolve from large complex components towards small and simple components, and I'm interested in engaging with the history of why "now" is the moment, rather than decades ago.

Could you expand on what you see as exciting developments? I’ll have to check out the op post link as well as yours and others in the thread.

It’s been a few years since I seriously looked at options for my personal use, but I remember being quite disappointed in the options I found. Zotero and org-noter seemed two of the best (though in completely different ways) pieces of software I could find regarding reading or organizing pdfs. I trialed OneNote for a year and liked it in the moment, but zero support for navigation or discovery or review of information make it untenable for building a knowledge base or doing literature review.

I imagine that software which makes reading and connecting document information (in any form: pdf, html, video or other) could be so much better than what I use daily.

A great resource that I should have found on my own. Thank you. I’ll look through this later. Giving it a quick glance now I see some of the same language I see other places; here that macros are “too far.”

I don’t know why macros are approached with apprehension. As I briefly get at in my first comment, I’m aware of a lot of dismissals of macros as a tool, but those dismissals don’t make sense to me in context. I’m missing some backstory or critical mind-share tipping points in the history of the concept.

What could be a good set of sources to understand the background perspective with which TC39 members approach the concept of macros?

Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros.

I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me.

At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are kicked out to transpilers and compilers.

Can anyone point me to authoritative sources discussing macros in JavaScript? I have a hard time finding deep and earnest discussion around macros by searching myself.

I picked this up at a used bookstore a while back for a dollar or two, and enjoy flipping through it from time to time. There’s something deeply satisfying about the quantity and density of the graphics in the book, and the visual simplicity of the prints.

Why do you post it here? What do you think about the book?

The future of coding link in the parent has a large list of similarly spirited projects. I have scattered lists of similar projects but none handy or packaged well. I'll point you to the Ink&Switch article on end user programming. https://www.inkandswitch.com/end-user-programming.html And encourage you to check out personal sites of the people involved. The lively kernel is a programming kit project that's been around in various incarnations for a long time. https://lively-next.org/ The history of Eve (also linked by that future of coding page) is rich and full of references to other projects http://witheve.com/ VPRI similarly is a gateway to lots of history on personal computing http://www.vpri.org/ of particular interest to me there is the graphical language Nile and the meta compiler Ohm. http://worrydream.com/ Bret Victor's site is another gateway you may have heard of, and the researchers at Dynamicland are also well worth exploring. More future of coding resources https://github.com/d-cook/SomethingNew

For more actual environments you can use I recommend https://observablehq.com/, https://starboard.gg/ and emacs along with the links above.

This is a great project in a space that I've been playing around for a little while, fun to see it here!

I'm interested in hearing what you think are some of the more difficult problems or bugs you've come across during development. Did you hit any stumbling blocks around handling user code or integrating babel or the terminal? Do you have any insights about preventing errors or crashes in how you parse and eval user code? (My typical test of a while(true) loop crashes this system, but you're still in good company; it crashes replit, browser dev tools, observable and just about every other clientside execution tool I've come across. The most popular solution appears to be the loop timeout transformation.)

I think the examples pages do a better than usual job of demonstrating your system, in particular the ubiquity of one liners and your connections between them. Do you have ideas or responses about the classic "mess of wires" critique that graphical coding systems inevitably receive?

This is such a fun domain to think about, thanks for sharing your work!

Do you see any other solutions in the same domain as Stopify? Another method that might provide a way to keep UI unblocked but still have user executable code?

> ctrl-C functionality

OS implementations dont solve the halting problem. I agree with the sibling comment.

Yeah! The general case of this is the halting problem... The best solution I know of is stopify, which the other comments have talked about. I just wonder if there's another take on the situation, something akin to OS task management.

Looks interesting, I'll do some digging around. Thank you for sharing.

This is what I use. Seems to be the only option, and it works.

Hi, yes! I like your project. I chatted about similar things on your launch post here. You also address this explicitly on your product which I appreciate.

What I'm getting at is that these browser notebooks try to get at the desire and feeling for rapid exploration and iteration. Losing context by having a crashing logic error is a massive blow to that ideal.

I'm not saying that your or anyone elses product is only for "rapid prototyping" but it's still true that larger projects could be bit by the same errors. When I crash my native code I C-c and I'm back in an instant. When I crash browser notebook code I lose a bit of time and unsaved code. I crash browsers often in creative coding where I write many loops and don't always do them right.

It may also be that my chrome and firefox experience on linus is worse than standard, I don't know. But I have crashed my entire browser in chrome when using observable, and I thought that wasn't supposed to be possible.

Yes, as the other comments get at the "hack" I'm referring to is a loop transform that adds a timer check to the condition.

I am aware of multiple hacky solutions, such as loop detection and adding timeouts. This fails in most non-trivial creative coding applications due to long running code. I'm interested what it would take to come up with a general escape hatch like any shell user has.

Do you, or the broader community, have any ideas about solving infinite loops? I'm on mobile so I can't test this at the moment, but I imagine that while(1) crashes the tab.

What would an MVP operating system like ctrl-C functionality look like for execution environments in the browser?

I think the other two comments make good points. There is every chance that everyone will learn to use a small set of fundamentally composable digital tools in the future. That's programming. I think "intellectually challenging" just means poorly explained or resulting from poor access. Anyone can program, it's just artificially hard to do it today.

Good point! I might give it another listen. I remember it being an interesting respectful conversation with no ground given on either side. Hence the title, I suppose.

This Idea Must Die is an interesting take on that concept.

Ah I didn't even realize the list I sent wasn't from his account. Thanks for the correction!

I'll second the computers for cynics. I don't think one of that series is about blockchain but he does have other videos about blockchain.

For those who don't know computers for cynics is his series about questioning the origins of the status quo and considering alternative futures with different foundations.

https://www.youtube.com/playlist?list=PLTI2Kz0V2OFlgbkROVmzk...

It's been a little while since I've heard this one, but if there's one thing that I remember hitting me is that the same language used by the interviewer is used today about privacy, end user programming and any other more powerful technology, programming language or paradigm. It seems that as an culture we're always able to go so far, but not all the way. We see the path between start and end, there's no genius needed for the last push, but after so much progress we reduce ambition towards the end goal and instead develop arguments against continuing.

At some point we just don't think people need help with paper based tasks, "look around you, it's how everything is done" yet here we are with the PC 40 years later. And people look around and think that there is no chance everyone could be a programmer "look around you, they're all consumers, they couldn't understand how to make the computer do what they like". In 40 years there's no doubt this viewpoint will be wrong, but the popular opinion on the matter can't see that future.

See Bret Victors history of computing. The biggest adversary we have to overcome towards progress is the mainstream experts of our own field.

We have apps which seem to be like starting from scratch every time, which can't have abilities known by all because they aren't prepackaged by the devs ahead of time. Every app reinvents a minimal subset of sorting and search. If you have a better idea or a different connection you want to make its just not possible in the app.

Stop pretending that debilitating users is actually good for them in the silly word games we play. Give users power.

A good read, mdn is far and away the best resource I have found for web technologies. I'm excitedly looking into some p2p tech and the webrtc articles are useful.

From the article:

> "Run to completion"...

> A downside of this model is that if a message takes too long to complete, the web application is unable to process user interactions like click or scroll. The browser mitigates this with the "a script is taking too long to run" dialog. A good practice to follow is to make message processing short and if possible cut down one message into several messages.

Good advice. And this is what happens when you `while(1) {console.log("loop")}`. Though I've never see a "taking too long to run" dialog, I'm just eventually able to kill the process myself and sometimes it takes a few minutes while my fans spin.

Very good points. Makes me think about a persistent web, what if every javascript code visible on your page could be edited and persisted between loads or visits or you could send a blog post link to a friend with your edits/comments/changed environment. Not arguing for that immediately, it's just interesting to think about.

Then what do you do when someone is demonstrating how to reset a page, whether that be document.body.innerHTML = "" or document.body.removeChild(main). They could be run in sandboxes, like starboard here in iframes. Or a powerful history tool can be attached to the page. Every program takes an environment as a parameter, maybe we can make it as easy to shuffle around them as playing with cards.

To really simplify it down, I'm exploring the space of digital workspace + shell. What do you get with a compute environment in OneNote or Figma or Sketchup. What do you get if you can position things in a freeform space rather than a filesystem and text based browser? Can I build a Sketchpad with code editing, and take advantage of viewport macros to build a space of my project and explorations?

Makespace.fun + jsfiddle/observable seems like an environment that I'd like to work in with myself, my collaborators and arbitrary content. To play with things like history and alternatives, and associations of material and ideas.

I have a good example of success of programmatic control of content and auto layouts working with my tiling window manager. Being able to explicitly describe compositions and demonstrating computational content seem to be targets not yet hit by the pop culture of personal computing.

I might be just blowing hot air with all this, but it is fun to play around with.

> Generally working with events in JS is easier than central run loops.

That's an interesting perspective I hadn't thought of before, I'll see if that can inspire some design pattern. Thanks for another good prompt!