Another way of assessing LiveCode
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Re: Another way of assessing LiveCode
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.
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.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
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
http://osxdaily.com/2017/05/27/run-hype ... owser-emu/
https://archive.org/details/@vintage_apple_mac
and no conveniently parked old Macintosh computer they can go here:
https://archive.org/details/AppleMacintoshSystem753
http://osxdaily.com/2017/05/27/run-hype ... owser-emu/
https://archive.org/details/@vintage_apple_mac
Re: Another way of assessing LiveCode
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.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
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.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
"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) . . .
- -
Err . . .
- -
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 ***.
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) . . .
- -
Err . . .
- -
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 ***.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
"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.
I am not sure about repr as I've fathered 2 sons already.
you should probably stick with repr yourself."
Cheese! A good thing I didn't get round to the tattoo parlour.
I am not sure about repr as I've fathered 2 sons already.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
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.
-
"In Python 3.0, all strings will be Unicode strings."
I cannot wait.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
So: Python 2.7:
- -
Python 3.5
- -
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).
- -
Lovely . . .
- -
Python 3.5
- -
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).
- -
Lovely . . .
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
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:
- -
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.
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:
- -
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.
-
- VIP Livecode Opensource Backer
- Posts: 7215
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Another way of assessing LiveCode
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.
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
HyperActive Software | http://www.hyperactivesw.com
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
So far I am finding Python a "load of old nadgers", but:any language that relies on excessive punctuation should be shunned
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.
-
- Livecode Opensource Backer
- Posts: 9287
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: Another way of assessing LiveCode
"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?
functionality)."
Why can't LiveCode be that complicated between major versions?
-
- VIP Livecode Opensource Backer
- Posts: 9802
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Another way of assessing LiveCode
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.
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Another way of assessing LiveCode
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.
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 -
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.
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
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.
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.
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).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.
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.
Like those mentioned above, Lc tends to change about as much in certain areas. Sound, video, db work, etc. [**]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.
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
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.
-
- VIP Livecode Opensource Backer
- Posts: 9802
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Another way of assessing LiveCode
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn