paddy_m

When I deal with datascience, I rarely have type problems in my programs that python typecheckers can't catch. I do have type and dirty data problems of the dataframes/csvs/parquet I'm reading.

Car manufacturers watch the cost of every piece of the bill of materials. Cars compete on price, and the assortment of pieces which add perceived value to consumers. Outside of performance and very highend luxury cars, tires are an afterthought to the average car buyer.

I have written a couple of eval harnesses to see how well LLMs drive software I have written. Basically I have data analysis software that I need LLMs to write code for. The code is complex, and I want to shape my APIs such that LLMs do a better job of quickly getting to the right answer. So I test different prompting and api surfaces, it's really easy to make quick gains this way and save your users from bugs. In this paradigm, I'm explicitly not testing different models, and I'm very interested to see how lesser models do with my software. Also for this type of testing, using the open weight models makes it faster, cheaper, and more reliable to test vs frontier models because I can trust that kimi-2.5-a-bunch-of-specs is going to behave more consistently than whatever tweaks Claude is making to Sonnet this week. API and prompting improvements seem to carry across the different models for gross improvements.

I haven't looked that hard, but I can't find articles about this type of eval testing, curious to hear if others have approached writing APIs in this way.

I'm as anti-car and pro-bike as they come. Cars and trucks are a much bigger danger than e-bikes...

But California's clear tiers of ebike regulations are meaningless without enforcement. Over the past half decade blue states have become unwilling to enforce almost any laws. when they do enforce the laws it is sporadically. This matters for ebikes, it matters more for cars. Running a stop sign is absolutely not enforced any more.

is webkitgtk different than the engine used in safari?

Location: Boston Remote: Yes Relocate: Yes Technologies: Python, Pandas/Polars, NumPy, Jupyter, JS/TS, React Résumé: linkedin.com/in/paddymullen Email: [email protected]

Python/Jupyter developer in Boston. I build data tools and I start by talking to the people who'll use them, because code that doesn't get adopted is wasted work. My main thing is Buckaroo (github.com/paddymul/buckaroo, ~680 stars), an open-source data table for Jupyter over Pandas/Polars. I built both the data layer and the React frontend. Looking for a team building data tooling (as a product or in house).

Mr. President, we must not allow a mine-shaft gap!

I think another factor is that people are rejecting the rounded corners and excessive padding of modern web design, you can't do that in a TUI, so you don't have a designer or standard practice encouraging you to do it. As implemented TUIs have greater information density than GUIs. Make no mistake though, TUIs are a decided step backwards from GUIs. Everything that you can express via text, you can also do in a text area on a GUI app.

I'd be really interested to see SGI on this chart. When did consumer hardware exceed what you could do on an SGI box?

I think Sun and HP had some 3d capabilities, but it was mostly aimed at engineering/CAD