https://github.com/shell-pool/shpool

Of course, but that's the difference between sins of commission and sins of omission. The question is what "pretty diligent" actually translates to in practice. How many people will encourage delays in a model release or post-training improvement waiting "for more thorough evaluation"? How many popularized AI results can you vouch for on this?

The zeitgeist is to celebrate bias for action, avoiding analysis paralysis and shipping things (esp. with conference driven research culture, even before we get into thorny questions of market dynamics), so even if we have a few pockets of meticulous excellence, the incentive structure pushes towards making the whole field rot.

But that's not what the above comment said.

> Just let it run, check debugger/stdout/localhost page and adjust: "Oh, right, the entries are missing canonical IDs, but at the same time there are already all the comments in them, forgot they would be there

So you did have an expectation that the entries should have some canonical IDs, and anticipated/desired a certain specific behavior of the system.

Which is basically the meaning of "what will the output be?" when simplified for programming novices at university.

Comments URL: https://news.ycombinator.com/item?id=47294144

Points: 1

# Comments: 0

It's not enough for a data structure to represent the "fundamental" degrees of freedom needed to model the situation; the algorithmic needs (vis-a-vis the available resources) most definitely matter a lot.

Can we use older (previous generation, smaller) models as a speculative decoder for the current model? I don't know whether the randomness in training (weight init, data ordering, etc) will affect this kind of use. To the extent that these models are learning the "true underlying token distribution" this should be possible, in principle. If that's the case, speculative decoding is an elegant vector to introduce this kind of tech, and the turnaround time is even less of a problem.

"Data science" is an extremely broad term, so YMMV. That said, since you asked, Julia has absolutely replaced Python for me. I don't have anything new to add on the benefits of Julia; it's all been said before elsewhere. It's just a question of exactly what kind of stuff you want to do. Most of my recent work is math/algorithms flavored, and Python would be annoyingly verbose/inexpressive while also being substantially slower. Julia also tends to have many more high-quality packages of this kind that I can quickly use / build on.

Do you mean people are happy to post on a thousand different threads, but no one reads posts from anyone else?

Why do you even have so many different active threads? Why not just let "resolved" threads be, and funnel conversations into fewer threads? (esp if you want ephemerality i.e. conversations to expire with time)

> 300+ members in a makerspace

If you have 300+ people discussing a wide variety of things, how do you ever expect to maintain your sanity with only channels and without threads? Won't every channel be quickly flooded and really hard to resurface anything useful from past discussions?

> I cannot [...] unless I have elevated access

Is your complaint that your Zulip space is not moderated well and that it would be helpful to ad-hoc decentralize some of the maintenance work across more participants?

I have a theory for why some people love Slack and others love Zulip (Completers -vs- cultivators) which I shared in a sibling thread.

https://news.ycombinator.com/item?id=46960569

Curious to hear what you think.

I have a theory for why some people love Slack and others love Zulip (Completers -vs- cultivators) which I shared in a sibling thread.

https://news.ycombinator.com/item?id=46960569

Curious to hear what you think.

Having thought about this a bit, I propose there is an underlying dichotomy between "completers" and "cultivators"

## Completers

Prioritize "velocity" and closing open loops. Limiting context means that they can act with focus. Close tabs often. Communication appends to the task queue; each conversation is an open ticket to be closed. Anything that scrolls off screen is implicitly marked as done. The ephemerality of the stream allows them to "process" a conversation and move on. Zulip might cause anxiety because threads/discussions linger without closure.

## Cultivators

Communication as externalized cognition. Messages are nuggets to be filed / incorporated into a larger schema. Wants a "dashboard" to maintain sense of control; fears something falling through the cracks more than they fear clutter. Don't care to "finish" a chat; want to keep the context organized and accessible for deep work / future decisions.

## Problems

Zulip defaults to assuming that all chat is valuable and taxes every interaction with a little bit of up front effort. Slack assumes most chat is of ephemeral value and doesn't see the point of taxing 90% of the interactions for the 10% that might be valuable. Slack forces cultivators to become completers and Zulip nudges completors to act as cultivators.

Completers preferring who prefers Slack/Discord/etc are implicitly adopting the the fragmentation of multi-system setup -- chat for ephemeral communication, and anything longer term must move to docs/wikis/Jira/whatever (which now begs for dozens of "integrations"). Understanding the state of anything now requires forensic archeology. (cue [Charlie Pepe Silvia meme]) Complicated acrobatics in channel names such as `#team-proj-blah` are attempts at combating the fundamental entropy of treating everything ephemeral.

The challenge is that, ultimately organizing is also real work and ignoring it in a short-sighted drive for efficiency hinders longer term effectiveness.

## Potential solutions?

1. The chat platform could offer two different views: a triage flavored mode for completers, and a dashboard flavored mode for cultivators. Even one person could toggle back-and-forth between the two as necessary.

2. Better UX for organizing incrementally, eg. UX improvements for manual clustering, and AI-assisted clustering / topic naming. Wouldn't it be great if people could continue chatting in the stream but the same message would simultaneously get filed under a topic? Technology might now enable such a product experience.

3. Slack needs to stop pretending that search is an effective replacement for organization (esp when search is crappy). I haven't used Slack in a while (preferring Zulip with catchall topics as a good balance) but I get the impression that Slack [Canvas](https://slack.com/intl/en-in/features/canvas) is an attempt to combat this problem.

----

[Charlie Pepe Silvia meme] https://knowyourmeme.com/memes/pepe-silvia

Eg. If I'm discussing buying a house or a career change (personal) or a new business strategy for my company (work) I don't want all conversations dumped into a single river. Slack's model of threads within a channel feels too schizophrenic; Zulip's model of multiple conversations arranged loosely by theme (and accessible from the sidebar) is much better.

Catch-all topics are good for the ephemeral stream of chatter.

Some might say that chat should be only for ephemeral stuff, but then that is basically avoiding the essential complexity (of long term conversations) which must live somewhere to enforce some Procrustean simplicity on the chat platform.

I wish Zulip (and other apps) provided an inbox instead of just ephemeral notifications that disappear once a message is viewed. Lack of inbox means that I have to use unread messages as a way to manage my inbox -- because the moment I click on a notification / take a quick peek at a message there's no easy way to mark it for coming back to later.

----

+100 for Zulip though; by far the sanest messaging experience for this kind of context.