Another way of assessing LiveCode

Want to talk about something that isn't covered by another category?

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Another way of assessing LiveCode

Post by bogs » Wed Apr 25, 2018 9:32 pm

I dunno, if I remember rightly, feeling wobbly would only apply to it if I were using it for production work, I'm pretty sure I considered the status of it about a notch above alpha, or maybe just below beta software.

I'm going to try and see how much of working in it I really do remember, as the last time I tested it, I only put the rbscripting to test.
Image

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Fri Apr 27, 2018 7:49 am

For anyone with a bad attack of nostalgie (de boue, possiblement)
and no conveniently parked old Macintosh computer they can go here:

https://archive.org/details/AppleMacintoshSystem753
nostalgia.png

http://osxdaily.com/2017/05/27/run-hype ... owser-emu/

https://archive.org/details/@vintage_apple_mac

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Another way of assessing LiveCode

Post by bogs » Fri Apr 27, 2018 2:50 pm

Yep, chuckm found this last year, and posted this thread about it. I still think it is way cool, and have been playing with it in SheepShaver on linux since then.
Image

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sat Aug 04, 2018 5:49 pm

naga.png
-
Just started teaching myself Python for a slightly unpleasant reason:

If one says "Python" more eyes light up than if one says "LiveCode": marketability, Old Bean.

It is clear to see that LiveCode is utter rubbish because on doesn't have to learn lots of nasty little things such as:

floats

//

%

**
[ I suppose using "^" is for babies ] or pow

abs

worrying about whether something is a STRING variable or not

==

round


AND that's only after 30 minutes. 8)

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sat Aug 04, 2018 6:53 pm

"A synonym for repr(x) is `x` (here, you use backticks, not single quotes). This can be useful"

Well, of course . . .

The fact that I haven't a Flying F*ck of an idea where to find a "backtick" on my keyboard has not been considered.

It really is time to ask Kevin and Co. why they didn't build backticks into LiveCode so we could all
curse them!

Oh, Lookee here: here it is (on my keyboard at least) . . .
-
backtick.png
-
Err . . .
-
Screen Shot 2018-08-04 at 9.12.58 pm.png
-
AND there's the crazy LiveCode people making things so easy . . .
-
I'm seriously considering having a "backtick", or is that a `backtick` tattooed on my ***. 8)

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sat Aug 04, 2018 7:18 pm

"Backticks are removed in Python 3.0, so even though you may find backticks in old code,
you should probably stick with repr yourself."

Cheese! A good thing I didn't get round to the tattoo parlour. 8)

I am not sure about repr as I've fathered 2 sons already. :?

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sat Aug 04, 2018 7:27 pm

Screen Shot 2018-08-04 at 9.25.10 pm.png
Screen Shot 2018-08-04 at 9.25.10 pm.png (10.45 KiB) Viewed 7697 times
-
I just hate the way LiveCode can cope with Unicode strings so easily.

As you can see, Python makes a real Pig's Breakfast of Unicode so we can all
have fun, headaches and suicidal thoughts. 8)
-
"In Python 3.0, all strings will be Unicode strings."

I cannot wait.

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sat Aug 04, 2018 7:38 pm

So: Python 2.7:
-
Screen Shot 2018-08-04 at 9.34.15 pm.png
-
Python 3.5
-
Screen Shot 2018-08-04 at 9.34.29 pm.png
-
WOW! That really makes LIveCode look like utter crud!

Unlike stagnant LIveCode where, 5% of the time syntax never changes between releases,
Python keeps us all on our toes by making us always have to be on our guard by changing
the simplest things (face it, this is my second hour with Python).
-
Screen Shot 2018-08-04 at 9.49.15 pm.png
-
Lovely . . .

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sat Aug 04, 2018 8:01 pm

I am getting increasingly angry with LiveCode and the LiveCode development team
as I see what fun Python programming has for me;

To learn Python versions 2.7 and 3.5 (I need to learn both versions) I have to keep
both programming environments open as things are done differently in them:
-
mental.jpg
-
NOW: I started out with LiveCode when it was called Runtime Revolution 1.1.1 and really suffered over the years because, as new versions were released I did not have to learn 8 new variants of the LiveCode language, merely had to learn new terms as they were introduced.

This is really disgusting when I consider the time LiveCode saved me because I didn't have to keep relearning new versions of the language.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7215
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Another way of assessing LiveCode

Post by jacque » Sun Aug 05, 2018 5:25 pm

Okay Fishface, I laughed. :)

If it helps, I went through the same agony during my brief and abbreviated experiment with C. My new rule is that any language that relies on excessive punctuation should be shunned.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Sun Aug 05, 2018 6:40 pm

any language that relies on excessive punctuation should be shunned
So far I am finding Python a "load of old nadgers", but:

1. Like it or not (and I don't) the educational market prefers Python to LiveCode,
and offering classes in Python is going to pay for the second-hand camper van in a way LiveCode seems unlikely to do.

2. Working my way through a teach-yourself thing for Python makes me appreciate LiveCode.

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 9287
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Another way of assessing LiveCode

Post by richmond62 » Tue Aug 07, 2018 11:37 am

"In Python 3.0, print is no longer a statement at all—it’s a function (with essentially the same
functionality
)."


