Another way of assessing LiveCode

[bogs]

I did actually take Richmond's observations into account in thinking about my reply, although I did not comment on them. He is, at the moment, comparing 2 different decades of a language at the same time. Had he say, started with 2.x and then moved to 3.x over that same period of a decade, I doubt he would find it so difficult an adjustment to make, not to mention (again) that they backported a lot of it as far back as vers. 2.6.

Just for comparison, or fun, or self mutilation , write a * video player / db library using **sqlite in the 2.6 version of Mc (about 2003 ?), and then in the 7.x version of Lc (about 2014) for say, the linux Os. Bonus if you include a ***browser, and a **datagrid, and then tell me there hasn't been much change

You and I have no disagreement that languages change, whether spoken, written, or programmed in. The parts of your statements I wasn't so sure of were that Lc by and large doesn't have these upsetting things happen, or where the language doesn't seem in flux as much as other languages. There certainly are better and worse examples of it happening (I tend to think Lc favors the better end of it myself ) but it still exists not so much differently than others.

... or anyone who managed to port a VB project beyond v6.

<raises hand> I don't know if I ever publicly mentioned how much I hated .net or not. In the end, it appears to have been a move in the right direction from Ms's point of view, going to the CLI, but for a lot of VS users who made VB what it was, it was a punch in the head. I'm sure I don't have to say that I don't use .net for anything since I completed all the migrations I had to do.

Yes I was and still am that angry about that time period

We may still see things differently. But I see what I see.

I wouldn't have it any other way my friend
______
* Getting Xanim to work in and of itself should be interesting. I did, but I cheated outrageously.

** I realize that the sqlite wrapper and datagrids did not exist in Mc at any point, but you are one of those I view as being "in a class of their own in this language", so I figure it won't be much of a challenge for you. I on the other hand wouldn't be able to get past it, at least so far.

*** This is do-able in both, but language deprecation and Os changes don't allow the same exact code to work, as far as I have tested out. Like I said, bonus stuff only

[FourthWorld]

The LC changes you mentioned were additive. We hope any system adds new things. The question is here is what from the past can't be carried forward to newer versions. In LC, it's very rare to see true deprecation.

I don't work in Python myself, but pretty much everyone I know who earns their living with it considered v2 incompatible with v3, and continued working in v2 for years after v3 was released to avoid rewriting code.

I have spent a lot of time in the Drupal world. Many there complain about the high cost of migrating from any major version to the next, but everyone in the core team considers it normal enough that they just shrug and keep doing it.

Apple changes things every other Tuesday because, well, Apple.

[jacque]

It's all about backward compatibility. I was just commissioned to update a stack I wrote ten years ago. I couldn't open it in LC 9 due to file format changes, so I opened it in LC 6. It ran fine. After saving it there I could open it in LC 9 and it ran fine there too.

The LC team, Mark in particular, is adamant about maintaining backward compatibility. Careful consideration is taken to make sure existing stacks don't break, and even old HC stacks written 20 years ago will still run once you move them through the file format adaptation. New additions are added all the time but the original terminology and syntax does not change.

A few things have been deprecated but even so, the deprecated terms still work for the most part. The only exception I can think of is the difference between char and byte, which were largely synonymous until LC 7 and have now diverged. We were warned about this years before it actually mattered.

[richmond62]

The only exception I can think of is

The "hiatus" created by the 'proper' unicodification (Is that a word? Oh, well, it is now!) of LiveCode as I spent an very, very long time indeed messing around converting stuff from

numToChar and charToNum

to

numToCodePoint and codePointToNum

because backwards compatibility in that area was broken.

But the end result was well worth is; especially as it meant dumping lots of time-consuming code calculating surrogate pairs!

Just my luck that the awkward bit struck at the most vulnerable parts of my work.

[bogs]

The LC changes you mentioned were additive. We hope any system adds new things. The question is here is what from the past can't be carried forward to newer versions.

*Some* of the changes I mentioned were additive, and I think I clearly marked where I know those to be. Maybe our opinions on what is an addition and what is a change are different too, I don't consider starting with one video playing setup, switching to another, and then to yet another to be 'additive', it is a distinct break in the chain.

DGs and the sqlite wrapper? Definitely additive. Adding a browser? Mixed bag, changed twice then switched to a preferred method of using one particular external, which you may or may not have on your system. Just saying.

Just to be clear, I am not saying change is necessarily bad, nor am I saying that wrong decisions were made, my point(s) were solely related to the (perceived) view that Lc somehow has avoided changes that almost every other system uses, and that (almost) every other system doesn't take the opinions of its user base into account, which is how I read the post I replied to.

In Pythons case, it would be particularly hard to believe that in a community decided move, somehow only a few knew about the changes or thought they were ok to go ahead with. To boot, a great deal of it was backported to previous versions. Is everyone going to be satisfied with that? Heck no, but again, you find that in any language, even this one As an example, look at some of the discussions around the development of widgets going from early 8 up, and how the format changed so much during that period.

I very much believe that Lc, as I stated a couple posts up, does this on the better end of the spectrum, as do some of the other languages I mentioned, and probably *most* other languages I've had actual experience with.

[bogs]

