Control a stack with multiple pages

[pajito]

Hi everybody

I made a code to control all fields in a card, then I made another card, and I changed my code to

Code: Select all

put empty into field x
Repeat x = 1 to the number of fields in stack s1

The problem is that it clears all fields in card 1 and not card 2 as well. It seems really strange to me,any suggestions.

Thank you in advance
Ioannis

[dunbarx]

Hi.

You almost have it.

Code: Select all

repeat with x = 1 to the number of cds of stack "yourOtherStack"
  repeat with y = 1 to the number of flds of cd x of stack "yourOtherStack"
    put "" into fld y of cd x of stack "yourOtherStack"

You need to be more precise about the target of your actions. Think Card. Controls are "owned" by their cards, and only tangentially by the stack that card lives in. If you had several cards, as per the handler snippet above, LC would not know you wanted to do them all. Never mind it would throw an error trying.

Very readable, I hope. You could always navigate, under script control, to all those cards. But that is slower and not as elegant.

Craig Newman

[pajito]

Hi Craig

Thanks a lot for the reply,it gave a lot to think about. I will give it a test tomorrow and I will let you know of the outcome.

Thanks Again
Ioannis

[Lagi Pittas]

Hi Craig

I know when it comes to livecode I'm teaching my granny to suck eggs here - but typing fld to save two keystrokes and cd to save 2 keystrokes is not not gonna save the world - but it flies in the face of the readability aspect of LC - especially when shown to a new user.

I've done the metrics - and our Cat agrees - we spend very little of our day actually writing NEW code and the greater part of typing is modifying/deleting old code and thinking/debugging drinking coffee and going to the loo.

I was going to say about 5 hours but it's probably fewer.

I won't assume the Fred Brookes figure of about 10 lines of code a day but say 500 - we are very productive in LC land - plus writing games or business software isn't anywhere close to writing an operating system.

The average computer typist does 40 words per minute just under 1 character per second lets call it 2 characters per second and round it to 100 per minute - I'm still a hunt and peck expert after 40 odd years,but I can type at between 38 and 50 words a minute when i'm not programming but writing a letter/email that doesn't entail "thinking" - a stream of consciousness if you will.

So if we typed to column 100 of each line we will be typing 500 * 100 characters in a day which is 50,000 characters.

https://www.ratatype.com/learn/average-typing-speed/

so to type 50,000 characters at 200 characters per minute is 250 minutes ~ 4.2 hours. (well what do you know I was not out by much above when i said 5 Hours)

Now this assumes we are typing at full pelt for 4 hours to write as many characters as a short story.

If you save 8 characters (on average) per line because we use cd and field twice each on each line we will save 4000 characters. That assumes we are typing CD and FLD on each and every line. But since we know the start and end of procedures , subroutine calls, variable declarations, NEXT repeat, END IFs etc don't have them and since we try and keep code as close to a card the code is for (I do when I can) we could probably say only 25% of the lines will save those strokes. So we are down to 1000 characters a day. We can type 200 characters per minute so we save 5 minutes in a typing period of 4 hours - just enough to stretch your legs and go to "Turn Your Bike around" - it's a euphamism.

