Ben Matthews

As a kid, I learned to write i = i +1, before school maths taught me it can’t. The point is, computers do iteration well, especially to model dynamics of real non-linear systems, while classical maths is good at finding algebraic solutions to equilibria - typically more theoretical than real. Calculus is great for understanding repeatable dynamics - such as waves in physics, also integrating over some distributions. But even without knowing that well you could still approximate stuff numerically with simple loops, test it, and if an inner-loop turns out to be time-critical or accuracy-critical (most are not), ask a mathematical colleague to rethink it - believe in iteration rather than perfect solutions.

I agree. For global discussions, are many Indians going to learn Chinese, Swahili, Hausa, Arabic, and vice-versa ? Meanwhile international-english is the new latin… Even within India, the south insists to keep english as an official language, to avoid being dominated by more populous hindi-speaking north.
Alternatively LLM-translation may facilitate multi-lingual discussion, but in this case the language of software development may still be influential during such transition.
By the way - this is an important topic for future of lemmy, which should expand more towards the south - where’s a good place to develop it (beyond such set of replies)?

I like some concepts and design of Mbin, something to learn from, but I’d believe more in its growth potential if not written mainly in php.

Interesting observation and analysis, and illustrates the potential of more lemmy-mastodon interaction.
Indeed mdon like-federation seems weird but I presume it was setup this way for efficiency, to reduce the number of small communications? Although Lemmy has a backend in rust - more efficient than mdon’s ruby - still I wonder whether the lemmy system of federating all upvotes would scale well if the number of users grows to that of mastodon and beyond ? Could there be some intermediate compromise solution (e.g. federate batches of 100 likes)?

Indeed to use scala-native you’d need pure-scala libraries, but the core lib re-implements most java lib, and there are now small simple external libs available for common tasks like file management, database, etc. - for example check out the lihaoyi suite.
I mainly use scala-js (to make this) which was formerly a java app - as it compiles to both js and jvm (cross-project) can gradually convert stuff you already wrote. I’ve tried native for stuff like pre-processing data files.

I didn’t discover Lemmy through search, nor did I ever use reddit - I found it from mastodon where a few people promote lemmy posts. Then gradually realised I preferred the community-focus here, compared to the individual-focus of mdon (although combining both could be good). As mdon has many more users, improving this inter-op would help to bring people here.

Scala compiles either to native, js or jvm - obviously the IO / interface options vary between these envs, but the lang is the same. Recently Scala 3.5 incorporates a simple-to-use CLI which makes it easier to compile to native (or just run a small file as a script, or experiment with a repl), native binaries are small and fast, and there are some simple io libraries. Since you can also compile to jvm to interop with java, that might help with transition.

I now use Scala 3, and very happy with syntactic whitespace (combined with an intelligent compiler)

Indeed that’s strange, and the flat slope in 2060 seems inconsistent with declared net-zero policies of China and even India. Russia has no such policy, but still strange to assume continuation of current government concepts there until 2060. (you can see the regional breakdown in supplem Fig 1. )

Regarding the map - an annual average cost is not so meaningful - in higher latitudes solar is not enough in winter - especially where it’s mostly cloudy during the first half of winter. Wind helps the balance but not everywhere, always. Of course, the sophisticated models behind the article know all that, the issue is simplistic presentation. I note “we assume hydrogen is used for seasonal storage” - this may be rather optimistic - how many dark months can that cover?

Scala-js is working on it - as its compiler design may facilitate this.
I haven’t yet tried (on todo list) and am not an expert, but bookmarked in passing:
recent github implementation, some history, following older discussion

I agree. The key symbiosis between coral and microalgae depends on fundamental thermodynamic equilibria of the carbonate chemistry of seawater - which are highly sensitive to temperature and atmospheric CO2, in very predictable ways. When living in coral becomes unprofitable for the algae, they leave. My instinct, from some experience with this system, is that introducing new species won’t do better than nature, nobody can beat thermodynamics. We have to reduce the CO2.

I use vscode as I develop this model in Scala3, whose language-server ‘metals’ integrates well with vscode, and when scala3 was new in mid-21 this was the platform they first targeted. But the scala command-line tools do the clever analysis, vscode provides the layout, colours, git integration, search/regex, web-preview etc… Now considering other options (eg zed) as vscode too dependent on potentially unsafe extensions (of which too much choice), also don’t want M$ scraping my code. Long ago when same model was in java I used netbeans, then eclipse. Would prefer a pure-scala toolset.

Thanks, fixed! As you can see parts of the science code are already accessible via the ‘cogs’, but not yet the structural code - anyway keeps evolving, update soon.

Similar - I thought about codeberg for the source of my interactive climate model,
but am not yet ready to give it a pure-foss license - might split in parts with different licenses. Could try self-hosting.

I don’t buy this. I’m still using SMTP on my own domain and it’s working fine, a bit of spam but not unmanageable, real messages get read. Main challenge is digesting so many potentially-interesting list messages, indicating email’s continued dominance for professional topics. Seems this author has another agenda.
Having said that, it’s a pity the world never agreed a protocol for micro-payment for emails (and for many other services), which would resolve the spam problem, and not be a burden for honest users.

I see that says ‘has to be local only, not federated’ (same issue also discussed on github).
‘Local only’ suggests to me front-end, i.e. info stored by browser. In that case people who are often switching devices would have to re-organise on each one, which could be tedious.
So isn’t there something in between local and federated - i.e. saved by the instance as user-settings, but not pushed to other instances?
Maybe there could be some manual copying mechanism, so a user who organises a big set of communities could share with others. (This reminds me of mastodon ‘lists’ and various ways of organising and transferring them).

Nearly 200 upthumbs, more ?!
But the discussion explores broader and narrow variants, need to coalesce.

I’m using Alexandrite, find it good

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.