I understand what they are trying to do, but to me it feels like the moment when MongoDB entered the database space, with semi-structured, "flexible" storage format. It has its uses, for prototyping mostly.
But in high-volume, production workloads, giving a structure to the data you extract (what Parseur does through defining the Fields in your Mailbox, basically giving your output data a schema) adds a ton of value, and the larger the dataset, the truer it is.
Usually, you start by defining where you want your data to go, and which structure it should have, before working backwards from here and starting to extract the data. This is the key to automating your document workflow.
Hey, good point about structure for integrated workflows:)
Fully agree, for enterprises we need to guarantee types, flag discrepancies and provide underlying sources so they can integrate it downstream (whether that's Databricks, n8n etc.)
There is no mention of the amount of fuel used to transport the fuel in the article. From what I know it’s a tiny fraction: boats are efficient at transporting stuff (slowly)
> Fossil fuels are roughly 40% of maritime tonnage, but in the model they represent about half of maritime freight energy because coal, oil, and gas are mostly long-haul bulk trades. Moving a ton of scrap metal a short distance and moving a ton of oil or LNG across oceans are not the same transport-energy problem, even if both show up as one ton in a cargo table.
as being exactly what was being talked about... more fuel is spent on transporting fuel due to distance it travels.
but your comment made me re-visit (i.e. more closely skim...) the article, and it's really about: "as the demand for fossil fuels is projected to decrease, (1) less long-haul shipping is needed and (2) a greater fraction of shipping will be short-haul, which will be practical for other types of freight fueling (i.e. what's shown in the figure at the top of the article)
I have no sense of how realistic the figure is. For example, I don't know the current projections for decline of fossil fuel demand over ?? year timeframe.
It happens for every single Anthropic release. Then I try it on real dev and the result is laughably bad. Except in design where it has been doing a decent job for a while. I am not a designer and my bar is pretty low.
I don't know; I am not sure I'm marketable in THIS particular market.
As for FastAPI bring a mistake - that's an overgeneralisation to be sure. It has it's uses.
My first issue is that it falls into the same kind of small footprint as Flask. Every Flask project I work on slowly reinvents Django via a combination of plugins of varied quality and custom code/plugins. Get some Auth plugins, build step for manifest static files, add in Jinja2, grab an ORM like SQLAlchemy (or hopefully PeeWee), a migration system, test runners with fixtures/dB integration and rollback and on and on and on.
FastAPI is operating more at that level but also adds the often unnecessary complexity of async. In Python this is a cooperative setup meaning you have to yield to the event loop yourself (otherwise despite being "async" it blocks). Plus with a webapp all async often does is let you hammer your services (i.e. dispatch more queries to your poor DB) harder. The actual performance improvements don't manifest so much at scale as people often think. Plus you end up with a whole second set of ways to call functions and... makes me pine for gevent.
There are absolutely cases for this kind of async, even in webapps, but it's often not actually that helpful in places that it's used (and doesn't actually need to be everywhere). Good development imo means picking the right tool for the job rather than jumping on hype trains.
Thank you for this answer, it saved me hours of experimenting.
And bonus points for bashing MongoDB, of course. Every single project that I worked on where MongoDB was used, also had MongoDB as the single largest constraint and operations time sink.
Are you building the site from the same json files that are used in the game?
AIs are still computer programs and are not given the resources to render javascript, so they cannot access the game data from the website. And they obviously don't have it in their parameters.
BTW Google Gemini Pro just told me that they know the game but did not know the value.
Actually, it points out that it is a known trap for AI to confidently give a wrong, hallucinated value. Maybe it had already seen this thread and integrated it in their parameters or fine tuning.
I don't know...
Gemini Fast confidently gives me a wrong value. But very quickly!
I'll attach the entire Gemini response as a sub-reply.
The json thing is what makes it particularly surprising.
It’s literally ’gameconstants.js’ with an item list that has a .name string and a .armor value that it could look up. But when I pointed it to the file and told it which row to read from, still chose to make something up instead of read the data designed to be read by computers.
I do like how your ai tries to cover for its buddies with lies about there not being any documentation online. Because pointing AIs to a specific page and asking them to read the numbers there is a known trap.
That just moves the question to how they figured out the genetic sex determination system of eels, or even how they figured out that sex is genetically determined in eels (and is it? many vertebrates don't have genetically determined sex).
After falling in love and hacking away with Claude for a few weeks, I'm now in the hangover phase, and barely using any AI at all.
AI works well to build boilerplate code and solve easy problems, while confidently driving full-speed into the wall as soon as complexity increases.
I also noticed that it makes me subtly lazier and dumber. I started thinking like a manager, at a higher-level, believing I could ignore the details. It turns out I cannot, and details came back to bite me quickly.
So, no AI for me right now, but I'm keeping an eye out for the next gens.
reply