Alternatives ?

[Skids]

Hi,

With the present state of affairs I have decided that I should have a back up plan for the time where I can no longer use an Xtalk language other than AppleScript. I have not really followed what has happened in computing over the years so wonder if I can canvas your opinions. What programming languages should I look at and for what reason?

At the moment I am trying Python. I can live with the syntax and am impressed by all the libraries that are available but the creation of user interfaces as far as I can tell leaves a lot to be desired. There is any amount of training materials and books and a very wide user base plus the price and license are right.

S

[FourthWorld]

What programming languages should I look at and for what reason?

I try to avoid telling anyone else what they should use until I know the scope of their needs sufficiently.

For my own needs the easy choice is JavaScript.

The separation of concerns between JS, CSS, and HTML leaves all three able to do what they do well with minimal interference between them.

The language itself is learnable enough, thanks to having such a mind-blowing plethora of learning materials all over the world. And for many UI tasks CSS lets me write just a few lines to do things that would take hundreds in an xTalk.

In the ever smaller number of cases where I need a native app, packagers like Electron are good, and have substantial backing from industry giants making them better every week.

At the heart of it, I cut my teeth back in the day with what was then the world's most powerful scriptable rich media engine, preinstalled on every GUI device of it's time, HyperCard on Mac's

Today the most powerful scriptable rich media engine preinstalled on every GUI device is the browser.

--

For some database-centric projects, I've begun getting back into Drupal. Everything I like about browser features, with a proven backend driven by the most popular server language, PHP.

But I never bother with PHP directly. Drupal is a no-code solution for making database driven apps. Not nearly as flexible as xTalks, more akin to the types of things we used to use FileMaker for. But all of it without having to write a line of code. And if you have some highly specialized need not already addressed among the thousands of community contributed modules, with a little PHP skill and time with the API refs you can add just about anything else you'd need.

--

Another no-code platform I'm enjoying is Nextcloud.

Just as I'm building out all customer-facing infrastructure with Drupal, everything back-office here is run inside Nextcloud.

NC is a hub for collaboration tools. The range of apps included and in its app store is large and growing. The ones I rely for my business include versioned file sync across all my machines, a kanban tool for project management, wiki for internal and client communications, appointment scheduler, calendar, time tracking, and others - all integrated with a single signon, with branding options for a very professional look. They also offer a Forms tool for simple DB apps, and a Workflow subsystem for automating routine tasks.

--

All of these I've mentioned are Free and Open Source, supported by reliably large commercial activity and a great many community contributors.

[richmond62]

