barishnamazov

> "I don't need to care about privacy because I have nothing to hide." is an argument that I have heard countless times. I found this argument difficult to counter in the past, yet deep-down I knew the reasoning was flawed.

This one is pretty easy to counter. Just ask the person to hand you their phone and go through their messages and photos. There's no one that wouldn't feel restless about it.

Thanks for sharing! I have been dreaming of writing (or better yet, finding!) a similar book for a couple years now. A hands-on guide that peels back the layers of abstraction to teach how things actually work under the hood by building them yourself. I hope one of us gets to it one day :-)

The "lies" described here are essentially the definition of weakly typed programming, even in statically typed languages.

Functional languages like ML/Haskell/Lisp dialects has no lies built in for decades, and it's good to see the mainstream programming (Java, TS, C++, etc.) to catch up as well.

There are also cute benefits of having strong schemas for your API as well -- for example, that endpoint becomes an MCP for LLMs automatically.

Happy New Year from Azerbaijan!

Don't want to be "that guy," but Euler's constant and Catalan's constant aren't proven to be transcendental yet.

For context, a number is transcendental if it's not the root of any non-zero polynomial with rational coefficients. Essentially, it means the number cannot be constructed using a finite combination of integers and standard algebraic operations (addition, subtraction, multiplication, division, and integer roots). sqrt(2) is irrational but algebraic (it solves x^2 - 2 = 0); pi is transcendental.

The reason we haven't been able to prove this for constants like Euler-Mascheroni (gamma) is that we currently lack the tools to even prove they are irrational. With numbers like e or pi, we found infinite series or continued fraction representations that allowed us to prove they cannot be expressed as a ratio of two integers.

With gamma, we have no such "hook." It appears in many places (harmonics, gamma function derivatives), but we haven't found a relationship that forces a contradiction if we assume it is algebraic. For all we know right now, gamma could technically be a rational fraction with a denominator larger than the number of atoms in the universe, though most mathematicians would bet the house against it.

Law 20 seems to express the state of most startups these days:

> "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."

I like that this relies on generating SQL rather than just being a black-box chat bot. It feels like the right way to use LLMs for research: as a translator from natural language to a rigid query language, rather than as the database itself. Very cool project!

Hopefully your API doesn't get exploited and you are doing timeouts/sandboxing -- it'd be easy to do a massive join on this.

I also have a question mostly stemming from me being not knowledgeable in the area -- have you noticed any semantic bleeding when research is done between your datasets? e.g., "optimization" probably means different things under ArXiv, LessWrong, and HN. Wondering if vector searches account for this given a more specific question.

I have worked in monorepos for large codebases. In those, file trees are completely useless because you can't fit the repo layout to your mind. Also, the file trees are so large that when I'd ask a coworker using VSCode to open a file, they'd usually take a few seconds trying to locate it (on remote ssh, it even takes a bit to load files to expand directory as well).

For smaller code bases, I usually read the repo first and I'm able to learn what exists while working through it.

Neat! Does it also preview files when doing fuzzy file or symbol search?

C++ (clangd) and Python (pyright and ruff). But I think the excessive memory usage came from huge number of files in the code base, plus some really large files (given I ran LSP on neovim too with much smaller footprints).

That exists, though it doesn't have a preview of the file. Also, jump lists to quickly take a look and ctrl+o to go back is a huge game changer for me. Not sure if VSCode supports that now, haven't used it in a long time.

In my previous work, a few folks in my team used VSCode on a shared dev box. The box has 1TB memory, and we'd frequently OOM due to vscode servers taking up tens of GBs of memory (which adds up quickly when there are multiple vscode windows per person). Sometimes it'd eat as big as 100GB until it had to be restarted. Sure, big codebases, but that's just straight unacceptable.

For me, the friction of VS Code is more cognitive than computational. I call it the "searching with your eyes" [0] problem. To make it clear, I've no problems with VSCode but haven't used it in a long time -- maybe it has added some keyboard-only features that makes workflow smoother.

VS Code's heavy reliance on the file explorer tree forces you to constantly visually scan nested directories to navigate. When I switched to Neovim (with Telescope/jump lists), I moved from visual scanning to mental mapping. I don't look for where a file is; I type what the file is. It sounds subtle, but removing that micro-latency of "eye-to-mouse-to-tree" keeps you in the flow state much longer.

[0] https://barish.me/blog/stop-searching-with-your-eyes/

That's amazing. Wishing you well, and thank you for all your contributions!

username doesn't check out

You probably mean, 99% of anyone older than 25.

I am a gen-z and most of my peers look at me weird when I express the same. It was once cool to have social media and presence -- I was only 8 when I made a facebook account. But now, things are different. I actively avoid social media and don't like to show myself online anywhere other than my personal website.

