Why is LiveCode not recognized more as an app developer language?

[stam]

Ambiguous name:

https://marketplace.visualstudio.com/it ... r.livecode

And this is the problem with GitHub as well: if you search for 'LiveCode' you get a ton of stuff about people 'coding live' or some such nonsense.

Would be great if LiveCode ltd could do something about this, such as getting LiveCode, LiveCodeScript, transcript or some such registered as a language - GitHub is used by so many, it can only help increase exposure but would also make it so much easier to actually search for LiveCode...

[FourthWorld]

Would be great if LiveCode ltd could do something about this, such as getting LiveCode, LiveCodeScript, transcript or some such registered as a language - GitHub is used by so many, it can only help increase exposure but would also make it so much easier to actually search for LiveCode...

Choosing a name has been problematic, twice. Changing the name again would be more problematic, and attempting to control others' indexes is a dream of every SEO "expert", who tellingly rely on marketing methods outside of SEO to gain attention.

One general tip is to use the phrase "LiveCode programming", with those two words adjacent in that order, to provide signalling to a good many SE indexers, most of which weight word proximity.

But that's for searchers, useful for those who already know the name and are now looking for code to use is more efficiently.

For that there's an option which amplifies both utility for the current user and signaling for searchers:

One comprehensive index of everything in the LiveCode universe that's not already in the box.

Many other language have one. Where would Python or Node be without their vast repositories.

Picture a web site with an API. Readable in the browser, traversable by spiders, useful via the API right in the IDE to find and install parts in just a click or two. Searchable/sortable by type, features, license, author, and more.

You could build it in something like Drupal in a day, and populate it in a week.

We could explain how we came to this place, a quarter century after launch, and still don't have this, but that's an awkward tale to tell fully.

Better to focus forward: could the team temporarily take someone off one of the exploratory sidequests to deliver this key element for the main product they have in hand today?

[stam]

Better to focus forward: could the team temporarily take someone off one of the exploratory sidequests to deliver this key element for the main product they have in hand today?

