This is one of those things that seems like a nerd snipe but would be more easily accomplished through brute forcing it. Just get 76 people to manually type out one page each, you'd be done before the blog post was written.
Or one person types 76 pages. This is a thing people used to do, not all that infrequently. Or maybe you have one friend who will help–cool, you just cut the time in half.
Typing 76 pages is easy when it's words in a language you understand. WPM is going to be incredibly slow when you actually have to read every character. On top of that, no spaces and no spellcheck so hopefully you didn't miss a character.
The first week of my PHD was accurately copying DNA sequences from an old paper into a computer file. 10 pages in total. I used OCR to make an initial version then text to speech to check it
As TFA says, the hard part is that "1" and "l" look the same in the selected typeface. Whether your OCR is done by computers or humans, you still have to deal with that problem somehow. You still need to do the part sketched out e.g. by pyrolistical in [1] and implemented by dperfect in [2].
I consider myself fairly normal in this regard, but I don't have 76 friends to ask to do this, so I don't know how I'd go about doing this. Post an ad on craigslist? Fiverr? Seems like a lot to manage.
Non-engineers are perfectly willing to volunteer their time to do drudgery. It's one of my opseng career's distinguishing specialties: I'll do drudgery rather than code when appropriate, rather than avoiding it or sulking about it (as was a common response at work for some number of decades!). Learned that lesson when I was 18 from an internship (where I completely failed to deliver any work product due to trying to code around the work). It's part of why I'm going into accounting: apparently having the stamina for dreary work is rare?!
Also look up double/triple data-entry systems, where you have multiple people enter the data and then flag and resolve differences. Won't protect you from your staff banding together to fuck you over with maliciously bad data, but it's incredibly effective to ensure people were Actually Working Their Blocks under healthy circumstances.
I do think running the code would be a tiny bit faster, even if it's merely seconds either way. Opening a python REPL and pasting that would take around 5 seconds in my case. Running the code in my head would take roughly the same at first, but then if it's in an interview I'd take the time to double check. And then check a few more times because I'd expect some kind of trick here.
Considering there's no (explicit) instruction forbidding or discouraging it, I'd consider the REPL solution to be perfectly valid. In fact some interview tests specifically look for this kind of problem solving.
I get it still, I'd expect some valuable signal from this test. Candidates who execute this code are likely to do so because they really want to avoid running the code in their head, not just because it's more straightforward, and that's probably a bad sign. And pasting that into an LLM instead of a REPL would be a massive red flag.
I just don't think answering "-11" here is a signal strong enough to disqualify candidates on its own.
If you're looking for junior-ish python devs, I'd expect a good chunk of the better ones to have a python repl open and ready just as a matter of habit.
So for them, yes, it would clearly be faster to run the code than to work through it manually.
What you're doing here is selecting for candidates who are less comfortable with using the tools that they'd be expected to use every day in the role you're hiring for. It's likely to provide a negative signal.
So I wouldn't go so far as to say that I'd fire someone for copying and pasting code, but it's definitely part of my company's culture that copying and pasting code off of a website, and especially executing it, is something heavily discouraged to the point that it doesn't really happen at my job.
I'm perfectly happy to use Stack Overflow and other resources/tutorials, blog posts etc... to find solutions to problems, but just instinctively I would never think to copy and paste a solution from these sites and incorporate it into my codebase and I sure as heck wouldn't think to execute code from some untrusted site I happened to come across.
But this may also be a consequence of the domain I work in where we take security very seriously.
You can tell how safe a code snippet is from reading it.
Like, there's no way you're going to copy a 20 line algorithm from stack overflow on balancing a red-black tree and have it encrypt your harddrive.
Obviously you still need to test the code to make sure it works and understand what it's doing, but there is very little security risk here. Just look up the functions youre using and understand the code and you're fine.
You mean a display engine that works like an HTML renderer, except starting from TeX source instead of HTML source? I think you could get something that mostly works, but it would be a pain and at the end you wouldn't have CSS or javascript, so I don't think browser makers are interested.
Browsers already support JavaScript anyway, so why not add another Turing-complete language into the mix? (Not even accounting for CSS technically being Turing-complete, or WASM, or …)
As far as I know the Tex team has been working hard lately on supporting accessible "tagged pdfs". Hopefully one day Tex/Latex output will be accessible by default and conversion to HTML will not be needed.
That would (mostly if not always) work in the sense of reproducing the layout of the pages, but would defeat the purpose of preserving the semantic information present in the TeX file (what is a heading, a reference and to what, a specific math environment, etc.) which is AFAIK already mostly dropped on conversion to PDF by the latex compiler.
This was the original goal of the Cornell box (https://en.wikipedia.org/wiki/Cornell_box, i.e. carefully measure the radiosity of a simple, real-world scene and then see how closely you can come to simulating it).
For realtime rendering a common thing to do is to benchmark against a known-good offline renderer (e.g. Arnold, Octane)
I like programming. It's fun, and sometimes it even requires creativity. There are plenty of times when it's not that fun, and doesn't require any creativity (because whatever it is has been done by someone else a thousand times over), and you just want a result. Vibecoding is great for _that_ stuff (think little throw-away scripts, shell one liners, tool plugins, etc)
I generally don't get great results from LLM code because most of my work is in C++ (which I'm guessing is underrepresented in the training data?), but when I point it towards some well-worn javascript thing I've had real successes! Most recent example is this little chrome plugin I had it whip up in one shot (https://chromewebstore.google.com/detail/favicon-tab-grouper...) because I couldn't find the exact functionality I needed in other plugins.
Works perfectly for my needs, took less than five minutes to spin up, and I use it all the time. If you're looking to get started with vibecoding stuff, try making plugins that provide niche functionality for your hyper-specific workflows.
It works poorly at any speed. Hi-Z is an undriven signal, not a specific level, so voltage-driven logic like (C)MOS can't distinguish it from an input that's whatever that signal happens to be floating at. In current-driven logic like TTL or ECL, it's completely equivalent to a lack of current.
reply