> It seems that elderly nowadays are super vary of any hacking or scams. YMMV.
I'm sure you meant "wary". How amazing, education really does work. There is such a thing as overabundance of caution. But it's possible further education could encourage users to apply more balanced caution policies.
> Have you guys never done IT tech support for your elderly parents' computers?
This kind of comment is frequently made on HN and elsewhere. However, more than a few "elderly parents" are as computer-sophisticated as their grown children. A safe bet it's not rare to be exchanging ideas with an elderly person sophisticated enough to make comments on HN.
AFAIK there's no shortage of careless, uninformed, non-elderly individuals who get scammed into doing stupid things. Age is only one possible factor out of many contributing to scam vulnerability. And let us not forget that youthful, well-trained professional IT workers, developers and software engineers are not immune to scams via misunderstanding elements of the systems or processes they supervise.
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.
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.
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.
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.
I'm sure you meant "wary". How amazing, education really does work. There is such a thing as overabundance of caution. But it's possible further education could encourage users to apply more balanced caution policies.