Now, part of me thinks 'is not letting students having AI like not letting them have a calculator'. On the other hand, if I just let the AI do the exam, well I don't really need the student at all do I?

I often think of the ‘news level’ of a bug. A bug in most code wouldn’t be news. A bug which caused lean to claim a real proof someone cared about was true, when it wasn’t, would in the proof community the biggest news in a decade.

Comments URL: https://news.ycombinator.com/item?id=47750486

Points: 149

# Comments: 114

When I am rigourous about the tests, Claude has done an amazing job implementing some tricky algorithms from some difficult academic papers, saving me time overall, but it does require more babysitting than I would like.

I haven't found a static generator which has as nice a WYSIWYG interface as wordpress.

I tend to take another view point (while I understand yours) -- if it's not tested, it doesn't work. And nowadays it's really hard to test big-endian code. I don't have one, I find running different-endian software in QEMU really annoying and difficult.

The author of the 'port' probably doesn't know your whole codebase like you, so they are going to need help to get their code polished and merged.

For endian issues, the bugs are often subtle and can occur in strange places (it's hard to grep for 'someone somewhere made an endian assumption'), so you often get dragged into debugging.

Now let's imagine we get everything working, CI set up, I make a PR which breaks the big-endian build. My options are:

1) Start fixing endian bugs myself -- I have other stuff to do!

2) Wait for my 'endian maintainer' to find and fix the bug -- might take weeks, they have other stuff to do!

3) Just disable the endian tests in CI, eventually someone will come complain, maybe a debian packager.

At the end of the day I have finite hours on this earth, and there are just so few big endian users -- I often think there are more packagers who want to make software work on their machine in a kind of 'pokemon-style gotta catch em all', than actual users.

I think love2d is better if what you love is coding, everything is code, love2d just executes Lua.

If what someone wants to do is make (for example) a 2d platformer, or definately for 3d, and the coding is something you need to do to make your game, goody is better, it includes so many batteries, have a built in gui level editor, etc.

One big advantage of love2d (although ironically not loved by many in its audience) is it is the AI friendly engine, as AIs love text and hate GUIs.

My modern choice is just to make clear to BE users I don't support them, and while I will accept patches I'll make no attempt to bugfix for them, because every time I try to get a BE VM running a modern linux it takes a whole afternoon.

It's also increasingly hard to test. Particularly when you have large expensive testsuites which run incredibly slowly on this simulated machines.

When emulating a NES (for example), you really have to emulate every register, how registers change, and also weird effects like instructions that take longer to read or write values, as games rely on that stuff. Once you have modern systems where much of the code was originally C, it becomes less important to ensure every register has exactly the right values when a subroutine finishes in most cases, you can rely that (most) of the code follows standard calling conventions.

It would be interesting to take the resulting solver and apply it to an unknown data set.

It does much better with good tests. In my case the output was a statically generated website, so I could just say 'make the same website, given these inputs'.

This is a combination of getting stuff merged upstream, and removing the need for some more specialist features.