Why can't LiveCode be that complicated between major versions?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Another way of assessing LiveCode

Post by FourthWorld » Tue Aug 07, 2018 4:23 pm

We have been spoiled. In all the years I've used LiveCode I can count the number of deprecated and significantly changed tokens my hands.

But once we step outside our world, we find a universe in which backward compatibility is handled with cavalier disregard, so frequently by so many languages that many think painful, efforts to make scripts compatible with the most recent version of whatever engine one's using is completely normal and as good as it gets.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

bogs
Posts: 5435
Joined: Sat Feb 25, 2017 10:45 pm

Re: Another way of assessing LiveCode

Post by bogs » Tue Aug 07, 2018 8:36 pm

Um, I'm not sure I completely agree with that assessment Richard, at least the way I'm reading it.

All langauges change, and Lc doesn't appear to change less to me than almost any other I can think of. Leaving aside for the moment whether all the changes are good or bad regardless of language, here are the things specifically I was thinking about.
FourthWorld wrote:
Tue Aug 07, 2018 4:23 pm
... once we step outside our world, we find a universe in which backward compatibility is handled with cavalier disregard, so frequently by so many languages that many think painful, efforts to make scripts compatible with the most recent version of whatever engine one's using is completely normal and as good as it gets.
What most people might think of as a "painful language" as you put it I am guessing would be something like C/C++ or maybe assembly would be an even better example (since it is processor type specific).

Yet as long as C/C++ has been around, you could pick up probably any current compiler and still write code just as you did in C from say the 80s [*]. You would loose out for not using new features, but the structure really is pretty backwards compatible.

SmallTalk - has this ever changed, other than to get faster and smaller?

Other less painful languages such as any number of BASIC variants also rarely have show stopping incompatibilities from old to new. VB6 for instance still supported syntax and language features from gwbasic (basica), Quick BASIC, etc., and that span ran close to 30 years. Other Basic variants all seem to follow this pattern as well (with few exceptions, see below).

Pascal, which is a language I tend to like, and its offspring Delphi variants (which I like even more) always seem to me to be languages I can pick up in a matter of days no matter where I left off in using it. Free Pascal almost exactly tallies to my memories of the original.

As for Python specifically, only the migration to 3.x really broke anything, and at that a great deal was backported to 2.6-7, as outlined in this article -
Wikipedia, the free encyclopedia wrote: Python logo, 1990s–2005
Main article: Python (programming language)

The programming language Python was conceived in the late 1980s,[1] and its implementation was started in December 1989[2] by Guido van Rossum at CWI in the Netherlands <sic...>

Python 2.0 was released on October 16, 2000, with many major new features, including a cycle-detecting garbage collector (in addition to reference counting) for memory management and support for Unicode. However, the most important change was to the development process itself, with a shift to a more transparent and community-backed process.[7]

Python 3.0, a major, backwards-incompatible release, was released on December 3, 2008[8] after a long period of testing. Many of its major features have also been backported to the backwards-compatible Python 2.6 and 2.7.[9]

So, we have a language that came around in '89, remained unchanged more or less for a decade, moved to a community backed process of development (which I take it to mean that any changes were hardly 'cavalier' as you put it), and finally (almost another decade later), had a significant rewrite after a long period of testing.
We have been spoiled. In all the years I've used LiveCode I can count the number of deprecated and significantly changed tokens my hands.
Like those mentioned above, Lc tends to change about as much in certain areas. Sound, video, db work, etc. [**]

RB/Xojo would be an exception in my book, as it seems like it changed pretty radically in language from revision to revision. Like going from 3 to 5 that wasn't so bad, 2006 to 2012 changed a lot, to what it is now which I can't stand to even open anymore.

Just my .00000000002 cents :|
_____
[*] I could be completely off in that statement, since the 80s was about the last time I did anything in C, and it was true up to the point I stopped using C++, which I treated (more or less) as C on steroids.

[**] I am only taking the period when RunRev/Lc actually took over, although this could I think be extended back as far as Mc. I really wish I had bookmarked what some of the people I consider in a class of their own in this language were saying about all this back then, as it was fascinating and quite humorous reading for me :mrgreen:

Edited - just adding that I've never actually used Python. I kept meaning to take a look at it, but you can only cover so much in the time you have available.
Image

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Another way of assessing LiveCode

Post by FourthWorld » Tue Aug 07, 2018 11:21 pm

bogs wrote:
Tue Aug 07, 2018 8:36 pm
Um, I'm not sure I completely agree with that assessment Richard, at least the way I'm reading it.
Consider Richmond's observations, and the note you included about the vast difference between Python 2 and Python 3, look at Apple's long history of API changes (pick your era, Pascal, C, C++, Objective-C), then talk to people using Drupal or Wordpress deeply (I realize the latter two aren't languages per se, but they are reflective of a deprioritization of backward compatibility), or anyone who managed to port a VB project beyond v6.

We may still see things differently. But I see what I see.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Post Reply

Return to “Off-Topic”