Now this assumes we are typing for the whole 4 hours non stop. It also assumes we have 500 lines of GOOD/Debugged code (I think Brooks in "The Mythical Man Month" was averaging the code over a certain number of months or years of a project to reach his 10 lines per day.

I know some days I might add 600 to a thousand lines of code to a project - especially when it is NEW or it is a totally new Module - but after that adding the time it takes to debug/clean up/refactor/debug//remove lines/think/debug/ modularize etc is what takes the time - and that is a lot of cut/paste and changing words rather than adding.

And remember I have used 500 lines a day and Brooks said about 10 lines whether it was assembly language PL/1 or Fortran.

If we use Brooks' metric then we save 6 seconds.

There are lies, Damned lies, and statistics

YMMV

Herman, you're the mathematician can you see anything wrong in my logic, calculations (most probably) assumptions etc? I'd like to be proved wrong and that I will save more than a Loo break per day.

I would wager being more productive is writing BUG FREE Code and I'm certainly not a Sophie Wilson, Steve Wozniak, Niklaus Wirth or Ken Thompson (in that order) who could write (almost?) bug free code in no time at all.

KIndest Regards Lagi

[dunbarx]

Lagi.

Was your post meant for another thread?

Craig

[bogs]

I can't be sure brother, but I think Laggi is referring to all the abbreviations in the example when posting for someone new to Lc. Or he could be just talking about in general.

Alternately, he may have meant to post in another thread

[Lagi Pittas]

Unfortunately not Craig.

I probably wouldn't have even posted if it was not in the beginners section.

It's just that in 3 lines of code you saved 4 characters - but the readability if you are brand totally new is not the same as the full spelled out "card" and "Field".

The Original Poster understood but when we have such readability in the language why not use it.

I appreciate you have been doing this since Noah was building boats and your hands instinctively type fld and cd but here in the beginners section at least we should be typing the full words.

When I was first learning Livecode one of the things I liked was it's readability - I never used the abbreviations in Foxpro even though there were many - except in the command window - LCs Messagebox.

Anyway as you know it's nothing personal it's just that I find that this terseness doesn't save enough over the long run to make much of a difference for me at least.I could be very wrong hence the (non rhetorical) question.

I was really waiting for Herman to pick faults with my logic/maths , but he probably has better things to do with his time.

It was probably me thinking out loud "why?" - maybe I shouldn't have posted it anyway .... sorry Craig it's not just you it's "C" code I look through where they write in 1 line what I write in 4 - 2 Braces on separate lines even when they aren't needed (I believe Todd has strict rules like that for his programmers - use the EndIf even if there is only 1 line?). Pascal has corrupted me I know.

Lagi

[Lagi Pittas]

Boggs said ...

I think Laggi is referring to all the abbreviations in the example when posting for someone new to Lc. Or he could be just talking about in general.

Spot on Boggs

Lagi

[dunbarx]

Ah. I see.

And yes, I cannot even spell "card" or "field" any longer. Jacque once wrote that she could no longer write "highlight".

But in that case, it was probably far more confusing to have posted an incomplete code snippet as opposed to a full mouseUp handler that could be pasted, working out of the box, into a button. Oh well.

I certainly do not want to confuse a newbie, so I will try to watch it. But even rereading your post, it is still hard for me to grok what you meant; I am not a newbie, usually, and I already knew the answer.

Craig

[bogs]

Being a beginner (again) myself, I can understand it. Of course, I tend to take a longer way of coding almost anything anyway, usually with much redundancy involved, then go back and prune it. And even with this language, which is usually eminently readable, I make liberal use of comments.

Craig, as you point out, probably abbreviates without even thinking about it, it is hard to overcome muscle memory, and when you type a line where you've typed 'put it into fld 1 of cd 2 of the mainStack' a gazillion times, your not even likely to think about it.

I think there is a benefit to it, though, in that it gives an informal introduction to the abbreviations available if you choose to use them, as came up in a thread just a bit ago where someone complained about the verbosity of the language. You and I may not think it is too verbose, but certainly others can, even brand new to it (or maybe specifically because they are coming to it from another language).

maybe I shouldn't have posted it anyway ....

Well, I can't speak for others, but I think if you feel a point should be made, or that there may be a better way of doing something, it is usually better when it is out in the open than stewing silently behind a grimace.

Just my .02, freely given and worth about that much

I see Craig posted while I was writing another great novel LOL

[jacque]

once wrote that she could no longer write "highlight"

I once wrote "hilite" in an email to a client and she corrected my spelling.

Mark Waddingham doesn't like abbreviations and once threatened to remove them. I threatened to kill him if he did. Well, not in so many words maybe.

As bogs said, it's very hard to erase 30 years of muscle memory.

[bogs]

once wrote that she could no longer write "highlight"

Mark Waddingham doesn't like abbreviations and once threatened to remove them. I threatened to kill him if he did. Well, not in so many words maybe.

Jacque, I actually had to erase all the things I just wrote in this reply 6 times

[jacque]

Don't worry bogs. I know where Mark lives. I don't know where you do.

[FourthWorld]

Lagi, the points you raise about abbreviations are good ones, but the subject is quite complex with more aspects at play than any single study I know of has accounted for.

While it's possible to isolate some metrics and extrapolate from there, doing so in isolation risks one of the core problems with extrapolation: one small error in the beginning can easily expand by the end to a much larger gap between expected and actual outcomes.

One of the benefits of abbreviation is useful for coding but bad for literature, for the very reason some prefer not to use them at all: they are less like English.

For literature, frequent use of abbreviations would of course be counter-productive (perhaps at least in part because in literature an abbrev. requires a period, a symbol we're conditioned to first evaluate as a full-stop), but with code our goals are very different.

Code is distinguished by being purely utilitarian, and ultimately of most explicit benefit to a machine. No matter how we might like to read something, if it's code then at some point it will need to be executed by a machine too stupid to count past 1. Machine constraints define the nature of code as a distinct form of writing.

So in code we use symbols, only some of which have any opportunity to even attempt to be English-like at all.

While this:

Code: Select all

put "Some Value" into SomeVariable

...works as English and code, this:

Code: Select all

put trunc(tNum) into tArray[tCustomerDiscount]

...would be horrible English, while it might be very good code.

As you noted, we don't write code nearly as often as we read it.

But more importantly, we rarely truly read code. Far more frequently we skim it to get the gist of an algo, or scan it to look for specific elements such as during debugging or looking for opportunities for enhancement.

With both skimming and scanning, visual distinction of a symbol aids identification.

Typing full symbols like "card", "background", and "scrollbar" have indeed likely never been cited on any coroner's report as a cause of death.

But for skimmiing and scanning, being longer contributes to a visually more dense space in which we're trying to identify specific things. And being "normal" words they're less distinct cognitively from the other words around them; a long string of long words is simply more cognitive work to process, and the more familiar the words the less distinct they are.

Ultimately, it's precisely because "cd", "bg", and "sb" aren't "normal" words that they're valuable: they refer to language-specific objects that have unique meaning in LiveCode; it's beneficial that they stand out visually in a dense body of code, every bit as much as using less-readable-as-literature-but-very-productive-as-code naming conventions for variables.

While Jacque is almost always less verbose than I am, I believe these considerations may be at the heart of her reaction to the thought of removing abbreviations. And they may be among the reasons why the original designers of this family of languages took considerable time and thought to include them.

And most simply, they've been around long enough in LiveCode that there's no practical way to remove them.

This leaves us in a pretty good place, as we find outselves when faced with so many of life's choices: those who like them can use them, and those who don't can use something else.

Vive le difference.


PS: Enjoy more bash. Not only does it offer tremendous value for system automation, it allows us to explore many language design choices quite different from those in LiveCode, and some are quite nice. Brevity is one of most famous distinctions of bash, but there are others as well (odd as it was when getting started I've become fond of "FI" <g>).

[Lagi Pittas]

Hi Richard

Erudite is your second name. I didnt really consider the cognitive aspects of skimming code at all and that makes sense. I think my main contention was about saving time which I still think it doesn’t, but agree with what you’re saying. I still think in the beginners section we should be using the full fat version of Livecode and let the newbies take it from there. But point taken on the cognitive load.

Lagi