(tl;dr you are confusing symptoms of a disorder with its root cause. See evidence below.)
I don't understand, are you suggesting that overconsumption / overstimulation behavior is / could be the cause of ADHD?
Because they certainly are effects and symptoms (not root cause) of ADHD, this is a well established fact, kind of core part of ADHD literature and research, actually... (I mean: dysregulation of dopamine; impulse control (lack thereof); higher substance abuse risk (esp. when unmedicated)).
While excessive screen time or poor diet can exacerbate executive dysfunction or poor sleep in any human (esp. child), they do not create the neurodevelopmental deficits that define ADHD. Taking away a video game does not repair a child's dopamine transporters.
I feel there is enough literature to substantiate this. I'm interested in this because I have a clinical diagnosis of ADHD which I got only in adulthood, but better later than never; getting the diagnosis has absolutely helped me in life, in various respects.
By the way: I recognize that in certain countries, ADHD may be overdiagnosed (idk, though); medications overprescribed (again, idk, but acknowledging the risk here; not here in Baltics (LT) though, I think);
AND - what ruffles my jimmies PARTICULARLY - prevalent overuse of ADHD term and culture of (over)self-diagnosis of ADHD in social media and elsewhere (general culture, too; I hate that so much, I believe it contributes to such one-sided unscientific docs as well as not-scientifically-grounded viewpoints).
Those over-self-diagnosing people really do not help the rest of us, to put it mildly.
As for canonical evidence and studies:
1. The World Federation of ADHD International Consensus Statement: 208 Evidence-based conclusions about the disorder (Faraone et al., 2021) - https://pubmed.ncbi.nlm.nih.gov/33549739/
I'd strongly disagree, Go panic mechanism (but not just in the runtime sense but also in language feature sense) is quite distinct from what we typically understand "exceptions" to mean (which - esp. depending on language - are not at all just about handling programmer error). I think this is a decent article on exactly this: https://medium.com/@AlexanderObregon/why-go-panics-are-diffe...
But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure. Not so in Go. (Not implying some one model is better here, just flagging that panic vs exception are sufficiently distinct in meaningful (and deliberate) ways such that we can say they are "different", imho).
Debatable. It correctly identifies that an exception is data structure (object), but claims that Go doesn't create one, even though it clearly does as it will plain print the contents of that "object" if you don't catch the exception. I will grant you that it doesn't pass the exception by value, which is different than in some other languages, but that's an implementation detail.
Furthermore it seems to claim that Go using basic stack unwinding precludes it from it having exception handlers, but that's an implementation detail too. Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers?
Funnily enough, it is Javascript, not Go, that doesn't create the exception object automatically. You have to manually initialize the poorly named Error type manually (`new Error(...)`) in your code in order to create an exception. But that also is just an implementation detail.
> But just imagine how exceptions typically have a whole propagation mechanism and type (=> catch) structure.
What's typical? We do see some more advanced exception handling systems out there, but Javascript's is just as simple as Go's (in some cases even simpler), yet nobody that I have ever met claims that Javascript doesn't have exceptions/exception handlers. The one thing Javascript does have that Go doesn't is try/throw/catch syntax, but, of course, you can easily emulate that if you're really hung up on trivial appearances: https://go.dev/play/p/aXS5WEziLzS Exception handlers aren't defined by any particular syntax. That, again, is an implementation detail. Go does have syntax for exception handling even if its syntax is unique.
Hey, I forgot to reply, but still wanted to quickly respond and to say - thank you for the detailed response, I concede your points are valid, and your perspective seems to be more accurate (with regards to incorporating nuance + reality fit) :)
> Javascript also uses basic stack unwinding. Would you also say Javascript doesn't have exceptions or exception handlers?
No, I wouldn't, so re: that - fair point;
For me, Go's error+panic lack of propagation + lack of exception type hierarchy are what stick out and seem vastly different to "typical"; and this does impact development, especially propagation mechanism / lack thereof. But I also haven't written lots of Go code, and could be possibly lacking experience, and am just looking from "typical" language lens (Java (not JS), Python, from my PoV)?
You mention "end to end encrypted comms", where to you see end to end there? Does not seem end to end at all, and given that it's very much centralized, this provides... opportunities. Simon's fatal trifecta security-wise but on steroids.
- this smells like unintentional decent C2 infrastructure - unless it is absolutely intentional, in which case very nice cosplaying (I mean owner of domain controls and defines everything)
> Isn't every single piece of content here a potential RCE/injection/exfiltration vector for all participating/observing agents?
100%, I wonder when we get LLM botnets (optional: orchestrated by an agent), if not already.
The way I see prompt injection is, currently there is no architecture for a fundamental separation of control vs data channels (others also think along similar lines of course, not an original idea at all). There are (sometimes) attempts at workarounds (sometimes). This apart from other insane security holes.
edit p.s. Simon has been talking about this for multiple years now, I should mention this in fairness (incl. in linked post)
This is a funny chain.. of exchanges, cheers to you both :)
At the risk of ruining 'sowbug having their fun, I'm not sure how Julian Jaynes theory of origins of consciousness aligns against your assumption / reduction that the point (implied by the wiki article link) was supposed to be "I am only my brain." I think they were being polemical, the linked theory is pretty fascinating actually (regardless of whether it's true; and it is very much speculative), and suggests a slow becoming-conscious process which necessitates a society with language.
Unless you knew that and you're saying that's still a reductionist take?.. because otherwise the funny moment (I'd dare guessing shared by 'sowbug) is that your assumption of fixed chain of specific point-counter-point-... looks very Markovian in nature :)
(I'm saying this in jest, I hope that's coming through...)
edit but also see cons[3] - maybe viable for very constrained domains, with strict namespace management and handling drop into debugger. Also, after thinking more, it likely only sounds nice (python vs lisp training corpus and library ecosystems; and there's mcp-py3repl (no reflection but otherwise more viable), PAL, etc.) Still - curious.
In theory (I've seen people discuss similar things before though), homoiconicity and persistent REPL could provide benefits - code introspection (and code is a traversable AST), wider persistent context but in a tree structure where it can choose breadth vs depth of context loading, progressive tool building, DSL building for given domain, and (I know this is a bit hype vibe) overall building up toolkit for augmented self-expanding symbolic reasoning tools for given domain / problem / etc. (starting with "build up toolkit for answering basic math questions including long sequences of small digits where you would normally trip up due to your token prediction based LLM mechanism"[2]). Worth running some quick experiments maybe, hm :)
P.S. and thinking of agentic loops (a very uh contemporary topic these days), exposing ways to manage and construct agent trees and loops itself is (while very possibly recipe for disaster; either way would need namespaces not to clash) certainly captivating to me (again given effective code/data traversal and modification options; ideally with memoization / caching / etc.)
[3] cons (heh): hallucination in the metaprogramming layer and LLMs being fundamentally statistical models and not well trained for Lisp-like langs, and inevitable state pollution (unless some kind of clever additional harness applied) likely removes much of the hype...
- `FEATURE_IMPL_PLAN.md` (master plan; or `NEXT_FEATURES_LIST.md` or somesuch)
- `FEATURE_IMPL_PROMPT_TEMPLATE.md` (where I replace placeholders with next feature to be implemented; prompt includes various points about being thorough, making sure to validate and loop until full test pipeline works, to git version tag upon user confirmation, etc.)
- `feature-impl-plans/` directory where Claude is to keep per-feature detailed docs (with current status) up to date - this is esp. useful for complex features which may require multiple sessions for example
- also instruct it to keep main impl plan doc up to date, but that one is limited in size/depth/scope on purpose, not to overwhelm it
- CLAUDE.md has summary of important code references (paths / modules / classes etc.) for lookup, but is also restricted in size. But it includes full (up-to-date) inventory of all doc files, for itself
- If I end up expanding CLAUDE.md for some reason or temporarily (before I offload some content to separate docs), I will say as part of prompt template to "make sure to read in the whole @CLAUDE.md without skipping any content"
Agree re: no need for heap allocation - for others: I recommend reading thru whole masscan source (https://github.com/robertdavidgraham/masscan), it's a pleasure btw - iirc rather few/sparse malloc()s which are part of regular I/O processing flow (there will be malloc()s which depending on config etc. set up additional data structs but as part of setup).
Have you looked at https://vvvv.org/ ? Maybe it's still comparatively too heavy but imho it's not that heavy (cf. touch designer and the likes). I want to play with it some more myself...
I don't understand, are you suggesting that overconsumption / overstimulation behavior is / could be the cause of ADHD?
Because they certainly are effects and symptoms (not root cause) of ADHD, this is a well established fact, kind of core part of ADHD literature and research, actually... (I mean: dysregulation of dopamine; impulse control (lack thereof); higher substance abuse risk (esp. when unmedicated)).
While excessive screen time or poor diet can exacerbate executive dysfunction or poor sleep in any human (esp. child), they do not create the neurodevelopmental deficits that define ADHD. Taking away a video game does not repair a child's dopamine transporters.
I feel there is enough literature to substantiate this. I'm interested in this because I have a clinical diagnosis of ADHD which I got only in adulthood, but better later than never; getting the diagnosis has absolutely helped me in life, in various respects.
By the way: I recognize that in certain countries, ADHD may be overdiagnosed (idk, though); medications overprescribed (again, idk, but acknowledging the risk here; not here in Baltics (LT) though, I think);
AND - what ruffles my jimmies PARTICULARLY - prevalent overuse of ADHD term and culture of (over)self-diagnosis of ADHD in social media and elsewhere (general culture, too; I hate that so much, I believe it contributes to such one-sided unscientific docs as well as not-scientifically-grounded viewpoints).
Those over-self-diagnosing people really do not help the rest of us, to put it mildly.
As for canonical evidence and studies:
1. The World Federation of ADHD International Consensus Statement: 208 Evidence-based conclusions about the disorder (Faraone et al., 2021) - https://pubmed.ncbi.nlm.nih.gov/33549739/
2. Dr. Nora Volkow's dopamine research (e.g. JAMA, 2009) - https://jamanetwork.com/journals/jama/fullarticle/184547
3. Dr. Russell Barkley's Theory of Behavioral Inhibition (see e.g. his long talk directed towards parents of ADHD children, if curious; on youtube)