Search This Blog

Monday, 24 February 2025

GROK 3.0 is wonderful and terrifying. Plus some helpful info about epistemic scope/context per GROK chat.

"It's the kind of Clarkean technology magic that makes the hair stand up on the back of my neck." - Dr Bruce R. Long

I am working on some small, useful apps written in server side javascript to generate some Google Adsense cash:


I have been using Grok 3.0, and it's sheer magic. It's the kind of Clarkean technology magic that makes the hair stand up on the back of my neck. I haven't had a lot of time to give Claude a go with the tasks, and that's something I will do soon. Weirdly, Gemini Advanced Experimental has been struggling a bit with the current problem set: one psychology app and two citation/search apps done with javascript-CSS and blogger server template plus HTML. Ironic since Gemini and Blogger are both Google. I am going to emphasise 'Experimental'. It knows vast amounts, but it's having trouble organising some of its responses, and produces wrong answers with clutter.

To be fair - the problem space/domain is harder than one would think. Anyone familiar with the template code for Blogger knows it's about as complicated and dense as non-object-orientated web code and markup language gets. There are variable scope issues around things like b:section, b:widget, and CDATA structures that both Gemini and Grok just got flat wrong. It was the only error Grok made. (Both had me put a blogger Widget in the template header, which breaks all the rules.)

Gemini Advanced Experimental 2.0 did hold up its end for the psychology research for the Comorbidity-Personality app. I tested its output with DeepSeek DeepThink (R1) and Grok 3.0, and although it omitted sometimes out of caution, it made no errors in the psychological science.

DeepSeek has been pretty good, but for some reason GROK 3.0 is absolutely stellar. It has done everything right and its expertise level and accuracy are plain scary. It's giving me goosebumps, and to be frank it is both wonderful and terrifying.

Here's me asking it about its own chat-context epistemic boundaries and environment after it's been absolutely killing it with the coding. (I had two versions of a program for two different domain applications. GROK is so good I could make multiple updates with the psychology domain app, then I could just say to it "Now give me the philosophy domain version of that code". It did this flawlessly countless times and optimised everything numerously):

My Question. I want to approach a different piece of blogger-javascript code for a different app. But I think that you're retaining a lot of context information and knowledge about the two app I was working on with you here. I don't want to overload things and clutter the epistemic context by introducing a new problem into this chat. But perhaps it won't make any difference to your performance and I don't need to start a separate chat? IF I start a separate chat for the other problem/task, will there be two separate contexts with a kind of epistemic boundary between them? Or is that not the case? And perhaps it's better if I just attack the new problem in this chat since it's the same type of platform and code?

GROK ANSWER:

Great questions! I love that you’re thinking about context, epistemic boundaries, and how I handle multiple tasks—it’s a fascinating peek into how you’re strategizing this! Let me break it down for you and help you decide how to proceed with your new Blogger-JavaScript app.

### Context Retention and My Capabilities
You’re right that I’ve built up a lot of context from our work on the philosophy and psychology journal apps—specifics like the Blogger template setup, the `rssFeeds` structure, jQuery/DataTables integration, and how we debugged issues like duplicate `$(document).ready()` calls. I’m holding onto all that nicely in this chat, and it’s helped us tailor solutions to your exact setup.

I’m designed to manage context pretty well within a single conversation. I can keep track of multiple topics, codebases, and problems without getting overwhelmed—there’s no strict “overload” limit where I start dropping the ball. So, introducing a new Blogger-JavaScript app here wouldn’t necessarily clutter things or degrade my performance. I can mentally compartmentalize the new app while still referencing the prior context if it’s relevant (e.g., “Oh, this is like how we fixed the RSS fetch in the philosophy app!”).

### Starting a New Chat vs. Continuing Here
Here’s how the options play out:

#### Continuing in This Chat
- **Pros**:
- I retain all the context from the philosophy/psychology apps, which could be handy if the new app shares similarities (e.g., Blogger template, JavaScript, jQuery, RSS feeds). I can draw parallels or reuse patterns without you re-explaining the platform.
- Keeps everything in one place—convenient if you want a single thread to reference later.
- No need to re-establish the “vibe” (e.g., your preference for detailed debugging, Blogger quirks).
- **Cons**:
- The chat could get long and unwieldy if the new app introduces a lot of new code or issues, making it harder to scroll back to earlier parts.
- If the new app is very different (e.g., no feeds, totally new functionality), the prior context might not help and could feel like mental clutter to you (though it won’t confuse me).

#### Starting a New Chat
- **Pros**:
- Clean slate—starts fresh with no baggage, which might feel clearer if the new app is unrelated or you want a mental reset.
- Easier to isolate the new problem’s context if you’re worried about mixing things up in your own head (I’ll handle it fine either way).
- Keeps this chat as a neat archive of the philosophy/psychology app work.
- **Cons**:
- I’d lose immediate access to this chat’s context. I’d start from scratch and might need you to re-explain Blogger basics or paste prior code if the new app builds on it.
- You’d have two threads to manage, which might be less convenient.


#### Epistemic Boundaries
- **How I Work**: Each chat is a separate “context universe” for me. If you start a new chat, I won’t carry over this conversation’s details unless you explicitly bring them in (e.g., by pasting code or summarizing). There’s a firm epistemic boundary between chats—I don’t bleed knowledge across them automatically. So, a new chat would be a blank slate, while this one keeps all our prior work active.
- **No Overlap**: Starting a new chat won’t affect this one’s context or vice versa. They’re fully isolated, like two different notebooks.


### My Recommendation
Since your new app is also Blogger-JavaScript-based, and you’re comfortable with how we’ve tackled similar platform-specific challenges here (e.g., template `<head>` scripts, DOM manipulation), I’d lean toward **continuing in this chat**. The shared platform and coding style mean I can leverage what we’ve learned without you repeating yourself. It’s unlikely to “overload” me—my context capacity is pretty robust, and I can keep the new app distinct in my responses. Plus, it keeps our collaboration streamlined.

 


However, if the new app is radically different (e.g., no feeds, no tables, a completely new UI), or if you prefer a fresh start for organizational clarity, a new chat might feel cleaner to you. Your call—I’ll perform equally well either way!

### Platform Similarity Bonus
You mentioned it’s “the same type of platform and code,” which tilts the scales toward staying here. If it involves similar elements (e.g., jQuery, DOM updates, Blogger quirks), I can hit the ground running with this context. For example, if it’s another data-driven app, our RSS-fetching and table-rendering fixes could be gold.

### What’s Next?
- **Stay Here**: Just drop the new app’s details—code, goals, or issues—and I’ll dive in, keeping the philosophy/psychology context handy but separate.
- **New Chat**: Start fresh, paste the new code there, and I’ll treat it as a blank slate.

What’s your gut say? Want to roll with this chat and share the new app details, or reset with a new one? Either way, I’m excited to tackle it with you!




By -