Alcides Fonseca

A equipa da Amália disponibilizou o seu modelo no HuggingFace, uma plataforma de partilha de modelos para se usar em casa, pelos mais aptos tecnològicamente.
O nosso primeiro-ministro indicou que esta versão ainda não responderia a perguntas, mas isto não é 100% verdade. Este modelo responde a perguntas, desde que cada um instale no seu computador. O estado neste momento não disponibiliza servidores para correr o modelo pelos portugueses.

Se for alguém mais familiarizado com linhas de comando, poderá simplesmente correr (graças ao Duarte Carmo) o seguinte comando:

llama cli -hf duarteocarmo/AMALIA-9B-0626-SFT-GGUF:Q4_K_M

Neste momento, pelo menos duas pessoas disponibilizaram um servidor que corre o modelo: temos a Amália do Duarte Carmo e a Amália do Henrique Macedo, ambas prontas a responder às vossas perguntas.

Mas mais uma vez, um político criticou o modelo por não estar a par das actualidades

Todos os modelos, sejam os Claudes ou GPTs, são treinados com dados até uma determinada data. Só conseguem responder com informação mais actualizada quando são treinados com a capacidade de recorrer a ferramentas externas (o famoso RAG).

Para dar esta funcionalidade ao Amália, eu — ou o Cursor, que programou esta funcionalidade por mim — criei um servidor intermédio, que recebe os pedidos do utilizador, e os envia à Amália, acrescentado alguns dados ao pedido: a data e hora actual, e a disponibilização de um serviço de procura.

Se a Amália decidir que precisa de algo, responde ao agente intermediário que precisa da informação X. O agente intermédio procura e volta a fazer o pedido à Amália, desta vez com o resultado da procura online. Assim que a Amália decidir que não precisa de mais procuras, a resposta é enviada ao utilizador final.

Este é o poder do RAG e, das minhas poucas experiências, parece que a Amália está bem preparada para ele.

I have been trying to debug why Claude (and Cursor) often skips running “git pre-commit hooks”, despite being in the Claude.md. I have to remind it every prompt, and even then it fails to run them. They only show up in CI, failing immediately (without running the test-suite). Now, this is also happening to the Dragonboat team and I know it’s not a me-problem.

One of the things that I changed during this debugging was to make each agent clone their own repo — our repos are quite small — and I’ve kept up with this practice, as there is no real advantage for me in keeping a centralized local repo. In fact, this way I am sure they don’t change the centralized database, potentially interfering with each other. In fact, I had some issues where agents would reuse branches, mixing different PRs together.

But worktrees have some significant limitations. Not least of which is that their dependence on hardcoded fully-qualified paths written into configuration files not only makes worktrees non-portable, but also makes them DOA for any kind of containerized development environment. The worktree.useRelativePaths option helps here, but as of this writing it’s still relatively brand-new (Git v2.48 released Q1 2025), and not available in the version of git you probably have installed on your host machine or any of your container images. On top of that, VSCode’s support for relative worktrees with devcontainers is experimental, totally undocumented, and (as of this writing) unreliable at best.

— Avdi Grimm in You probably don’t need git worktrees

I wasn’t aware of all of those disadvantages, but it is so easy and fast to clone a new version. And even if you want to work offline, you can just clone from another local repo, like I did in 2007 when there was no wifi on campus.

Now if you have a multi-gigabyte repo, you might think twice about skipping worktrees. But then you have bigger problems to worry about.

There are a few people I recommend following to understand what is going on with software development:

• Martin Fowler is probably my best reference in software engineering, both from the low-level Design Patterns point of view (where he made his fame), to more processes oriented and the more recent AI impact on the development processes. Even academics would agree with me on this one.
• James Governor (Redmonk) do a more industry-wide macro view of the software development trends. They advise big companies on what route to take, and they estimate the money involved in these new trends. I would hire them if I was running a SaaS or devtools-focused VC. I met James last year at LisbonAI, and there is a large contrast between his wacky style and the sobriety of his writing.
• Simon Willisson has been the new person in terms of AI development. I follow Simon since before Django had a 1.0 release, and he has become the reference in terms of AI development. He even has a paid newsletter with less content. Simon focus more on the exploratory side, and less on the engineering side, although he has started to document agents design patterns.

The fourth spot on my Mount Rushmore is up for debate. Tim Bray would blog a lot about the organizational side of things, but has now retired from that. I used to love the writing of Steve Yegge, but I think he has drank too much of his own cool aid.

The new kid on the block for me is Mitchell Hashimoto. He has the technical background — Vagrant, Terraform and Ghostty — and he does not mind sharing his path.

