Why we abandoned open source: LiveCode CEO on retreat despite successful kickstarter An easy to use programming language that was made open source in 2014 after a successful crowdfunding campaign is going back to closed source after too many customers switched to using it for free. LiveCode Community, open source under the GPLv3, was archived on GitHub and future development will be closed source. In the …
Some developers of open source software are in it because they love to code or they developed software that they wanted to solve their problem and offered it to others.
But for projects with ongoing development, often an active user community of unpaid developers is not enough. Some rely on sponsors contributing employee time or money. Others transition to separate licenses for commercial and non-commercial use.
Because of the way LiveCode development was funded, with a single Kickstarter payment but with few in the user community who could contribute expertise to development, these don't seem to be options. Offering the existing software as open source and continuing development as closed source seems reasonable.
I suspect funding development will be a growing issue for the FOSS community.
I do not think it is a growing issue, its a very old one.
You open source something you develop yourself and you can either get other people to contribute, or, at the very least, lose nothing by open sourcing, or something that supports your business (so it increases your sales for customisation, consultancy, or hosting services, or helps you sell hardware, or whatever) or something you can get funding for (grants, sponsorship, whatever) or some other benefit.
The problem is that these people have no idea how to make money from it. No one else wants to cotnribute code, they have no plans for funding except the one off kickstarter. It looks as though it failed as a proprietary product, then failed as open source. The company was in serious trouble not long ago and is technically insolvent with a lot of debt, even after raising more capital. See accounts to June this year.
Icon because that is what Live Code is!
or, at the very least, lose nothing by open sourcing
…except your paying customers if they switch to it. Which is what happened here.
The problem is that these people have no idea how to make money from it. No one else wants to cotnribute code
Because the main users base (by definition) aren’t the kind of people able to contribute.
Whilst livecode may have other issues, it’s certainly not had a positive experience with open source, and it sounds like their new approach might be the right one for them.
Open source is wonderful, but that doesn’t mean it’s the correct solution for everyone, or that it doesn’t bring with it’s own issues, to pretend otherwise is somewhat myopic.
Personally, I wish them luck.
"except your paying customers if they switch to it. Which is what happened here."
Exactly my point. They had a lot to lose from it.
On the other hand they did not have much to gain from it, other than a one off cash injection from the kickstarter. All very well, but not sustainable.
They do not seem to have a plan. It seems to be that they could not make a profit from their proprietary product, so they open sourced it out of desperation, got some cash in from the kickstarter, and then realised it was not going to work long term.
I very much doubt the new approach will solve their problem. Their problem was not so much that they lost paying users to the open source version as that they never had enough paying users to have a viable business in the first place.
The article says: LiveCode syntax is English-like, and the company argues that "every semicolon or bracket required by a language introduces another potential source of error."
So less punctuation by the sounds.
Yes but if its your product you want schools/colleges/Universities to be teaching it surely?
The more people who are taught a specific piece of software in schools means you are more likely to use it (For me in college this included Original Visual Basic 5, Office VBA, Photoshop Illustrator, etc...).
Anyone who says "nothing" doesn't know anything about the history of the family of languages that LiveCode is built on. The evolution of xTalk languages date back to the 1960s and intertwines with the history of the HyperText, HHGTG, TBL first web browser, wikis, etc. If Apple had made xTalk into an open standard in the 80s it may have filled the role that was eventually filled by ugly JavaScript. LC is built on a foundation of HyperCard (which is still somehow mentioned fairly often despite being abandoned by Steve Jons when he came back to Apple) and a raft of clones SuperTalk, Oracle MediaTalk, Lingo, Gain Momentum and a raft of other contenders to be heirs to that thrown.
I wondered how this revolutionary natural language programming script worked. So I looked up some samples. And found gems like this.
on keyDown pKey
if the length of me >= 5 then
// If there are 5 or more characters in the field
// beep and prevent text entry
beep
else
// Allow text entry by passing the keyDown message
pass keyDown
end if
end keyDown
I was hoping to see something like Github's code pilot where you type in a natural language description and it does the work. But its a recognizable programming language. And despite claims about punctuators I can see a greater-than-equals sign and a C++ comment. And there's camel case, too; I didn't stay to find out how significant it is.
I'm not going to diss it too much. Maybe it's a bit less intimidating. But its made choices that have been around since before Pascal and added some verbiage and/or draws information from prepositions. No doubt it takes some finessing under the hood. But its still describing the same structures in the same way that we're all used to. There's nothing that revolutionary here. Still, good luck to them!
[Warning: generalizations ahead!]
I'm all for new languages as long as they have a clear purpose and/or offer useful novelty, but languages created for the specific purpose of teaching programming or CS are often useless IMHO. They may help learn the basics quickly, but limitations get very obvious very soon.
One of the worst cases was (is?) Portugol, a Pascal-like language used to teach programming in Portuguese in the 80-90s. I was teaching at a Brazilian university and was very against it -- why not just teach Pascal or C? Some colleagues that were in favour of it said that commands in Portuguese were encouraging and that the learning curve was less steep than the ones for other languages.
As a practical result, I had to teach second-year students C before teaching Data Structures. Portugol was a waste of our time.
[rant over]
They may help learn the basics quickly, but limitations get very obvious very soon.
But that’s what they’re for. To teach the basics. They’re not meant for university level students, they’re meant for children. It provides an easy route to writing simple software. The nuts and bolts are what you learn as you progress, but when you’re 10 having an easy to understand language that gives you the BASICs can really get you started.
When I grew up it was BASIC on one of the 8bit home machines, but that was the same, you could just start typing and make the thing do something with very little knowledge. It provided a gentle enough slope for me to get interested without overwhelming me.
This is the step you take when you’re 8 or 9, before you graduate to Python or similar.
I don't know about you, but I spoke to my kid in English right from the git-go, not the cut-down version some people call "baby talk". As a result, she learned to speak, read and write proper English much earlier than her peers. Go figure.
When the time came, I extended the concept to programming languages. It seems to have worked.
It's strange you mention Perl. Because I find the suffix unless and if are much more natural than standard if statements. For example:
pass through keypress unless length >= 5
Describes a normal rule (pass through) and an exception to the rule. And then you could add
beep if keypress didn't pass through
I think it's far easier to focus on what is going to happen, and then, once you know what's going to happen, to think about when it can or can't happen. Learning to reverse that is probably the difficult conceptual step.
We're used to if/then constructs if we have ever programmed in the usual languages. But you may have a point about how people understand things. I was working on a protocol specification recently and put in an if *foo* then *do this* description. Government reviewers (important role in this case) rewrote it to *do this* if *foo*. They thought it was clearer that way, it was semantically equivalent, and nobody objected. So LiveCode may have a point.
Perl actually has some clever syntactic bits, and also values brevity. But as much as it pulls people in with it pragmatic bits, only those with tremendous will can maintain the discipline to write sound maintainable code with it. But just like stocking the break room with unlimited pork rinds and soda, or vodka and redbull. While one or two members of the team will be fine, you are really setting up the rest to fail spectacularly.
Which is why the unwritten rules of the road state that Perl is for hacking, not production. It's not the languages fault, but it is an enabler of your worst self, thanks to implied syntax et al. Too much jazz and lsd under the hood.
I don't know about that. Perhaps I'm just too used to the if/then syntax, but I feel it makes more sense in code and in English. We use sentences like that all the time: "If your car isn't going, check the fuel gauge to see if you need to add more". Far from expressing a rule, you're specifying a situation that is possible and what to do under that situation.
I like that syntax in English for most conditional statements. The unless version can get very confusing if things are long. "If you see an alert on the security monitor, first press the acknowledge button, then alert the security station, then contact the police" makes sense. "Press the acknowledge button, then alert the security station, then contact the police if you see an alert" runs the risk that they will miss the important bit at the end which controls whether any of that should be done.
"Ah, so you didn't teach her Perl then."
She discovered perl on her own. Back in early 1988 she was subscribed to comp.sources.unix and read Larry's first post on the subject. She emailed me and suggested that it would be fun to join in from the beginning. I agreed, and so we learned it together.
Ignoring the mystique and FUD surrounding perl, after all these years it's still a fun and useful language that runs on damned near everything. Recommended.
Except I taught myself how to write c64 basic from the machine's manual. It was my first exposure to programming, and I guess that this was the case for many of us. Once you have learned how to think about programming, picking up a new language is simple. Like really simple, especially if it follows a similar logic, that is procedural, functional or object oriented. Teach the kids how to think logically, break down problems into tiny pieces and the language you use is mostly irrelevant (I'm talking about kids age 10 or so).
You can teach the basics just as well with a normal language where you don't tell the kids about the other parts. They start with the basic expressions and you eventually give them the rest. Or, for people who want to jump into more complicated programs, you provide a library which abstracts out such things until they know enough to read that library and understand what you wrote.
I remember creating several of these libraries when my sister showed interest. It started with some basic input functions and expanded to handle other operations, in each case with a limited interface which worked. Instead of writing a new compiler from scratch, I wrote maybe 500 lines over a month or two by adding new functions when asked. And as a bonus, once she knew enough not to need that library, she could start understanding the language reference docs and building more complex stuff. No learning of new syntax when new functionality was desired.
I'd always wondered if there were other programming languages built on a non-English substrate.
I can certainly see the attraction of writing code using a syntax like:
programa
{
inclua bibliotexa Matematica
funcao inicio()
{
inteiro variavel = 123
}
which would be less intimidating to a native Portuguese speaker, than:
program
{
include library Matematica
function main()
{
integer variavel = 123
}
Of course, one can argue that English is the lingua franca of science and engineering - but, I am sure, it won't always be so.
Of course, the language mapping might be less of an issue for those who "instinctively" view things like int, char, etc as symbolic than linguistic elements.
Anyone know of other programming languages that use another language or glyph system (Cyrillic, Hiragana, etc) at their core?
> Anyone know of other programming languages that use another language or glyph system (Cyrillic, Hiragana, etc) at their core?
There was some version of Pascal(?) in German. So a for-loop would be a für-loop, I kid you not. It didn't help that ü has no ASCII encoding, at a time where UTF-8 wasn't heard of.
Anyway, using keywords not in one's own language is in my opinion an advantage, no confusing connotations!
Didn't the characters ion Stargate come across a computer programmed with hieroglyphs?
I wonder if the Chinese Linux distros use any Cantonese or Mandarin based programming languages? It'd not surprise me, they have a very large internal market so have a potential for a larger user base than some of the current lesser known English based languages which are still maintained.
This post has been deleted by its author
If you see (or hear) 吗 (ma) at the end of a string of Chinese, you can often assume a question with a yes/no answer is being asked. Ideal for IF THEN constructs.
Thinking further, the problem with learning BASIC is that there are no constraints or incentives to learning structured techniques. One method that sure does do that for you is to use Nassi-Shneiderman (N-S) charts. If the chart gets overly busy in a particular part of its body, then it's time to separate out the block into a separate procedure.
Reason why N-S charts have never made it big IMHO is that a lot of people know of them, and how to use them, but to generate one after a program is written is cumbersome either because of the need to compress a section of code into tiny, tiny boxes (because the procedure is too long and/or it does too many things), or the programmer may have taken liberties with structured programming principles in writing their code. A common one is explicitly exiting a loop without going through the END at the bottom of the loop.
Simplistically, Chinese characters are sometimes characters within characters, (吗, for example comprises two characters mouth 口 and horse 马) so your question triggered off in my mind the idea of an IDE (editing and programming environment) that uses squares instead of indents for its structure. Programming arguably is still rooted in text-based systems, yet many aspects of technology have moved on to GUI's.
To my mind a radical way to progress the art of coding is to use an N-S IDE in place of a text editor.
To produce a program, drop a square on the page and fill it out with code blocks, if/then blocks and loop blocks, much like a Chinese calligrapher. Very visual, very structured, very well-documented with little effort. Errors, particularly those involving program flow, should be much more apparent visually. Producing programs this way should be more fun because of the visual element to the design.
Turning that into viable code should be a doddle if the problems of defining and editing the blocks on the page can be overcome.
Great reply. It often takes a completely different culture/way of thinking to come at a problem/task from a different perspective and come up with (what maybe) an elegant alternative approach.
Latin text is obviously simply one possible way of visually communicating intangible logic, but we've kind of got stuck with it.
Anyone know of other programming languages that use another language or glyph system (Cyrillic, Hiragana, etc) at their core?
There used to be a French Algol 68 system. I can't remember the chap's name (French academic of course) but at A68 conferences he'd have example code like
SI x < y
DEPUIS
… code …
IS
[Not sure about that closing IS, it would have clashed with the IS operator in English, but I can't remember whether his compiler accepted English reserved words.]
And there was always APL which had its very own character set, mixing mostly mathematical symbols with Greek letters.
MIT's Scratch has been translated into loads of languages, as have several derivatives such as Berkeley's Snap. These are block languages and so also avoid the punctuation problem. They are also free.
Once you've learned them, you are probably ready for something like Python, which is also free. If you get even deeper, the Linux toolchain is free and so is Visual Studio's Community Edition.
So I am rather puzzled to understand why anyone thinks there is a market for a non-free language for teaching.
The problem is marketing and management want coding to be inexpensive. So easy, in fact, that kids can be taught to program by a teacher with a certificate to teach general education.
Unfortunately for them, computers are the single most complex tool HomoSap has managed to invent. They are inherently difficult to program. And there is no easy way around that ... regardless of language.
At secondary school (13-14 years old , this was 1986-88) I was at a school who were very proud of their computer lab. They had maybe 20 IBM PCs (the Swedish head office of IBM was in the same area as the school, so I'm guessing they donated them?) that they used for teaching everything from typing (anyone remember IBM Writing Assistant?) to geography (blind maps!) and mathematics.
At one point we were introduced to a pseudo-programming language called "Myrsteg" (literally "Ant Steps") that was supposedly based on Logo and used commands in Swedish. You typed a bunch of commands that directed a triangle cursor (the ant) on the screen to draw lines and geometric shapes, very simple commands like FRAM 10 (forward ten pixels), VRID 90 (turn 90 degrees) and HOPPA (jump; that is, do not draw a line during the next movement). There were some more involved commands for loops and for drawing lines between points you couldn't easily get to without incessant jumping; if I recall correctly they were something like TRÅD (thread; anchor a thread at the current location), then do a bunch of movement and eventually SPÄNN (tense; pull the thread from the original point to the current one taut, essentially drawing the line).
As I recall it, you could type the programs one-by-one into a "live interpreter" or store them in a script and run them in one go. Just like Python today, I guess, only with less tracebacks.
And I wonder if there's punctuation hiding there in plain sight. How are statements delimited? I suspect that EOL has a function in the language.
If so then either
1. They can't write multiple statements on one line
2. They can't write statements that run onto the next line unless there's a way of escaping the new lines in which case
3. They now have to learn about escape characters, a more complicated concept, and
4. They also have to learn about statement delimiters which is more complicated because
5. They're hidden in plain sight.
Well, there has to be, doesn't there? Even in human written languages punctuation is a necessary thing. We need to delimit individual thoughts/concepts. For example,
It's time to eat George would you set the table
Is that:
It's time to eat George. Would you set the table?
or is it:
It's time to eat. George, would you set the table?
We could define rules for writing it without the commas, by say requiring a EOL instead of a period and EOL + indentation for a comma.
It's time to eat
George
would you set the table
But it is just trading character codes. How does that make it less error prone? And wouldn't this just be a more COBOL-like version of BASIC?
In C++, and other languages, the greater than sign is a punctuator. As is the equals sign. Together in succession they form the greater-than-or-equals operator.
Anyway, the language seems to use parentheses for function calls:
sort lines of tMovies by letterGrade(last item of each)
So that meets your definition.
Once of the best BASIC style langauges I ever played with was DarkBasic, it had ingrained hooks into DirectX on Windows so within a few lines and about 10-15 mins you were drawing true 3D graphics and loading sprites in!
I always thought DarkBasic would be perfect for schools
- it runs on Windows, bog standard old spec Win10 can run it
- it was made by a British company
- it's very quick and easy to learn
- it compiles to a binary EXE
- standard BASIC syntax so the syntax knowledge can be re-used
- it gives quick and fun feedback within minutes which is what you need to for kids
Failing that a lot of places did go for Python, not my first choice and certainly not in my top 10 langs list but at least Python does try to teach good coding habits for the most part, way better than what i can see of this LiveCode syntax.
Yes, BASIC and its variants don't get the respect they probably deserve. Beginners All-purpose Symbolic Instruction Code was easy to use for simple programs. In its original Dartmouth DTSS version (which I used back in the 1960s), you could basically treat it as a calculator, noting that pocket calculators didn't exist yet. It also had decent string functions. The use of line numbers for structure didn't scale well, of course, and EDIT RESEQUENCE was often necessary. But later versions fixed that.
Hard-core programmers prefer C-type languages, which get closer to the hardware, but most people would probably get more done with a higher level of abstraction.
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.”
― Edsger Dijkstra
I never cared for this quote, as I learned BASIC in the late 70s and am still professionally writing code today. But I get his point, given the time it was made.
Dijkstra ? isn't he that guy that wanted to abolish the GOTO ? a goto is nothing but a jump instruction.
Kinda hard to make a processor that can't execute a jump ... you could only write linear programs. no calls, returns , subroutines, functions, loops, if-then , do while constructions.
They all require 'GOTO' operations at processor level.
Agreed.
A high-level interpreter/compiler will keep that within some kind of bounds though.
I've worked with Assembler on Intel chips where there were opcodes for Jump within Page available. The idea was to reduce cycles but it arguably helped with readability and damage limitation. On the downside, trying to manage the artificial (artificial to the coder, that is) constraint of a Page can be a pain.
It is easy to do dodgy things with Assembler, such as manipulating the stack, then exiting from a subroutine to a completely different location to where it was called. Easy to do, a nightmare to debug.
Oh yeah. 8048 and 8051. i still use 8051's ! i program them in intels PL/M language.(the same language used to write the CP/M operating system.)
The page jump is beneficial as you don't have to reload the entire 16 bit address. The address bus is multiplexed into two bytes so you save a processor cycle if you only need to do short jumps.
That PL/M language is specifically designed for the 8051 ( and later also for the x96 and x86 series as well as the i960). it has constructors where you can assign routines to specific register banks so you don;t have to waste cycles on moving data in and out of routines. since the 8051 has 4 register banks i typically use bank 0 to make a small operating system, nothing more than a pre-emptable scheduler in like 200 bytes of code and 20 bytes of ram) . it has hardware timers to fire off interrupt that switches threads. The remain 3 banks are used for three 'threads' , each in their own bank.
Thread 1 handles all i/o of the program : keys, displays , leds, serial. input hardware interrupts set flags and create software interrupts (can be pre-empted). and output is a time scheduled task attached to a hardware timer. so all I/o is time driven and takes a fixed amount of processing time. the whole thing is near real-time deterministic.
Thread 2 nd 3 are for the real application. the beauty of this is that i can swap threads without needing to perform context saves . I can pass variables without having to move them. This saves a tremendous amount of cycles and code. Both of which you don't have a whole lot of in a machine with 8K rom , and 256 bytes of ram
He didn't want to abolish GOTO, he considered it harmful as used in most cases.
And yes, he considered learning BASIC as your first programming language as a good way to fuck up your ability as a programmer for life, partially but not only due to the heavy use of GOTO. After many years in the industry, I tend to agree with this assessment. HOWEVER, please note that I know people who are exceptions to the rule ... but most of them will agree that learning BASIC first stunted their early growth as a programmer.
I Never understood the adversity to basic. It has the same command set as any other programming language out there. (we're not talking runtime libraries here ! . only the elementary constructs)
- you have subroutines (functions that don't return anything) and functions
- switching logic : if-then-else-elseif / select case
- looping logic : for-next, while and do-until
- you have all the elementary operators , mathematically (+-/*^and sqrt, rounding and sin cos and other stuff. many other languages aready need additional libraries for trig stuff) and boolean (and / or / not)
- you have all datatypes : integers and floats , multidimensional arrays and strings
Basically all you need and have in any other language (pun intended)
On top of that:
- simple , easy to understand plain english keywords.
- No mindfuckery with whitespace for flowcontrol (like python) and the endless associated tab/spaces problem in the editors.
- No need for all the braces and semicolons like C and many others. why do you need to tell the compiler a statement ends ? it can't figure that out by itself ? and why can't it use the implicit <CR> or<LF> at the end of line instead of me having to explicitly type it ? Ok, ok i hear you : long instructions.. statistically speaking there is less long instructions than short ones. So you need less 'continuation' characters' than 'termination' characters. Besides, if the instruction becomes that long it can't fit in 80 columns: time to carve it up in multiple shorter chunks. it only improves readability and understandability.
- No endless crap with having to help the compiler with = / == as the compiler knows exactly when it means 'assign' and when it means 'compare'. (any language can do that. the decision tree is very simple and many language much older than c could already do it)
- you get a runtime library with string handling and many other things. automatic bounds checking, no memory overruns in arrays or strings as those their length stored upfront so the runtime can throw an error if you step out of line.
What's there not to like ?
All these other languages are nothing else but Basic in a different form made more complicated requiring more compiler handholding and less bound checking and more curly braces, semicolons and other stuff that makes it look like a mathematicians wet dream.
This reminds me of SimScript-II. The trouble with languages like that is they become really tedious to type, using four characters where one would do. (" of " in stead of ".") His beef seems to be with punctuation that is used for structural purposes, since he allows them in arithmetic operators.
Ok, what are some existng languages that do the same thing? COBOL?? Talk about tedious.
Or LISP - it only has four special characters: ( ) . and space.
Actually a nice middle ground is plain old Fortran.
It depends on which concepts you want to get across and which ones to de-emphasize. Which keys you type seems an odd thing to focus on. I have heard of Erlang being used in introductory programming classes which is an interesting take since it completely lacks the concept of 'variable'. Is that more useful than avoiding the use of colons?
Or LISP - it only has four special characters: ( ) . and space.
#*Cough* reader macros #*cough*.
Actually a nice middle ground is plain old Fortran.
Nice??? Sorry, that should be .NICE.???
I have heard of Erlang … it completely lacks the concept of 'variable'.
It has logic variables(*) that work by unification.
(*) aka "You Keep Using That Word, I Do Not Think It Means What You Think It Means"
Erlang does not have what most other languages call a 'variable', that is a memory location that can be written more than once. This avoids a certain class of errors that prop up in multi-threaded programming. You can get sort of the same effect but through other more explicit and safer means. PonyLang also has a concept of write-once memory but takes a different approach to get there.
Erlang does not have what most other languages call a 'variable'
Hence my Princess Bride quote. "Variable" has a variety of meanings, and logic(*) variables predate programming variables by several decades.
This avoids a certain class of errors that prop up in multi-threaded programming. You can get sort of the same effect but through other more explicit and safer means.
I would argue that if you're trying to prevent problems with shared memory races there's nothing more explicit and safer than simply not having shared memory. That's why I prefer programming in the Erlang/Elixir world for when I'm dealing with heavy concurrency, I've spent too many hours trying to debug intermittent memory race bugs in operating systems. [It's when you haul out the storage scope to debug the device driver that you know you're having a bad day.]
(*) As in variables in a formal logic system, not Booleans.
Maybe if they encouraged the kids who are interested in the subject and stopped trying to force it on all and sundry?
In my experience, the kids who are interested in it are disgusted at being held back by their peers who have no interest in the subject matter whatsoever.
The "no kid left behind" concept is ruining an entire generation. Fact is, we are NOT all the same, and we are NOT all capable of the same work.
"Maybe if they encouraged the kids who are interested in the subject and stopped trying to force it on all and sundry?"
100% agree - kids with an aptitude should be identified and streamed early on, with good apprenticeship-style positions in companies later on to entice them. This 'everyone must be a coder' thing is as much nonsense as 'everyone must be a car mechanic capable of stripping and rebuilding an engine'.
Jeeziz People ! This ISN'T A NEW LANGUAGE, it's an xTalk, a family of languages that started with HyperCard / HyperTalk in the 1980s, and continued on with a bunch of clones, LiveCode is a descendent of one of those clones originally called MetaCard. So any comment about why make this language is entirely misguided, it's been a language (and object oriented, live editing, GUI toolkit) since before web browsers existed!
I expect it's not the language that's the moneymaker, but instead the educational resources around it. They've said that a large number of schools are using this for education. Whether or not that's a good idea, that's a lot of schools who now have to purchase licenses, especially if their next version develops backward-compatibility issues. Whether the schools will do that or switch to something similar remains to be seen.
It seems likely that external contributors had to sign a license to allow them to sell it closed source as well as providing it as an opensource before they were allowed to contribute. Considering the company owned the starting codebase this seems a likely hedge and enabled them to do this legally.
My university takes the same approach for code written on the university time/equipment/contracts, assuming other funding compatibility, yadda, yadda, yadda, so they can use anything I write on their dime in other internal /external projects without open sourcing those.
Alternatively an analysis of external contributions may have revealed a very small amount that needed closed-room re-implementation to clear the licensing hurdle.
And that right there may well have been why they did not attract more developers to help write their code for them.
I wonder if they were hoping for a 'free lunch' scenario where they could effectively outsource significant development of the codebase and then close source it once it had achieved critical mass...
They may have requested that all contributors assign copyright and ownership to them. That's not unusual--even the FSF do that. The problem of course is that they can then relicense it at any time to whatever they wish (they can't take the old code away from you, but they can benefit from the work of others and make proprietary-only software). Some projects eschew those agreements for that reason, which is the primary reason Linux has remained GPL2 only (also because Linus prefers it, but even without him it would be nearly impossible to get everybody's agreement to change it).
I dont think teaching a wierd language to school kinds is helpful really. Using a good mainstream interpreted language has much greater benifits outside of the school room. memory management? not needed in most mainstream code these days. good on em for doing what they want but to those schools try python with visualstudio code community addition. or serverless on aws free tier.
These were the primary languages I was taught in CompSci:
* Modula-2. Pascal-esque language that went nowhere
* Prolog. A niche AI language that went nowhere
* dBase - please kill me
* Z notation - a specification language that went nowhere
* occam - a concurrent programming language that went nowhere
I suspect that we had these inflicted on us, not because of their real-world relevance, but because various academics had bet their careers on these niche languages. They're written some papers, written some books and by golly they were going to make us buy those books no matter what.
Finally by year 3 there was a C programming course, but I learned mostly by messing around in the labs running online games like text muds and my own Amiga that I had at the time.
I would hope more modern courses would teach at least Python, Java and SQL. But I wouldn't be surprised if there are still professors trying to force feed their own pet language down student's throats.
The point that you are learning how to program in several different programming paradigms which teaches you how to think about problems in different ways. After that, you can pick up other syntaxs relatively easily and you have a better understanding in general of differing languages strengths and weaknesses.
If there is a job that requires language X or Y for it's products, then the employer has some responsibility to provide relevant training.
That is, if your like me and expect our education system to actually educate rather than turn out programing drones.
Back in the late 1980s when first learned BASIC it was OK but my mate and I would head down to the woodwork/metalwork rooms at secondary school 'cos the teachers down there were doing C/C++ in their spare time and they had experience of microprocessor coding from uni courses they's done plus working with various programmable machines for wood/metal working. They had a couple of old PCs down in the woodwork offices and me and my mate would often go down lunchtimes and after school to spend time talking to those teachers, we learned way more real world knowledge about how code actually did things you could see and touch. We learned bits of x86/z80 assembly, C/C++ even a little Pascal!
Good times and set me and my mate on a course into coding and tech which I don't think would have happened if all we did was the dull BASIC langauge stuff we'd do in the computer classes. The computer class teacher was a good guy but he had to teach to the lowest common demoninator and that meant we'd be lucky to get 3 lines of BASIC coded in an single computing lesson some days as this was around 1986 and computing was so foreign to kids back then.
I was taught occam - and used it on transputer systems - at the time potentially a big new thing but those systems never took off - but if transputers had become popular would have been lauded as a great decision.
Also taught dBase, at the time it was a big player in desktop database systems, but faded away. At the time that was a "safe" choice as widely used.
Its always a gamble what is taught but at least (when I learned them) their were (FSVO) aruably valid reasons for those 2.
.. Also taught lots of other stuff that is still in use today to varying degrees (C, Algol, ADA, Fortran, various assemblers etc)
* Modula-2. learned structured programming
* Prolog. learned declarative functional programming
* dBase - learned database programming
* Z notation - Learned a high level formal notation
* occam - learned about parallel programming
All you seem to be missing is something like Smalltalk for OO, and it sounds like you had a pretty rounded computing education where you could take anything that was thrown at you
* Modula-2. Pascal-esque language that went nowhere
It turned into Modula-3. That went nowhere.
* Prolog. A niche AI language that went nowhere
It inspired Erlang.
Also, back in the early 80s Prolog was going to save the world because the Japanese were basing their Fifth Generation Computing Initiative(*) on machines that executed Prolog directly so you'd just specify your problem in Prolog and no one would ever have to actually write a computer program ever again and excuse me but I'm giggling too much to finish this bit …
* dBase - please kill me
It would be a mercy.
* Z notation - a specification language that went nowhere
Oh God, I'd forgotten about that. Eldritch.
* occam - a concurrent programming language that went nowhere
Didn't it go into space? I certainly remember that Transputer chips were naturally rad-tolerant if not rad-hard, and the idea was that you stuck four in a deep space probe and used voting logic, resetting an incorrect one on disagreement(**). Four would be sufficient for a 10-20 year mission because you'd expect to lose at most one to permanent damage on that timescale so the voting logic would keep working.
(*) I was at the academic conference where this was announced to the world. Far too lowly to meet the bigwigs, I drank with the bigwigs' retinue who'd be doing the actual development. I asked them if they really thought it would work and they replied to the effect "well we're guaranteed 5 years funding, and 10 unless we screw up royally, so who cares".
(**) Transputers could be rapidly rebooted and reloaded from any other Transputer.
The main language on my CompSci course was also Modula-2 (aka Son of Pascal). On the first day of the course the head lecturer stood in front of us all and said "...we could teach you something commercially viable lie Ada 95, but we're not into that...". The next year the main language of the course changed to Ada.
So as well as those two off the top of my head we also dabbled with C, Lisp, Eiffel, SQL amongst others. I also had to learn Z and we had some Win-based software to run do stuff and it was without doubt one of the worst applications I have ever used.
As alluded to elsewhere on this thread I'd started with BASIC and then COMAL before university. So I was in for a bit of a shock when came to the programming side of things. To be honest I never got over it, which explains why my final year project was written in VB and I'm now a sysadmin... Though I can still throw together the odd bit of Python, Ruby, Perl depending on what (possibly) ancient script has stopped working.
"I dont think teaching a wierd language to school kinds is helpful really."
Depends what you mean by "school". Almost no one leaving school at 16-18 is going into a programming job, so teaching the basics and structure is what's important, and as with most subjects taught to that age group, one teaches everything in general because individuals in your class may or may not be specialising in the subject taught at the next stage.
If by "school", university is meant, then yes, learning the languages actually used in the real world, even if by "real world" we mean academics who also need to be able to program for their job/research projects/whatever. Then again, no matter what languages leaned at university, 3-4 years later out in the real world, at least one of the languages learned will probably have fallen by the wayside and gone niche :-)
FWIW, I got taught COBOL only on my System Analysis degree course and even then it was already fading as a useful skill for the majority going into the industry.
Ditto. I haven't heard of it either, and this is the kind of thing I would have expected to have heard about at some point. Maybe they would still have not had enough paid users, but it couldn't have hurt to get the word out a bit more than they did.
In a computing magazine from the early 1980's I saw an advert for "The Last One" (TLO) - supposedly the last programming language which would ever need to be written, because anyone could program in plain English.
Now it's just a footnote to history in the briefest of wikipedia pages, although the example shown is very illuminating as to how rubbish it was.
https://en.wikipedia.org/wiki/The_Last_One_(software)
There was a version of it in BASIC printed in PCW or Practical Computing. It was in two parts, a programme generator and a report generator. Both produced BASIC programmes as their output. It took a long time get it all typed in and then debugging the typos. It seemed to be limited to producing database-like programmes and creating pretty reports from the results. I've no idea if the full version was any better, but it was very, very far from being the last programme I'd ever need.
On the other hand, it was a long time ago and showed more the authors lack of vision regarding the development of computers at the time. Considering the almost constant and rapid changes in the technology at the time, that was very short sighted. I mean, The Last One couldn't even generate games!! :-)
Or Logo and play with a turtle.
Technically, Logo was the first language I was "officially" taught. I learned BASIC on my own.
Frankly, this company is already dead. It's all over bar the shouting. The moment one group of schools start asking why they're paying that £X/pcm, they'll all switch to something else and poof, dead.
There are a lot of "toy" languages used to teach core programming techniques, some are better for absolute beginners, others have a higher initial step but much longer useful life.
The GUI tends to be the differentiator. Really, it makes far more sense to build a good GUI teaching framework around a "real" language (Logo is Lisp!) and spend your effort on those visible tools, instead of inventing toy syntax and having kids quickly hit the limits of what's sanely achievable - and getting bored.
"Frankly, this company is already dead. It's all over bar the shouting. The moment one group of schools start asking why they're paying that £X/pcm, they'll all switch to something else and poof, dead."
Not necessarily as easy as you may think, possible teacher retraining, learning resources, the school syllabus, exam boards, etc. It could take a year or three to switch and as the article said, the open source version is still available so it's not going away next week.
"There are a lot of "toy" languages used to teach core programming techniques, some are better for absolute beginners, others have a higher initial step but much longer useful life."
That's true. Part of the problem as I see it is there seems to be an emphasis on kids having "fun" at school rather than actually learning. Great if both can go together, but IME, that takes a really good teacher.
LiveCode syntax is English-like, and the company argues that "every semicolon or bracket required by a language introduces another potential source of error."
Utter nonsense. The purpose of the semicolons and brackets are to remove the inherent ambiguity of English that leads to potential errors when trying to program in English-like languages.
Semicolons are like fullstops in English. While they can be omitted, text written without them is a lot harder to read and fraught with ambiguities. And if we need them, computers definitely do.
For a worked example see the rules around Javascript Automatic Semicolon Insertion. Even if you use semicolons, you can still get bitten. And good luck trying to remember when they are mandatory.
I see a lot of discussion about the fact that LiveCode's programming language is non-standard and people are wondering why LiveCode exists. Here's why: It's NOT JUST a coding language. It's a RAD tool, and with it you can build an application for iOS, Android, Mac OS, Windows, and Linux at the same time.
The programming language uses syntax easier for newbies to understand, but the power is in the RAD tool. It IS great for education, because kids can build an app with actual graphics and user interface with very little effort on any platform including Linux, and the language is simple enough for a 10 year old to learn, but can go deep enough to open ports and use arrays. And up until now, it was open source. I guess schools can still use the open source version. It'll probably run on Windows for another 20 years, and on the Mac for another 5.
You can also run cgi scripts with it, and there's a server version which essentially allows you to use your LiveCode programming chops to build web pages in a way similar to PHP.
There aren't a lot of RAD tools that can develop to every platform at the same time using an easy to use programming language.
But LiveCode is a jack of all trades, master of none tool. It's great for developing software quickly, but you're not going to make the next Photoshop with it. It's a tool, like any other, with pros and cons. Moving away from open source is a bad long term move for the company, but the company looks to be on shaky ground financially.
Just wanted to add clarification. You can't compare LiveCode to Perl - LiveCode is a RAD tool.
And that's why it's dead.
If it was a RAD wrapper around a "real" language then it might have a future, because they'd be spending all their effort on making the RAD easier to use and directly supporting more concepts. Plus users would be able to write their own extensions using the same language - thus creating the possibility of an actual community around it.
Instead, their effort is split between writing the RAD, the language constructs, runtime and compiler. Thus all suffer, as each of those is a very large job.
It does have a foreign function interface via a middle-ware language called "Builder" which is more "real" language like (compiles byte code, strictly typed variables and such, a hybrid of it's Script), so you CAN actually wrap libraries written in C/C++, ObjectiveC, Java (I assume those are the "real" languages your'e referring to). I've wrapped a few such as FluidSynth and if I had the time I'd wrap a lot more, like all of SDL!
You make some good points.
I was an early user. The article talks of LiveCard being inspired by Hypercard. LiveCard was directly derived from Metacard which was originally a Hypercard-inspired program for Unix systems.
Although you can make full applications for various platforms and phones, I've tended to use it for small, personal tasks - password generator, report writing, calculations, name anonymizing, whatever. I tend to think of the LiveCode "stacks" more as clever documents than applications. And I imagine that is seen as an advantage at schools. Drag out three fields and a button on a "card/page". Add code to the button to multiply the content of field 1 by the content of field 2 and put the answer into field 3. Label the button "Multiply". Then take it from there.
I know to some, the English-like language is attractive, but I don't see it that way. Personally, I'd prefer if it was more Javascript-like, but that's just me (I like curly brackets).
> "I think that for all the reasons that it didn't happen during that eight years, it would be a bit odd if it suddenly happened now."
Not odd at all. It was getting actively developed, there was little or no reason to fork it. Now that it'll be dead code, as soon as anybody finds a bug or wants a new feature, they'll have to fork the GPLv3 version to fix it.
Actually, I think the reason no one has forked it back then was because it was free and open. Now that they're closing the source, I'm optimistic about a fork appearing.
That happened with the Solaris On/Net kernel. For so many years after it became open source no one forked. Then Oracle bought Sun, and in their infinite greed decided to close the source, discontinue OpenSolaris, and forced people who depended on OpenSolaris for so long to buy Solaris.
Guess what? illumos happened.
I tried livecode a few years back, using the non-open-source version, at the lowest cost level.
It did seem a good solution for simple cross-platform apps, that did not need 3D graphics & GPU support.
Then, when a new livecode version was released, one of the critical features needed for the apps I was developing stopped working, an included facility to download data from a server.
The makers CLAIMED that it was not compatible with the latest update of iOS, so could not be left in.
But the app that had been compiled with the previous release _still_ran_perfectly_ on the new OS devices, using that feature which was magically "incompatible" with them.
I seem to remember that they added an alternate system to the "professional" high cost version, or something like that - but there was no way I was going to trust a company that pulls such stunts, it's verging on extortion in my book; "Pay up (more) or your apps stop working".
Goodbye livecode.
I hope someone does fork the open source version and develop that so noone wants a subscription version.
The software is made on macs, the prices are mac-like, the mobile target is mainly iOS. Linux, Android & Windows are supported nominally, but in fact ignored. They just spent a lot of time to make a version for FileMaker (!), while a bug causing pressed buttons to flicker (!) still is unsolved for those 3 OS'.
Don't get me wrong - Livecode is a great RAD tool, you can create full fledged applications that run on Win, Linux, Android, MacOS from the same source code. Or - it could be such when Livecode Ltd. wouldn't insist that the main target are "iOS apps". All effort goes into following Apples loops and circles, while developers of the other platforms (that could actually earn enough for the outrageous fees) are alienated. (Current fee for Win, Android, non-blocking network & support: $999/year + VAT)
Add to this that they became "agile" in the worst sense: Expect a new "stable version" every few months, containing an exciting collection of new bugs. And another new "stable" long before these are fixed ... Older fellows know such as "public betas", and will desperately search for a real "stable" - in vain.
The problem is Livecode Ltd. They are old, hard core Apple fans scorning anything else. They don't like OpenSource (main selling point for their proprietary versions: "Hide your code!") as long as they cannot exploit it. They don't like to talk to a community (they have a forum that they never read), they prefer to stay in their filter bubble (a mailing list).
They have no money, so they cannot grow, so they rise their prices, so they lose more customers, so they have even less money ...
A shame.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
