Fork me on GitHub
#membrane
<
2022-10-05
>
phronmophobic20:10:45

I've fixed and improved all the of the issues I marked for this update. version "0.10.0-beta-SNAPSHOT" now on clojars. The only remaining issue is to finish improving the docs.

phronmophobic20:10:08

Making UI components work more like values is a much bigger deal than I thought it would be. It's already made some changes much easier. I think it will take a while to fully realize the utility of UI components as values.

🎉 2
phronmophobic22:10:53

I did read through that post. I would also like to see software and UIs be more dynamic, but I have a pretty different take on how to go about it. The early clojure talks (especially "Are we there Yet?" and "Simple made easy") discuss some fundamental programming problems. The talks also explain how Clojure is designed to address those fundamental problem. If you look at the problems with building user interfaces, it's mostly the same problems. • place oriented programming • weak support for information • brittleness/coupling • Parochialism/context • concurrency UI programming is still stuck in an OO world. I don't think a new language is required to start addressing those problems. Further, I think clojure already provides lots of support for taking on those challenges. React was an improvement over existing options when it came out, but I think there's still huge improvements to be made. It's hard to find UI frameworks where views are immutable values and components/events are pure functions. I feel pretty good about membrane so far but there are still dozens of places where I know things could be simpler, but I haven't had the time to design and implement the improvement.

Ben Sless03:10:34

I don't think a new language is required either (besides, macros are always a new language). I do think the dependency flow analysis is interesting

phronmophobic05:10:04

yea. I don't think the optimization part is that hard. If you're using immutable values, you seem to get a significant speedup just by memoizing expensive calculations

Ben Sless05:10:23

Yeah, and for optimization there's a lot else you can do, like representing the basic primitives with more efficient types and primitive values. Putting numbers on the heap and taking them off constantly has a cost. Implement a (deftype Point [^double x ^double y]) would probably carry far

💯 1
phronmophobic06:10:33

especially for UI, I feel like prioritizing "how" over "what" is a trap. you get really great feedback improving benchmarks, but it doesn't really address the problems of building complex, dynamic user interfaces. However, once you you define the "what", there are plenty of existing techniques for optimizing them.

👍 1
Ben Sless06:10:04

Yeah, more how-s and more stuff, e.g. menus, primitives, graphics, windows, popups, hovers

phronmophobic07:10:21

I don't think more stuff is a problem.

phronmophobic07:10:29

just make more stuff out of simpler stuff

Ben Sless07:10:36

sure, which gets to the how, which, the simpler it gets, will be easier

phronmophobic07:10:50

I think that tends to be true since simpler stuff usually let's you separate what from how, but the point is to focus on the what