valw

If you can't name one important outcome for your job, maybe it's time to change jobs. OTOH, if all you lack is directing your attention to these important outcomes, I'd recommend some rituals like meditation.

Hopefully, you're learning that new tool to achieve some worthwhile goal?

For example, I recently had to learn a desktop programming toolkit in Python, which I found very tedious and uninteresting. But knowing that I was doing it to help a team of engineers design a new kind of lightweight electric vehicle really drove me to put my heart in it.

Even when your project isn't aiming for such impacts, just putting (good) food on the table of your family can be a motivation I guess.

Might sound cheesy, but cultivating love and passion for what you do, especially targeting the tedious aspects of it.

Most people tend to assume that they have a fixed amount of energy, motivation and ability for their work, and don't realize how much these can be inflated by positive emotions.

This is where a musician finds the perseverance to do the technical exercises that get her to playing a piece. And where a budding scientist finds the patience to work through a complex topic in spite of all the overwhelming conceptual hurdles. And where a programmer gets the motivation to learn arcanes of some obscure tool.

WARNING: before anyone gets overenthusiastic, please observe that adopting this setup probably caused more harm to the environment than it prevented. Despite their romantic reputation, photovoltaics aren't green - they cost a lot of (usually dirty) energy and precious metals to manufacture, and are not renewable devices, so you want to make them count, i.e utilize them to a significant fraction of their potential, especially so on a grid like the Netherlands. This is not what this project is doing.

I'm absolutely sure the author means well and it sure is an interesting exercise, but this is not what transitioning towards green IT looks like. Sorry if this disappoints people's expectations, but these issues are more and more overlooked.

(Can't give you numbers rn as I'm on my phone, but you can work them out from e.g solar electricity emission factors)

> This one is interesting, again, will just get more expensive with time, but that one I never seen any project that allow to buy carbon credit for theses kinds of projects.

And yet Gold Standard reports renewable energy projects are a high share of their pipeline: https://www.goldstandard.org/sites/default/files/documents/m...

> Where can I offset my CO2 emission that way?

That's still at an experimental stage AFAIK (like most CCS technology), so unfortunately not yet available for such purposes.

> I don't care about investing in a solution that has no future. If what I pay for it means that it will just make the next ton more expensive, when it's already hard to make people pay for it already, I'm not for that solution.

A more optimistic way to look at it is as such: if we commit to offsetting our emissions by buying carbon credits, rising prices will pressure us towards reducing our emissions.

That's where we want to be headed, because there is NO future where emissions remain high and are totally offset.

I would encourage you to rethink your approach as follows: invest in the transition, not in the destination.

> Sure that one is 100x more expensive, but the cost can only go down with scale, and if it doesn't, well it will just push other technological solution to be developed because it's a proof there's money in sustainable solutions.

What makes you so sure that ClimeWork's solution can scale better? Their solution requires huge energy expenditures, and its not like we have a lot of geologically favourable sites for their solution.

If you want long-term innovation, why not fund general CCS research instead? It's much more likely to yield impactful and well-thought solutions.

I was just refuting the incorrect statement: "The only way to make tree-growing carbon negative* is to sequester the grown trees underground."

It would indeed be foolish to believe we can halt climate change just by growing trees. But AFOLU is part of the toolkit we need to use (the most important tool in this toolkit is sobriety).

There's a common misconception that voluntary carbon market projects solely consist of planting trees - that's not the case. There are also forest protection projects, energy transition projects, and so on. ClimeWorks' project could be certified as well... but then carbon credit buyers would realize it's just less effective than the alternatives. I guess that's why ClimeWorks's go-to-market strategy is 'high-tech' branding: they go after technology lovers rather rather than informed investors.

Also see what I mentioned about CCS. AFAIK, the most promising CCS technology consist of burning biomass in power plants, and then using geological confinement of the sequestered carbon. The reason it's more effective, as I mentioned, is because the carbon is captured where its concentration is high - less entropy to fight.

It's absolutely true that current offsetting methodologies won't always stay so cheap - and as prices rise, new innovative methodologies will develop. Buying carbon credits is not an impediment to innovation; but it has the advantage of rewarding projects for being efficient, rather than "technologically cool".

Examples: forest protection programs in low-wage countries, investing in renewable energy on high-carbon-intensity grids, distributing enhanced ovens to reduce wood consumption...

Carbon offsetting is cheap currently, but won't always stay so, getting more expensive as we exhaust the low-hanging fruits.

I don't think it's technically hard on their end - we totally have the science required to estimate how much their process captures.

What for? the harm done by excess CO2 is global, not local.

