OpenXTalkPaul wrote: ↑Sun Jul 28, 2024 2:57 pm
Again, the play command, the APIs that this command relied on have changed so much it's broken and virtually useless now on some platforms, and it never followed (what I call) 'standard' xTalk anyway.
The principle in play was custom behavior merits a custom name. If built-in functions can be altered by libraries, predictable engine behavior becomes an unpredictable runtime environment.
That conversation was part of what led to my xTalk mantra:
Know the engine.
Trust the engine.
Use the engine.
But of course that only works where the engine is well maintained.
If the play command worked (syntactic warts and all), there would be no need to overload.
Indeed, given the syntactic warts, truly overloading the existing syntax isn't the desire here.
But without an engine that can play multimedia, any new syntax is dressing a corpse in a tuxedo: looks great, can't dance.
Scripting languages in general offer this value proposition: we handle the OS APIs so you can focus on application-specific functionality.
Multimedia playback is fundamental. When it works in the engine, details about how to use it conveniently can be worked out with relative ease.
But if the engine doesn't do what it says on the tin, Dr Raney saw that as his responsibility.
doesn't read very English-like, which I always thought was the goal of xTalk.
"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" reminds us of the challenges of attempting "English-like" in any language designed to send unambiguous instructions to a machine.
There is also conciseness, which usually increases learning/reading time up front, for the payoff of years of reduced typing.
For example, I'm grateful I can use the common syntax for arrays:
Code: Select all
put "10000" into tBudgetA["expenses"]["vendors"]["newfees"]
...rather than a more conversational:
Code: Select all
put "10000" into hashbucket "newfees" of hashbucket "vendors" of hashbucket "expenses" of variable tBudgetA
CSS is an extreme of this sort of conciseness, at first mystifyingly sparse, but ultimately replacing hundreds or thousands of lines of code with a very few lean directives (think 2D and
3D transforms, so elegant in CSS, so slow to execute back when we attempted those in JavaScript).
Of course language design is a matter of taste, and there's no disputing taste.
But where any additional learning effort is more than offset by downstream usability, my own tastes tend to enjoy the learning. I no longer see it as "I HAVE to learn that", seeing it instead as "I GET to learn that".
Whether code written for unambiguously telling a machine what to do also happens to read like a conversation with a friend over tea isn't something I think about often. I just want the machine to do what I want it to do so I can go get tea.