Another reason to stick with LiveCode?

[stam]

https://www.infoworld.com/article/37132 ... c.amp.html

[richmond62]

Is LiveCode Memory-safe?

https://about.gitlab.com/blog/2023/03/1 ... vs-unsafe/
-

RM.png (20.63 KiB) Viewed 913 times

[stam]

Since it seems I need to clarify my post:
LiveCode language is memory safe because you don't deal with memory allocation/deallocation through the language. Perhaps something to celebrate. This is the point of my post.

From your own URL:

A memory-safe language is a language where memory allocation and garbage collection are abstracted away from the developer and handled by the programming language itself. These languages include Python, Java, and Go, to name a few.

In contrast, manually managed languages provide a developer with full control over the system memory (with some exceptions). The most popular manually managed languages are C and C++.

So I'm not sure what you mean by your question or how you are 'devils advocate'. How can there be a 'devil's advocate' response to this? It's not a debate.

[FourthWorld]

Since it seems I need to clarify my post:
LiveCode language is memory safe because you don't deal with memory allocation/deallocation through the language. Perhaps something to celebrate. This is the point of my post.

The misunderstanding here seems to stem from LiveCode's decision to have "LiveCode" refer to the company, the tool, and the language. You can livecode LiveCode's live code in LiveCode by LiveCode, much like "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" is a grammatically correct sentence.

LiveCode the scripting language does not directly handle lower-level memory management, so as you noted that part is exempt from such considerations.

LiveCode the engine needed to run LiveCode the scripting language is written in C++, where lower-level memory management is an inherent part of the coding process.

A trip through the bug DB will show that from time to time we see occasional memory leaks and other such things, as one would expect for a code base of that size. And since these types of things can in some cases have critical impact, they tend to get priority.

Maybe Richmond could explain what low-level memory issues he's encountered which will help us understand his concern.

[richmond62]

I have experienced no obvious memory leaks with LiveCode.

But I did wonder at the OP's posting that implied that LC was Memory-safe. On the basis of what?

'Tis a grand claim, and grand claims generally need supporting evidence.

[stam]

On the basis that you do not manage memory allocation directly when you code with LiveCode.
This is what “memory safe” means.

Python is also written in C, but is considered “memory safe” for the same reason.

This does not mean you don’t get bugs or memory leaks caused by the IDE. This means the language itself has no potential to be memory unsafe (how it is implemented is a different matter).

It’s not a matter of “evidence”, it’s a matter of definition.

I’m really not sure how much simpler to put this, other than perhaps suggest you read the article you yourself posted above, which provides a clear definition of what “memory safe” means.

Or perhaps pick up C/C++ to see the difference with high level languages like python and livecode.

[richmond62]

As quite a lot of LiveCode has been written in C++ . . .

[stam]

I’m only going to suggest you read the previous posts carefully and then perhaps tell us why the fact the LC IDE is built in C++ is completely irrelevant to this discussion.

Hint: we are discussing the LiveCode language, not the tools used to create the environment to run it. Exactly the same as Python and many other high level languages. Your own linked URL explains this well.

[richmond62]

I think perhaps your reading comprehension needs some work.

Not really: but my understanding of exactly how memory-safety works is a bit 'juddery'.

[stam]

This may help:
https://www.pcmag.com/encyclopedia/term/memory-safe

In short:

Memory safe refers to functions in compilers and runtime engines that prevent a program from crashing due to invalid memory references

With LiveCodeScript you can’t reference an invalid memory address because you can’t access system memory directly as you can do with C/C++.

In LiveCodeScript you can explicitly or implicitly define a variable. When the variable goes out of scope it’s automatically cleared from memory.

But you don’t need to create a memory allocation for this, store a pointer to the memory address, ensure the memory is released when it goes out of scope and ensure the pointers to that memory allocation are removed, like you have to in C/C++.

C++ is a great language - but is much harder work than LC and more prone to runtime errors (not picked up at compile-time). Code is only as good as the developer, so the binary produced may be entirely safe and unbreakable. But C/C++ has the potential to create binaries that can be hacked because of memory mismanagement, and hackers can exploit this to insert malicious code into memory and execute it.

This is not something you’ll ever hear with high-level languages such as LiveCode because that is abstracted from the user. This doesn’t mean you can’t cause errors and crashes in LiveCode - of course you can. It means that crashes won’t be because you’ve attempted to access invalid memory.

As the LiveCode IDE is built with C++ it is also potentially subject to this type of error. But the LiceCode language as such is not; as a liveCode dev you never access memory directly with LiveCodeScript.

[AndyP]

Interesting thread.

So as I read it, the act of writing a program in the Livecode language is considered memory safe as the programmer has no control on how the program written in the Livecode language allocates the memory the program uses.

However, the Livecode engine is written largely in c, c++ which is not considered a memory safe language as the programmers at Livecode HQ have control over memory allocation when writing the program.

Now as I understand it,(correct me if I'm wrong) the Livecode engine is bundled along with the program code written by the Livecode programmer, so is the resulting program now considered memory safe?

[stam]

Practically all languages deemed memory-safe are built with memory-unsafe languages.

Nothing is 100% safe.
But the language itself doesn’t let you screw things up on this front.

That’s all memory-safe means.

[richmond62]

C++ is a great language - but is much harder work than LC

I wouldn't know about the first part of that statement as I only got to about page 20 of the 'Teach Yourself' book before I felt an urge to go for a 4 hour walk on the hills with my pipe.

Practically all languages deemed memory-safe are built with memory-unsafe languages.

My doctor said something similar to me when I had a heart attack.

[stam]

There is something to be said about learning other programming languages. But it does require time which is always in short supply for most.

If you're looking to learn another language and you're on Mac, you could do worse than Swift. Lots of tutorials out there, pleasingly nice language and certainly easier than C++ while still being lower level and creates much faster apps than LC. But again more complex that LC.

Sorry to hear about your heart attack, hope you have recovered well from that.

[richmond62]

Sorry to hear about your heart attack

2014: big thrombosis: 5 stents. BUT, sadly for some: I am still here to . . .

I really wouldn't wish what happened to me on anyone: but if it does happen I would wish on them a skilled medical team as I had, as here in Bulgaria (oddly enough, given the fact that the place has an awful reputation and stinks from top to bottom of corruption), that sorted me out, and saved my life.