Specifically, I think two of his recent blog posts were what every developer needs to read:

Historically, the effort required to understand a codebase, implement a change, and submit that change for review was high enough that it naturally filtered out many low quality contributions from unqualified people. For over 20 years of my life, this was enough for my projects as well as enough for most others.

Unfortunately, the landscape has changed particularly with the advent of AI tools that allow people to trivially create plausible-looking but extremely low-quality contributions with little to no true understanding. Contributors can no longer be trusted based on the minimal barrier to entry to simply submit a change.

— Vouch, an open source tool to explicitly keep track of trust in open source repos.

Agents will more readily pick open and free software over closed and commercial. At the time of writing this article, this is an objective truth. Independent research labs running experiments on popular models have found repeatedly that under diverse circumstances, models pick open and free alternatives over commercial. So far.

— The Building Block Economy, which gives you a new perspective on the impact of LLMs on the software development economy and tooling.

Last night, while I was catching up on email, I wanted to make use of my time and our Claude subscription. I decided to scratch an old itch.

Our aeon programming language has Liquid Types (e.g., {x:int | x > 0}) and we rely on an SMT solver to type check the implications of subtyping (e.g., when passing something of type {x:int | x > 3} to a function that accepts {x:int | x > 0}, we need to verify whether x > 3 -> x > 0, for all x).

But there was an issue: aeon is written in Python and relies on the z3 bindings that contain C++ code. We can run Python code in the browser with Pyodide, but the native libraries are not directly supported (at least this one, that relies on multi-threading).

On the other hand, there is a z3 port to web assembly (by alectryon’s Clément Pit-Claudel, no less) but it follows the C API, and has no browser-Python bindings.

So while I went through the ivory tower tall pile of emails, Claude reimplemented the z3 bindings in a different package, used the export to SMT-lib format feature, already present in z3, and passed that to the z3-wasm package.

I asked for examples, and piping the errors I found in the browser back to Claude, I gave up on being a middle man, and instructed Claude to use Rodney to interact with the browser directly (I was running this on a linux server, not my local machine). It then went ahead and made the examples work on Chrome, in a nice demo page. Unfortunately, it did not work on Safari due to the lack of stack switching support in web assembly, so I needed to make another prompt to fix that issue. It deployed to GitHub and Pipit automatically, with little effort.

Of course you get what you paid for: I provide no assurance that there are no bugs. But it’s useful enough for me to prepare some demos and materials for students that do not require any installation or compilation in their machines. That’s a win in my book.

And now, you have support for z3 in Python within the browser for your existing z3 Python projects, or just to play with z3 because the Python bindings are by far the most easy to just play with.

via Aws Albarghouthi

So Feyman did the 15 competing standards joke before xkcd. And apparently, he did some ocasional industrial consulting.

There is no longer a curl bug-bounty program. It officially stops on January 31, 2026. […] Starting 2025, the confirmed-rate plummeted to below 5%. Not even one in twenty was real. The never-ending slop submissions take a serious mental toll to manage and sometimes also a long time to debunk. Time and energy that is completely wasted while also hampering our will to live.

— The end of the curl bug bounty by Daniel Stenberg

Early last year I defended that the internet needed to stop being anonymous, so that we can live among LLM-generated content. The end of the curl bug bounty program is another piece of evidence — if we cannot tie submissions to real-people, tracking their reputation and eventually blocking them from trying a second or third time.

PGP was probably a solution behind its time. On the other hand, maybe we were lucky of what we achieved with anonymous developers working together on the internet.

• Declare variables at the smallest possible scope, and minimize the number of variables in scope, to reduce the probability that variables are misused.

• There’s a sharp discontinuity between a function fitting on a screen, and having to scroll to see how long it is. For this physical reason we enforce a hard limit of 70 lines per function. Art is born of constraints. There are many ways to cut a wall of code into chunks of 70 lines, but only a few splits will feel right.

— TigerBeetle codestyle

I remember when getting into Haskell, back in 2010: “If your function has more than 4 lines, it is wrong”. For me, that is more meaningful than the 80 character limit. Soft-wrap exists to adapt lines of any length to your own screen. However, managing the complexity of functions and code-blocks is way more important in my book.

I know you have larger functions in Haskell (especially with monads), but keeping functions within 4 lines makes it an interesting trade-off between badly-named functions and the complexity of each function.

I know when to break this rule, as do most senior programmers. However, junior programmers lack the sensitivity to make such decision. I love having a rule-of-thumb for newcomers who are not familiar with the ecosystem or programming in general.

