JetSetIlly

I'm happy with this "maintenance mode" tag. Personally speaking, so long as it continues to get security fixes and the build system is kept working, I'm a happy user.

I totally agree with this. I've always found debugging Excel spreadsheets to be a real challenge.

I work in accountancy and while its possible to audit the output of the spreadsheet, (as I'm sure it's possible to audit the output in other domains) as an erstwhile Software Engineer I can't help but think it would be better if I could better verify the integrity of the spreadsheet itself. It's far too easy to introduce unnoticed errors.

Other people have different views on this but I love the idea of spreadsheets but I don't like any spreadsheet software. I think there's massive room for improvement. But if you were to ask me how to improve it specifically, I couldn't really pinpoint anything.

I had a go at doing something in this space to scratch a very specific itch but of course, it doesn't address any of my complaints here. Rather, it tried to tackle another of my complaints - the lack of good support for different number bases https://github.com/JetSetIlly/Ivycel/

It's good for final product too. Moonring is an excellent game by Fluttermind, and written in LÖVE

If he sees his opponent with a marked string, he knows it's time to bring out the metal chestnut.

I've been working on an Atari 2600 emulator for many years. I've recently decided to end development at v0.34.0 and thought this was a good time for people on Hacker News to see it.

The emulation is complete and the 6507, TIA, RIOT and memory sub-systems are all accurate. It supports all the known cartridge formats, including those that make use of on-cartridge ARM processors and also specialist cartridge types like MovieCart.

The debugger is extensive and, uniquely, allows the emulation to be stepped at a sub-CPU-cycle level. Programs running on the ARM can be inspected at the source code level if DWARF data is available; breakpoints can be added and local/global variables can be inspected.

For the player, games can be played with a simple but effective series of CRT effects (implemented with GLSL shaders) and quick and responsive rewinding of gameplay. In fact, the rewind system plays an important part in the debugger too.

From the perspective of a Go developer, I believe it shows that the language can produce good and useful applications for the desktop. There is an undoubted performance penalty introduced by the use of supporting C libraries (SDL, Dear Imgui, etc.) but it is, in my opinion, not terrible. Other people may disagree with that and I'd be interested in hearing their thoughts.

The project is not worthy of a v1.0 tag but I now consider it complete if not bug-free. I know I've made some poor engineering choices but I believe many of these mistakes were due to my inexperience with the language - I would certainly make different choices today.

I look forward to constructive criticism from the programmers and engineers on Hacker News before moving onto my next project.

True.

> I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the core Golang design values.

I'm not sure I would agree with that. go:generate is a core part of Go since v1.4 and the enum generators are the kind of thing that was intended. https://go.dev/blog/generate

That said, enums would be a welcome improvement to the language. But even then, I think go:generate has a place.

Good summary but the article doesn't mention the engineering of the user interface. In this field of accountancy, I think the UI is an engineering problem at least as important as anything else mentioned in the article.

As someone who works in accountancy (as a bookkeeper/accountant) I have to be brutally honest and say that I've been very disappointed in the UI of all the accounting software packages I've used. None of them give me the immediacy or simplicity of a well organised filing cabinet, they really don't.

I'm not sure what a good solution would look like, but I can't help thinking that making the double-entry system more visible and apparent to the user would be a good start.

I love the Practice of Programming. Of all the books on programming that I've read, the lessons of that book are the ones that remain strongest in my mind. I've not read it in many years but I feel it influences my practice everyday.

Agreed. I admire the clarity of Cox's writing, as much as his thoughtful restraint on adding new features to the language.

Yes. The Go implementation from Google is under the BSD licence.

There's also the GNU implementation in GCC that's under the GNU GPL 3 licence. Moreover, the specification itself doesn't seem to have any licencing requirements at all.

So you're absolutely right: Go is the very opposite of proprietary.

The 2600 is streaming the data from the cartridge, including the program that is run on the 2600. We should remember that there's no frame buffer in the 2600, so there's considerable work done by the 2600 every frame - just as there is when its working with any other cartridge.

The 2600 kernel that runs on the 2600 is excellent but the encoding method is what makes a real difference here. Lodefmode did a great job with this. The use of playfield/background and player colour is exceedingly clever.

Yes. The Harmony Cart and the UnoCart/PlusCart both have ARM chips. Games have been made that make full use of the chip. Probably the most impressive IMO being Robotron from ChampGames.

The PlusCart also includes a WiFi chip for Internet access.

Exciting times in the world of the Atari2600.

There are several categories of mistake that you can make when bookkeeping. Some are caught by the double-entry system when a trial balance is prepared.

The error you've described is an "error of original entry" and will be invisible if you only look at the trial balance. It can ultimately be caught when you compare the banking ledger with what's actually in the bank.

Other errors that don't appear in the trial balance can be incredibly hard to detect and in fact, may never be noticed. This is where the real art of bookkeeping is IMO.

The types of errors that do affect the trial balance are things like forgetting to enter a purchase in the purchase ledger but entering the transaction into the banking ledger correctly. Silly errors really, but we can all need help to stop us making those.