It's all about backward compatibility. <sic>
....A few things have been deprecated but even so, the deprecated terms still work for the most part. The only exception I can think of is the difference between char and byte, which were largely synonymous until LC 7 and have now diverged. We were warned about this years before it actually mattered.

I do find the degree of being able to go backwards and forwards in Lc particularly comforting, which is why I said the language is on the better end of the scale imho

Things that were deprecated, on the other hand, tend to be a crap shoot, in some cases just failing silently, or worse yet, partially (but not completely) working, which leaves you with a guessing game as to where the failure is. I've only hit that situation 3 times so far, but I figure if I hit it 3 times, someone else must have hit it over and over again, especially if they've been doing this for decades like a lot of you have been doing. Alternately, I may just be lucky enough to find screwy things, and am totally alone

Thankfully, Richmond lets me know that just isn't so

[FourthWorld]

I do find the degree of being able to go backwards and forwards in Lc particularly comforting, which is why I said the language is on the better end of the scale imho

Exactly.

That's pretty much all I'm saying. There can't be a system that survives through so many generations of operating systems without changing a few tokens from time to time.

But overall, I see more effort devoted to maintaining backward compatibility in LiveCode than I see in most other projects of similar scope, even among those with much larger teams.

[richmond62]

Screen Shot 2018-08-08 at 10.14.44 pm.png (15.74 KiB) Viewed 10615 times

screw.jpg (4.96 KiB) Viewed 10615 times

-
Wouldn't it be GREAT if LiveCode were that bloody-minded?

[richmond62]

Ah:

Python is a language that uses indentation to make you curse and swear

[ http://www.whyispythonsoobtuse.com ]

INDENTATION
-

-
NOW WHY CAN'T LIVECODE BE SO "xyz*&#@" ?

[dunbarx]

Richmond wrote:

I spent an very, very long time indeed messing around converting stuff from

numToChar and charToNum
to
numToCodePoint and codePointToNum

because backwards compatibility in that area was broken.

I was concerned about this when if first came up years ago. But I have never seen it broken. I never did go through all my scripts and change to the new functions. The old ones do not seem to be deprecated at all, however old-fashioned they might be

Is that dangerous? Am I living on the edge? Will they one day simply not work? But then in that case, I would get a compile error, no?

Craig

[richmond62]

Am I living on the edge?

That depends how Unicody you are trying to be.

If you live inwith the old ASCII comfort zone you'll be as safe as a pig in pyjamas.

[FourthWorld]

I think you're fine for the foreseeable future, at least as far as the charToNum and numToChar functions themselves go. The older functions relied on text always using single-byte encoding. AFAIK as long as you're working with text where you can guarantee every character will be single-byte, they'll continue to work.

Now that we live in a world where a "character" may be one byte, or two, or four, LC provided two pairs of replacements for those so we can get good results for both use cases:

If working with text, numToCodePoint and codePointToNum will work with any text encoding.

If you need to work the decimal value of a byte (as opposed to a character), we now have numToByte and byteToNum.

[dunbarx]

All,

I am aware of that. Thanks, though.

My point is really, I guess, that the word "deprecated", as regards to numToChar was somewhat alarmist when it first came out. It really should have been, er, "marginalized" or "now limited in scope".

I was at the time alarmed. I am happy now to be merely limited in scope.

Craig

[FourthWorld]

All,

I am aware of that. Thanks, though.

My point is really, I guess, that the word "deprecated", as regards to numToChar was somewhat alarmist when it first came out. It really should have been, er, "marginalized" or "now limited in scope".

Yes, "deprecated" is as frequently misunderstood as it is misspelled (I can't tell you how many times I've seen "depreciated" <g>).

It doesn't necessarily mean "stop using it now!", and almost never means "it's been removed", but it always means "there's now a better way".

[LCMark]

@all : Okay I've only had time to skim read this thread - but I've found myself actually laughing out loud to myself at numerous intervals. I don't think I've ever come across such an amusing and generally in 'good fun' cross-critique of programming tools articulated by a collection of people (particularly @richmond62 - I love your graphics!).

Just a couple of things to note...

Python *could* have not 'broken the world' when they added unicode support (prior to 3 it was the same situation as prior to LC7 for us). I know this because (save for *two* functions!!!) we managed to. So either, they didn't know how, didn't have the technical expertise to pull it off, were just plain lazy, or didn't think it was an issue.

And on those two functions - numToChar / charToNum. Those functions remain the same as they always did - there was simply no way to make them work in the 'transparent unicode' way that we had engineered for everything else. Why? Because they were the *only* two functions which both did native text *and* old style UTF-16 (binary!) unicode text. They cross-cut the two worlds and as such *couldn't* be unified. Indeed if you give charToNum a char in the native encoding you get a number < 256 - which is the code in the native encoding. If you gave it two bytes - you'd get a number > 256 - which was the unicode codepoint. At 256 there's actually a discontinuity (of sorts).

Anyway, those two functions will never go away - and if you only ever use them to process native encoding (old style extended ASCII) text; or to produce UTF-16 two byte sequences... You are absolutely fine.

In Richmond's case (having seen some of the code he had to write prior to LC7 to deal with the Devanagari Unicode script) - I would hope that whilst an onerus task (for him) to move forward, the update to LC7 has at least made that code a little easier to deal with now, after that work is done (even if it didn't help, or made, everything else worse ).