from a troubleshooting perspective alone ability to back up would be nice, much like some use the beta update channel and previous channel could be used.
would have helped me in the recent past for sure.
gbooker wrote:I'm sorry, but misquote? I seem to have quoted you exactly as was written. I do frequently shorten other people's posts down to the relevant sections I am responding to, in order to make my intent clearer, but the complete original is always just a few posts back. In this case, I haven't removed anything of your entire response to stratcat. You and stratcat both were (apparently) under the impression that brightscript was the only language option for developers bringing new channels to the Roku platform. I simply pointed out that was not true. It is not true that they were stuck with it, nor is it true that they are ' stuck with it for now', as they already have another option to offer to interested parties.Since it appears my questions are not going to get an answer, I no longer see the harm in sending this thread off-topic.
gonzotek, why did you have to misquote me to make your point? I explicitly mentioned they are stuck with it for now. That implies it can change, but also implies that a change would be slow. I've posed a scenario to several colleagues which mirror's Roku's development and asked them whether they would create their own language for third-party development or use an existing one. Every single one said use an existing language, for much the same reasons. Since you seem to need this list to be provided to you, here are a few more reasons why Brightscript is a poor choice:
Development of a language requires a large investment of time and resources. It requires the creation of a parser, compiler, virtual machine, and debugger. This involves both the creation and maintenance. To develop their own language, Roku had to "divide their resources" between development of the rest of the firmware and their language. This thread has already indicated that these resources quite thin within the company.
Brightscript's virtual machine is a new development. All new developments/features are prime targets for security attacks since history has shown them to contain many vulnerabilities. An existing virtual machine has been pounded by so many that it's security footprint is well understood, but Brightscript's is not. I've already found a few disturbing bugs in their virtual machine myself. If I deemed the device worth the effort, I would have investigated these for arbitrary code execution. Their behavior indicates that they are prime candidates.
Modern languages contain numerous constructs, required significant effort to bring a new language up to the same bar. I've noticed several items missing from Brightscript ranging from switch/case statements to loose OO design to lack of threading. Even languages which have had OO design added later in their lifetime have far better OO behavior than Brightscript. I know that many programmers are incapable of properly using threading, but the language's lack of support deprives those of us who can use it properly.
Established languages have numerous libraries available for use under a variety of licenses. Say I wanted a json parser/encoder: With an established language, I could go to http://json.org/ and pick a good library. With Brightscript, I have to contend with a very basic parser and lack of encoder. Additionally, the parser is quite slow and lacks the ability to deserialize into a specified object type. Before anyone argues the merits of json parsers, note that I was solely using json as an example. The same argument applies to any library functionality.
Tooling and Community Support
Established languages have large communities and as such have developed good tooling. While Brightscript has its Eclipse plugin, it's a far cry from what you can find with other languages. Additionally, the community support for Brightscript is so small that it's hard to find useful information. Check for the number of posts on stackoverflow referring to Brightscript to see what I mean. Check the number of posts there concerning other languages.
The list goes on and on. These points exemplify why programmers are encouraged to not re-invent the wheel unless it is absolutely necessary. The only reason any of my colleagues gave for creation of a language was a "bored academic," but even then one wouldn't use it in a production environment.
gonzotek wrote:I'm sorry, but misquote? I seem to have quoted you exactly as was written.
gonzotek wrote:it is simply untrue that they are 'stuck with it now'.
gbooker wrote:one that Roku is essentially stuck with for now.
gonzotek wrote:You and stratcat both were (apparently) under the impression that brightscript was the only language option for developers bringing new channels to the Roku platform.
gonzotek wrote:I simply pointed out that was not true. It is not true that they were stuck with it, nor is it true that they are ' stuck with it for now', as they already have another option to offer to interested parties.
gbooker wrote:That implies it can change, but also implies that a change would be slow.
gonzotek wrote:My opinion that it is not a poor choice wasn't simply formed as a gut reaction to your posts, but through watching the platform grow over the last several years, seeing how much content has appeared in public and private channels(in the end, the point of any language is to communicate something), and working with it firsthand.
gonzotek wrote:However, even factoring in the validity of (some of) those points
gonzotek wrote:BTW, if you're interested, there is indeed a Roku json library that includes encoding, I'm using it successfully in one of my upcoming projects(it isn't perfect, and might not be fast enough or compliant enough for every situation, but it solved my problem):
You and stratcat both were (apparently) under the impression that brightscript was the only language option for developers bringing new channels to the Roku platform.