You are viewing archived messages.
Go here to search the history.

Kartik Agaram 2024-07-01 23:21:01

Shower thought on yesterday's thread above: the painter's algorithm is a way to make an interface less stateful. It lets you specify shapes to draw in any order. However:

  • It does this by adding more state to the implementation. You can't just draw each shape as you encounter it in the code. You have to shove them all into an array, sort by z value, and then draw them all.
  • It does this by adding more state to the communication channel. The human has to provide a z value now for each shape. Sometimes this is naturally obtained, sometimes it is not and the human now has to think in their heads about what z value to give their shapes to make the drawing come out as they want.

Thinking about this, it feels like state is to some extent inevitable. There's some conservation of state going on. You can't really eliminate it. You squeeze it down in one area and like a balloon it pops up somewhere else.

Beni Cherniavsky-Paskin 2024-07-02 06:29:54

"you have to shove them all into an array" ā€” Well, painter's algo is just one solution; a z-buffer remembering the depth of previously painted pixels can truely allow drawing in any order, as you encouter them in the code. And by deciding per-pixel it avoids issues like occlusion cycles.

Sure that doesn't "eliminate state", I added a whole-frame buffer! But conceptually I think of it as a much smaller departure than "record, sort, replay".

Pedagogically I wouldn't get into either of this until the student (1) understands occlusion and paint order (2) feels that re-ordering code themselves (painter's algo being run in programmer's head not computer) got frustrating...

Beni Cherniavsky-Paskin 2024-07-02 06:31:30

Also good old wireframe drawing can postpone worrying about occlusion for a while.

Ivan Reese 2024-07-02 15:50:03

The err, if there is one, is forgetting that ~source order is state~ .

William Taysom 2024-07-03 06:59:40

But is it hidden state?

Kartik Agaram 2024-07-03 14:10:36

This morning I'm thinking about turning šŸ’¬ #devlog-together@2024-06-30 into a visual notation for something we typically use keyword args for. For example, the following glyph might represent a function for initializing a text editor widget with the following signature:

edit.initialize(top, left, right, bottom, font_size)

And the numbers indicate a specific call to this function:

edit.initialize(15, 15, 115, 215, 20)

visual-keyword-args.png

Kartik Agaram 2024-07-03 14:20:27

Interestingly, these alternative semantics would make for a more pleasing glyph.

edit.initialize(margin-top, margin-left, margin-right, margin-bottom, font-size)

visual-keyword-args2.png

Kartik Agaram 2024-07-03 14:26:15

Uh-oh, there I go again, obsessively circling questions of notation šŸ˜‚ (šŸ’¬ #devlog-together@2024-06-30)

Ivan Reese 2024-07-04 03:51:26

This week, I'm learning more WebGPU, since I'm hoping to use it for a handful of visual programming projects down the road. I'm also still looking at options for šŸ’¬ #administrivia@2024-06-24. Would love to find something that feels more like a forum than a chat, but not toooo much like a phpbb, and doesn't have a per-user cost, and doesn't impose a maintenance burden, and is accessible to search engines (and accessible to all people, natch), and isn't likely to "incredible journey" or "we AI'd every text field for you" etc. So we're currently whatever the opposite of "spoiled for choice" is :)

Kartik Agaram 2024-07-04 04:05:06

choiced for spoil

Jack Rusher 2024-07-04 05:34:15

Iā€™m curious about this empty part of the design space šŸ¤”

Ivan Reese 2024-07-04 06:35:34

I wonder if my ideal would be a collaborative, public-facing CMS. Or maybe it's just Tumblr, but small. Possibly wiki-esq, but wikis don't organize around time.

Kartik Agaram 2024-07-04 13:56:41

They could ..

Jack Rusher 2024-07-04 14:41:22

It would be nice if chronological convos were more easily wikified

Ivan Reese 2024-07-04 14:58:30

What do you guys want?

Jack Rusher 2024-07-04 15:28:53

It would be nice if the path from chat to easily retrieved knowledge were a bit better paved.

Kartik Agaram 2024-07-04 15:35:51

Today I'm thinking about the Campfire idea in the other thread even though it requires self-hosting. Considering paying $299 just to play with it for myself(!) It feels like it might fit all of my (espoused) ideals, and if so I want to make sure? Maybe my desired future is already here, and all it requires is company- and culture-building skills I have no prayer at. I can live with that.

Basically the plan in my head is to self-host and then pave the way from chat to knowledge. No idea how realistic that is.

Ivan Reese 2024-07-04 15:38:19

Personally, I'm not giving dhh any more of my money.

Kartik Agaram 2024-07-04 15:39:17

Ah. I've never given him money before. Why, was it not a good time?

J. Ryan Stinnett 2024-07-04 15:42:01
Ivan Reese 2024-07-04 16:04:13

Yeah, thats some of it. In general I just find him to be a very mean-spirited person and don't want to do business with him.

Beni Cherniavsky-Paskin 2024-07-04 18:11:59

path from chat to easily retrievable knowledge

You mean better than "Searchable Log of All Conversation and Knowledge" which we use now? šŸ˜†

One big achievement in "prioritize knowledge over in-the-moment-chatter" space was StackOverflow. But I suspect you didnt mean Q&A.

Can you elaborate how it could be paved?

Konrad Hinsen 2024-07-04 18:19:47

Here's an idea that looks easily implementable (an important condition for being able to explore it): once a thread loses activity, have it automatically copied to something like a Wiki page and send an invitation to all participants, asking them to clean it up, summarize lengthy parts, add keywords, etc.

Implementation: a forum plus a Wiki plus a bot that links the two.

Ivan Reese 2024-07-04 19:12:48

In general, I love the idea of "we build the thing we want". I just don't know that anyone here with the skills to do that has the time and interest in doing it for free.

Ivan Reese 2024-07-04 19:14:20

I'd feel great about picking some existing thing that's close to what we want, that's OSS and minimalist, and then extending / modifying it to suit our exact desires. But I know of no such thing.

Konrad Hinsen 2024-07-05 07:16:45

We could start by adopting some chat/forum that we consider open and stable enough that it's worth building on its API. And then slowly, and ideally collectively, build the Wiki and bot parts. Maybe explore different directions in parallel.

One reason I believe it's worth an effort, and a reason why I'd be happy to join such a project, is that it's not just us. I participate in two other communities that are wondering about the same questions. But those communities are not about software, so there's little in-house competence to draw on. If we can't scratch our own itches, then who can?

Konrad Hinsen 2024-07-05 07:21:07

I guess I wouldn't have written this before my Smalltalk experience over the last five years. The main lesson I learned from other Smalltalkers is the value of growing software rather than designing it, if it is for your own use (no contracts, no marketing people, ...). You start with the simplest thing that can possibly work (a phrase due to Ward Cunningham), and then you start using it to find out where you really want to go.

Florian Schulz 2024-07-07 13:32:12

One thing I loved about phpbb etc. was the possibility to organize by topics but also the ability to view a chronological feed of new posts across all topics. Replying to a topic would bring it to the top of a forum and also surface in list of latest posts.

We have channels in Slack, but in Slack, threads get burried quickly.

Forums are the sections where topics are stored. Without forums, your users would have nowhere to post! Creating forums is very easy.

phpbb.com/support/docs/en/3.3/ug/quickstart/forums