Difference between revisions of "Talk:Client-side Scripting for HUDs and Widgets"

From Second Life Wiki
Jump to navigation Jump to search
(New page: * First draft thrown in. I hope it's readable. :-) ~~~~)
 
 
Line 1: Line 1:
* First draft thrown in.  I hope it's readable. :-) [[User:Morgaine Dinova|Morgaine Dinova]] 04:57, 16 November 2008 (UTC)
* First draft thrown in.  I hope it's readable. :-) [[User:Morgaine Dinova|Morgaine Dinova]] 04:57, 16 November 2008 (UTC)
* Geneko, I've removed your sentence "A problem with this approach is that LSL2 scripters would have to learn another language", because the opposite is actually true:
** LSL scripters can continue to program their sim-side HUDs in the language that they already know, as nobody is proposing that current HUDs should disappear.  LSL scripters wouldn't have to learn anything new unless they want to do something new.
** Any problem that may exist was actually created by LL way back when they defined LSL, a totally oddball language like no other (Cory said it was a one-night hack, and it shows).  Moving to a "proper" language seeks to undo that problem.
** Client-side programming is more dangerous even if VMs are sandboxed, and requires more skills and background.  People whose only exposure to programming is through LSL should not be attempting to use "real" languages unless they are willing to learn new skills.  Distancing client-side programming from LSL scripting isn't a "problem", it's a benefit for safety and stability. [[User:Morgaine Dinova|Morgaine Dinova]] 19:22, 17 November 2008 (UTC)

Latest revision as of 12:22, 17 November 2008

  • First draft thrown in. I hope it's readable. :-) Morgaine Dinova 04:57, 16 November 2008 (UTC)
  • Geneko, I've removed your sentence "A problem with this approach is that LSL2 scripters would have to learn another language", because the opposite is actually true:
    • LSL scripters can continue to program their sim-side HUDs in the language that they already know, as nobody is proposing that current HUDs should disappear. LSL scripters wouldn't have to learn anything new unless they want to do something new.
    • Any problem that may exist was actually created by LL way back when they defined LSL, a totally oddball language like no other (Cory said it was a one-night hack, and it shows). Moving to a "proper" language seeks to undo that problem.
    • Client-side programming is more dangerous even if VMs are sandboxed, and requires more skills and background. People whose only exposure to programming is through LSL should not be attempting to use "real" languages unless they are willing to learn new skills. Distancing client-side programming from LSL scripting isn't a "problem", it's a benefit for safety and stability. Morgaine Dinova 19:22, 17 November 2008 (UTC)