royjacobs

It seems rather disingenuous to talk about severely outdated features without mentioning the fact that said practices are multiple decades out of date.

Let me put it another way, it doesn't strike me as the best possible example to use.

It's unfortunate that this article is based on some flawed assumptions, such as "Java provided a suberbly user-friendly way of serializing any object to disk and recovering it back in its original form. The only unfortunate problem was that there was no way to say which object you are expecting!".

Java serialization is not what is used by web frameworks. They use JSON deserializing, typically using libraries like Jackson, which are of course fully strongly typed.

Not everyone wants to use existing engines. Or are you saying you want to embrace vendor lock-in in that regard?

I can vouch for VuePress as well. It's fairly straightforward to set up, and extremely easy to deploy. I've used it to not only write the docs for my 6502 assembler, MOS[1], but I took advantage of the fact that VuePress could generate a very simple front page as well.

[1] https://mos.datatra.sh

It also used to form the basis for Redcode, the file format used by RED digital cinema cameras. Not sure if the current version is still based on JPEG2000 though.

The podcasts "Bad Blood" (by Carreyrou) and "The Dropout" (about the currently ongoing trial against Holmes) cover these questions and more. I can highly recommend them.

It was John Carreyrou at the WSJ who did so. The rest of the press printed all of Holmes' lies verbatim (and some retracted after the scandal came to light).

Which, to be fair, isn't exactly a high profile game a lot of pirates are clamouring for.

If you don't want to see development effort wasted I hope you'll contribute to the project. I'm sure the authors will applaud and enjoy your passion.

>Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers".

Neither were the authors of the DAW, someone else posted it using this title.

(btw I do have plenty of experience using DAWs (going back to Notator on the Atari ST) and have been an amateur musician since childhood. I just don't see how it's relevant in a discussion about an aspirational MVP design. Thanks for assuming the worst, though!)

I'm not sure why the amount of audio production experience is relevant in this case. I also don't have a horse in this race. I just find it curious that you seem to be so extremely passionate about taking a random item in a _design_ for an _MVP_ and drawing all sorts of conclusions about both the tool and the authors of this tool. Why does it matter so much that it doesn't align with what you find the most important aspect of an MVP?

Again, this is even just a _design_ for an MVP. If it doesn't align with what _you_ find important then that's fine. Just use something else, you've clearly been doing so for about 15 years. I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.

Okay, you just want different things from this MVP than the developers want. That's fine.

"Including a rear parking sensor is a non-goal for the MVP of the car we're building" seems to be a closer analogy.

If you cannot use the MVP of the software for your use cases, that doesn't mean it cannot be worthwhile for anyone else.

The document states this is a non-goal for the MVP, not a non-goal for the final product.

It can be quite tricky to get right once you get into ownership issues. If you delete an item, undo'ing that should reinstate it. So that undo step becomes the owner of the data of the item, otherwise it couldn't reinstate it. This can already become a bit complicated if you're dealing with memory management of this item. Do resources that the item uses get deleted immediately, or do you want to keep them around in your undo state too? If the resource requires a lot of processing then that may be the only option.

This then grows more complex if items have parent-child relationships and you also need to start storing all the information required to completely reinstate all the children, possibly also in the same order they were originally created in.

You know, tricky.

That's an interesting analogy. I would say even the market share is similar to Esperanto and English, respectively.

Haha, yes, I can relate. I didn't do any 6502 coding for ~25 years and it mostly just stuck around. Apparently it's like riding a bike.

In the meantime I've forgotten most of the 68000 and z80 instruction sets.

The cool thing about LLVM-MOS specifically it that by using the zero page as virtual registers you sort-of get the same output with 'regular' code as opposed to this 'global variables' style of programming.

I recall a tutorial for 'cc65 optimizations'[0] which basically destroys a well-structured C program in order to do all of these optimizations (like making everything global) and it was absolutely terrible, code-wise. Well, the end result was probably fine, but it's just a shame these 'optimizations' were needed.

[0] I think it was this one: https://github.com/ilmenit/CC65-Advanced-Optimizations

You can treat 2 bytes (not just in the zero page, though) as indirect jump addresses, yes.

Doing something like "JMP ($2345)" will jump to whatever $2345/$2346 is pointing to.

They actually address some of that on their project page, see: https://llvm-mos.org/wiki/Findings

That is so cool. I saw some posts about LLVM-MOS a while ago, but at that point I thought it would be just another in a fairly long list of attempts to try and get LLVM to output 6502 instructions.

I never expected it to come together this well! Especially considering that the author of the article mentions there were so many issues with LLVM-AVR, you'd expect them to exist in LLVM-MOS as well. Apparently not! I guess the code quality will only improve from here on out, the loop at the bottom of the article does seem like it is not as optimal as it could be :)

What? The 6502 is in the Atari 2600. The Atari ST had a 68000.

I might as well plug my 6502 assembler MOS[1] again. It's written in Rust and comes with a full language server implementation that does things like full code formatting, refactoring support (go to symbol, renaming, etc) and if you're using the VICE emulator for the c64 it even integrates with the Visual Studio Code debugger.

[1] https://mos.datatra.sh

They are focusing on healthcare and personal care products and are doing pretty well there. Their MRI scanners are well regarded, for instance.

Other electronics like televisions are still produced under the Philips name, but that's just TP-Vision making them in China and slapping the Philips name on it.

Ah yes, ASML. I have a number of friends and ex-colleagues who work there. Unsurprisingly, due to their importance, ASML are extremely well-known inside of the Netherlands. It's one of those companies that spun out of Philips Electronics and became very successful (NXP is another good example).

A lot of research and development is still going on in the area where Philips had their research labs. If you're curious to see what kind of high-tech is being worked on in the "Dutch silicon valley" I suggest you Google "Brainport Eindhoven" or "High Tech Campus Eindhoven".

It's a really fun architecture, agreed. I spent the last few months writing an assembler, formatter and language server for 6502 code. If you're interested, it's available at https://mos.datatra.sh

But in the system proposed in the article there are virtual function calls everywhere, which will surely trash any cache? Not to mention these function calls cannot even be inlined.

Yes, that was the point I was trying to make (also in my other comment). It's certainly bad, but if you iterate across, say, two components it shouldn't be too bad?

It's also an option to have your component data interleaved, if you know the iteration usage upfront, I suppose.

What's wrong with iterating across multiple components? You seem to imply that this is "hopping around" and therefore bad, but it's perfectly acceptable to do so.

Of course, if your system needs to iterate across 20 components to do its job then maybe you need to check if you've factored your components correctly.

Hmm, I don't get it. Isn't one of the major reasons to use ECS to exploit mechanical sympathy, i.e. you make sure that cache lines are always full, you can use SIMD for calculations, etc.

All of this is pretty much out of the window for this design, so what is the benefit of the ECS here?

You seem to have a fairly combative tone, which I suggest you temper a little bit if you want to have an actual discussion.

Having said that, since when is an emotional reason to use something not a valid reason?

I mean, I don't like MacOS for a bunch of reasons that are probably unreasonable or emotional, but that's my right too.