Wait...WHAT?!?

[FourthWorld]

A no-code front-end is a perfect compliment to LiveCode.

I would not doubt that for a minute if it is to be advocated as a thing
for people to make Powerpoint knock-offs, but not if it is to be advocated as a step
in learning how to code with LiveCode.

We disagree. I believe it can be a powerful tool for learning the language for a wide range of learners, and for some much faster.

[richmond62]

We disagree.

Good. If we all thought the same thing the world would be boring in the extreme.

Who are "we"?

I believe it can be a powerful tool for learning the language for a wide range of learners, and for some much faster.

If the thing had a no-code front-end how would one learn the language?

[stam]

Clearly you have a lot of experience in teaching Richmond, so will defer to your expertise...

From my personal experience:
I remember struggling with DOS back in the 80s and not really 'getting it'. Then the first time i used a Mac, all the way back in 1985, everything suddenly just 'clicked'. Paradoxically, having a GUI to represent computer concepts facilitated a quantum leap in my understanding of the CLI.
Yes, the Mac helped me understand DOS better

Perhaps age is a limiting factor? Going from maths to algebra (ie representing numbers with variables, or going from hard-coded values to a representation of values) was step-change in school, and one that could not be done at an earlier age (funny what you remember 45 years later...). Maybe something similar comes into effect with teaching programming?

In any case, i'm not qualified to comment on what is or isn't best practice for teaching, I'm only commenting on my personal experiences.
However what is being discussed here:
- doesn't affect LiveCode in it's current form, should only offer an extra tool and should not hinder you in teaching as you think is best
- would not be primarily directed at children, much like Automator on MacOS isn't a child's plaything.

[mwieder]

I'll defer to Richmond here on questions of education because it certainly isn't my field.

But I'll pop in to add that I had the same misgivings about the link from LiveCode to other more "acceptable" programming environments, as in the leap from

Code: Select all

put 3 into x

to

Code: Select all

x = 3

but it seems that this doesn't seem to be an obstacle.

[FourthWorld]

We disagree.

Good. If we all thought the same thing the world would be boring in the extreme.

Who are "we"?

The participants in this thread who share that view.

I believe it can be a powerful tool for learning the language for a wide range of learners, and for some much faster.

If the thing had a no-code front-end how would one learn the language?

What I wrote earlier about the limitations of no-code solutions still applies.

Consider where we are now: we have LC Script, and when we need to do something beyond its scope we can use LC Builder. When we need to do something beyond Builder's scope we can use the externals API. When we need to go beyond that we can access the engine's source directly.

An optional no-code frontend is just one more layer in what is already a richly layered cake.

[richmond62]

I do not disagree with this:

An optional no-code frontend is just one more layer in what is already a richly layered cake.

What I disagree with is how that layer could help anyone learn the language as it is, by its nature, languageless.

[mwieder]

Hmmm. I didn't realize that's what was at issue here.
While I agree with you, I'd like to point out that what HyperCard did some thirty-odd years ago was allow non-programmers to get an idea of how a computer could be coerced into doing things, and if that sparked their attention they could then dig in deeper to explore the programming language underneath. So yeah, I think a no-code frontend could be the gateway for some into an interest in learning programming.

[stam]

What I disagree with is how that layer could help anyone learn the language as it is, by its nature, languageless.

it's not 'languageless' in the broader sense though, is it?

take some examples of what code does:

• it reacts to inputs
• it stores and manipulates data
• it manages states of objects
• it produces some form of output

All, or most of the above can be represented graphically and be made more approachable, theoretically at least.
I mean sure - you don't get the liveCode script 'language' exposed directly. But a lot of the understanding of how to build apps, or components for apps doesn't come from understanding the innards of a handler (although that helps), it's about managing the the business logic. What is the point of learning a language if you can't do that? Conversely, once you have the business logic clear, implementing in language is much easier.

OK granted - this won't in itself make you an x-talk guru... but at the end of the day, HyperCard was not described as a programming language, it was described as a software erector kit and it was wildly popular in the late 80s/early 90s, because it let you build stuff so easily and pleasantly. And it would draw you in to HyperTalk...

Actually, (and i'm sure i'm paraphrasing someone more knowledgeable than me) - which technology you use is irrelevant. There is more to building stuff that what language (or even what building blocks) you use...

As Richard says, LiveCode is already a very richly layered cake - adding a tasty looking front end will only make it better IMHO.

[FourthWorld]

For myself and most others I know, learning any programming language isn't the goal. The goal is making software. Learning a language is a step in fulfilling the goal, as is learning the IDE.

We don't use the Message Box for everything, often relying on tools to make routines tasks simpler.

What's good for using the the IDE is good for other aspects of making software.

Consider: what is a code library? If you use someone else's code, you're getting a lot done without having to learn those nuances of the language.

[jacque]

I don't have any particular viewpoint on this, but wanted to mention that HC had only one automatic programming feature. You could drag a button to the card and HC would lead you through the process of linking it to another card. That was pretty much it.

The user guide mentioned a single example of actual HyperTalk: hide menubar. That gave me such a thrill that I immediately sent off for the scripting guide and started to learn the language. Apparently enough people did the same that HC began including the guide with the software and added a dictionary to the installation.

Edit: I forgot about the pre-fab buttons, maybe because I didn't use them much. There were a few.

[jiml]

MarkW wrote:

I'd like to point out that what HyperCard did some thirty-odd years ago was allow non-programmers to get an idea of how a computer could be coerced into doing things, and if that sparked their attention they could then dig in deeper to explore the programming language underneath.

Exactly. Mark's metaphor is apt. As I recall one's HyperCard digging was neatly divided into 5 levels: Browsing, Typing, Painting, Authoring, and Scripting. They were a kind of geologic or archeologic strata, You could move from one to another as your comfort and confidence allowed - uncovering more and more power as you dug deeper.

LiveCode doesn't have that. A new user is thrown into a deep Scripting hole all at once. This probably confuses some new users and turns them away.
Providing a no- or low-code entry point to LiveCode might help LC novices.

[richmond62]

Well, why not have EXACTLY what HyperCard had: a visible HOME stack with 5 levels?
-

HCIntro8.gif (2.93 KiB) Viewed 5601 times

[stam]

Well, why not have EXACTLY what HyperCard had: a visible HOME stack with 5 levels?
-

HCIntro8.gif

Erm... that's kind of irrelevant. These are just access levels in Hypercard, limiting what the user can access. It does not in any way approach what is being discussed here.

Instead, the analogy i have in my head is more akin to Automator on mac (the 'successor' to HyperTalk on Mac is AppleTalk - well, kinda - and a newer development was Automator), which puts a graphical interface on AppleScript, but appleScript still remains unchanged and works as it did before:

[richmond62]

Don't you think there is a possibility that an automated front-end

[see my MSc thesis: https://www.dropbox.com/s/aknlqyovmke61 ... f.zip?dl=0]

would result in end-users thinking,

"As it does it all for me why should I bother to go to the trouble of learning the underpinnings?"

[stam]

Which is the type of argument people used to proffer when GUIs hit the market in the era of DOS….

Is greater ease of use and convenience for new users and potentially bring more users in really an argument against change? (And by change I of course mean keeping what’s there and adding something new).

If your entire point in life is to learn x-talk as a language then perhaps.

If on the other hand your aim is to facilitate RAD, ease of use of building apps, and make it easier for non LC users to join the fold, then that is a weaker argument…