OpenXTalk Manifesto!

Sub-forum to lay a basic framework for future expansion and/or modifications to OXT
User avatar
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm

OpenXTalk Manifesto!

Post by OpenXTalkPaul »

I made this a sub-forum where we can work out an OpenXTalk Manifesto of sorts because I'm getting really tired and distracted by having to have essentially the same conversation with different people in multiple areas, in private messages, on social media, and various topics here... I'm going to keep this topic locked and updated as needed based on related community dicussions (which hopefully will stay in the this sub-forum)

I'm not a CEO or CTO. I don't own OXT and no one should, that's the Open in Free Open Source Software (FOSS). Of course anyone is free to fork-off from this or LCC and go in a completely different direction (indeed that has been the fate of other xTalks over the years, see HyperTalk->S8Script->AppleScript, Director Lingo -> Adobe ActionScript, or Gain Momentum -> whatever RadBuilder is, for some examples). I would hope we could cooperate with any such effort (even commercial efforts) to maintain a high level of interoperability.

So what exactly do we want from an OpenXTalk language and IDE?

In my opinion xTalk should NEVER become JavaScript (that was the original sin of the first web browsers, which should've/could've used an xTalk that Apple once had a working group to standardize ), nor should it become Flutter/Dart, Python, BASIC, etc. etc. etc. It is xTalk . xTalk has either existed since before the most of those, or has bested them by miles for their intended use (I've never seen any flavor of BASIC that is any wear near as instantly understandable for beginners). And let's be realistic you are NOT going to get something of the quality and fervor around xTalk as you are going to get from something like Apple-backed Swift, or Google-backed Flutter/DART, not from here and not from a small company like LC Ltd. (dedicated, hardworking or not, I'm pretty sure they've only got about 20 to 30 employees, and apparently that company doesn't have gazillions of money like Google or Apple have).

xTalk has always been about a user-centric, easy to understand, "natural language" English-like syntax, and as instant gratification as possible, "live reload" (constant just-in-time recompiling of bits of code) editing with a GUI toolkit that has most elements people would need to build any sort of "app" like collection of data and/or data-processing. From very early on xTalk was highly extensible (which had a lot to do with people still using it long after Apple/Claris FileMaker had abandoned it) with XCMDs/XFCNs (Eternal Commands & Functions). It was Object-Oriented-like Programming, before that existed as a programming paradigm, and surely it influenced some 'Gang of Four', as it did so many other things.

xTalk ( in it's current and previous states ), is already modular, and object-oriented-ish (predating the OOP term) and is highly extensible going back to xTalk's main progenitor HyperCard's XCMDs/XFCNs extensions. The IDE sits on top of a cross-platform VM (virtual machine) engine, that has been refactored and gifted with features to help keep it modern (Unicode and the 'Builder' middleware language) and up to date with ever changing computer platforms and their latest/greatest APIs.

As far as modifying the language itself the ONLY things I'd really consider changing would be possibly adding some alternative synonyms for existing syntax or maybe even something engine-level like adding the apostrophe (as has been used in AppleScript / AppleScriptObjC and a few other xTalk related languages in an possesses a property sort of context). Things like lower level language symbols (i.e. == instead of or in addition to 'put into') should be kept to a minimum I think, this could be a discussion but I think Symbols make a language more cryptic looking to non-programmer types and I'm actually in favor of going the opposite direction of adding MORE syntactical sugar! The core language in the Engine has most everything xTalk needs in my opinion. Additions to xTalk can and should if at all possible be built in the higher-level layers, with Script Libraries, Externals, or Builder Extensions, keeping the core intact.

Who is online

Users browsing this forum: No registered users and 1 guest