The present state of affairs means that everything is just fine unless you have serious mental problems about developing for MacOS 16, 17 18 or whenever Rosetta goes down the pike (I thought I'd pop that phrase in there: I learnt it in Illinois: childish or what?).

I have been flirting with PYTHON and feel:

1. It resembles PASCAL V (which I studied in 1984) too much.

2. It isn't object based.

3. It is too much like hard work just to get anything look like anything I have managed with xTalk over the last 31 years.

Personally between LCC 9.6.3 and OXT Lite 1.10 I have no quibbles whatsoever (that does NOT include the Dictionary that resembles the Hitch-hiker's Guide to the Galaxy).

After all: MOST of the time I use a 32-bit laptop running Debian to develop ESL (English as a Silly Language) standalones with Runtime Revolution 2.2.1 (the FREE version given out by Oracle for Linux about one million years ago).

My Devawriter Pro, Sheba:Makeda, Grendel, and PISMO for writing dead languages in dead writing systems (talk about NICHE) are fine in OXT Lite or LiveCode (and to be 100% honest, it makes not an iota of difference which of the 2 I use) as my clients/victims are all people who either cannot buy the latest computer models/operating systems, or if they can realise that that is NOT the most besetting problem in life.

So: "Alternatives"

There are no 'alternatives' in the strict sense of the word: there ARE entirely different tools for getting similar things done.

Whichever entirely different tool for getting similar things done you choose will COST you an awful long time in getting as skillful with it as you might be with xTalk at the moment: in my case it's not worth the bother.

[Skids]

I try to avoid telling anyone else what they should use until I know the scope of their needs sufficiently.

A fair point: most of the applications I write are for my own use and typically help manage files on my system e.g. copying and renaming image files from an SD card to my image library. Mind you I have just discovered that this application can be replaced with an Automator service that uses the exiftool pearl modules. I have no idea what the general term is, system extension perhaps?

Today the most powerful scriptable rich media engine preinstalled on every GUI device is the browser.

This is an option that I know nothing about. What exactly is possible? Where does the source script have to be stored?

And for many UI tasks CSS lets me write just a few lines to do things that would take hundreds in an xTalk.

Any chance that you would expand on this?

I shall certainly have a look at Javascript after I have finished looking at Python.

Talking of Python:

2. It isn't object based.

Strange as I was under the impression that everything in Python is an object. Perhaps you mean a different type of object i.e. stacks and button objects.

3. It is too much like hard work just to get anything look like anything I have managed with xTalk over the last 31 years.

Yes the creation of a UI does seem complicated but I have not looked at the web page based solutions yet.

There are no 'alternatives' in the strict sense of the word: there ARE entirely different tools for getting similar things done.

Point taken.

will COST you an awful long time in getting as skillful with it as you might be with xTalk at the moment: in my case it's not worth the bother.

Given that you have a number of users of your applications your view is understandable whereas I am my only customer so I am not as tied. I can probably get away with building my two or three applications into apps that will run on App silicon and then use a new language in the future.

S

[FourthWorld]

I try to avoid telling anyone else what they should use until I know the scope of their needs sufficiently.

A fair point: most of the applications I write are for my own use and typically help manage files on my system e.g. copying and renaming image files from an SD card to my image library. Mind you I have just discovered that this application can be replaced with an Automator service that uses the exiftool pearl modules. I have no idea what the general term is, system extension perhaps?

Yours is a use case where the benefits of web tech may not shine as brightly as for others.

You don't need easy deployment across multiple platforms and device types, single user only, and you'll need local file I/O which means setting up Node.js on your system.

If you can find a GUI toolkit you like, Python may be a good bet for what you're doing.

Today the most powerful scriptable rich media engine preinstalled on every GUI device is the browser.

This is an option that I know nothing about. What exactly is possible?

Everything you've ever seen on the web, including this forum where we're having this conversation.

Also probably half the apps on your phone were made with web tech wrapped in a packager like React Native or Electron, including Facebook, Instagram, WhatsApp, TikTok, Twitter, and soooo many others. And lately we're beginning to see more desktop deployments as well.

Where does the source script have to be stored?

You can store JS directly in a page, but as with xTalk behaviors if you want code used across multiple layouts you can store it in a separate file.

And for many UI tasks CSS lets me write just a few lines to do things that would take hundreds in an xTalk.

Any chance that you would expand on this?

Here's an example:
viewtopic.php?t=1301

There are countless others. Microsoft recently published an article about how many thousands of lines of code they were able to replace in Edge with smaller, simpler CSS.

xTalks were richer GUI environments than web tech for most of their history. But with the advent of "Web 2.0" driven by xmlHttpRequest we started seeing true application behaviors in browsers in the early 2000s. There were still trade-offs both ways until a few years ago, but these days web browsers have significantly deeper rich media capabilities.

Consider three areas of interest to UI devs: text, images, and video.

LC 5.5 raised the bar significantly for text handing, adding many powerful new features for paragraph-level formatting, table display, and much more. But all of that is a subset of features available in today's browsers

Same with graphics. LC added Google's Skis engine in a major upgrade for its graphics primitives, also gaining gradients and many other effects along the way. But again, those are a subset of capabilities available with SVG directives in browsers. And browser rendering is so much faster, it's a solid multiple in framerate.

And video. LCs video support on macOS is pretty good, but their Windows implementation lacks some features and was sorely limited in codec support until very recently. And video hasn't worked on Linux at all in years. Browsers handle all platforms very well, with features like callbacks supported on all of them.

The LC team has done an amazing job, unparalleled by any other company of their size.

The engineering effort that goes into browsers takes the best of what Apple, Microsoft, and Google can invest in it, along with thousands of external contributors (much of the core of modern browsers remains the open source WebKit, and JS, CSS, and HTML are all open standards).

That combined force has produced a scriptable rich media engine beyond anything else I've seen in all my years. No single company could possibly replicate that effort.

[Skids]

Yours is a use case where the benefits of web tech may not shine as brightly as for others.

Ok but I also program for my own entertainment and this web tech sounds interesting and powerful.

find a GUI toolkit you like, Python may be a good bet for what you're doing.

I'm about to take a look at NiceGUI https://nicegui.io/#demos

xTalks were richer GUI environments than web tech for most of their history.

Past tense noted.

Same with graphics. LC added Google's Skis engine in a major upgrade for its graphics primitives, also gaining gradients and many other effects along the way. But again, those are a subset of capabilities available with SVG directives in browsers. And browser rendering is so much faster, it's a solid multiple in framerate.

You are beginning to make me regret paying my license fee over the past decade and a half! While I have enjoyed using Xtalk and the forums over the years I can now see that I've isolated myself from what else is available to do similar tasks.

The LC team has done an amazing job, unparalleled by any other company of their size.

O.k. but you give the reason below why there is almost no competition or alternatives below. Others have recognised that it is not cost effective to attempt to develop such a complex language tool in isolation

best of what Apple, Microsoft, and Google can invest in it, along with thousands of external contributors .....
that combined force has produced a scriptable rich media engine beyond anything else I've seen in all my years. No single company could possibly replicate that effort.

I had not realised that the difference between Xtalk and the mainstream was so large. Your post has caused the scales to drop from my eyes: Livecode/Xtalk are in a niche corner and have little or no hope of out competing with the likes of Apple, Microsoft and Google (and I'm sure others).

Thanks for the wake up call.

S

[FourthWorld]

You are beginning to make me regret paying my license fee over the past decade and a half!

I'm paid up for a while, and I have no regrets.

For a wide range of multiplatform desktop apps, there's no easier way to make 'em than an xTalk as powerful as OXT or LC.

The MC engine they acquired is efficient, mature, and robust, and the many enhancements they've made with Skia, Unicode, and the rest have helped it stay very useful for much of what I do. I still have two LC projects in progress right now. For the desktop, unless you need animations, it's pretty great.

Their mobile offering was a good start, but it seems there's never been an effort toward the same level of fit and finish in the workflow that xTalks are famous for. Things like making a scrolling field for mobile is so much more complicated than making one for desktop. And while the work done for remote debugging is very helpful in later stages, the lack of emphasis on responsive design and other UI patterns has obviated many opportunities to spend more time testing mobile UIs right in the IDE, where time is most productive.

A little polish to bring the mobile experience on par with desktop building could allow LC to keep a good foothold.

One of the upsides with the wide variety of web tools is that there are so many, yet that's sometimes also a downside. Lots to choose from, and some work better with others, some less so.

LC"s one-stop-shopping for everything from prototype to deployment is a pretty nice.

I had not realised that the difference between Xtalk and the mainstream was so large. Your post has caused the scales to drop from my eyes: Livecode/Xtalk are in a niche corner and have little or no hope of out competing with the likes of Apple, Microsoft and Google (and I'm sure others).

Thanks for the wake up call.

Yeah, it's funny, like so much of life, it's easy to keep doing one thing, and as long as it's working out why look anywhere else?

As a consultant, the big shift for me came when I noticed my phone ringing less.

Back in the days when LC was marketing actively and promoted their third-party ecosystem, some of the work that needed done fell my way.

A lot of that changed when LCFM became their marketing focus, and marketing the main product nearly stopped altogether. Then after that, they got back into consulting, so third-parties no longer figure into their plan.

So it was clear I needed to pivot to a wider range of service offerings, and while exploring options for rebuilding my web properties I started falling in love with web coding, along with nocode tools like Drupal and Nextcloud.

I'd like to continue also using LC indefinitely if I can, and I have one project in mind that requires GPL so OXT would become the perfect fit if we can get over the Apple ARM hurdle.

The world is full of great tools. There was never a better time to enjoy making software. I'd like to see xTalks remain part of that for as long as we can enjoy them too.

[Skids]

I'm paid up for a while, and I have no regrets.

I have no real regrets but I have decided that enough is enough. RunRev Ltd seem to be always about to implement the next great thing, normally combined with some money generating scheme, then once the dust has settled nothing much has changed. This is one of the reasons that when my LC license expires in the middle of the year I am unlikely to renew.

The MC engine they acquired is efficient, mature, and robust

Perhaps it is. However, the most recent version of LC v10 still suffers from greyed out menus after a few minutes use; the "copy files" build settings just do not work; the auto inclusions often fails to include basic inclusions and I am sure there are many other "minor" issues.
I suspect the revenue generated by license sales and consultancy is insufficient to pay for a development team large enough to support the Livecode engine/s and tools. I can understand why Livecode needs to transition to Create but I wonder if they can afford to fund the transition. The latest two year license for the price of one year suggests that they are strapped for cash (again).

A little polish to bring the mobile experience on par with desktop building could allow LC to keep a good foothold.

While true it has to be paid for.

A lot of that changed when LCFM became their marketing focus, and marketing the main product nearly stopped altogether. Then after that, they got back into consulting, so third-parties no longer figure into their plan.

What ever happened to all the File Maker stuff? Not being a user of File Maker I did not pay much attention but do seem to remember that it was going to be worthwhile and open up a whole new market for Livecode. Did this ever happen?

Are we the "third parties"? I feel more like third class rather than third party as I read that its only the consulting wing of RunRev that is keeping them going and this is the reason why we have to pay more. Hmmm let me think about that.

LC"s one-stop-shopping for everything from prototype to deployment is a pretty nice.

Absolutely.

I have one project in mind that requires GPL so OXT would become the perfect fit if we can get over the Apple ARM hurdle.

The thread Bit Rot suggests that the ARM hurdle presents a very difficult challenge that requires knowledge of C which is a problem as we all self selected to use a high level language to avoid using the likes of C.

The world is full of great tools.

If is. As I have written elsewhere I am trying out Python. The language syntax is fine and I am amazed the power that is contained in libraries. For example a teaching video introduced dictionaries and stored a count of the letters in a piece of text, this was easy and could be done just as well in Xtalk. However the following line made a call to a library that returned a good looking bar graph plotting the character counts. This would be more challenging in Xtalk and require a substack be created (at least that is how I did it years ago when plotting the time of arrival of messages of position beacons). This example torpedos the often made claim that Xtalk saves you time.

best wishes

S

[richmond62]

the often made claim that Xtalk saves you time.

I think that this WAS the case until comparatively recently, but Python and Co. have been playing catch-up extremely well because it has an enormous amount of support and a vast installed base which LC/OXT does not.

This probably comes down to 2 things:

1. Very Bad Marketing (or lack thereof).

2. Complacency . . .

What xTalk does save is quite a lot of cognitive load.

[FourthWorld]

This probably comes down to 2 things:

1. Very Bad Marketing (or lack thereof).

2. Complacency . . .

My list would be:

1. Open Source

2. The Zeitgeist Dice Roll of Cultural Shifts in Computing

The first is a tired subject where too many have been too quick to toss "just" in front of a given proposal to make whatever follows sound easy, and I've long since lost my appetite for the coulda shoulda woulda such conversations spawn.

The only relevant takeaways for going forward is that most languages today are open source, and despite the near-necessity it's not easy to succeed in open source, and given how it ended any possibility of considering a return to FOSS is closed to them forever.

I'm content to have FOSS discussions limited to this FOSS fork. This project's success will determine how easy/not easy it is.

As for zeitgeist:

There is an argument that could be made that if HyperCard were born just eight years later it would look a lot like JavaScript.

This may seem self-evident, but if not here's a clue underlying the argument:

What is the value of having two handler types (commands and functions) as opposed to just one?

Pondering that a few years ago led me down a rabbit hole which led to my current opinion about the timing of the language in the larger context of computing evolution.

[richmond62]

What is the value of having two handler types (commands and functions) as opposed to just one?

None that I can see, and as a result I have always gone for a COMMAND rather than a FUNCTION.

[Skids]

What is the value of having two handler types (commands and functions) as opposed to just one?

Possibly so the specs of the language look good. Otherwise pointless and possibly confusing especially as variables can be passed by reference thus removing the need to return a value.

Python and Co. have been playing catch-up extremely well because it has an enormous amount of support and a vast installed base which LC/OXT does not.

Yes and there is no getting away from this; large companies are invested in these languages meaning they can make cases to spend money supporting its development.

What xTalk does save is quite a lot of cognitive load.

Perhaps it did in the past but I'm not so sure these days. Start using a datagrid and arrays and the load increases. I also find myself bumping into bugs all the time but perhaps thats just me.

Take a look at a snip of Python code:

Code: Select all

sherlock = '''
Mr. Sherlock Holmes, who was usually very late in the mornings, save upon those not infrequent occasions when he was up all night, was seated at the breakfast table. I stood upon the hearth-rug and picked up the stick which our visitor had left behind him the night before. It was a fine, thick piece of wood, bulbous-headed, of the sort which is known as a “Penang lawyer.” Just under the head was a broad silver band nearly an inch across. “To James Mortimer, M.R.C.S., from his friends of the C.C.H.,” was engraved upon it, with the date “1884.” It was just such a stick as the old-fashioned family practitioner used to carry—dignified, solid, and reassuring.

Text cut to reduce the length of this example
'''

letter_count = {}
for letter in sherlock:
   letter_count[letter.lower()] = letter_count.get(letter,0) + 1
  
import matplotlib.pyplot as plt

x,y = zip(*letter_count.items())

letter_count_clean = {}

for k,v in letter_count.items():
   if k.isalpha():
       letter_count_clean[k] = v
       
print(letter_count_clean)     

x,y = zip(*letter_count_clean.items())

plt.bar(x,y) 
plt.show()   

This outputs the following png:

Screenshot 2025-02-01 at 11.59.09.png (12.19 KiB) Viewed 3160 times

Try and do this in Xtalk in sixteen or so lines of code.

S

[tperry2x]

Code: Select all

import matplotlib.pyplot as plt

Try and do this in Xtalk in sixteen or so lines of code.

Well, that's not really 16 lines of code.
import matplotlib.pyplot is depending on the matplotlib, so akin to running another function in xTalk.
I could have 16 lines of code in a button, but peel off to functions and commands in the card. So it looks like 16 lines, but depends on this rather complex library.

Try and do that in Python, without the matplotlib function and see how many lines of code you end up with.

There is already the line graph as a widget, but you've given me an idea for a bar graph stack.

[tperry2x]

I have always gone for a COMMAND rather than a FUNCTION.

A command performs an action but does not return a value.
(it does not return a result)

command.png (20.93 KiB) Viewed 3145 times

A function performs an action and returns a value.
(return [something] gets passed back to the function that called it)

function.png (19.33 KiB) Viewed 3145 times

[Skids]

I have to admit I thought you could get a non function handler to return a result using "return" but I have not been able to get it to work so I will chalk that up to poor memory.

This is a more risky form of returning a value, I write risky because it breaks the rule that a command handler should be self contained.

Code: Select all

On MouseUp
   put "TEST" into  tReply
   ShowMessage "I sent this string to the showmessage command", tReply
   answer "This is in tReply : " & tReply
end MouseUp

On showmessage pMessage, @pReply
   answer information pMessage
   put "There, I displayed your message!" into pReply
end showmessage

S

[Skids]

or use the global theResult as shown by Klaus

Code: Select all

command anyhanlder
  ...
  dothat
  put the result into tReturnedValue
  ## Do somehting with that variable
end anyhandler

command dothat
  ## do something here and output the result
  ## Cheap-o example:
  put 10*20 into tResult
  RETURN tResult
end dothat

[tperry2x]

or use the global theResult as shown by Klaus

well, you could use a global variable anywhere, but commands are designed to issue commands where you don't typically return the result.
A command such as "hide menubar" - you don't expect to get any return data from that

However a function is designed for when you want to return data back from it. That's the purpose/difference between the two.

For example, the revIDELibrary stack is packed full of functions the IDE uses, which other things link into inside the IDE - and expect data to be returned back from.
Here's an example - if you put this in a button:

Code: Select all

on mouseup
   dispatch function "revIDEEditableStacks" to stack "revIDELibrary"
   put the result into tReturnValue
   put tReturnValue
end mouseup

It'll return a list of all the editable stacks you might have open. (Stacks that aren't considered part of the IDE)

[FourthWorld]

What is the value of having two handler types (commands and functions) as opposed to just one?

Possibly so the specs of the language look good. Otherwise pointless and possibly confusing especially as variables can be passed by reference thus removing the need to return a value.

OXT supports pass-by-reference for both commands and functions.

Notice that most of the world's languages use functions only.

Then notice that most also use zero-based indexing, the same three loop forms, and sparser syntax.

Scripting is programming-lite. Designers tend to model their scripting languages around their experience with lower level languages.

What was Apple's main programming language in the 1980s when they made HyperCard?

[Skids]

What was Apple's main programming language in the 1980s when they made HyperCard?

I have no idea; I want to say Jovial as I only know of one project that used it but a wild guess is that Apple were using "C" back in the 1980's.

I'm sure that nothing I write below is either new or surprising to old Xtalk hands or those with vastly greater programming experience than I have. I post it as it may be of interest to other Xtalk users thinking of change.

I think I should state that while I started this thread my aim is to keep using OpenXtalk for as long as I can. However, there is always a chance that I will be unable to use it at some point in the future, no doubt due to Apple, which is the reason I started this thread hoping to get some ideas on which other languages I should try.

At the moment I am trying python and have signed up for a course hosted by Udemy and I have also purchased several books about programming in python. So how do they compare?

Python is better at maths once the numbers get very large. In Xtalk the code has to revert to using strings to store the digits and the code has to do the maths on a small scale and do any carries that are required. An example is trying to calculate the size of fibonacci sequence after more than 100,000 iterations. See https://forums.livecode.com/viewtopic.p ... 2&start=45

Python use the equals sign to assign values to variables and a colon for assignments in dictionaries (which are similar to arrays in Xtalk). The big surprise is how python relies on white space in the form of indentation: sub clauses such as 'if' statements and 'function definitions' are completed by tabbing out.

By way of example I enclose my most recent exercise in both python and Xtalk. The aim is to process a string of bracket characters [ { ( ) } ] and ensure that the brackets are "balanced". For unknown reasons the course instructor introduced the concept of a stack. Neither pyton or Xtalk have a stack object so for this exercise in python a stack class is defined. In the Xtalk version I just used a string (KISS!). As an aside to me "the stack" exists down at CPU level and either machine code or Assembly language is used to push, pop or peek values to and from the stack.

Here is the definition of the stack class in python:

Code: Select all

# Define  stack as a class

class Stack():
    
    def __init__(self):
        self.list_stack = []
        
    def is_empty(self):
        if not self.list_stack:
            return True
        else:
            return False
    
    def push(self,item):
        self.list_stack.append(item)
        
    def peek(self):
        if self.list_stack==[]:
            return None
        else:
            return self.list_stack[-1]
        
    def pop(self):
        return self.list_stack.pop()
        
    def __repr__(self):
        return repr(self.list_stack)

In the code snip the use of self refers to the name of any variable that is an instance of the class stack so it is similar to how Xtalk uses the me command. Note that == is used as a comparison operator with != meaning not equal. Also a colon is used where Xtalk uses then. The comparison ==[] would be 'is empty' in Xtalk.

Code: Select all

# Example strings to be tested
# {[()]}  ==> TRUE or Balanced
# ({[)]   ==> False or unblanced

the_string = "({[{}[[]]()]})"
my_stack = Stack()
# Assume that all other characters have been filtered out

Here some comments are followed by declaring the string to be tested as the_string and then an instance of the stack class named my_stack. This gives the variable my_stack all the methods (procedures) defined in the class definition above. There is no equivalent in Xtalk; the closest is that screen controls may be given methods using behavior buttons but its a stretch to claim any equivalence to OOP.

Code: Select all

# Set list and dictionary to test character types
openers=['{','(','[']
correct_close = {
    '{':'}',
    '(':')',
    '[':']'
    }

status = "undetermined"

def is_correctclose(peeked,char,close_dict):
# find the correct close character of 'peeked'
correct_char = close_dict[peeked]
if char == correct_char:
return True
else:
return False
[/code]
Here the list variable openers is defined as a list of three characters ( { [. Next comes the definition of the dictionary correct_close where a key character is set to equal another character via a colon, thus the key "{" will return "}" and so on. The variable status is being used as a flag which I grant is a little ugly but there you go! Lastly a function is defined to check that the character passed a variable 'char' is the correct closing bracket for the character passed in variable 'peeked'.

Code: Select all

 
 for char in the_string:
    # Starting with empty stack
    if my_stack.is_empty and char in openers:
        my_stack.push(char)
        continue
    
    # Stack is populated  
    if char in openers:
        my_stack.push(char)
        continue
    peekedchar = my_stack.peek()
    if is_correctclose(peekedchar, char, correct_close):
        my_stack.pop()
    else:
        status = "Unbalanced"
        break

if my_stack.peek()==None and status != "Unbalanced":
    status = "Balanced"   
else:
    status = "UnBalanced"
print(status)

This last section of python contains the logic of the string testing. Note how the tab position determines the end of various statements e.g. the line peekedchar = my_stack.peek() is outside the if statement above because of its indentation and my_stack.peek() reads the top value from the logical stack.

So compare and contrast with the Xtalk version. Note I have not bothered with attempting to emulate the stack class and have just used a standard string instead.

Code: Select all

on CheckBalance   
   put field "testString" into tWord
   
   # populate some character strings
   put "{[(" into tOpeners  # list of valid open characters
   # build an array of closure characters to allow rapid lookup
   put "}" into tMatchedA["{"]
   put "]" into tMatchedA["["]
   put ")" into tMatchedA["("]
   
   # prepare variables
   put "undetermined" into tStatus
   put empty into tStack
   # loop through the characters in tWord
   repeat for each character tChar in tWord
      
      # first character is special case
      if tStack is empty and tChar is in tOpeners then
         put tChar after tStack
         next repeat  // clearer (to me) than python's continue
      else if tStack is empty then
         put "Unbalanced" into tStatus
         exit repeat
      end if
      
      # tStack has at least a single character
      if tChar is in tOpeners then
         put tChar after tStack
         next repeat
      end if
      
      # case where tChar is not an opener, is it the correct close character?
      put the last char of tStack into tPrevChar
      if is_correctclose (tPrevchar,tChar,tMatchedA) then
         delete the last char of tStack
      else
         put "Unbalanced" into tStatus
         exit repeat
      end if
   end repeat 
   
   if tStack is empty and tStatus is not "Unbalanced" then
      put "Balanced" into tStatus
   else
      put "Unbalanced" into tStatus
   end if
   
   put "The string is : " & tStatus into field "result"
end CheckBalance

function is_correctclose pPrevchar,pTestchar,@pMatchedA
   # find the matched close char to prevchar
   put pMatchedA[pPrevchar] into tCorrectChar
   if pTestChar = tCorrectChar then
      return True
   else
      return False
   end if
end is_correctclose 

( I'm sure my code can be refactored but it serves a purpose in its present state - well thats my excuse!)

I suggest that the key differences in the code are that Xtalk uses a more verbose syntax which takes longer to type but is simpler to read, compare the definition of the dictionary in python to that of the array in Xtalk. Also python's 'continue' and 'break' statements are ambiguous when compared with Xtalks 'next repeat' and 'exit repeat'.

The major difference is that the python code only runs in an IDE or terminal window. To give it a user interface requires the use of a library such as tkinter and more code. In comparison Xtalk starts with a user interface in the form of a blank stack/card. My Xtalk stack has a button and two fields, one for entry and one for reporting the status and is ready to be saved as a standalone. I don't know for sure but I believe that building a python script into a standalone requires the use of a packaging application but I guess this will become clearer as I progress through the course.

So to close for the reasons above I shall continue to use Xtalk for as long as I can and I will keep python as my standby should I have to use it or I want to explore the types of UI that can be created using a web UI library as mentioned by ForthWorld.

[FourthWorld]

What was Apple's main programming language in the 1980s when they made HyperCard?

I have no idea

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

Just a few years later Apple switched to C.

One can easily imagine that if HyperTalk was designed a few years later than it was it would look a lot like JavaScript.