milancurcic

Agents are destroying open source. There will only be more of this crap happening and projects will increasing turn read-only or closed.

The company features on the front page was a great opportunity to point out their positive impacts on the world. Instead, they focus on $BBB. Nice new site though.

I agree with the second statement but public ridicule can be understood to have a stronger effect, and be in bad faith itself.

I think that a warning of public ridicule may be fine. However, actually doing it is quite low brow IMO. I'm sad to see more and more otherwise admirable projects step down to that (assuming they actually do it).

> The industry had reason to be optimistic that 2025 would prove pivotal. In previous years, AI agents like Claude Code and OpenAI’s Codex had become impressively adept at tackling multi-step computer programming problems.

Both of these agents launched mid-2025.

Thanks for sharing. I always enjoy reading author-publisher process articles as they get to the true behind the scenes story. I can relate to most things mentioned, and the terms seem identical to what I had when writing Modern Fortran with Manning. I also started with the intent to write for experts, but the publisher pushed for targeting beginners. The author can concede or (usually) give up the project.

One important aspect to this is that a typical first-book technical author knows well the subject matter, and sometimes knows how to write too (but usually not, as was my case), but does not know how to edit, typeset, publish, market, and sell well. That's what the publisher knows best. And of course, they want sales, and they understand that overall beginner books sell better than advanced/expert level books.

I encourage the author to continue writing and self-publish, and at a later time a publisher come to package and market a mostly finished product.

Neal delivers. I recently learned that viruses are not considered living being, but I'm nevertheless happy they're included here because they're both relevant and interesting in this context.

Cool! Essentially Fortran coarrays from 2008.

Just vibe clean it when GPT-6 comes out.

I and many others do. It's common in formal writing such as academic papers. It's also the most agreed upon correct use of em dash.

"Recent large-scale upticks in the use of words like “delve” and “intricate” in certain fields, especially education and academic writing, are attributed to the widespread introduction of LLMs with a chat function, like ChatGPT, that overuses those buzzwords."

OK, but please don't do what pg did a year or so ago and dismiss anyone who wrote "delve" as AI writing. I've been using "delve" in speech for 15+ years. It's just a question where and how one learns their English.

This site breaks the browser's back button.

"True peer review begins after publication." --Eric Weinstein

As a real-world counter-example, CLiMA (Julia) lists 54 people on their Sci&Eng team, and the project has been going for several years now. It is far from production ready. Granted, they tackle everything at once (atmosphere, ocean, data assimilation, machine learning etc.). I'm a big fan of the project and wish it the best. This is to illustrate what a huge endeavor it is to build a system like this, regardless of the implementation language.

Developing projects like this in Fortran is not any more difficult than other languages. I can't speak to Julia because I don't understand it well enough, but in my experience writing this kind of code in Fortran is more natural and easier than in Python + numeric/array/accelerator libraries. The key unfulfilled need is to have Fortran compilers do offloading efficiently for you. Then, there's no comparison.

There are a few other active projects porting weather, ocean, and climate models to Julia, C++, or Python.

Getting a weather or climate model from zero to production grade requires approximately 100 person-years, or $20M (personal experience). Because of extremely high scientific expertise needed to correctly implement such models, it's more difficult to leverage open source contributions from a broader community, like it is with web or ML frameworks. So most of the development in these projects is done by full-time hires, and to a lesser extent by contributions from early adopters.

The key technical arguments that I hear/read for such transition projects are ease of portability to accelerators (e.g. GPUs), and higher availability of programmers in the workforce.

My intuition is that a $20M budget, if carefully allocated to compiler and hardware accelerator teams, could solve running Fortran on any accelerator in its entirety.

With Fortran's tooling and compiler support for offloading standard Fortran to accelerators slowly but surely improving over time, the rationale for porting to other languages becomes increasingly more questionable and is being revisited.

But regardless of technical arguments, it's a good thing for large models and frameworks to be written and explored in diverse programming languages.

A few more:

https://github.com/modern-fortran/neural-fortran (disclaimer, I originally created this one)

https://github.com/BerkeleyLab/inference-engine

https://git.exeter.ac.uk/hepplestone/athena

You're correct about the compiler flags. 10K will be the line length limit; the 1M limit is for a statement length that can span any number of lines.

