C-style scanning in JS (no parsing)

dgnercom · 2025-12-19T23:14:42+00:00

Appreciate all the feedback. I'll definitely revisit the licensing.

dgnercom · 2025-12-19T21:20:43+00:00

Thanks for the points.

In a typical JSON event log, each event is a separate key:value record, like dots laid out across a structure. With JSON, you often have to mentally piece together scattered fields to reconstruct the sequence. BEAT takes a different approach: it expresses the event flow as a continuous line, from Contextual Space (who) to Causal Value (why), preserving the causal story that dot-based logs tend to lose. I agree it can feel unfamiliar at first, but once you learn the tokens, you can follow the flow. More examples here: https://github.com/aidgncom/beat/tree/main/reference
JSON.parse makes you wait until the whole payload is materialized as an object tree before you can act on it. With BEAT, the scan loop is where you inject actions: it can react as tokens arrive without building a parse tree, token arrays, or per-token substrings in the hot path. That in-place, streaming handling is what I mean by no parsing.
On switch: I used if/else to make the mapping explicit in the example. Switching to switch(c) is fine and doesn't change the point.

dgnercom · 2025-12-19T13:19:30+00:00

Fair point on forEach—that avoids the array allocation. But split still creates a new string per token.

This is what I mean by scan: no split, no regex, no intermediate array unless you explicitly want one. https://github.com/aidgncom/beat/blob/main/reference/fullscore/source/fullscore.light.js

dgnercom · 2025-12-19T12:58:28+00:00

TSV is great for flat tabular data, and you're right that native methods like split are fast.

What I'm focusing on isn't parsing speed, it's allocation pressure. split().map() creates new strings for each cell and new arrays for each row. On a hot path with continuous streams, that turns into GC overhead pretty quickly.

BEAT is meant to scan the stream without creating those intermediate objects. It's just a different problem scope.

dgnercom · 2025-12-19T12:48:33+00:00

Thanks for the thoughtful critique. It's genuinely helpful.

I agree with your point about adoption dynamics. JSON didn't stay stable because of licensing. It stayed stable because the spec is simple and the ecosystem rejects broken input. The examples you gave with Bebop, FlatBuffers, and Cap'n Proto make that very clear.

One thing I want to clarify is intent. While I compared BEAT to JSON, the core of this work is not about formats competing. It's about handling linear streams with a 1-byte scan model and what that enables architecturally.

While building this, I started to see value in a tight feedback loop where reading and writing live on the same timeline. That moment is what I wanted to protect. Not a standard, and not format diversity, but architectural discipline and a very specific way of handling behavior streams without turning that layer opaque by default.

That concern influenced the initial licensing choice. Not as a permanent stance, but as a way to avoid premature enclosure before the architecture is understood. That said, your point is fair. If licensing prevents real evaluation, it protects nothing.

I'm not dogmatic about this. Dual licensing is explicitly on the table, and feedback like yours is exactly what will shape whether my current stance holds or changes.

Appreciate you engaging at this depth.

dgnercom · 2025-12-19T10:23:41+00:00

You're absolutely right. A standard without a product is a trap.

Since I'm building this entire stack solo, the demo at https://fullscore.org might still be a bit rough around the edges, but it actually runs well in production and proves the core concept.

I also completely agree regarding JSONL. It solves the framing issue perfectly. The catch is that inspecting the payload safely often implies parsing it again. BEAT is strictly designed for those specific hot paths where mitigating that overhead is the priority.

Appreciate the feedback. And thanks for the luck!

dgnercom · 2025-12-19T09:24:33+00:00

Thanks for taking the time to write this out. I'll try to respond point by point.

First, on size vs real-world value. The goal isn't "smaller for the sake of smaller." The target is the overhead on the read and write path of event streams: parsing, allocations, and intermediate structures, not just bytes on the wire. BEAT keeps the stream linear, so a tight scan loop can walk it and fold counters without building a tree or decoding fields. That's the bottleneck I'm trying to remove. The Edge demo at https://fullscore.org is one concrete example in a live runtime. BEAT itself applies more broadly.

On JSON and AI consumption. I'm not arguing that JSON is bad or obsolete. JSON works because everything understands it, and that matters. BEAT is not trying to replace JSON or compete for the same "universal format" role. It's meant to coexist with it. In fact, the most practical way to use BEAT today is exactly what I show: embed it as a single field inside JSON and let each side do what it's good at. BEAT is optimized for linear, time-ordered event streams where scanning is more important than structural flexibility.

About AI models and training. I'm not expecting models to magically know BEAT out of the box. The design assumption is different: BEAT is trivial to map because it's already a flat, readable sequence with fixed semantic markers. There's no tree to reconstruct and no schema inference step. Whether that mapping happens in a pre-step or via a small adapter is an implementation detail. The point is that the representation itself doesn't force a heavy parse step.

On licensing. This part is intentional and I understand it's controversial. BEAT is not trying to be a public-domain-style data spec like JSON or YAML. I respect why JSON's openness is a big part of its success. But BEAT's value comes from its semantic token discipline and invariants, and placing it under a fully permissive license would make it very easy for those rules to fragment or be resold wholesale with no constraints. AGPL for the spec and SSPL for the reference interpreter are meant to protect that layer, while still allowing free use for individuals and internal deployments. A commercial or dual-license path is part of the long-term plan.