The author missed the mark on the financial barriers to entry. He predicted that the shift from text to broadband/multimedia would make politics "more expensive" and raise entry barriers because video is costly to produce.

In reality, the cost of video production dropped to near-zero (smartphones, TikTok, YouTube). However, he was right about the outcome. The "entry barrier" isn't the cost of the camera, it's the cost of the algorithmic optimization and the "strategies to draw attention" in an information glut. The rich didn't win because video is expensive; they won because virality is gameable with resources. Credits where due, he indeed called out this potential for "international manipulation of domestic politics" well before the major scandals of the 2016 era.

And that's without a way to disable this without using a custom Link component. I noticed that with only 2 users (testing stage), my website had ~3-4k daily requests. After a bit of digging, I found out that every visible link on the webpage did two tiny server requests (totaling <5kb) -- one for metadata, and one for some javascript -- and it only happens on production, not locally.

This probably makes a lot of money for Vercel and Cloudflare.

I'd like to share Shoelace [0], a library of nice web components I used long ago for some websites. It's now part of Web Awesome (a company behind Font Awesome), though it seems like the original author, Cory, is still working on it.

[0] https://shoelace.style/

No offense taken, but realize that good number of us folks who have learned English as a second language have been taught in this way (especially in an academic setting). LLMs' writing are like that of people, not the other way around.

I built a local competitive programming judge a while back where I fell into the exact trap of manually correlating steady_clock and system_clock.

I was timestamping everything using steady_clock to strictly enforce the time limits, and then just applied a calculated offset to convert that to wall time for the "Submission Date" display. It worked in testing, but during a long stress-test session, my laptop did an NTP sync. The logs then showed submissions appearing to happen before the source code file was last modified, which confused the caching logic. I was essentially betting that system_clock was stable relative to steady_clock over the process lifetime.

I eventually refactored to exactly what the article suggests: use steady_clock strictly for the runtime enforcement (is duration < 2.0s?), but capture system_clock::now() explicitly at the submission boundary for the logs, rather than trying to do math on the steady timestamp.

Also, +1 for std::chrono::round in C++20. I’ve seen code where duration_cast was used to "round" execution times to milliseconds for display, but it was silently flooring them. In a competitive programming context, reporting 1000ms when the actual time was 1000.9ms is a misleading difference because the latter gets Time Limit Exceeded error. Explicit rounding makes the intent much clearer.

I don't think Kindle ads were available in my region in 2015 because I don't remember seeing these back then, but you're a lucky one to fix this classic mistake :-)

I remember trying out some of the home-made methods while I was implementing a creative work section for a school assignment. It’s surprising how "flat" the basic average looks until you actually respect the coefficients (usually some flavor of 0.21R + 0.72G + 0.07B). I bet it's even more apparent in a 4-bit display.

I love posts that peel back the abstraction layer of "images." It really highlights that modern photography is just signal processing with better marketing.

A fun tangent on the "green cast" mentioned in the post: the reason the Bayer pattern is RGGB (50% green) isn't just about color balance, but spatial resolution. The human eye is most sensitive to green light, so that channel effectively carries the majority of the luminance (brightness/detail) data. In many advanced demosaicing algorithms, the pipeline actually reconstructs the green channel first to get a high-resolution luminance map, and then interpolates the red/blue signals—which act more like "color difference" layers—on top of it. We can get away with this because the human visual system is much more forgiving of low-resolution color data than it is of low-resolution brightness data. It’s the same psycho-visual principle that justifies 4:2:0 chroma subsampling in video compression.

Also, for anyone interested in how deep the rabbit hole goes, looking at the source code for dcraw (or libraw) is a rite of passage. It’s impressive how many edge cases exist just to interpret the "raw" voltages from different sensor manufacturers.

Neat! I'll add it to my blog.

Thanks for the feedback! Agreed, I too have experienced those quirks. This applies to most modern CSS features in general :-)

FWIW, I also have had also success with running a server-side headless chromium instance on an app where I was generating nicely formatted exam from provided questions.

CSS rules for printing is one of my favorite features of the web. You get a powerful typesetter directly in your browser. For those wondering how it's done, I wrote about it [0] recently for my friends who frequently asked how I generated PDFs for my blogs.

[0] https://barish.me/blog/make-your-website-printable-with-css/

Your game repo is private.

Then should we apply formal verification to the vibe coded formal verification software?

For a long time I've been looking to solve the repetitive schema pattern issues in SQL. This week I created a DSL that allows parametric polymorphism for SQL, and I wrote a compiler for it.

Source code and playground here: https://github.com/BarishNamazov/gsql/

Background blog here: https://barish.me/blog/parametric-polymorphism-for-sql/

Feedback is super appreciated!