jrapdx3

Programming in Prolog back in the 1980s was a pleasant experience. I wrote some useful programs with Prolog but as I remember that era, the language made a brief splash and soon relegated to niche settings.

Nowadays I enjoy programming in Scheme, which I'd guess is chosen by developers about as often as Prolog. Using Scheme stirs up memories of my Prolog experience. Intuitively it seems like these PLs require or stimulate a similar thinking process that appeals to some of us. I haven't pursued this idea, but it lingers in my brain.

Curiously both PLs were developed in the early 1970s and first official versions released in 1975. Is it possible the authors of Scheme knew about and were influenced by Prolog? Not too likely, but Prolog's creators did spend some time at MIT, the birthplace of Scheme, so the odds are a bit better than 0.

If you doubt that it's true, do a bit of research and find out if it's so.

Here's one source[0], there are others.

[0] https://en.wikipedia.org/wiki/Mummy_brown

The value of exploring tombs for the purpose of illuminating ancient cultures is inestimable. It seems humans have always been happy desecrating burial sites if not for treasure then to prove dominance over another tribe or nation.

Of course some exploitation is beyond permissible. Back in the 18th and 19th centuries there was an artist's pigment called Mummy Brown. It was sold for many decades, a rich, transparent brown unlike other brown pigments. It was made from actual mummies scrounged from unknown sources in Egypt. These were not the remains of royalty, rather these mummies were those of common people. Apparently until the early 20th century there was an ample supply of these remains to satisfy demand. Eventually the availability of mummies diminished and by 1915 the pigment quality became erratic and subsequently disappeared from the marketplace.

Comparatively, respectful exploration of ancient tombs is a whole different program than things our species has demonstrated a willingness to do.

I find it interesting that a number of PLs were initially developed as educational or research tools but later expanded for general use. Some examples are Pascal, Scheme, Prolog. AFAIK many development languages are used in education so the distinction is rather fuzzy.

Several Scheme implementations, e.g., Chicken, Chez, Gambit, are capable of producing almost any type of program. I'm most familiar with Chicken Scheme. Comes with a large "standard" library plus a broad range of available extensions. Its easy to use FFI adds to productivity.

My experience anyway. Of course, mileage varies widely among users of any language.

How right you are! I use PowerShell when I have to.

Seems like PS was designed under the motto, "The choice: why make it simple when we can make it complicated?"

Scheme language is very well-suited for producing websites, I've been doing that for several months with decent results. But unless I missed information, I think you're right that has nothing to do with WebAssembly. However I know Scheme->wasm compilers exist if unsure of their status.

Of course many languages can be used to create or serve websites. If language doesn't matter, then why not Scheme? It's at least as capable as the languages mentioned. OTOH much less is written about Scheme vs. more "mainstream" languages. Maybe that does make a difference.

I'm a physician, an old one. We're lucky to live as long as we do, but life will end. The article emphasizes the value of dying peacefully. Sure, that's how we want it to be, but we have to make it known to assure it goes that way.

Don't know what happens elsewhere, but every time I see a doctor someone asks if I have a signed, notarized directive. Yes, I've done that, but so should everybody else concerned about the issue.

I have asked aged patients the same question. More than not the answer is "no". Why haven't you? Various versions of "on my list of things to do". We can't really predict future events, in our own interests best to be prepared. Some will take the hint, more than not, people procrastinate.

At least I've done what I can do, but we can't save people from themselves. Maybe people in healthcare are more aware of what's at stake, but everyone has the option to make it as clear as possible their wish (no, their demand) to die in peace.

IIRC SQLite originated as a Tcl extension. In Tcl at the user level "everything is a string" or a number. So it's logical SQLite would accept values as a string or number. Interestingly a Tcl function defines its own semantics, an input value means whatever the function says it means, perhaps a timestamp. SQLite inherited these attributes, and as many commenters observe, SQLite largely continues to work that way.

Implies documentation is crucial. Fortunately SQLite's documentation is among the best out there.

Thanks for the hint! Didn't know about zellij, but indeed looks very interesting. Downloaded and will try it out.

I was having similar thoughts about building UIs back in the late 90s and a few years thereafter. There were a number of tools, I remember using Tcl/Tk to create a GUI scheduling program that was relied on for many years. Later on we had Delphi and numerous others. I suppose building for the web was so much more complicated because the HTML/CSS/JS infrastructure was ill-suited as a basis for comparable GUIs.

Of course many, even most, painters do sketch what they intend to paint, likely that's the predominant technique.

But it's not universally true, particularly among artists working in the last 100 years or so. Certainly Jackson Pollock (whether one regards his work as good or not) didn't sketch out how he was going to distribute paint onto canvas. Another example is Morris Luis (and other "stain painters") who didn't sketch out how he applied paint to canvas.