Interesting. With a bit of work, this would have genuine use for something like a text display on an Atari2600, where the dimensions are significantly limited.

I've used glyphs as small as 4x5 but I've struggled to come up with anything smaller for most characters.

Here's an example of a full text adventure for the 2600 if anyone's interested https://github.com/JetSetIlly/Adventureland-2600

Better or worse with an even smaller font? I'm not sure.

The drifting of code from comments is a problem I would love to see solved.

I've seen tools that can compare the git commit dates of code with nearby comments and that's a good start. However, there are potential problems with that, such as code and the comments that discuss the code not being near each other; or the code being updated and there being no need to update the comment

I think literal programming might help here, but that's an entirely different topic really.

Looking for more advanced tools that that and I suppose we're into the world of AI - asking the tool to understand both the code and the comment and to compare the underlying meaning.

Code review is an option but outside of an organisation that's difficult to do and besides, I think the problem would be best solved by something that is repeatable and part of the build process. And I'd love to be able to have a git commit hook that can say, "hold on! you've updated code but there's a comment that now looks old". That's the dream.

I've always been amused by these boring sounding cover names. In the USSR, nuclear related work was administered by the "Ministry of Medium Machine Building".

And The Manhattan Project was originally the "Manhattan Engineering District". Although that sounds a little bit exotic, at least to my ears.

GCHQ was the cover name for Bletchley Park but the organisation's name at the time was GC&CS which was established in 1919. So very old and surprisingly predates WW2

Speaking of which, this 1D version would translate very well to the 2600

Gundo is great. There is also mundo, which is a fork of gundo. And, undotree, which doesn't require python support.

I agree with you. I don't begrudge the 2600+ but it's not one for me.

It seems to me that compatibility with any cartridge would require a recreation of the actual VCS hardware. That sounds expensive to me and is probably why Atari haven't gone down this route. But as you say, that leads to a half-baked solution.

The other option is an emulator that can communicate with the cartridge in real time - but that doesn't exist and I doubt Atari have gone to the trouble of making one (we're all assuming they're using Stella at this point, but I don't think that's been confirmed).

Yeah. Many of the most popular games released in recent years have contained an ARM chip. As it happens Atari Age have removed many of those games from distribution (in readiness for this takeover by Atari) because they weren't properly licenced. A good exception to this rule is LodeRunner which has been licenced and uses an onboard ARM.

If the market for this product is people who only want to play the older ROMs on a HDTV then I'm sure the 2600+ is a fine product.

Unfortunately, it's not compatible with DPC or DPC+, CDFJ+, etc. The emulator works by "dumping" the ROM binary from the inserted cartridge. This is fine for simple cartridges but for more advanced bank switching technologies it's difficult to do correctly and for processor-cartridges it's impossible.

As you suggest, one way around that is to fingerprint the cartridge and then to load a binary into the emulator from internal memory (if they're using Stella then the emulator is capable of emulating the processors on those chips) but I don't believe that is an option provided by the 2600+. And if it was, it's a very limiting option for the end user because new homebrew games wouldn't work.

You've hit the nail on the head for me. From my point of view, vim is simpler than neovim. I value that and wouldn't like to see neovim subsume it (although I'm sure people are happy with neovim for very good reasons)

In principle, I like the idea of it. Whether or not it's a binary or source to be compiled locally is irrelevant, I suppose.

My concern is that it's not clear to me how this will look on my computer. Currently, I download the source tarball and build with the latest Go toolchain I have previously installed. I then change the path to point to the newly built toolchain.

So, in the future, what is it I'm downloading? How does the toolchain get updated exactly? Where does the new executable reside? What happens to the toolchain that I explicitly built and installed? How does Go1.21 change my path?

As I say, I like the idea in principle but there are details that I think are important, that don't seem to have been explained anywhere.

Thanks. I'm now not sure how I feel about this.

It sounds to me like this is downloading the toolchain as though it were any other Go package and compiling it. I'm not sure it's downloading binaries, as the article suggests.

From the Go Toolchains documentation:

"When using GOTOOLCHAIN=auto or GOTOOLCHAIN=<name>+auto, the Go command downloads newer toolchains as needed. These toolchains are packaged as special modules with module path golang.org/toolchain and version v0.0.1-goVERSION.GOOS-GOARCH. Toolchains are downloaded like any other module, meaning that toolchain downloads can be proxied by setting GOPROXY and have their checksums checked by the Go checksum database."

I don't know for sure though.

I didn't know that. That's genuinely useful to know.

That used to be how you started a go project. Unfortunately, modern Go requires you to first setup a go.mod file with:

    go mod init <project name>

Still simple but for better or worse it's now a necessary part of the process.

> Russ obviously went out of his way to come up with a nuanced solution, which one could reasonably disagree with, but I have the impression many people didn't bother reading it,

Telemetry is one of those topics that comes with a lot of baggage. Coupled with Google's baggage and we see the inevitable response. I have a similar impression as you - people saw the word "telemetry" and thought they'd read enough.

I thought Cox's posts were great. I came in thinking, "telemetry? hell no!" but came away thinking he made a good case. People can still disagree over it but some of the misinformation is absolutely unbelievable.