Conceivably parenteral capsaicin has different effects on hippocampal integrity or physiology than achievable with ingestion. I'm not familiar enough with disposition of capsaicin in the gut to comment further. My question is whether capsaicin passes from gut into the circulation in any appreciable quantity. I suspect it doesn't but I couldn't say I know for sure. I'll have to add it to the already long list of things I need to look up.

You should take a look at the current releases, you might be pleasantly surprised.

Tcl does have a few disadvantages, for one the lack of distinction between string and list types makes certain programs hard to write. Also the absence of lexical environment for the apply command requires awkward workarounds. Many Tcl users dislike expr syntax.

Warts notwithstanding, Tcl has allowed me to be very productive. Over the years it's been steadily improved, and yet remains mostly compatible with code written even decades ago. That's a rare accomplishment in the programming universe.

AIUI the Iranian attack on Arab countries is strategic, increasing energy costs pressures the US to stop military action. However the US and allies were prepared with set aside oil reserves, increasing supplies from other sources, and reducing Iran's ability to interfere with shipping.

Major warfare always has tragic effects, but against regimes actively pursuing destruction of other nations, return of fire is a rational response.

While programming in C isn't especially difficult for me, writing/reading Scheme is far more satisfying and significantly easier to accomplish. It's certainly true that the visual "shape" of code contributes crucially to grasping what the code is supposed to be doing. But that makes sense for strongly visual learners for whom text is initially an abstract visual form. Extracting the verbal (auditory) meaning is effortful and possibly only partially successful.

Logically we'd expect such fundamental differences to underlie programmers' language preferences. I don't know, but it seems most programmers don't/can't see Lisp/Scheme code as visual shape, regarding it as a non-linear tangle populated by endless parentheses. The connections among brain-related factors and programming proficiency deserve greater scrutiny.

The Chicken C API has functions/macros that return values and those that don't return. The former include the fabulous embedded API (crunch is an altogether different beast) which I've used in "mixed language" programming to good effect. In such cases Scheme is rather like the essential "glue" that enables the parts written in other languages to work as a whole.

Of course becoming proficient in Scheme programming takes time and effort. I believe it's true that some brains have an affinity for Lispy languages while others don't. Fortunately, there are many ways to write programs to accomplish a given task.

I appreciate your comment pointing to the importance of carefully evaluating individuals manifesting new onset delusional ideation or other "mental" disturbance. It might be associated with an obscure condition, but likely enough it's the result of common maladies. The worst error is thinking one knows what's going on before (or not at all) thoroughly investigating the possibilities.

Most trials have long lists of excluded conditions. As you say, one reason is reducing variability among subjects so effects of the treatment can be determined.

This is especially true when effects of a new treatment are subtle, but still quite important. If subjects with serious comorbidities are included, treatment effects can be obscured by these conditions. For example, if a subject is hospitalized was that because of the treatment or another condition or some interaction of the condition and treatment?

Initial phase 3 studies necessarily have to strive for as "pure" a study population as possible. Later phase 3/4 studies could in principle cautiously add more severe cases and those with specific comorbidities. However there's a sharp limit to how many variations can be systematically studied due to intrinsic cost and complexity.

The reality is that the burden of sorting out use of treatments in real-world patients falls to clinicians. It's worth noting level of support for clinicians reporting their observations has if anything declined over decades. IOW valuable information is lost in the increasingly bureaucratic and compartmentalized healthcare systems that now dominate delivery of services.

Ultimately judging what's "best in class" depends on exactly what criteria are applied. How old is the saying "one man's meat is another's poison"?

Anyway, the class of browsers is perhaps the most volatile in the software world, top of the heap changes constantly. But within it there are good examples of quality open-source programs and some that are not free at all. We decide on our own terms which among them is the "best".

I think the question is this: is having totally free cell phones, etc., the essential criterion of success? Or is something less than embodying FSF-style ideology acceptable? To be sure, there's no definitive answer to such a question. But ideological purity is a luxury in the real world that even FSF acknowledges, compromises sometimes have to be made, pragmatic considerations have to be taken into account.

Nothing wrong with keeping lofty goals, but as practical necessity frequently dictates, graciously accepting less than total victory more often than not best serves our interests.

(Edited re: grammar.)

Since the 1990s I've been thoroughly committed to using and developing open-source programs. I strongly prefer using open-source products even when they've been less robust than proprietary options. In recent years, that's changed in favor of open-source, a number of open-source programs have become best-in-class. To name a few Blender, postgresql, Firefox, most developer tools. Still, proprietary products dominate areas like OSs, enterprise programs, etc., and will probably continue to do so.

But even if not as widely used, the fact that quality alternatives exist to a significant share of proprietary offerings speaks to open-source success. It's noteworthy that giants like Microsoft have open-sourced some of their products, a practice unheard of a couple of decades ago that shows influence of the open-source movement.

A winner-take-all philosophy is bound to be as deleterious to open-source advocacy as in any other endeavor. Realistically, producing excellent, bug-free, well-documented open-source software is what it takes to find an appreciative user-base. Perhaps not the majority of users of that category of software, but is that necessary to call a project successful? To say it is seems a prelude to enduring a constant sense of failure and missing out on authentic victories.

However, a connection of particular interest concerns ADHD, a disorder identified as having a strong link to obesity, including common genetic predisposition [0]. Furthermore, individuals with ADHD are also more likely than non-ADHD peers to develop drug dependence, including cannabis-use disorder [1,2]. If ADHD was not among direct or indirect exclusion criteria, the results of the recent study could be misleading or at least incompletely characterized.

    [0] https://pmc.ncbi.nlm.nih.gov/articles/PMC6097237/ 
    [1] https://pmc.ncbi.nlm.nih.gov/articles/PMC5568505/  
    [2] https://pmc.ncbi.nlm.nih.gov/articles/PMC8025199/

More likely than not it's a matter of what a person gets used to. I've enjoyed working in Lisp/Scheme and C, but not so much in primarily functional languages. No doubt programmers have varied histories that explain their preferences.

As you imply, in C one could write nested functions as f (g (h (x))) if examining return values is unnecessary. OTOH in Lisp return values are also often needed, prompting use of (let ...) forms, etc., which can make function nesting unclear. In reality programming languages are all guilty of potential obscurity. We just develop a taste for what flavor of obscurity we prefer to work with.

Fortunately the PS language was very well documented. That made writing PS pretty straightforward, at least for the reasons I was using it. Curiously other concatenative languages have been harder for me to grasp. Maybe that's because I regarded PS as a specific-use tool vs. a general purpose language.

If nothing else PS showed the value of excellent documentation. Lack of it probably accounts for many software project failures, particularly in the open-source world.

"Years of experience" means an increasingly larger population has been subject to use of the compound. It may take 10's of millions of exposures for the problems to become clear enough to elicit action.

A surprising number of drugs (and food additives) have been used for decades before their adverse effects were recognized and the offenders removed from the market.

We should regard initial or early claims of safety as preliminary statements. Indeed skepticism is warranted. Ongoing monitoring/reevaluation is necessary. Certainly utmost caution is needed before allowing products to be widely used.