Fortran-lang's role (as an open-source org) has been 4-pronged: Tooling (build system and package manager, testing, eventually compilers etc.), modernized and maintained libraries (stdlib, minpack, fftpack, etc.), community space (Discourse), and evangelism/marketing (website, Twitter, blog posts etc.). Some members participate in the standardization process of the language, but the groups and processes are separate and complementary.

It's true that one goal may be to pick an important race and try to win it.

Another goal, in my view more important, is to make Fortran more pleasant to use for people/Orgs who need it (there are many) and for people who love it (there are many).

I've found that more often than not, people/teams first like working with a technology, and then come up with technical arguments for why that technology is the best choice. Often the arguments are valid, sometimes they're made up, but ultimately underneath it all you either like it or not and that's all that matters. My goal with Fortran-lang has been to slowly and continuously increase the surface area of Fortran's likability. Fortran is not for everyone, but for people who think it may be, we can work to make it better and more pleasant to use.

As one example, we just released a small library to make high-level HTTP requests from Fortran applications: https://github.com/fortran-lang/http-client. This was a product of one of our Google Summer of Code contributors.

And the line length limit will soon (with Fortran 2023 later this year) practically go away--a hard limit of 10,000 characters.

Ah, good point. I'm in Earth sciences. 3 papers before PhD is reasonable here, just not a formal university requirement.

It's been mostly like this for a long time, but it is slowly changing. Open data repositories and scientific software libraries/products are beginning to count more and more (at least many of us are pushing for this). It also depends on the target career past graduation. Papers matter a lot for tenure-track positions, and much less for science support (scientific software developers, data engineers, lab managers etc.) in academia, or most jobs in the industry.

The 3 paper requirement in the game is also not a formal requirement in most universities--it's more of an implied requirement by individual PhD advisors. FWIW, my first lead-author paper I published a year past my PhD. During my PhD, I produced two relatively large scientific software applications (one open and one closed source) and a few open datasets. I'm now 8 years past my PhD and relatively successful in my field, 90th or so percentile based on common metrics--papers, citations, and funds raised.

Bottom line, papers are important but not the only thing that counts. Outside of tenure-track careers where they are crucial, it's possible to establish yourself as a scientist and be respected by your peers by publishing software and data.

Yes, the city limits are approximately at Powerline, with deviations here and there. Area to the west is unincorporated.

I don't know how it works exactly but assume it's in the city's zoning code. Thinking more about it, there's not a single superstore in the city. A Costco and several Targets are immediately outside of city limits. It's not even that small of a city--around 100k pop.

Boca Raton doesn't allow billboards, car dealerships, or Walmarts. We don't normally notice it, but these things jar us as soon as we go to neighboring towns. It's a subtle improvement of outdoor experience (more architecture and green spaces) that percolates into quality of life. A good analogy of this may be browsing the web with ad blockers--pages with ads are busier, noisier, and load more slowly; yes, if the page content is bland, removing the ads will make it blander.

My son died at birth in August of 2022. A month later, my wife found a group of 30-some Loss Dads who at the time met monthly via Zoom. I quickly bonded with all the Dads there, despite most of us never having met each other in person. I attribute our strong bond to us sharing a rare and intense life experience, as well as to the fact that it's still difficult to find support, and even willingness to talk about, with friends and family who have not experienced child loss. Fast forward to today, we have an active Discord server and meet on Zoom bi-weekly. The group has also recently filed for a non-profit status and has raised funds and materials to help grieving parents as well as hospitals.

If you're a grieving Dad and are looking for support from other grieving Dads, please email me at milancurcic@hey.com.

The well-optimized part is C calling Fortran. :)

I've found individual years and year-ranges useful as an indication on when the code was first/last/how often updated.

Having worked with WRF for 13 years now, contributed patches to many releases, and built a SaaS business centered on WRF (https://cloudrun.co), I still discover new things about it and run into interesting scientific and engineering challenges. It's not the kind of software that's easily picked up and run by a non-expert. It's a large framework that's more niche, more obscure, and not as well documented as something like, say, Tensorflow. There's still a ton of value to derive from making WRF and similar models more usable by non-experts and without access to supercomputers.

Thank you for sharing it!!