7,254 karma · joined March 13, 2014
To be fair they developed this whole new platform to build this app with. I guess that's where the effort went.
* Buy food locally, support your local farmers.
* Grow your own vegetables (some are really easy: potatos, onions, garlic, zucchini, corn, beans, etc.). Even tomatos, peppers and eggplants are not that hard.
* Compost your food waste - put it back in your garden.
* Learn how to preserve food when there's an abundance.
* Also, learn to eat better.
I think it's a real shame that so much food waste ends up in landfill instead of being composted locally. If you compost your leftovers, you turn your waste into a resource, and use that to fertilize your garden.
What I see everywhere, not just in Britain, is the same old story over and over again: privatizing the profits, nationalizing the losses.
OTOH, plants (i.e. trees) can live for hundreds of years, they are self-replicating, they extract their own minerals from the ground, require very little energy input to put in place, play an crucial role in the water cycle [1], reduce the albedo effect [2], cool the air [3], provide a habitat for a multitude of species, and bring joy to our hearts.
Oh, I almost forgot, they also fix carbon! And they do all this for free, the only thing you have to do is, you know, not cut them down.
I would say that's a pretty good deal.
[1] https://sustainablefootprint.org/nederlands-trees-and-the-wa... [2] https://en.wikipedia.org/wiki/Albedo#Trees [3] https://www.epa.gov/heatislands/using-trees-and-vegetation-r...
This is really what stands out to me when people on HN suggest that global warming is totally solvable with just enough technological innovation. The sad truth, and what this article is really driving home, is that while we're waiting for a deus ex machina, we continue to trash our planet, as if we can just move to Mars or something when earth is done.
I'm quite skeptical about the whole "collapse of industrial civilisation" schtick, but I am worried, most of all for my children and their generation.
Besides, the act of recycling in itself comes with its own problems: energy use (it would be interesting to have an estimate of EROEI of recyled solar panels), fresh water usage, pollution and effluents, and finally the recycling rate (how much of the input is actually recycled).
It is relevant IMO to note that after decades of plastic recycling operations, the rate of plastic waste being actually recycled is at about 9%. And recycled plastic in itself has degraded performance characteristics.
I think one could say a lot of the reaction of governments around the world was knee-jerk, "let's copy what that other government is doing" kind of thinking. Not that this is specific to the CoVid situation, there's plenty of it going on at any given moment.
The two are not necessarily mutually-exclusive. What's wrong with scheduling interactions, or simply working asynchronously? Yes, it's a bit slower, but why do we need to rush all the time?
Not in my experience, especially not reading code someone else wrote.
Personally, I really don't mind doing this. And each time I get a little better at it. I much prefer this to having an AI agent write code for me that I then have to audit and verify it does what it's supposed to do. I highly doubt this will reduce work.
I think it would be interesting to look at how much biodiverse forests we have now compared to 100 years ago. I might be proven wrong.
So yeah, deforestation + pesticides = less birds, and will lead to a desertification of Europe in more than one sense. But even in the desert you can find here and there an oasis, a place full of life where birdsong is just as vigorous as ever. There are still many places across Europe where this is happening, many oases (plural?) that teem with life, and bring happiness to the heart. In fact, this is not so difficult to do, just bring back the trees and the biodiversity, then the insects will return, and when the insects are there, birds will return.
Build it and they will come.
It is high time we change our agricultural practices from destructive to regenerative. The techniques are already well known, and pioneering work in this field of regenerative practices have been going on for decades already - from Yeomans, Molisson, and Holmgren in Australia to Fukuoka in Japan and Goetsch in Brasil, the knowledge is there.
I live with my family on a small piece of land where we work to increase biodiversity and to reforest. Every year, birdsong gets louder and louder. I know it's possible and my garden is proof. Build it and they will come.
I think it's time we explored the true costs to our species. Maybe in the end people are not that expensive after all if you consider the alternative.
You can pass any data between fibers using "receive" and "<<", including fiber refs.
> In my original code sample, my code refers to the children tasks. In your code sample, the parent refers to the children tasks. This seems to be a property of structured concurrency.
In general, yes, but in Polyphony at least you can easily walk the fiber tree using "Fiber#parent" and "Fiber#children".
Not really. Concurrent-Ruby implements a lot of different concurrency patterns. Polyphony has a much smaller scope, though I imagine you could reimplement a lot of concurrent-ruby on top of Polyphony. I think there's a place for the two in the Ruby ecosystem.
This was the main driving force behind the development of Polyphony. I've been exploring all the different ways of expressing concurrent operations: callbacks, promises, async/await. Each of these solutions has its drawbacks: callbacks make you split your app logic across different functions; promises are a somewhat better API but do not solve the split logic problem; async/await potentially leads to two types of functions (the "what color is your function" problem). All three kind of break Ruby's exception handling model.
In contrast, Polyphony relies on Ruby fibers, which provide a base for implementing cooperative concurrency, where each fiber does its work, yielding execution whenever it performs a blocking operation, such as reading from a socket, or waiting for a timeout. In addition, fibers are arranged into a tree where each fiber is considered the child of the fiber from which it was spawned, and is guaranteed to stop executing before its immediate parent stops executing. Any uncaught exception raised by a fiber will be propagated up the fiber tree. This implements a pattern known as Structured Concurrency [1]. Fibers can communicate by sending each other messages, in a similar fashion to Erlang/Elixir processes.
There's no direct equivalent in Polyphony to the program you included, which seems to implement two generators running asynchronously. But the following does something similar.
def number_generator
n = 0
loop do
client = receive
client << (n += 1)
end
end
task1 = spin { number_generator }
task2 = spin { number_generator }
10.times do
task1 << Fiber.current
puts "next number from task1: #{receive}"
task2 << Fiber.current
puts "next number from task2: #{receive}"
end
So in the above program, two fibers are spun, each running the same number generator, which repeatedly waits for a message which is actually the fiber of the "client", and sends the next number to the client. In Python there's the Trio library [2], which implements structured concurrency, and which was actually one of the main inspirations for developing Polyphony.
[1] https://en.wikipedia.org/wiki/Structured_concurrency
[2] https://github.com/python-trio/trio