Garth Goldwater 🕰️ 2020-12-19 16:27:28 i was thinking today about aspect oriented programming, rails hooks, and synergies in video game strategies (eg: water type attach + your water type attacks now also strike lightning bolts + your lightning bolts have a chance to strike twice). it seems like a lot of power comes from the ability to split out concepts into distinct modules but then combine them causally. my understanding of hooks and AOP is that they were hard to reason about because ordering becomes very sticky (eg: after you save a post by the user, update the user’s post karma rating). it seems like those techniques are actually looking for some kind of constraint solving approach that’s worked directly into the language. does anyone know of papers or projects on this topic?
William Taysom 2020-12-21 01:53:05 I miss AOP. 😢 Not sure why it didn't catch on more. Weave order isn't in principle more difficult than regular imperative coding, which of course is ordering error prone. Rails hooks in particular create an especially gnarly, overcomplicated call graph.
Harry Brundage 2020-12-21 02:06:18 i kind of think that declarative approaches where the system figures out the order to do something in shine when the details of the execution don't matter, just the end result, and i think for the things that the rails callback system gets used for, or for turn based game programming or whatever, the order of execution really does matter
Harry Brundage 2020-12-21 02:06:53 that going more declarative and towards the constraint solving world might actually make it harder to reason about if you want control over the inner bits for say a database transaction boundary or what have you
Harry Brundage 2020-12-21 02:07:30 i think i am saying the manner in which and the order all the things compose is often essential complexity that you can't fully abstract away
Garth Goldwater 2020-12-21 03:20:06 right, i’m asking about systems that help you explicitly declare exactly the essential ordering complexity, eg “lightning strikes after pushback effects”
William Taysom 2020-12-21 03:27:40 It's like multiple inheritance: lots of ways to do it, every one wrong. So it's best to have a common-case, easy-to-reason about default together with a flexible, explicit construct when the default isn't right.
A potentially better, but more conceptually challenging step, is having a system that's really good at assisting with order. People have certainly looked into this with types and contracts and what have you, but I don't feel like it's been nailed. AOP, for instance, was good for describing long distance ordering constraints as a double check.
Garth Goldwater 2020-12-21 05:45:37 exactly! i’m asking if there are any environments or languages that let you declare loose constraints in an ad hoc manner (eg, this requires this to happen first, this construct never happens without or before this other thing) and then just orders it for you and points out any cycles that can’t be resolved. id guess build systems (although a lot of them seem to err to extremes), and i’d be really interested in any examples with type systems
taowen 2020-12-21 05:58:58 the power of AOP seems coming from "extract cross cutting concerns", by re-organize the code, "shorten the editing distance between related code". But that leaves two questions: 1. what is the value of re-organizing the code, just to allow me move my mouse less? 2. The pointcut / advice seems complex. My recent thought on this is: The value of re-organize the code is to re-design the dependency relationship between packages. If cross cutting concern extracted out into same package, there is little extra benefit. If extracting cross cutting concern allows us to optimize the dependency graph, so that more package can be removed from dependency list, it worth the trouble. It is just a package management game in the end.
taowen 2020-12-21 06:00:55 In a typical inverted dependency relationship, the bottom package serves us integration between the top packages. It is kind of manifest file or configuration file, declaring how those upper packages integrated with each other. In this sense, introducing new language of pointcut / advice is not necessary. We just need to invert the dependency relationship, and keep the bottom package minimal.
Harry Brundage 2020-12-21 02:09:43 for those that have used node and wire programming systems frequently, how often are both your hands on your keyboard vs only one? been watching a designer colleagues hand movement recently and it's super interesting how different it is than my own, and that designers don't seem to complain about having to move back and forth that much. I think drawing boxes (or if you take it all the way, AutoCAD style work) with a keyboard is a non-starter, and they're only typing rarely, so they end up with mouse hand for the fine inputs and keyboard hand for tool selection or chords
Garth Goldwater 2020-12-21 03:22:37 i’m also curious if any of these systems are designed to be used specifically with one hand on the keyboard and one on a mouse the vast majority of the time
William Taysom 2020-12-21 03:28:59 Depends on the tool, but I see the default as right hand on mouse and left hand on keyboard.
Ivan Reese 2020-12-21 16:54:13 Yeah, I'd mostly have 1 hand on each while working, and then only use both hands on the keyboard once in a while. Just like any GUI creative tool.
Aria Minaei 🕰️ 2020-11-19 20:15:05 This is from Neil Postman's https://www.technodystopia.org/:
The printing press gave the Western world prose, but it made poetry into an exotic and elitist form of communication. It gave us inductive science, but it reduced religious sensibility to a form of fanciful superstition.What does he mean by "reduced religious sensibility to a form of fanciful superstition?" Was religion in a more enlightened form before print culture?
Kartik Agaram 2020-12-21 23:09:02 "Even if you understand nothing about a thing, worship is a way of centering it and ridding yourself of the assumption that you are at the center when you are not. That's epistemic progress. Even if your mental model of the thing you're centering is completely wrong and childish."
https://twitter.com/vgr/status/1341113153199849472
Christopher Galtenberg 2020-12-22 18:19:50 Ivan Reese 2020-12-22 21:23:25 :P
Grid-based programs (both text-grid and spreadsheet-esq) should dream of being articulated within a free-form, animated art canvas. We've had movements of impressionism and expressionism, time for a movement of comprehensionism.
Breck Yunits 2020-12-23 04:09:15 The new Our World in Data makes heavy use of Grid-based programs
William Taysom 2020-12-23 05:36:00 Think of it this way. Tangled node-edge graphs aren't the best. If your graph is planer, then you can lay it out on a grid (more or less). With the geometry of the grid corresponding to the connectedness of the graph, you don't need edges anymore.
Three dimensions of course is enough to keep wires from intersecting. And with more dimensions, you can keep wires from snaking...
Ivan Reese 2020-12-23 18:57:09 You can do wires in 2d that don't intersect by using "hop overs" (shown here in isolation, and in the context of a moderately complex electrohydraulic schematic).
Ivan Reese 2020-12-23 18:58:28 Imagine if VPL tools like Blueprints had the sorts of fast, flexible, powerful layout tools found in industrial schematic drawing apps.
Actually, don't imagine it. The pain of longing is too intense.
Christopher Galtenberg 2020-12-24 00:31:07 Sheets and cell border edges (or just cell references!) would be good enough for me 😊
elvis chidera 🕰️ 2020-12-07 15:24:07 Working on a low-code project for native apps. The idea is predicated on the argument that many apps are just "skins around a database".
Why is declarative UI + declarative queries a bad idea? For example we create a todo app like this:
Duncan Cragg 🕰️ 2020-12-13 18:36:38 Are there any non-techies here? I need to talk to you! 😄
Duncan Cragg 2020-12-24 17:58:41 Hi everyone again - I've updated the page (http://object.network) with a different angle and some more material.
Hopefully this approach works better.. ? 😄
(Please hit Big Refresh, as I don't seem to have my cacheing settings right on the server so it'll probably give you a stale page if you just visit the link.)
Mariano Guerra 🕰️ 2020-11-02 12:01:54 What do you think about a "FoC fund" where FoC members agree to give X (5?) dollars a month to the FoC fund and then paying members can vote on projects to fund? (I guess each project can access a max amount of money/months per year)
The best way to predict the future is to fund it
Robbie Gleichman 2020-12-26 10:24:06 I would be willing to put in at least $50 a month into a "FoC fund". I don't have strong opinions on how exactly it should work, but perhaps we can first gather proposals to see what level of funding would be needed to make a significant difference (e.g. enough funding to work on a project full time)
Emmanuel Oga 2020-12-27 00:04:48
ANTLR v4 is the result of a minor detour (twenty-five years) I took in graduate school. I guess I'm going to have to change my motto slightly.
Why program by hand in five days what you can spend twenty-five years of your life automating?
ANTLR v4 is exactly what I want in a parser generator, so I can finally get back to the problem I was originally trying to solve in the 1980s.
Now, if I could just remember what that was.
http://media.pragprog.com/titles/tpantlr2/preface.pdf
I wonder how this resonates with people on this community.
On the one hand I love building tools, but in the other, there are so many apps I want to build... I don't necessarily want to spend a lot of time building a "generalized problem solver" for each instance of the problem I want to solve.
As seen in ANTLR example, building a general tool can take years.
OTOH I'm grateful of all people that have spent so much time in building amazing tools like ANTLR.
Jean-Louis Villecroze 2020-12-27 00:51:03 Very much resonate with me. I see building your tooling as important as developing the end product.
Christopher Galtenberg 2020-12-27 02:03:09 I want to build 10 apps that are somewhat similar from one particular perspective. So I'll build the 1 thing, which is ultimately 100x more time consuming, but many others may ultimately be able to use (in ways I could never predict). I think that's the heuristic most of us here go by.
