masswerk

The site covers mostly retro- and classic computing. (Strictly no AI generated content.) Here in convenient format:

  (
    :name "Norbert Landsteiner"
    :site "https://masswerk.at/"
    :blog "https://masswerk.at/nowgobang/"
    :feed "https://masswerk.at/nowgobang/feed.xml" //covers blog only
    :about "https://masswerk.at/info/"             //legal info
    :hnuid "masswerk"
    :bio "web developer and designer, site content is mostly retro- and classic computing."
  )

Something along the lines of Intel 8080 assembly may have been more appropriate, given that the target platform would have probably been a coin-op machine. (Given that "Gun Fight", the first arcade video game utilising a microprocessor, wasn't yet released, even this would have been an ambitious choice. Atari doing research for something that required an ALU may be even more interesting than the involvement of the young Steve Jobs.)

PS: This is just to give some truth to "this is where the hackersnews jerks will say this is an ad". ;-)

Meaning: also no images.

For example, when a process implies a conversion according to the contract/convention, but we know that this conversion may be not the expected result and the input may be based on semantic misconceptions. E.g., assemblers and contextually truncated values for operands: while there's no issue with the grammar or syntax or intrinsic semantics, a higher level misconception may be involved (e.g., regarding address modes), resulting in a correct but still non-functional output. So, "In this individual case, there may be or may be not an issue. Please, check. (Not resolvable on our end.)"

(Disclaimer: I know that this is a very much classic computing and that this is now mostly moved to the global TOS, but still, it's the classic example for a warning.)

Referring to the examples provided in the article, I'd suggest that the impact on the Safari app menu should be minimal (so these are non-functional icons), while the impact on the Move & Resize submenu would be devastating and should result in confusion (so these are essential).

If you can remix with minimal impact, don't do icons. (In the case of the app menu, these are apparently meant to add structure, which is already established by other means like menu separators, so you have now two – or, including indentation, three – systems of structure and visual hierarchy that are fighting each other.)

Moreover, if you put icons everywhere, you're forgoing the facility to convey state, like active state checkmarks, since these, instead of standing out and signalling change, would be just drowned in the decorative clutter. (So what's next? Add color and/or animation, like swirling checkmarks?) And this, BTW, is also why the icons in the Move & Resize menu are effective: they are conveying and illustrating state (in terms of a preview), while most of the other menu icons (mostly referring to activities) do not. So, as a rule of thumb: icons referring to state may be useful and even desirable, while icons referring to activities are probably better left out. (And, if you feel the need for something like bullet points to mark your most important menu items, there's probably a deeper problem with your menu structure.)

(Fun fact, the most amazing layout foot-guns, then: Effective font sizes and line-heights are subject to platform and configuration (e.g., Win vs Mac); Netscape does paragraph spacing at 1.2em, IE at 1em (if this matters, prefer `<br>` over paragraphs); frames dimensions in Netscape are always calculated as integer percentages of window dimensions, even if you provide absolute dimensions in pixels, while IE does what it says on the tin (a rare example), so they will be the same only by chance and effective rounding errors. And, of course, screen gamma is different on Win and Mac, so your colors will always be messed up – aim for a happy medium.)

Fun fact: Java was also renamed from formerly Oak.

I'm also not too sure, if LiveConnect (the connection between JS and Java applets and vice versa) was already a thing, when JavaScript was announced. (I think, this came a little later.)

Edit: I've a Netscape JavaScript book from when this was still in beta. (My first reading on the subject.) It does mention applets on a single page and that you may address them per ID via LiveConnect in a single sentence. So this was already implemented, but it wasn't advertised prominently. The book is all about form based examples.

(The applications in this book were the same that were demoed as showcase applications by Netscape on their website – and probably represent a significant part of what these voices reacted to.)

Of course, there was the infamous `document.write()`, when the document was loading and the document stream was still open, but this was more of a hack than an interaction model.

(Meaning, if we're making generalisation from worst examples a virtue, there will be hardly an argument left. E.g., as there are buggy programs, LLMs are just yet another bug.)

E.g., https://www.masswerk.at/wp-admin

Actually, integer arrays use just 2 bytes per entry (contrary to simple integer variables). And integers are really all what's needed here.

Therefore, using `DIM %R(RC,6)` should come with less overhead.

As for calculating overheads: String variables use 5 byte and the memory required for the actual string (one byte per character). Arrays use 2 bytes for the name and then 2 bytes for a length offset and 1 byte for the width/length per dimension, plus the space required for the individual entries (for integers 2 bytes per entry, for floating point 5 bytes and for strings 3 bytes). So a 2D array uses 2 + (2 + 1) + (2 + 1) = 8 bytes for the header plus the space for the entries.

Regarding performance, mind that arrays come after simple variables in memory and must be relocated (moved) each time, a new simple variable is defined (or used for the first time). So make sure to define simple variables before DIM-ing arrays. (As a lesser known feature, you can define simple variables by DIM as a list at once, where no dimensions parameters are provided, which should make this easier. E.g., `DIM A$, I%, X, Y`. Mind that this also defines the lookup order, so define often used variables before infrequently used ones. Add your array-DIMs after this.)

The study: https://budgetlab.yale.edu/research/evaluating-impact-ai-lab...

[1] https://www.masswerk.at/6502/6502_instruction_set.html#stack

(In my experience, if an interface elements raises questions, even more so, if these are fundamental questions, you do have a problem. If not for other reasons, just for the few more bits of awareness spent on these questions, every time you see them.)

At this point, does it need that residual variation or is this just adding noise? Also, a shape inside a shape inside a shape inside a shape isn't anything anyone is likely to parse – how many bits of information is this? So maybe just go with a simple default wrench icon for all of them?

Meaning, no way, just for the security aspect.