This is one of those things that is blindingly obvious to people in adjacent sectors of the industry, but maybe there just hasn't been enough cross-pollination of ideas in that direction (or in either direction).
This is one of those things that is blindingly obvious to people in adjacent sectors of the industry, but maybe there just hasn't been enough cross-pollination of ideas in that direction (or in either direction).
This seems not necessarily very hard to me? All you have to do is keep yourself honest by actually trying to reproduce the results of the notebook when you're done:
1. Copy the notebook
2. Run from first cell in the copy
3. Check that the results are the same
4. If not the same, debug and repeat
What makes it hard is when the feedback loop is slow because the data is big. But not all data is big!
Another thing that might make it hard is if your execution is so chaotic that debugging is impossible because what you did and what you think you did bear no resemblance. But personally I wouldn't define rising above that state as incredible discipline. For people who suffer from that issue, I think the best help would be a command history similar to that provided by RStudio.
All that said, Marimo seems great and I agree notebooks are dangerous if their results are trusted equally as fully explicit processing pipelines.
It's one thing when I'm relying on my own attention to detail to make sure all the intermediate results have been correctly recalculated, but it's entirely another when I have to rely on even trusted co-workers' attention to detail, much less randos on github. As a sibling comment points out, the "reproducibility crisis" numbers are very much not in favor of this approach being the right idea.
... Or you could work in a format that makes incorrect / out-of-date intermediate state impossible (or at least hard) to represent, which is (I believe) what marimo is an attempt at.
In my case - indeed the name is a historical baggage, I'm not arguing for or against it.
Indeed we had regularly situations that we had to pull in experts from other rooms, to discuss specific topics (like TCP), so we should have forwarded the conversation at the start.
But I don't think this should be categorical. There is value in non-experts responding faster (the channel had good reach) by your non-expert colleagues than waiting longer for the experts on the other continent to wake up.
Maybe there should be an option to... move conversation threads across channels?
I think there is place for both - unstructured conversations, and structured ones. What I don't like about managerial approach, is that many managers want to shape, constrain, control communication. This is not how I work. I value personal connections, I value personal expertise and curiosity. I dislike non-human touch.
"You should ask in the channel XYZ" is a dry and discouraging answer.
"Hey, Mat worked on it a while ago, let's summon him here, but he's in east coast so he's not at work yet, give him 2h" is a way better one.
I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.
And yes, I don't like managers trying to shape communication patterns.
I believe Zulip can do this, but Zulip is not really favored in these parts
The reason one might find this cumbersome or problematic, is in the case of very large numbers of lines of code - sure, your example is visible and somewhat readable (arguable) in its current form - but tell me you won't have issues when the loop is 80 or 100 lines of code, and you need to add another inner loop as part of the development process.
Are you now going to go through and be sure all your breaks are numbered properly? Are you really, though?
Better, imho, would have been to introduce labels and "break <label>", but even that is going to cause more headaches than its worth.
Ultimately, one shouldn't write such horrid code anyway.
Gmail's threading is an abomination.
"If you want to fork a thread, just change the subject!" This idea is so brain-dead and antithetical to deep mailing list conversations.
"Oops too many people replied, guess gmail'll fork the thread without changing the subject"
My disdain for this misfeature is palpable.
for i = 1, 10 do -- Loop 1.
for ii = 1, 5 do -- Loop 2.
break 1 -- This will break from Loop 2.
break 2 -- This will break from Loop 1.
end
end
https://pluto-lang.org/docs/New%20Features/Break%20Statement local stop = false
for i = 1, 10 do -- outer loop
if stop then break end
for j = 1, 5 do -- inner loop
break -- to break from inner loop
stop = true; break -- to break from outer loop
end
end
So this new feature fits with the general theme of pluto being a very-sugared lua.See e.g. https://lilypond.org/doc/v2.18/Documentation/notation/ancien...
If you wanted to use LE though, you could use a more "traditional" cert renewal process somewhere out-of-band, and then provision the resulting keys/certs through whatever coordination thing you contrive (and HUP the nginxs)