Ben Matthews

Hi, excuse me for replying so late, but i’ve been away from lemmy for.a while. Well, to summarise, the model calculates the future trajectories, of population, economy, emissions, atmospheric gases, and climate response etc., according to a set of (hundreds of) diverse options and uncertainties which you can adjust - the key feature is that the change shows rapidly enough to let you follow cause -> effect, to understand how the system responds in a quasi-mechanical way.
Indeed you are right, complexity is beautiful, but hard. A challenge with such tools is to adjust gradually from simple to complex. Although SWIM has four complexity levels, they are no longer systematically implemented - also what seems simple or complex varies depending where each person is coming from, so i think to adapt the complexity filter into a topic-focus filter. Much todo …

I can relate to this, having developed a coupled socio-emissions-carbon-climate model, which evolved for 20 years in java, until recently converted to scala3. You can have a look here. The problem is that “coupling” in such models of complex systems is a ‘good’ thing, as there are feedbacks - for example atmospheric co2 drives climate warming but the latter also changes the carbon cycle, demography drives economic growth but the latter influences fertility and migration, etc… (some feedbacks are solved by extrapolating from the previous timestep - the delay is anyway realistic). There are also policy feedbacks - between top-down climate-stabilisation goals, and bottom up trends and national policies, the choice affects the logical calculation order. All this has to work fast within the browser (now scala.js - originally java applet), responding interactively to parameter adjustments, only recalculating curves which changed - getting all these interactions right is hard.
If restarting in scala3 I’d structure it differently, but having a lot of legacy science code known to work, it’s hard to pull it apart. Wish I’d known such principles at the beginning, but as it grew gradually, one doesn’t anticipate such complexity.

In defence of the jack-of-all-trades, if everybody is a cog in the machine, nobody sees the overview of how the cogs could connect.
For what it’s worth, here’s an overview of some cogs made by a j-o-a-t, for whom software developer is just a sub-role, within understanding complex climate system.

Hi, thanks for the encouragement, delayed response due focusing on the code, and a related conference, and now trying to keep up with the COP. As it happens, the “ratchet” system of pledges created in Paris (COP21) is an iterative algorithm - start with wild guesses and gradually improve them by feedback - this made sense given the weaknesses of diplomacy, but it’s hard to summarise this mess with neat code in a compact model.

This principle works most but not all the time. I develop an interactive climate-system model that evolved with many small steps over 23 years. So it has many patchy fixes as climate policy structure changed, gases and sectors added etc. Then converted from java to scala module by module (out of ±50) , each step checking the plots looked as before. Result is it works, but parts are messy with legacy options and outdated code style. So sometimes it’s necessary to radically rethink the structure, take big bold steps before it works again, that’s hard. Scala strong type system, with hints from compiler (and “metals”) help make such refactoring easier.

Some of us will even remember when compilers ran on big central computers, and you might have to wait 15–30 minutes to find out if your code was syntactically correct (let alone if it worked.)

My father remembers when he wrote code printed on a set of punched cards, they traveled several hours on an evening train to a warehouse with a big government statistics computer (that was too busy during daytime), the result came back by train next morning. Syntax error? try again tomorrow…

I develop an interactive climate / future scenario model, now in scala, earlier in java, almost no dependencies. No visualisation frameworks - the diverse plots hand coded in scala (transpiles using scala.js, makes SVGs on demand). The science code from demography through economy emissions, bioegeochemistry, to climate - just scala, no interface to other languages / models, no “solver” tool. Data input just text files -easy to check. Some modules over 20 years old (except converted java -> scala), still work reliably. It’s efficient as all client-side, no IO/net between adjustments and results. Seems no big institute would employ me for such model dev because my experience doesn’t tick the boxes of all the current fashionable frameworks. But at least I can share a way to explore the future for ourselves … and yes it’s bleak but not so dire as many people here seem to assume, we still have choices.

No, as it happens I think pure-functional is over-hyped too, except for specific massively parallel tasks. I’m not an expert on any programming ecosystem, I’m a climate scientist who codes a complex future-scenarios model and like the multi-paradigm nature of scala, with a lot working out of the box, without many dependencies. Scala’s sophisticated type system catches most errors, so I don’t have to run loads of tests like the python people do, yet with Scala3 syntax it’s even more readable than python, and just works in the browser through scala.js (it helps js and scala share a lot of concepts). It’s a pity we have cycles initial hype - disappointment - slow but steady fixing - then obscurity so just when everything starts to works well, people move away to next hype.

I note the lemmy devs are working on converting their gui from react to rust too - let’s see if this works out - but maybe it’s too low-level a language for this.

Seems to me Rust is overhyped - sure it’s better than C, it can power WASM, Lemmy is written in it, borrow-checking is neat, etc., but it’s got a long long way to go to gain the high-level features of Scala. Problem is that hype is important to grow a community, and as LiHaoyi wrote, that peaked for Scala some years ago. I’d like to see more progress on Scala Native, to enable moving stuff between wasm and scala.js.

(even newer here, hence a belated reply).
My interactive climate model SWIM now written in scala3 (originally java), uses loads of enums for real-world things, for example gases in the atmosphere, landuse biomes, sources of electricity, economic sectors, scenario definitions, stabilisation/equity algorithm options, etc. Such enums help map over irregular data structures, connect with user-adjustable choosers, etc… So I waited for scala3 before embarking on this project - and am very happy with the language.

Recently I experiment applying enums also to region-definitions, but anticipating over 1000 of these, fear that the neater code may compromise efficiency (bearing in mind, this all works in scala.js - client side). From such experience, could elaborate (maybe elsewhere …?) some ways Scala3 enums might still be improved.