Btw, the rest of the style guide is quite good! Except for the number of columns thing.

How do you acquire the fundamental computer skills to hack on a complex systems project like OCaml? What’s missing and how do you go about bridging the gap?

— KC Sivaramakrishnan

KC gives several resources for students to get up to speed with contributing to OCaml.

One of the interesting resources is MIT’s the Missing Semester. This semester I created our own version of this course, covering git, docker, VMs, terminal/bash, testing, static analysis and LLMs for code.

While we cover how to do a Pull Request, I don’t believe students are ready to actually contribute. Reading large codebases is a skill that even our graduate MSc students don’t have. Courses are designed to be contained, with projects that need to be graded with few human effort, resulting in standard assignments for all the students.

I would love to run something like the Fix a real-world bug course Nuno Lopes runs. But being able to review so many PRs is a bottleneck in a regular course.

I use Hacker News as a tech and economy news feed, but I don’t necessarily comment or upvote a lot.

Just like Youtube or Spotify’s wrapped (I personally use Last.FM), there is this fun HN wrapped that was done with a tongue-in-cheek style that I particularly love.

As software engineers we don’t just crank out code—in fact these days you could argue that’s what the LLMs are for. We need to deliver code that works—and we need to include proof that it works as well. Not doing that directly shifts the burden of the actual work to whoever is expected to review our code.

Simon defends that engineers should provide evidence of things working when pushing PRs onto other projects. I recently had random students from other countries pushing PRs onto my repos. However, I spent too much time reviewing and making sure it worked. I 100% agree with Simon on this, but I feel the blog post is a bit pessimistic in the sense that software engineers might only be verifiers of correctness.

Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it.

This is my experience for user-facing software. But these days, I spend little time writing user-facing code other than compiler flags.

Why do I run Prometheus on my own machines if I don’t recommend that you do so? I run it because I already know Prometheus (and Grafana)[…]
This has a flipside, where you use a tool because you know it even if there might be a significantly better option, one that would actually be easier overall even accounting for needing to learn the new option and build up the environment around it. What we could call “familiarity-driven design” is a thing, and it can even be a confining thing, one where you shape your problems to conform to the tools you already know.

— Chris Siebenmann

I do exactly the same thing. There is so much technology in my life that I need to reduce the number of tools, languages and frameworks that I use.

Very basic hello world app hosted under gunicorn (just returning the string “hello world”, so hopefully this is measuring the framework time). Siege set to do 10k requests, 25 concurrency, running that twice so that they each have a chance to “warm up”, the second round (warmed up) results give me:

• pypy : 8127.44 trans/sec
• cpython: 4512.64 trans/sec
  So it seems like there’s definitely things that pypy’s JIT can do to speed up the Flask underpinnings.

— Twirrim on HN

I had no idea Pypy could improve webapps this much. I really ought to give it a try speeding GeneticEngine again. Guilherme suggested it originally, but there was some C-binding issues at the time. Will report back.

Simon Willisson’s 10 years of Django presentation

I remember using Django back in 2010. There were a few problems with it:

• Deployment: you could not just upload files like with PHP, you had to rely on some cgi-bin magic (fastcgi was introduced later, if I am not mistaken), making me buy my own VPS for the first time, which I still use to run this website, now deployed using Phusion Passenger.
• Versioning: There was no stable version. Each project I started, I ended up following the official recommendation: use the trunk version! For the young developers out there, trunk is SVN’s main branch. So there was no stable version I could use, or keep all my websites on the same version and every 6-or-so months upgrade all of them.

And that’s it. Everything else was awesome: nice templating system, URL scheme, MVC (MTV in their style) pattern, image uploads, etc. The one thing missing for large-scale applications was migrations (the main thing Ruby on Rails had and Django didn’t). But that did not stop me. Migrations were done manually in the shell. For a one-man job, it worked perfectly.

Besides this website, I build a project management tool for jeKnowledge (a junior company I founded back in 2011), an App Store for a touch screen wall, a Python blog aggregator and a few other pet projects. Later, I would end working on a startup for tennis match-making as well as on a web application for automating genomics testing, all in Django.

Visualization is essential to explaining algorithms. Sam Rose did an excellent job with visualization of Reservoir Sampling, an algorithm to sample with equal probability when you do not know the size. He also shows how this can be applied to log collection.

In 2010 Carmen Reinhart and Kenneth Rogoff published Growth in a Time of Debt. It’s arguably one of the most influential economics papers of the decade, convincing the IMF to push austerity measures in the European debt crisis. It was a very, very big deal.
In 2013 they shared their code with another team, who quickly found a bug. Once corrected, the results disappeared.
Greece took on austerity because of a software bug. That’s pretty fucked up.

