home.social

#orms — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #orms, aggregated by home.social.

  1. Mathematical Optimization, Full Professorship (W2) @rwthaachenuniversity

    areas: continuous, stochastic, discrete optimization, convex/non-convex analysis, variational methods, non-smooth/set-valued analysis, optimal control, and/or inverse problems #orms

    berufungsportal.rwth-aachen.de/

  2. AI is Making Libraries Obsolete

    Summary: AI agents are fundamentally changing the economics of general-purpose libraries. Why build on Bootstrap when an agent can generate exactly what you need? A collection of thoughts on where this is all heading.

    The Great Library Unbundling: How AI is Eating the Software Stack

    More than a year ago, I told people that ORMs like Entity Framework were going to feel like relics. That LLMs would just generate the SQL you need, making all that object-relational mapping overhead pointless. A few people told me I was crazy and doing things wrong (and to be honest I wasn't good enough at explaining why I thought this).

    Well, time seems to have been on my side (Wwo is laughing now hahahaha!!).

    Now, this is a hot take, so I will go forward and talk as a hot take. If I put my devil's advocate hat on, I would probably rage against whoever wrote this post. But because I LOVE MYSELF, I won't do it. I certainly see flaws in my arguments. So buckle up—this is not rage bait, it is just a hot take from a Mexican developer who spent the weekend arguing with AI agents instead of sleeping like a normal person.

    The ORM Prediction, or How I Accidentally Became Right About Something

    Here's the thing about ORMs: they exist because writing SQL is supposedly "hard" and "error-prone." Meanwhile, I've been writing raw SQL since my first job at a tiny shop in Tepic where we didn't have the luxury of Entity Framework or Hibernate or whatever fancy abstraction layer the cool kids were using. We just wrote the queries, crossed ourselves, and hit execute. Catholic upbringing has some unexpected engineering applications.

    Now, to be fair—we did end up building our own tailored ORM for the common cases. Because once you've written the same parameterized INSERT fifteen times, even the most stubborn raw-SQL purist starts thinking "maybe I should abstract this." And ORMs do earn their keep in some areas: SQL injection prevention, enforcing parameterized queries, handling connection lifecycle stuff that nobody wants to think about. Security guardrails that your 2 AM brain will absolutely forget to implement on its own. I get it. ORMs aren't stupid—they solved real problems.

    But here's the trap: as soon as you start getting into complex queries, you're no longer just maintaining your application logic—you're also maintaining the ORM and the complex queries. You end up fighting the abstraction to make it do what raw SQL does naturally, and now you have two problems instead of one. The thing that was supposed to simplify your life becomes another layer you have to debug, optimize, and keep in your head at the same time. And whoever has run a high-performance application—like an ecommerce site during Black Friday—knows exactly what I'm talking about. That query you spent weeks trying to optimize through the ORM, doing quirky reflection tricks and fighting with expression trees? You ended up raw-dogging the SQL anyway, because that was the only way to get the performance you needed. The ORM was never going to get you there. It was just standing in the way, politely.

    Now Claude just writes you the exact SQL you need—parameterized, injection-safe, the whole deal. No mapping, no configuration, no surprises. Just the data access pattern you actually want. It's like having a DBA who never sleeps, never complains about schema changes, and doesn't passive-aggressively CC your manager when you write a bad join. The abstraction layer that was supposed to save us from SQL is now the thing standing between us and the AI that's better at SQL than most of us ever were.

    Agentic Development and the Death of One-Size-Fits-None

    This isn't just about ORMs. I've been thinking about how agentic development fundamentally changes the whole premise of general-purpose libraries and building blocks.

    Platform teams across the industry are going to start questioning their investments in broad, one-size-fits-all libraries. And honestly? Good. Because "one-size-fits-all" always meant "fits nobody perfectly but everyone tolerably." Like those beach ponchos they sell at every tourist shop in Nayarit—technically covers you, technically functions, but you look ridiculous and you know it.

    Take CSS frameworks. Bootstrap, Bulma, Fluent UI—they're great for getting started quickly. But you end up learning their specific class naming conventions, carrying tons of CSS you'll never use, fighting against the framework the moment you want something custom, and—my personal favorite—looking like every other Bootstrap site on the internet. Your site ends up with more unused CSS than empty beer bottles after a Sunday carne asada in Nayarit. And that's a lot of bottles, trust me.

    With agentic development? You just tell the agent what you want your UI to look like. It generates exactly the CSS you need. No framework lock-in, no unused code, no learning curve. The agent doesn't need to know Bootstrap's grid system (although it probably was trained on such codebases)—it just writes "vanilla" CSS that does what you asked for. I know this because that's exactly what happened with this blog. The CSS you're looking at right now? Generated. By an agent. Who understood what I wanted better than I understood what I wanted (debatable).

    MCP is Already Feeling Old

    Speaking of things that are aging quickly: the Model Context Protocol. MCP. Remember when everyone was wrapping every CLI tool as an MCP server like it was the new hotness? That was, what, months ago? In AI time that's basically the Paleolithic era.

    Here's the thing—CLI tools already come with perfect documentation in the form of man pages. They're basically documented APIs already. Your agent doesn't need a special protocol wrapper to use gh pr create or az webapp deploy. It just reads the docs, fumbles the first attempt (like any of us), and then figures it out. Combine Claude Code with existing CLI tools—GitHub CLI, Azure CLI, kubectl, whatever—and you've got everything MCP promised, but without the ceremony.

    Microsoft's already doing something interesting with their dotnet/skills repo. Skills that are just prompts guiding the agent through repeatable processes. No protocol, no server, no serialization format drama. Just a well-written prompt. Turns out the best API for an AI agent is just... words. Who knew. (Okay, a lot of people knew. But still.)

    Hugo Drove Me to Build My Own (Again, Because I Never Learn)

    I just finished redoing my entire publishing workflow. Hugo felt limiting and bloated—all these features I'm maintaining, constantly broken by dependency updates, GitHub workflows failing for mysterious reasons. Every time I pushed a new post it was a coin flip whether the build would succeed or I'd spend an hour debugging some Go template issue that made me question my life choices.

    So I rewrote it in .NET. Dead simple. I don't expect anyone else to use it—exclusive distribution, zero units available—but damn, it felt liberating. The CSS and HTML of this blog changed completely, and I actually understand every piece of it now. No more cargo-culting Hugo partials I copied from a theme three years ago and was afraid to touch.

    This is the pattern I keep seeing: when AI can generate exactly what you need, the appeal of heavyweight, general-purpose solutions just evaporates. Like fog burning off in the morning sun in Tepic. One moment it's there, thick and omnipresent, and then it's just... gone.

    The Accountability Problem

    Here's something that's been bugging me. I saw a conversation on the fediverse about more and more tools being created with no clear ownership. Developers suspect some might be entirely AI-generated, with humans just shepherding them into existence like zookeepers who can't actually control the animals.

    That sucks. Humans should be in charge and taking responsibility for the software they put into the world. There's a difference between using AI as a tool and letting AI be the architect while you nod along pretending you reviewed the blueprints.

    When something breaks, when there's a security issue, when users need support—who's accountable? You can't file a bug report against GPT-4. And "the AI did it" is not an incident postmortem. Not yet, anyway. Give it a year (debatable).

    Copilot's Infinite Loop of Self-Criticism

    Speaking of AI quirks: Copilot keeps finding issues in my PRs, I ask it to fix them, it fixes them, and then when I ask it to review again, it finds more issues. In the code it just wrote. In the code. It. Just. Wrote.

    This is like watching someone argue with themselves in the mirror. Except the mirror is burning tokens, the person is burning my budget, and the argument never ends. The AI equivalent of "works on my machine" syndrome, except it doesn't even work on its own machine.

    Blog Posts Are Better Than Repos for Teaching AI

    Here's something that genuinely surprised me. A friend at Microsoft pointed his AI agent to my blog series to implement ActivityPub. Not to a GitHub repo with code samples. Not to the official W3C spec. To my blog posts. The ones I write at 1 AM like a gremlin-raccoon, full of rambling asides and half-baked metaphors.

    Turns out prose explanations with context and reasoning are way more effective for agents than just dumping code at them. Blog posts tell the story of why decisions were made, not just what the final result looks like. The agent needs to understand intent, not just syntax. It needs the narrative—the "I tried this and it broke spectacularly, so I did this other thing instead" part that never makes it into a README.

    So all those years of writing meandering blog posts about my projects instead of writing proper documentation? Turns out I was ahead of my time. Or just lazy. Probably both.

    Where This Is All Heading

    I think we're heading toward a world where general-purpose libraries become luxury items—nice to have, but not essential. Where AI-generated, purpose-built solutions become the norm. Where documentation and prose become more important than code artifacts. And where human accountability becomes the thing that actually differentiates good software from the rest.

    This doesn't mean libraries disappear overnight. But the incentives are shifting. Why build and maintain a framework used by millions when everyone can have their own custom solution?

    The future might be less about sharing code and more about sharing knowledge, context, and decision-making frameworks. Less "here's my npm package" and more "here's the blog post explaining why I built it this way so your agent can do something better."

    Anyway

    This post is a collection of half-formed thoughts and observations. I'm not claiming to have all the answers—hell, I'm not even sure these are the right questions. But something is shifting under our feet, and pretending it isn't doesn't make it stop.

    Are we heading toward a more fragmented, AI-generated software landscape? Or am I just another old developer yelling at algorithmic clouds from a small corner of the internet?

    Honestly, I don't know. But I'd rather be wrong and loud about it than quiet and surprised when the whole toolchain landscape looks unrecognizable in five years.

    Also readable in: https://maho.dev/2026/03/ai-is-making-libraries-obsolete/ by @mapache:

    #AI #Software Development #Libraries #Agentic Development #ORMs #CSS Frameworks #MCP #Developer Tools #Future of Coding #Hot Takes #LLM #Copilot

  3. There is a new Operations Research Discord server at discord.gg/RcUfeV2F. The old OR Discord server is still up, but it no longer has an owner and has been targeted by spam bots, so we are encouraging people in the #orms community to switch to the new server.

  4. some three weeks ago, our #openaccess book on "branch-and-price" got finally published; you can download it for free here: link.springer.com/book/10.1007

    #orms

  5. SCIP #optimization suite 10.0 is out!

    scipopt.org/

    it comes with GCG 4.0.0, PaPILO 3.0.0, SCIP 10.0.0, SoPlex 8.0.0, UG 1.0.0 (no longer beta), and ZIMPL 3.7.0.

    there is a 50+ pages release report optimization-online.org/2025/1

    enjoy!

    HT @svigerske #orms

  6. full professorship in industrial mathematics at RWTH in Aachen

    expected: distinguished expertise and visible research agenda in applied #maths with implementation-oriented industrial relevance

    research topics include [....] optimization!

    more info: berufungsportal.rwth-aachen.de/

    #orms

  7. [new paper] “Political districting to maximize whole counties” coauthored with Maral Shahmizad

    github.com/maralshahmizad/Poli

    We propose a combinatorial Benders decomposition algorithm, solving (nearly) all instances across the USA.

    Our approach provides intuitive optimality proofs suitable for courts/laypeople: at least one county must be split in each enclosed region. #orms

  8. #ORMS #Analytics quietly powers decisions in healthcare, supply chains & beyond... yet is largely invisible to the public. Drawing inspiration from the growth of #ML, we outline 10 key actions to help move this status quo: pubsonline.informs.org/doi/ful
    What else would you suggest?

  9. Jury simulation using SimPy

    In this article we design and build a SimPy simulation model of a jury summoning process The goal is to reduce the number of people summoned for jury service.

    Simulation is often seen as an easy way to model to situation. It is not. This model highlights a key lesson for simulation modelling in general: details matter, sometimes a lot.

    #orms #Python
    solvermax.com/blog/jury-simula

  10. Efficient jury empanelling: Respecting people's time

    This article is inspired by a recent experience of being summoned for jury service. We describe a simulation model of the jury selection process. The goal is to explore how the needs of the justice system can be met while also respecting the time of people who report for jury service. Specifically, we want to see if the number of people summoned can be reduced while ensuring that sufficient people are available for the scheduled trials.

    Jury service is an important civic duty, providing a way for people to directly participate in upholding the law and contribute to their community. But the jury service process, like much of the justice system, is designed around the needs of the system rather than the needs of the people it serves.

    #orms #Python
    solvermax.com/blog/efficient-j

  11. final day of our 2025 school on column generation in Paris #orms

  12. The muffin problem: A slice of recreational maths

    In this article, we solve 'The Muffin Problem' which is a recreational maths puzzle that is simple to state but hard to solve in general.

    The goal of the muffin problem is to divide a number of muffins equally between a number of students, maximizing the size of the smallest piece that any student receives. Some cases are trivial, while some others are easy. But once we have more than a few muffins and/or students, this becomes a difficult problem to solve.

    We use a Mixed Integer Linear Program to solve the problem. Along the way we play with some parallel computing to substantially reduce the run time, and throw in some symmetry-breaking constraints and objective function bounds to help the solver.

    #orms #Python
    solvermax.com/blog/the-muffin-

  13. Pivot irrigators in a 100 acre field

    We formulate a non-linear, non-convex model for optimizing the layout of centre-pivot irrigators in a field. Several free and commercial solvers fail to find good solutions. Then we try the MINLP-BB solver via NEOS using a multi-start technique.
    Can it find an optimal solution?
    #python #orms
    solvermax.com/blog/pivot-irrig

  14. Job opening at TU Graz: Full Professor Position for Computational Discrete Mathematics #orms

    jobs.tugraz.at/en/jobs/dec7b34

  15. Locational marginal pricing of potatoes

    We apply Locational Marginal Pricing (LMP) to the supply of potatoes. The article describes the model, calculation of LMPs, and scenarios for how the suppliers and contractors may respond to the price signals.
    #orms #pyomo
    solvermax.com/blog/locational-

  16. Jacques Desrosiers delivered the sad news that an #orms giant has left us forever:

    François Soumis passed away last night. The depot of this last vehicle tour is in heaven.

  17. Permission granted: A role mining model

    We implement a recently published role mining model using both constraint programming and mixed integer linear programming, then compare their relative performance while solving several examples.
    solvermax.com/blog/permission-
    #orms #pyomo #ortools #python

  18. New item in our list of #orms resources:

    Collection of videos from Associate Professor Alberto Del Pia, University of Wisconsin-Madison.
    There are around 100 videos, collated into playlists relating to specific optimization papers taught at the university.
    solvermax.com/resources/links/

  19. Celebrating the 50th birthday of EURO - the Association of European Operational Research Societies. #orms

  20. The Association of European Operational Research Societies (EURO) celebrates its 50th birthday today! #orms #ORawarenessDay #EURO50thbday

    buff.ly/40w6fQu

  21. Article: Can AI code an entire optimization model?

    In this article we pursue an ambitious goal: Create an entire, non-trivial optimization model using Artificial Intelligence (AI).

    Our approach mimics a user who is familiar with the situation, and has some experience with formulating optimization models, but is not familiar with implementing an optimization model in Python code. We want the AI to do all the coding for us.

    We report our experience of using Copilot to write a model for us. Rather than presenting a verbatim transcript, which is very long, we focus on what went well and what didn't go well as the model evolves. We also summarize general lessons from the process.

    solvermax.com/blog/can-ai-code

    #copilot #Python #orms #optimization #modelling #highs

  22. Article: Objectives matter: Sorting using a MIP model

    We replicate a model by Erwin Kalvelagen at Yet Another Math Programming Consultant (YAMPC), "Sorting using a MIP model".

    In this article, we assess the impact of using an alternative objective function in the same model. The idea is to give the HiGHS solver greater traction while working through the solution space, hopefully helping it to solve the model faster. We've found this technique to be useful for some other models – will it help in this situation?

    solvermax.com/blog/objectives-
    #Python #orms #optimization #modelling #CPLEX #highs

  23. Article: Gerrymandering made easy

    In this article, we take a simple approach to modifying a redistricting design. We add a requirement to our model that could be interpreted as either:

    - The laudable goal of grouping together "communities of interest" – a common requirement when designing voting districts; or
    - A nefarious attempt to manipulate the electoral outcome by gerrymandering.

    Gerrymandering is the opposite of the model's purpose in our previous article. But, as model designers, we need to be aware that we don't always control the purposes to which decision makers apply our models and decision makers don't always understand the implications of small changes to a model.

    solvermax.com/blog/gerrymander
    #Python #orms #optimization #modelling #gurobi #highs
    @AustinLBuchanan

  24. Article: Academics, please publish your data and code

    Academic research papers can be a valuable source of material for creating and improving real world optimization models. But we wish that academics would publish working code and data to accompany their papers.

    In this article:
    - Firstly, we briefly look at some reasons why academics might be reluctant to publish their data and code.
    - Then we replicate, modify, and explore a published model that has been done well, with the data and program code publicly available.

    solvermax.com/blog/academics-p
    #Python #orms #optimization #modelling #gurobi #highs
    @AustinLBuchanan

  25. Article: Well, that escalated quickly: Pyomo

    We conclude our series of articles to decide the best order for positioning devices in a rack.

    This article discusses Model 5, which formulates the situation in Pyomo as a Mixed Integer Linear Program (MILP). We solve the model using a single instance of Gurobi and parallel instances of the HiGHS solver.

    Does this model perform better than the previous methods?

    solvermax.com/blog/well-that-e
    #Python #orms #optimization #modelling #gurobi #highs

  26. Article: 10 times faster, running cases in parallel

    In this article, we explore running optimization model cases in parallel. Specifically, we use the Python multiprocessing and mpi4py libraries to fully use the many CPU cores/threads in modern computers.

    Our goals are to:
    - Illustrate how to apply the multiprocessing and mpi4py libraries to running optimization model cases in parallel.
    - Measure the performance of running cases in parallel compared with serially.
    - Compare the performance of an old 4 core / 4 thread CPU with a new 20 core / 28 thread CPU, using the HiGHS solver.

    solvermax.com/blog/10-times-fa
    #Python #pyomo #orms #optimization #modelling #HiGHS #multiprocessing #mpi4py

  27. Warehouse space for free: Exogenous enumeration

    In this article series, we look at improving the efficiency of a pallet warehouse, where all items are stored on standard-size pallets.

    In part 3 of 3, we make some variables exogenous and enumerate all of their combinations. The goal is to make the model solvable at full scale in a reasonable time.

    The result is a 200 times improvement in model performance, leading to a 40% improvement in warehouse storage efficiency.

    The model is built in Python using Pyomo, and solved with either the Gurobi or HiGHS solvers.

    solvermax.com/blog/warehouse-s
    #Python #pyomo #orms #optimization #modelling #Gurobi #HiGHS

  28. Warehouse space for free: Linearized model

    In this article series, we look at improving the efficiency of a pallet warehouse, where all items are stored on standard-size pallets.

    In part 2 we linearize our model to, hopefully, make it easier to solve.

    The model is built in Python using Pyomo.

    solvermax.com/blog/warehouse-s
    #Python #pyomo #orms #optimization #modelling #Gurobi #HiGHS

  29. 2023 was a very positive year regarding my Julia endeavours. In short, I gave 4 talks, I started doing more general Julia videos in English, and I started working a lot more with Julia at my current job. I give more details in this post: abelsiqueira.com/blog/2024-01-

    2024 will also be a great year for Julia, but more on that later.

    #JuliaLang #JuliaProgramming #Julia #talk #optimization #mathematicalmodeling #orms

  30. Lately I have been working with an energy model over a graph, and it motivated me to create a new mathematical modeling video.

    It is a much simpler video about a very traditional network flows problem, the maximum flow: youtu.be/AtfuShpbWEQ

    Maybe we'll get to energy models in future videos?

    The video also serves as a brief introduction to Graphs.jl, and how to use it in conjunction with JuMP.jl. Many more fun things can be done with this combination, so let me know in the comments if you're interested in that.

    #JuliaLang #JuMP #Graphs #MaximumFlow #ORMS #NetworkFlows #MathematicalModeling #Optimization #Pluto

  31. Javier is back, now including the demand for his art in the production planning. Sorry for the long video, I hope it will at least be watched by the #Julia enthusiasts or the #orms people out there. Maybe #microeconomics people will enjoy it too. Once more I use #pluto and #jump.

    When planning the production, in our last video, we ignored the demand for the products. In this video, we will evaluate two strategies to include the demand into the model.
    The first strategy is to have a sale of excess products. In this case, we have a piecewise revenue function, and we use some modeling tricks to model it into a mixed-integer linear program.
    The second strategy is to consider the price at which we sell things to be a decision variable as well and to model the demand as a function that depends on the price linearly. This case leads to a very interesting conclusion about the nature of demand satisfaction.

    youtu.be/0HRAYGYrkIc

    You check a blog post and other links at abelsiqueira.com/youtube

    #mathematicalmodeling #mip #optimization

  32. In Brazil, when we got overwhelmed with our studies, we would say that we were thinking about dropping out and selling art on the beach.
    Well, if you did that, could you optimize your art production?

    Check out how to model and solve that using #JuliaLang and #JuMP: youtu.be/IOUi1juD5HQ

    You can find the #PlutoJL notebook for this code at abelsiqueira.com/youtube.

    #Julia #orms #optimization #mathematicalprogramming #MathematicalModeling