Agree with everything you say - however the GitHub thing does sound like something that can be done by a non-programmer moderately quickly (it's just a process to follow). Strikes me as something a PR person could do (if they still employ such) and would likely be more beneficial than things like revamping websites...
After all, if XOJO can do it and be recognised as a language I really don't see why LiveCode can't...

[richmond62]

Where there is a will there us always a way.

But floppy rabbits only flop around.

[FourthWorld]

Better to focus forward: could the team temporarily take someone off one of the exploratory sidequests to deliver this key element for the main product they have in hand today?

Agree with everything you say - however the GitHub thing does sound like something that can be done by a non-programmer moderately quickly (it's just a process to follow). Strikes me as something a PR person could do ...

Absolutely, AND not OR. Good audience building is multifaceted, using every opportunity available, ideally in strategic coordination for a multiplier effect.

[Francesco77]

...

Why is LiveCode not recognized more? Because it's not really free for professional app development. ...

It doesn't really have to be free. It would be quite sufficient if it were possible to use the program free of charge until you actually want to create a commercial application with it.


Until then, anyone should simply be able to install LC on their computer free of charge to test whether it is suitable for them.

I am sure that anyone who has created a well-functioning app in this way will then also be prepared to pay for commercial export to various platforms.

I think most people who want to try out a new tool or programming language don't want to start by buying an expensive license.

This system will never work in my humble opinion.

Edit:

I have just checked briefly whether I am still right with my argument.

It could be that something has changed in this respect since I accessed the LC website several weeks ago.

Unfortunately, there is no good news there. The website itself still shows the same boring example app.

And you can only try LC for free for 10 days(!!). And even for that you have to register with your name and e-mail address.

So, that's not going to work.

[stam]

It doesn't really have to be free. It would be quite sufficient if it were possible to use the program free of charge until you actually want to create a commercial application with it.

I believe this may have been tried before although predates my involvement with LiveCode.
I believe the issue is that people just share a stack and advise to download the 'free' IDE to run it, thereby bypassing the need to build an app.

In other words people can still distribute an 'app' in the form of a stack file without ever committing to payment.
This is where the immediacy of the of the interpreted nature of stacks is a disadvantage - there is no compilation required to run a stack so for an end-user there is really little difference other than having to download the IDE and presto - you have licence-free distribution.

I believe the web version of Create will have a free tier that only allows 1 app at a time, although can't be sure (that certainly seems to be the case right now). Perhaps this is the acceptable compromise for the company and the users...

[Francesco77]

It doesn't really have to be free. It would be quite sufficient if it were possible to use the program free of charge until you actually want to create a commercial application with it.

I believe this may have been tried before although predates my involvement with LiveCode.
I believe the issue is that people just share a stack and advise to download the 'free' IDE to run it, thereby bypassing the need to build an app.
...

Do you really believe that?

First, I guess no one who seriously creates applications and sells them tells their customers that they have to run the delivered solution in a programming environment in order to use it.

At least, in 30 years as a software developer, I've never seen anything like it.

Secondly:
I think there would be many simple ways to prevent this kind of abuse of the program.

One could even bind the generated stacks to the developer's particular LC version. Then it might not work at all in another environment.

The key question is what the goal is. If you want to have a broad user base with many users, you need a free version. Otherwise this will not be possible.

If you don't want that, there is no other option but to make the product very expensive for very few users.

Whether this method will work, however, is very questionable in my opinion.

[stam]

Do you really believe that?

I do believe that very much I'm afraid...
Not because serious developers would do this; and even though I'm not a professional developer I certainly wouldn't; but precisely because LiveCode openSource favoured many - shall we say - less regimented developers?

I'm fairly certain I've seen talk of something like this a while back (perhaps with version 6? predates my involvement with LC which started with version 9) and certainly LiveCode ltd seem to think it's an issue and they are the only ones who know their numbers.

And again to be clear, I would not dream of doing this even if I was creating opensource freeware - but some obviously have.

And yes, I agree with you on many points.
Personally I think they missed a big trick 10+ years ago. Looking at python - is it really a better language/environment? is it really easier to use? more capable? In itself, no. In many ways it's kinda lame. Of course it also is more digestible to C-style language developers and worshipers of OOP.
But a whole industry has sprung up around it and made it what it is because the engine was available freely.

One can only speculate, but not releasing the engine as a free/opensource runtime and allow coding from any IDE but also sell a premium IDE commerically as the main moneymaker might have made LC a python-killer. But that's pure speculation that can never be proven now...

Having said all of that - the pricing structure seems to be changing back to more reasonable levels (albeit with a royalty fee) and I think there will be free tier for the online version of LiveCode Create. And while LCC is a bit different it is still LiveCode and with the right incentives, could be an attractor for new users.

But it would have to be a tasty hook to catch those fishies...

[richmond62]

Constant bad marketing and not listening to the many, many people who told them to do things differently.

[Francesco77]

... (albeit with a royalty fee) ...

.. when I read that (in the product information for LC) I was actually a bit shocked.

I think royalty fees are a relic from the 80s or 90s of the last century.

It's bad enough that Apple or other distributors are getting paid well for their stores. Now royalty fees for a product that the developer created himself?

You could perhaps think about something like this if you had thousands of developers developing commercial products with LC. But in the current situation, where we should be happy about everyone who uses LC at all?

It all seems rather strange to me. Royalty fees for all I care - but then a free development environment. But not a subscription + royalty fees.

That's just strange.

[stam]

Like you (and I'm sure everyone else) I do not enjoy paying more either. But I would point out a few things

.. when I read that (in the product information for LC) I was actually a bit shocked.

I think royalty fees are a relic from the 80s or 90s of the last century.

The royalty fees are maximally 5% of profits made; or nothing if freeware (but with a yet-to-be-revealed branding mark - I do object to how this has been described and have voiced this elsewhere - but we don't yet know what that will look like).

I guess the choice would be between paying something like the fees for Qt (~$2-4K annually) or paying much less + royalties. I know I'd prefer the latter.
And no, royalty fees still do exist for some platforms. It's just that many platforms have either gone free or charge crazy amounts of money (Ionic.io - $4200/year for standard licence). It seems "free' was not a viable alternative for LiveCode and in fairness they did try that for several years.

It's bad enough that Apple or other distributors are getting paid well for their stores. Now royalty fees for a product that the developer created himself?

$99/year gets you free storage/distribution/exposure on the app stores - and you are now able to code-sign and notarise all your apps for that low fee.

If you think that's a lot, have a look at our Windows brethren - they now have to pay between 5 and 10 times as much just for code-signing their apps and you can optionally pay for 'good reputation'. And this fee is to 3rd party companies, not from Microsoft - so you get nothing from Microsoft for paying $800/year to code-sign your apps.

You could perhaps think about something like this if you had thousands of developers developing commercial products with LC. But in the current situation, where we should be happy about everyone who uses LC at all?

But this is the point - including royalties means that LC have reduced the subscription cost from the previous "standard license" by quite a bit - depending on your previous license by as much as 70%. And my understanding is that there will be a free tier for the online IDE of LiveCode Create - both of these things will reduce obstacles to new developers taking this up.

The current subscription cost is on par with competitors like XOJO (although they are still a bit cheaper), as the sub costs have been reduced to logical levels by deferring payment by royalties - and really if your app is massive successful it is not unreasonable to share a tiny fraction of that profit and if not the additional cost is very low.


Actually my biggest issue with the new liencing schemes personally is not the royalty scheme - that is actually not bad.
It's more for the "internal users" license that requires each end-user to pay a subscription as well. That is going to be a harder pill to swallow for companies employing developers to create custom solutions, so I think that will be an obstacle. Of course I only speculate because I'm not in that position.

But for small/indy devs I think this change is a benefit, and almost on par with the old Indy license, which I always felt hit the sweet spot exactly.