— How do we trust our science code? by Hillel Wayne

As more and more scientific publications are dependent on code, trusting code is more and more needed. Hillel asks for solutions, I propose to tackle the problem in two fronts.

1 – More engineering resources

Writing production-level quality software requires larger resources (usually engineerings, but also some tooling). Most scientific software is written once and read never. Some PhD or MSc student writes a prototype, shows the plots to their advisors who write (some or most of) the paper. It’s rare for senior researchers to inspect other people’s code. In fact, I doubt any of them (except if they teach software engineering principles) has had any training in code inspection.

We need research labs to hire (and maintain) scientific software engineering teams. For that to happen, funding has to be more stable. We cannot rely on project funding that may or may not be awarded. We need stable funding for institutions so they can maintain this team and resources.

2 – More reproducibility

Artifact Evaluation Committees are a good addition to computer science conferences. Mostly comprised of students (who have the energy to debug!), they run the artifacts and verify whether the results of the run justify the results presented in the paper. Having done that myself in the past, it is very tricky to find bugs in that process. Mostly we verify whether it will run outside of your machine, but not whether it is rightly implemented.

What would help is to fund reproduction of science. Set 50% of the agency funding for reproducibility. Labs that get these projects should spend less than the original project to reproduce the results (and most of the challenging decisions are already made). In this approach, we will have less new research, but more robust one.

Given how most of the CS papers are garbage (including mine), I welcome this change. We need more in-depth strong papers that move the needle, and less bullshit papers that are just published for the brownie points.

Overall we need better scientific policies with the right incentives for trustworthy science. I wonder who will take this challenge on…

Take python magic methods and add LLM code generation. That’s Gremlin, which no one should use.

However, I would certainly use this (if the output had a different mark, like color in my interpreter) for debugging code.

from gremllm import Gremllm

counter = Gremllm(“counter”)
counter.value = 5
counter.increment()
print(counter.value) # 6?
print(counter.to_roman_numerals()) # VI?

Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project.

A web browser engine is built to run in hostile execution environments, so all code must take into account potential security issues. Contributors play a large role in considering these issues when creating contributions, something that we cannot trust an AI tool to do.

— Contributing to Servo (via Simon Willison)

Critical projects should be more explicit about their policies. If I had a critical piece of software, I would do the same choice, for safety. The advantage of LLMs are not that huge to be worth the risk.

This tradition started back when I was a student. I installed random software for each of the 5 courses I took every semester. I ended up with wasted disk space, random OS configurations and always a complete mess in my $PATH.

So I started formatting my Macs at the end of every semester. And I continue doing that today. Being a professor, I also deal with the software baggage every same semester — otherwise I would probably format it every year.

Most of the people I know think this is insane! Because they spend days in this chore, they avoid it as much as possible, often delaying it so much that they end up buying a new computer before considering formatting. And they also delay buying a new computer for the same reason.

My trick is simple: I automate the process as much as possible, such that it takes ~20 minutes now to format and install everything, and another 2 hours to copy all data and login into the necessary accounts. And you can watch a TV Show while doing it.

I keep a repository with all my dot file configurations, which also contains scripts to soft link all my configurations (usually located at $HOME/Code/Support/applebin) to their expected location ($HOME). This process also includes a .bash_local or .zsh_local where I introduce machine or instance-specific details that I don’t mind losing when I format it in 6 months. Long-lasting configurations go in the repo.

If the machine runs macOS, I also run a script that sets a bunch of defaults (dock preferences, Safari options, you name it) that avoid me going through all settings windows and configuring it the way I like it.

But the most useful file is my Brewfile, that contains all the apps and command-line utilities I use. I should write another usesthis, where I go through all the apps I have installed, and why.

My process starts with copying my home directory to an external hard-drive (for restoring speeds). During this process I usually clean up my Downloads and Desktop folders, which act as more durable /tmp folders. When it’s done, I reset my MacBook to a new state. I then install homebrew and Xcode command line utilities (for git), I clone my repo and run the setup script. At the same time, I start copying back all my documents from the external drive back to my Mac. Then it’s time to do something else.

Two hours later, I can open the newly installed apps and login or enter registration keys, and make sure everything is working fine.

Now I’m ready for the next semester!

Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we’re undertaking this more as a port that maintains the existing behavior and critical optimizations we’ve built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

— Ryan Cavanaugh, on why TypeScript chose to rewrite in Go, not Rust (via Simon Willison)