Alternatives ?

[Skids]

Pascal. One of the very few languages ever that had two handler types.

I see. Also wasn't Pascal similar to Xtalk in being quite verbose; I seem to remember that moving from BBC Basic to Turbo Pascal and Delphi was not difficult whereas C looked like someone had spilled braces characters onto the page.

[richmond62]

Cripes: I suffered PASCAL V way back in 1984 at University, and was extremely glad when I was able to leave it behind.

My project crashed the University computer because it took more than the 2 MB RAM available.

And I can remember nothing about the language at all.

However: Yes: Moving from FORTRAN to BASIC was very easy indeed: then I had a 6 year gap with no computer programming at all, and then PASCAL: seem to remember the whole thing was not difficult at all: although the shocking concept of NOT having line numbers took a bit of getting used to.

[richmond62]

Mind you, I do not quite understand why xTalk having both functions and commands should be such a concern.

[Skids]

I don't think it's much of a concern although it could be argued that having the two makes the syntax more complicated than it needs be.

For example if both commands and functions were written as functions then the only change needed in a definition would be to include the return statement and also the code that uses the return value.

e.g.

put myFunctionName(paramA, ParamB) into tAnswer -- standard function

or

myFunctionName(paramA, ParamB) -- Alas this does not work

but the following does work although I can see no point in using it.

Code: Select all

on mouseUp pMouseButto
   put NonReturnFunction() into tReturn
   --NonReturnFunction()  # Does not work with or without brackets
   call NonReturnFunction()  # This works as does using put
   
   wait 5 seconds
   put empty into field "report"
end mouseUp

function NonReturnFunction
   put "This was populated by a function that has no return statement." into field "report"
end NonReturnFunction

[FourthWorld]

Mind you, I do not quite understand why xTalk having both functions and commands should be such a concern.

Intrinsically, it's a very minor additional contribution to cognitive load, so unlike anything else commonly used in the 21st century, and likely offset by other learnability benefits of the language.

But it can help us understand the declining popularity. Most other popular languages have enough common design features that learning another one is often easier than learning and xTalk.

[dandandandan]

In the same way that

5 + 8 * x

Is a lot more concise than

Get 8
Multiply 5 by it
Add 5 to it

Despite being “harder”…

HyperCard was very creative and HyperTalk was a fantastic stab at beginner level coding, coining the term scripting just for it. It was mercifully free of syntax, but there was a very low ceiling for complexity. Hard things were just too hard to do. It fit the path at the time towards simplifying things, and tossing around check boxes and buttons and things to click on with a mouse.

Programmers have sort of given up the quest for English clarity in programming languages. I think everyone wants code to be readable, in the sense that you can verbalize the syntactical aspect. Calling functions functions is normal, calling them as f(…) is an expected level of complexity.

I see live code script and it just feels bizarre to me shoehorning complex concepts into semi English. I see the additions they want to add that are JavaScript already. That tells me they can tell what direction to go. But the web took over this space completely years ago. There are ways to support xtalk but I assume they all require learning the modern way of scripting first.

[OpenXTalkPaul]

I see live code script and it just feels bizarre to me shoehorning complex concepts into semi English. I see the additions they want to add that are JavaScript already. That tells me they can tell what direction to go. But the web took over this space completely years ago. There are ways to support xtalk but I assume they all require learning the modern way of scripting first.

Which complex concepts are you thinking of here? I think many complex concepts could be made more english readable. Put element 1 of myArray into element x of myOtherArray ... is pretty readable to me, as is: set myProperty of myObject to myValue.

There's also Extension Builder, which has slightly different syntax and is more a hybrid language with strong (but not strict) variable typing. It has syntax for defining syntax in language modules. At one time their stated goal was to eventually 'bootstrap', build the whole thing with itself. It was developed as part of an 'Open Language' ambitious goal never quite reached.

Over all, I think they did pretty well in extending xTalk mostly without straying too far from the original. Although I preferred how certain things like menus/menuitems/doMenu worked HyperCard. I seems they tried to keep syntax compatible with other xTalk implementations (Plus/Oracle Media Objects, SuperCard, etc.) over the decades so I imagine that shaped LC Script to some degree.

HC was limited but it also had the benefit of extensibility via resources/XCMDs/XFCNs so there were multiple 'community' created implementations for things like array handling or binary file read/write (there was no 'null' keyword in HC so it couldn't even handle that 'natively'). I think HC would've had to change significantly if it had been developed past mid-1990s v2.4.1.

[OpenXTalkPaul]

As for alternatives, I would say JavaScript, Python, Lau may be on the easier side and most useful languages to jump ship to for xTalkers. There's lots of other languages that look fairly readable to me. I like some of the ideas with Ring (lang). None are as readable as xTalk style.