You're comment is largely correct, just pointing out that more than a few "decent artists" didn't (or don't) work that way.

I've long regarded the great variety of chilis as its own distinct food group. But wonderful as they are for flavoring food, quite often in my home, I'm not sure how much of an effect orally consumed capsaicin has on memory functioning.

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.

AFAIK the answer is an emphatic yes, a lot has changed since 2005. Tcl9 was recently released and has many new features. As far as Tk goes, for a number of years we've had "themed Tk" or Ttk widgets, much better styling, resembles native widgets quite closely. Ttk widgets aren't as configurable as regular ones, well, everything has tradeoffs.

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

Yes indeed, I concur completely with your comments. I've used Tcl/Tk for a few decades and for a long time enjoyed it's Lisp-like character. Of all GUI toolkits Tk is by far the best thought out, no wonder it's been adopted by a number of other languages.

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.

Probably not what most on HN would think of, but for writing a simple app with a GUI, I'd suggest that Tcl/Tk is hard to beat. Of course the simple approach wouldn't suffice if the program had to be compiled to a native binary. Though Tcl/Tk has an excellent C API, so a binary version of the app could be built if considerably more work to accomplish.

A very good response to the parent comment and summary of the current situation.

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.

Though I haven't endured the "spinning" as described in the OP, I do appreciate how the "shape" of text promotes or inhibits comprehending it.

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.

Chicken indeed interoperates with C quite easily and productively. You're right that the generated C code is mostly incomprehensible to humans, but compiles without difficulty.

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.

Perhaps a bit tangential to the main topic, but it is of course true that UTIs can adversely affect cognition in the elderly, even precipitate delirium, etc., depending on type and severity of infection. Naturally that also occurs with other sources of infection, and factors including intoxication due to drugs (prescribed or otherwise) and a host of others. Vulnerability to such decompensation is greater among those already functioning marginally. As such accurate diagnosis can be hard to establish particularly when multiple factors are implicated, hardly a rare circumstance. (At least in my physician-practice that's frequently been the case.)

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.

Having been an "investigator" in a few phase 3 and 4 trials, it is true that all actions involving subjects must strictly follow protocols governing conduct of the trial. It is extremely intricate and labor intensive work. But the smallest violations of the rules can invalidate part of or even the entire trial.

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.

Couldn't disagree that FF has its deficits, IME it's not the best browser for videoconferencing. OTOH FF provides top-quality developer tools. And AFAIK preserves user privacy better than certain other browsers, Chrome being the poster child for the issue. FWIW FF remains unique and influential.

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".

Sure, the FSF is as idealistic as it has been influential. Can't fault FSF for unrelenting commitment to stated purposes. While the totally free OS was a goal that never quite materialized, a large proportion of modern open-source systems is composed of free (in the FSF sense) software. What FSF advocates has indeed mattered.

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.)

This topic provokes a question, what exactly is "winning" anyway? As others point out, how could there be absolute winning, or complete dominance of the whole gamut of software used for every purpose. Of course, no one ever proposed such a definition of open-source success.

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.

Yes indeed, holding up over time is not characteristic of digital technologies. To be sure I owned all of the "ancient" storage formats you mention, and down in the dark corner of my basement some of the old denizens still abide if not actually used. From time to time it's painfully evident that optical drives have all but disappeared too. We're all writing in electronic sand, endurance of our messages, ideas and creativity seems hardly a high priority.

In studies of monozygotic twins (shared genetic predisposition), typically the twins were raised in different environments (adoption, etc.). If behavior among the twins is divergent then environmental factors are likely predominant. OTOH if concordance of traits is strongly evident, behavior is attributable to genetic factors.

It is indeed a win. It's long been established that for obese individuals even 5% weight loss reduces comorbidity of obesity-related conditions. Of course greater weight loss, 10-15%, gives better outcomes. Typically the difficulty is maintaining lower weight for the long haul. For those who can do it the payoff is substantial.

After reading the article and the comments on this page, I also think it's unclear what exclusion criteria were used to select the cannabis using and control cohorts. Controlling for likely and unlikely confounding variables is essential in this kind of study. Obesity is a notoriously heterogenous condition with a great number of inheritable and environmental contributors which makes the task especially difficult.

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/

Interesting comment. I found the lisp/sexpr form instantly understandable. While the others weren't hard to grasp it took a moment to consciously parse them before their meaning was as clear. Perhaps the functional arrow notation is least appreciated because it's seems more abstract or maybe the arrows are just confusing.

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.

Absolutely. Years ago writing programs for *BSD/Linux, PS was the natural, most direct way to implement printing to printers equipped with a PS interpreter.

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.

Well, Tcl is kind of a mixture of scope rules. In some respects, e.g., within a proc, it's mainly a lexical environment, but of course dynamic scoping is introduced by commands like upvar/uplevel. FWIW Tcl programmers don't concern themselves very much with sorting out dynamic vs. lexical. In any case, Tcl programmers are careful to maximize static scoping. No doubt that's necessary to create reliable larger programs many of which have been written in Tcl.