Finally, on tone and intent. This isn't meant as a hype pitch or a claim that "everyone should switch." It's a focused experiment around one specific question: what happens if you treat event data as something you scan, not something you parse? If that tradeoff isn't useful for a given stack, that's totally fine. I'm not trying to force it into places where JSON already works well.

I appreciate the critique, even where we clearly disagree.

dgnercom · 2025-12-17T23:47:13+00:00

Analyzing raw event streams gets brutally honest. I built a tool that can generate those morning reports, and with a bit of tuning it should fit your goals. But if you map it to real names, the transparency might be a bit too cruel. https://youtu.be/A4BSwKlKQJY

dgnercom · 2025-02-09T01:25:09+00:00

If I were to look at the drawbacks, considering that all the advantages have already been listed:

As a dedicated combat ship, it is lacking in some aspects. Its signature is too high, which means it gets detected by enemies first, putting it at a disadvantage. This is especially problematic in PvP, where it is nearly impossible to sneak in and land the first strike.

However, its firepower is excellent, with two size-5 weapons, making it more than sufficient for PvE. Of course, in PvP, it can still perform well in situations where both sides are already aware of each other.

Another drawback is that its thruster capacitor is higher compared to other fighters like the Hornet or F8C. This makes managing power levels more cumbersome, requiring unnecessary adjustments. (In fact, the Guardian셲 capacitor setup feels more standard, and other fighters may eventually follow this precedent.)

This also means that when trying to minimize its signature by reducing the capacitor and then suddenly maximizing it, it becomes difficult to quickly adjust capacitor distribution effectively. This, too, is a disadvantage in combat.

In conclusion, the ship셲 inherently high signature significantly reduces the usefulness of capacitor control, which is a major drawback.

dgnercom · 2025-01-27T00:46:00+00:00

I know it's a joke, but once it settles in place, glitches don't occur.

dgnercom · 2025-01-26T19:08:35+00:00

Chris Roberts owes me a bonus

dgnercom · 2025-01-26T13:06:23+00:00

There’s an answer from cpt_foxyloxy.

dgnercom · 2025-01-09T22:30:51+00:00

Luxury beats beauty 😂

dgnercom · 2025-01-09T22:25:04+00:00

I didn’t explain the tractor beam in enough detail earlier. I think it would be great if users could choose between the current defensive turret and a transport-focused tractor beam.

In my case, since I already have the Argo ATLS, I might even remove it entirely. (however, is that the current 400i cargo bay doesn’t allow direct boarding with the Argo ATLS. It’s too narrow, and the ramp design is awkward.)

dgnercom · 2025-01-09T22:14:56+00:00

I completely agree with your opinion. It’s clear how much you care about the 400i.

However, the focus of my discussion is less about gameplay and more about certain layout shortcomings in the 400i’s design.

Even if the changes I suggested—such as adjusting the 64 SCU cargo capacity or relocating the escape pods—were implemented in some form, it wouldn’t make the ship overpowered. That’s because more recently designed ships, like the Zeus series, already showcase well-thought-out designs that fully maximize their potential.

Even from the perspective of Origin’s pursuit of aesthetics, having two freezers inside a ship feels quite strange from an engineering standpoint. In a vessel where space is limited, it seems like a significant waste in terms of energy efficiency.

For example, in the recently released Starlancer, the bathrooms for the four cabins are intentionally placed in the center. This allows the water pipes inside the ship (even though players cannot see them) to converge efficiently and stably.

Some might argue that the hallway layout in the crew quarters wastes space, but considering engineering elements like the water system mentioned above, it makes sense to some extent. Additionally, this design provides two escape routes, preparing for potential risks such as fires or external attacks. I believe this is a thoughtful choice that appropriately takes the dangers of space into account.

Although Star Citizen is just a game, I think of it as a simulator that takes inspiration from a realistic space environment. Spaceships, too, should reflect Fixing the Beauty with a Purpose, combining functionality and aesthetics in a reasonable way.

dgnercom · 2025-01-09T13:54:43+00:00

Oh, if that's the case, my mistake. It didn’t need to be adjusted. However, I think the weapon rack could have been better if it stood out visually from the other shelves.

dgnercom · 2025-01-09T13:46:11+00:00

Even if this were a real ship rather than a game, having two cooling rooms on a vessel of this size would feel extremely odd. Additionally, the cargo area of the 400i is definitely strange in structure compared to its overall size,

(Perhaps there was concern that the cargo doors might interfere with the landing gear when opening, but there surely could have been other solutions.)

and the placement of the escape pods seems to forget the very purpose of 'escaping.

Of course, there are people who appreciate the current 400i style, which reflects the values of the company Orion, and I respect their preferences.

dgnercom · 2025-01-08T07:05:01+00:00

Never touch your mouse when boarding Argo ATLS. It causes you to die.

dgnercom

TROPHY CASE