CO2 is diffused across the whole world in a matter of months. Its climate-changing effect lasts much longer than that - decades to centuries.

Actually, you can buy carbon credits for less than that if you make bulk purchases. It's usually for preventing emissions from occurring rather than capturing carbon from the atmosphere.

But we couldn't keep this price so low if we scaled this to world emissions - the price of carbon offsetting is low now because we're still picking the low-hanging fruits of carbon offsetting.

That argument gets brought up again and again, and is just wrong. Can't people see the basic contradiction in that reasoning? Trees have always died!

What matters with forest-based offsetting is the increase of forest biomass - the deaths of individual trees don't matter. If you grow a forest, the corresponding CO2 is offset for as long as the forest stays there.

Better: protect a forest.

Most solutions to climate change are subtractive, not additive.

There's no 'first' - it's a battle we must fight on many fronts :) Destroying Bitcoin, and more generally digital sobriety, is only one of them!

If you want make your money work against climate change, I wouldn't recommend this service - it's simply not competitive compared to voluntary carbon markets, in which well-certified projects can offset a teqCO2 for less than 10 USD (that's 100 times more efficient carbon offsetting than ClimeWorks, for high-end projects), and do so with additional co-benefits in terms of biodiversity and livelihood of local communities. REDD+ projects such as https://www.standfortrees.org are good examples of that.

The differentiating factor of this service is that it's "Permanent: turn CO2 into stone". That benefit is mostly psychological, not pragmatic. Aside from that, the 'small land and water usage' metric is also biased. Yes, rainforest protection projects use land, and you know what else they do? Protect rainforests!

It's also not that promising as a CCS technology. Just like energy, CO2 is most efficiently captured where its concentration is highest - that is in power plants, steelmaking plants, etc.

I know we love revolutionary startups and shiny new things here, but there are scientific bodies and certification standards which have already done the work well in this space, looking at the problem with a holistic approach and with numbers.

I know people mean well here, but for climate change what matters is results, not intentions - so run the numbers before you throw your money out of the window. Cool startup branding is not what makes a project impactful.

Frankly, this service is basically reinventing the wheel of volontary carbon markets, and doing so much, much less efficiently, and with fewer co-benefits.

Well-certified projects can offset emissions at a price of about 10$/teqCO2. I personally recommend https://www.standfortrees.org.

And assuming a person needs 0.5 gallons (2 liters) of drinkable water per day, we get that 1 square meter provides drinkable water for 15 to 30 people. Not bad!

Of course, once we factor in cleaning uses of unsalted water, the picture is less pretty. Still, not bad.

What I would call "quantitative environmental consciousness" - things like estimating energy consumption and carbon footprints.

Topics like energy policy and CO2 emissions will become increasingly critical in our lives, and yet you don't find many people reasoning about them in a lucid and informed way.

A great place to start is the SEWTHA book by MacKay: https://www.withouthotair.com/

I wrote a blog post making a similar point with Clojure as an example: https://vvvvalvalval.github.io/posts/2018-01-06-so-yeah-abou...

The core ideas are timeless really, but the examples might be a bit more relatable today.

I'm reproducing the ToC here:

  1. Does syntax matter?
  2. The ingredients of Clojure's syntax
    2.1 Data literals
    2.2 Macros
  3. Consequences
    3.1 Verbosity is a solved problem
    3.2 Separation of concerns: code layout ⊥ program structure
      3.2.1 Example: the Builder Pattern
    3.3 Code = Data = Data Viz
    3.4 Tooling as libraries
    3.5 An 'all-tracks' language: embedding paradigms
      3.5.1 Example: Web UIs
    3.6 Saner language stewardship
  4. Summary

To the experienced data scientists / statisticians here: does this sort of regression analysis between the actual and predicted age seem legit to you?

It seems very weird to me. From what I understand, the p-value tests the hypothesis that the predicted and actual data are correlated, which seems like a very weak way of assessing the reliability of the prediction.

An estimator of the test error seems more relevant, and that's kind of what the R^2 does, but why do an affine regression between predicted and actual value instead of say an RMS error? Isn't this using the test data for parameter-fitting, i.e training?

cough Datomic cough: https://www.infoq.com/presentations/Datomic-Database-Value/

Some programmers will ask you "why didn't you just" questions about something you've worked on for weeks, months or years, not because they think they're smarter than you, but because they never think about anything for weeks, months or years.

Don't let the title fool you - 90% of the advice given in this book isn't specific to Clojure, and boy is it good advice.

This book contains some of the deepest programming insights I've encountered, to be put on the same level as SICP or the Pragmatic Programmer.

The discussions on naming and abstraction are particularly illuminating, exposing some fundamental tradeoffs like synthetic vs natural names, or principled vs adaptable systems of abstractions. Were these notions more widespread, a lot of the pointless rants and debates we hear in programming circles would disappear.

I would not recommend this book to beginners - this book is most useful when you are experienced enough that your struggle is to make choices, not to get things to work.

Not going into this explanation (as I believe the qualities of languages can only be assessed through experience, not theoretical arguments), but I, and many others, have been through Scala with high hopes before finally settling for Clojure - this should tell you that there are indeed good reasons for favouring it.

An analogy to pique your curiosity: I would say that if Java was a balloon, Scala would be a zeppelin, and Clojure would be a plane.

I would also say that the stewardship of Clojure is much saner than that of Scala, due to a strong emphasis on stability. Typesafe / Lightbend is bigger than Cognitect, but big does not mean reliable. One sign of this is that Clojure now grows via libraries, the core having reached stability. Scala is still figuring out its fundamental semantics.

Don't forget that the IPCC report concerns itself not only with preventing climate change, but also with adapting to it. What's more, changes in land management can be part of a solution for GHG sequestration, so it's not just about reducing emissions. All the more reasons to put significant effort on land management, and therefore diets and forests.

That being said, the IPCC never said that transportation, electricity production and industry must be ignored.

A rational approach to climate change consists of accounting for GHG emissions where they are and cutting them where they are. Meat production and fossil energy are 2 large causes of GHG emissions, and so we must significantly reduce both. There's no debate to be had about this, it's just facts and numbers.

The point is not to make people for eating meat, just like it's not to make people guilty for lighting and heating their homes with coal-powered electricity. It's just to live sustainably. Let's not deny the facts because we don't like to hear them.

Is eating less beef a decrease in life comfort? Yes, it certainly is. It's still much, much better than living in a +2°C hotter world, in which getting any food at all will become challenging.

That said, about 40% of arable land is currently being used to grow cattle fodder. So there's a big opportunity here: if we drastically reduce our meat consumption (especially beef and lamb), which is not a huge effort, we can significantly reduce GHG emissions, stop deforestation, and reclaim arable land.

From experience: you don't have to dig into the Java world for using Clojure any more than you have to dig into the C world for using a Unix shell.

> I'm digging deep into analysis and combinatorics

Thanks, could you provide some material recommendations?

I'll share one: I've really, really enjoyed 'Graph Theory' by Bondy and Murty (2007 edition): https://www.springer.com/kr/book/9781846289699. Disclaimer: it's much more focused on the mathematical / combinatorial aspects of graphs than on concrete algorithms, although there are some algorithms in there. Some math background recommended.

I think our understanding of the good parts and bad parts of OOP has matured a lot. As a result, we tend to find the good parts of OOP in new languages (runtime polymorphism, 'metaprogramming' facilities, sometimes message passing), whereas the bad parts of OOP are left out (classes, concrete inheritance).

This raises the question: how have we concluded that these parts are bad? Inheritance is the easiest one - it tends to dramatically increase the surface for coupling, which is why composition is recommended over inheritance. Classes is more subtle; I would say the issue with classes is that they strongly encourage you to couple various aspects, as classes are a single programming construct with which you do data representation, data specification, interface declaration, interface implementation, code organization, plain old logic, state management, and sometimes types declaration and concurrency control.

It takes discipline and awareness to resist the temptation of baking many aspect of a program into one class (even more so when you have to come up with a name for each class - naming is costly!), whereas it's natural in a language where each of these aspects is addressed by a different language feature. Finally, this temptation is made even stronger because class hierarchies feel so elegant - you spent a lot of time designing your class hierarchy (deciding where each part of the logic goes, choosing if methods were public of private and so on, applying various design patterns, etc.) so that MUST mean you've produced quality code, right? We love to tell ourselves this story, when the truth is we wasted a lot of time on non-essential decisions.

So many programmers don't resist the temptation, and end up with a tangled inflexible mess.

Don't take my word for it - try a variety of 'OOP' and 'non-OOP' languages! You can't achieve a good understanding of this unless you have empirical perspectives from both the inside and outside.

One thing that doesn't help is there isn't an agreed-upon clear definition of OOP. There was one made by Alan Kay, but the mainstream language we call OOP are very far from embodying it. So OOP is more a fuzzy cultural notion: "this cluster of mainstream languages that use classes." I think it would by much easier to discuss all of this if we separated the notions of 'OOP' and 'class-based programming'.