Your Digital Media Has Never Looked So Good

 
dmacleo
Posts: 40
Joined: Mon May 31, 2010 10:20 am

Re: Revert Firmware?

Mon Dec 05, 2011 9:13 am

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
Posts: 17
Joined: Sat Sep 10, 2011 8:50 am

Re: Revert Firmware?

Tue Dec 06, 2011 8:20 am

Given that it is "MUCH better to have ALL engineers working on the same code," how long till the Roku 1 sees it's last firmware? Additionally, what happens if the last firmware is released and not all of the regressions have been fixed or new ones have been introduced? Will users be stuck then with the last firmware or will you allow reversion of previous firmware then? Given that there's no future support at that point, what's the harm in allowing firmware reversion at that point?
 
gbooker
Posts: 17
Joined: Sat Sep 10, 2011 8:50 am

Re: Revert Firmware?

Mon Dec 12, 2011 10:06 am

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 time
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.

Security
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.

Language Features
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.

Library Availability
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.
 
User avatar
gonzotek
** Valued Community Member **
Posts: 2206
Joined: Thu May 06, 2010 12:40 pm
Contact:

Re: Revert Firmware?

Mon Dec 12, 2011 1:12 pm

gbooker wrote:
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 time
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.

Security
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.

Language Features
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.

Library Availability
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.
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.

To the remainder of your points, I did not request any elucidation on why you feel it is a poor choice. I have my opinion, and you have yours. 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. None of the points you've brought up are trivial, and I don't want anyone to think I'm dismissing them out of hand. However, even factoring in the validity of (some of) those points, my opinion remains unchanged.

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):
https://github.com/rokudev/librokudev/b ... rdJSON.brs
(requires https://github.com/rokudev/librokudev/b ... ialize.brs)
Remoku.tv - A free web app for Roku Remote Control!
Want to control your Roku from nearly any phone, computer or tablet? Get started at http://help.remoku.tv
by Apps4TV - Applications for television and beyond: http://www.apps4tv.com
 
gbooker
Posts: 17
Joined: Sat Sep 10, 2011 8:50 am

Re: Revert Firmware?

Mon Dec 12, 2011 2:17 pm

gonzotek wrote:
I'm sorry, but misquote? I seem to have quoted you exactly as was written.

Seriously? I put the portion of the misquote in bold and you still didn't see it? How about now:
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.

I was never under any such impression; I stated it was idiotic, and you disagreed. I backed up my claim with more evidence.

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.

I guess you completely missed the point where I said:
gbooker wrote:
That implies it can change, but also implies that a change would be slow.

I supposed I didn't mention it, but they are also stuck with the development time devoted to maintaining it as well as the security problems for now. Dropping the language would mean dropping all code that's been written in it.

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.

What would have happened if they used an established language? When I was first exposed to it, my first reaction was to question why it was created. Then, when reading the documentation, I questioned who edited it since it's in dire need of proper organization. If it weren't for the fact that I had planned to replace my AppleTV with this device, I would have decided that the language was not worth the effort.
How many were sitting on the fence as I was before delving into it, and decided to fall on the other side rather than have to learn yet another language? Those are lost developers.
How many decided that there is too little code availability to the language such that the barrier for a particular task is too high? Those are lost developers.
How many decided the debugger was too archaic, missing so much fundamental functionality that it wasn't worth the effort. Those are lost developers. BTW, I fall into this camp. Noticing the "Connection reset by peer" in the telnet connection and the device rebooting while stepping in the debugger countless times was the final straw.
To give you some idea on just how poor this language is, I was creating a program with a client-server relationship. When I reluctantly decided to give Brightscript a shot, I intentionally designed the server to have so little Roku specific code in it that I increased the development time of the server significantly. I didn't trust that the Brightscript/Roku API combination would be sufficiently powerful enough for my needs; a fear when I later realized was true.

gonzotek wrote:
However, even factoring in the validity of (some of) those points

Which do you think have no validity?

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):

I missed the encoder on that one, but as you point out, not compliant. Additionally, people with lesser morals would have lots of fun hitting that with non-compliant strings to execute unintended code. It's the days of SQL-injection attacks all over again :P
 
stratcat96
** Valued Community Member **
Posts: 3432
Joined: Sat Nov 06, 2010 7:22 pm
Location: Ice Planet Hoth
Contact:

Re: Revert Firmware?

Mon Dec 12, 2011 3:25 pm

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.


ok, your little internet pi@@sing match is fun to read along with but please keep me out of it ;)
 
zzxx
Posts: 80
Joined: Wed Nov 09, 2011 8:28 am

Re: Revert Firmware?

Mon Dec 12, 2011 3:42 pm

Enough already. This thread needs to be locked ASAP. It is getting out of hand.

Who is online

Users browsing this forum: jeffrok and 35 guests