BASIC scripting engine retired

Started by Rhadamanthys, May 28, 2017, 04:48:28 PM

Previous topic - Next topic

Rhadamanthys

Just to make sure I got it right:
Migrating to IMatch 2017 means my numerous scripts will not work anymore and I would have to implement their functionality in Java or so?

DigPeter


Mario

Precisely.

I've kept the BASIC scripting engine running and maintained for about 10 years. That's enough.
It is outdated, slow, very expensive and the BASIC programming language is now really a thing of the past. It offered no way to create modern or even responsive user interfaces required for today's hardware.

IMatch now comes with a built-in WebService, publishing the IMatch object model and feature set via standard web service endpoints. The default programming language for IMatch is now JavaScript and HTML, the same environment as used for IMatch Anywhere. IMatch comes with extensive and comfortable JavaScript libraries which make wiring apps very easy.

But since IMatch is an open system, you can use every programming language that can utilize a WebService (C++, C#, VisualBasic.NET, Windows PowerShell, Java, Go, Python, PHP,...) to access IMatch locally or remotely via IMatch Anywhere WebServices.

The documentation of the IMatch WebService is directly accessible via an app included in IMatch.
Several large apps, including the Map Panel, are included in source code in IMatch 2017.
About 20 sample apps show how to use every major feature of the embedded WebService.
All other aspects of writing scripts for IMatch, with many examples, are available on-line in the IMatch Developer Center.

-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

RLYPhoto

Yup. Sounds like it was a COLD DROP for script developers with no migration guide or plan. I know my workflow, used almost daily, is at a complete stop if I want to use 2017. Good thing I copied my Imatch 5 databases before the upgrade. Using 2017 for my DAM is now on the back burner until I get time to create my own missing script migration guide.
Just some guy who likes his camera...

medgeek

I don't think it's fair to characterize this as a "COLD DROP."  Mario has said for months that Basic would be dropped in favor of modern web programming tools, for exactly the reasons he mentioned in his post above.

Carlo Didier

Quote from: medgeek on May 31, 2017, 07:44:21 PM
I don't think it's fair to characterize this as a "COLD DROP."  Mario has said for months that Basic would be dropped in favor of modern web programming tools, for exactly the reasons he mentioned in his post above.

True, but it would have been nice to have some information or at least hints about what major changes that would imply (like asynchronous processing, etc).
I actually imagined just rewriting my scripts nearly line by line without bigger problems. But right now it looks like I'll have to learn completely new ways to code and test.

Mario

Quote from: Carlo Didier on June 12, 2017, 10:33:23 AM
True, but it would have been nice to have some information or at least hints about what major changes that would imply (like asynchronous processing, etc).
I actually imagined just rewriting my scripts nearly line by line without bigger problems. But right now it looks like I'll have to learn completely new ways to code and test.
Asynchronous processing in JavaScript has nothing to do with IMatch. This is how all modern language utilize web services. Asynchronous / multi-threaded programming is standard for 10 or more years. It just was not in BASIC, because BASIC could not handle it. All modern programming languages re designed to make use of the multiple processor cores your PC, tablet or smart phone has. Else these would be useless.

Making a web service call and letting JavaScript call you back when it is done and you can continue is actually a really neat concept.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

Carlo Didier

Quote from: Mario on June 12, 2017, 11:46:09 AMMaking a web service call and letting JavaScript call you back when it is done and you can continue is actually a really neat concept.
True, but that doesn't make it the best solution for every case. Having the choice would be optimal.
And you can still program linearly in most languages, it's the "web based" approach which forces in the asynchronous part.

Even seeing the advantages in certain cases, I personally hate asynchronous processing. It's like shouting something into the forest and hoping that someone will sometime shout back an answer ...  :)

Mario

QuoteTrue, but that doesn't make it the best solution for every case. Having the choice would be optimal.

No point in arguing that with me. You can always simulate a blocking call like I have explained it in my responses to several of your posts today.
I don't make JavaScript and I cannot change the language core. You may want to contact the responsible body, which is most likely http://www.ecma.ch/ and suggest an option for blocking AJAX calls.

Or you play with the async parameter of jQuery AJAX calls, as explained here: http://api.jquery.com/jQuery.ajax/
Never used this so I cannot tell you if this works or how well.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

Carlo Didier

I know it's not your fault how javascript is working. It's just that I did some simple things in the old scripts and when I try to find out if and what is possible in the new environment, I find lots of resources on the internet, but on each page I open, I must google every tenth word at least ... and from there again. It's frustrating.
I'm not even sure I know what Ajax is. Definetely have no clue what jqHXR is. Googling any of those just generates dozens more"Huh?"s from me ...

I really want to migrate my scripts so I can use iMatch 2017, but it's extremely complicated if you don't know anything of this new stuff.

For you as a "full time" programmer, it's relatively easy. But, although being an IT professional, I never had to program more than vbscript or now Powershell scripts (although some of those have several thousands of lines of code), for me, this is like learning chinese.

Mario

AJAX is just how JavaScript talks to WebServices. I simplified all that with jQueries helo into IMWS.get() and IMWS.post() and IMWS.delete().
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

thrinn

Some interesting patterns and anti-patterns regarding Promises can be found at:
http://www.datchley.name/promise-patterns-anti-patterns/
Of course, there are tons of other blogs and articles, but I think Dave Atchley gave some good and short examples for some common problems and how to solve them.
Thorsten
Win 10 / 64, IMatch 2018, IMA

Carlo Didier

Quote from: thrinn on June 12, 2017, 09:27:36 PM
Some interesting patterns and anti-patterns regarding Promises can be found at:
http://www.datchley.name/promise-patterns-anti-patterns/
Of course, there are tons of other blogs and articles, but I think Dave Atchley gave some good and short examples for some common problems and how to solve them.

This actually sounds less like Chinese to me, more like ... Russian  8)
Seriously, I find the necessary syntax quite contorted and complicated, just to execute things serially ...

I see that there are maybe more possibilites in this, like executing multiple things at the same time (if needed!!!), but that also over-complicates things that would otherwwise be very simple.
A bit like using a fancy compiler in a very high level programming language, producing a 200MB executable, needing at least 2GB of RAM, when a simple batch file with the line "@echo Hello!" would be enough.
I'd largely prefer the batch file to say Hello  :)

Oh the old days, when we programmed a second degree equation on my HP41 with only 27 program steps! And that included the case of imaginary number solution!

Jingo

I can relate to this but realize I need to adapt and change to keep up with the times.  I used to program HTML websites for clients using powerful - but simple - text editors because I knew 90% of the HTML commands inside and out.  The pages were neat, simple and fast and worked well... for the times (12+ years ago).  Now, those pages looks antique and no one would dare program them using straight HTML as such... you need AJAX, Javascript and the ability for them to dynamically resize for hundreds of different sized devices.  Libraries and available scripts make this possible without having to re-code things... but you need to learn how to implement them... and that takes time... 

I for one welcome the flexibility and possibilities... but recognize that developing scrips and apps is not for everyone - nor is it really needed in most cases since the software can natively do so much already.

Here's to learning new things!   8)