Scripter or Builder ?

[Selene Gregoire]

[ellestones]

On 12/23/2018 at 5:51 PM, Madelaine McMasters said:

A mentor of mine got his PhD in computer science from MIT. He told me that the entry level "C" programming course actually had a no-requisite of BASIC programming experience. Students who had a course in BASIC on their transcripts were required to take a de-programming course in Pascal first, to rid them of bad habits they were presumed to have acquired learning the awful language rival Dartmouth College had unleashed on the world.

My personal experience with computer languages has been that their differences are fairly minor compared to differences in function libraries and programming models (event driven, parallel, etc). And it's when the differences are fairly minor that I keep getting into trouble.

i have been meaning to come back to this, so I do it now

yes. Formal training tutors tell the students to forget about what they previously know. As the student is in the class to learn to speak the computer language. They are not in class to learn how to interpret what they know into the language being taught. Where an interpretive language is necessary to communicate to the students what they need to know, then a human language is deployed, English for example

the next thing I would like to touch on is what Phil was talking about before the conversation got a bit sidetracked. And show a circumstance where he can be right

given two people who have backgrounds in applied logic, design, flow charting, etc. Say 2 business analysts

one has some prior experience in some other computer language. The second person has no scripting experience at all, so goes on a formal LSL training course. The first does not, no formal training and just goes off what coding experience they already have

and then they are both given access to the LSL wiki

in the LSL-grammar there are: 7 flow controls: do, for, if, jump, return, state, while
7 types: float, integer, key, list, rotation, string, vector
32 operators: +, -, *, /, =, ==, !=, !, ~, <, >, <<, >>, ^, ~, |, ||, &, &&, etc
49 events: state_entry ... state_exit

how many of these is the first person going to recognise from their previous coding experience? Some. How many will the second person recognise? Most, particularly the events

then there is a whole heap of LSL API functions. How many of these will each person recognise? Some

as they both have backgrounds in logic, design and flow then one of them is going to write complete LSL works sooner than the other

where Phil is correct is when neither of them read the manual, don't bother getting any training. Just sit down at their keyboards and start typing based on what they know already and what they can work out for themselves from their own reading of the wiki and existing scripts they may find

in which case the person with some other coding experience will probably get their inworld door to open and close a bit sooner than the other person. Sometimes not, as the other person finds a complete door script on the wiki first

 

i just add something else about my own experience of formal training

7 years ago now I asked my boss for a substantial pay rise. He goes: Why would we give you that?  I go: Because I know stuff and I am worth it. He goes: You are unqualified. You are about as qualified as that person out there emptying the rubbish bins. I go: Waah! He goes: That person knows stuff as well. What they do is an important job, probably more important than your job as my assistant. I could probably do without an assistant. I couldn't do without the cleaner though

and I am like oh! man. And then he says: I want you to go to university and get qualified. It is not enough to know stuff, you have to be able to demonstrate that you do, and be able to show that you have the discipline to complete and obtain a degree

5 years distance learning part time, and done - BSW

I go to my boss after graduation and say: What about my pay rise? (during my study years I had been getting normal grade and cost of living adjustment but not anything substantial)  And he goes: Sorry I can't do that. I go: Waahh! And he says: You are over-qualified for the role of my assistant. I am going to have to let you go and get someone else. Do you think you would be able to help me find your replacement?

and I am just looking at him, glaring actually. And he cracks up and starts laughinh

then he says: We have had issues with our recruitment processes as you know. So I am promoting you. And between us we are going to sort it out. And I say I am not ever going to be an HR officer, not even!  And he goes: I thought that you might say that. Sign here, you are now a consultant on monthly retainer. I look at the amount of retainer and ooh! and sign. And then he says: Right! Get to work and earn the big bucks I am now paying you. Consult with all the department heads who will be affected and I want a draft recruitment process design document on my desk before the end of the month for every role we have. Our org has a lot of roles. IT/IS, line management, health practitioners, educators, accountancies, social workers, ancillary staff and now that we are into housing then project managers, building and maintenance contractors

lots of technical disciplines to recruit too. From my pov it's not about who we hire, it's about how we hire people. And one of the best ways I have found in understanding how to recruit people isn't so much in us getting the correct answer to a question. It is about examining the person's understanding of the answer they do give

an example. Recently we looked to appoint a Clinical Director. Senior Medical Officer status, highly-qualified and experienced doctor specialising in general mental health. One of my questions to the applicants was: How conversant are you with the Ministry of Health guidelines relating to client rights under the Mental Health (Compulsory Assessment and Treatment) Act ? And could you relate an instance from your own experience of this please ?

when a candidate at this level gets asked this kind of question, not being a technical practice question, they respond in different ways. Most candidates respond cautiously and some few don't. As when they look at the doctor convening the interview panel and see that doctor looking at me, then most candidates realise that their answer is going to be tested by my follow up questions. Their continuing responses followed attentively by the candidate's medical peers in the room. Basically, Doctor do you understand what you just said ?

is early days yet but what we working to discover is: Is there a process whereby roles can be filled by self-selection. A process by which the understandings of the candidates are revealed by themselves to themselves. In other words, having examined myself then I know that this role is actually for me, or this role is actually not for me even though I think I would like it

 

[Phil Deakins]

14 hours ago, ellestones said:

functions do exist. For a computer to run it has an operating system. A whole bunch of functions.  In the tiny 16byte program above the line JSR $FFD2 is a function call to the operating system API. Its equivalent in LSL is llSay(...). In assembly, like in any other language, when there is no API function call to do what we want then we have to write it ourselves

<groan> Ok. Forget it. I've told you more than once that you can include machine code/assembly if you like because it makes no difference whatsoever. You're just being argumentative for the sake of it, and I'm not going to explain to you why you are wrong. However, I will concede if you can show me any loop function in machine code. I don't mean for you to write one. I mean one that already exists in the language itself.

Or perhaps what you call a function isn't called a function by others. Every 'code' performs a function of course, but that is nothing like what I mean by the functions in high level languages. I gave you examples of what I meant, so I won't repeat them.

Incidentally, your arguing is so stupid because I've said more than once that you can include machine code, because it makes no difference. Perhaps you just like arguing for the sake of it, or maybe you're a bit bored lol.

ETA: I'm going to stop discussing this with you now. It seems that what you and I call functions in languages are different. So it's just a matter of you understanding one thing and me understanding something different. And that means, continuing to discuss it is pointless. Also, it has nothing whatsoever to do with the topic of this thread, and doesn't belong here. I do think you know what I'm saying, and I do think you're arguing just for the sake of it. But that doesn't matter, and I'm out.

 

Edited December 24, 2018 by Phil Deakins

[Innula Zenovka]

On 12/21/2018 at 1:17 PM, Rolig Loon said:

They come to LSL with preconceived ideas about the way it ought to work and then get confused by the fact that it's event-driven, does not have true boolean variables or arrays, or a host of other features that they have taken for granted elsewhere.  It does help to know what loops and branching and user-defined functions are, and it certainly helps to be accustomed to thinking logically.  Those advantages are quite often offset by the fact that LSL is truly a different kind of duck.  All I said earlier was not to get cocky about what you think you know about programming. 

Certainly I have noticed several people in the in-world scripting groups over the years complaining bitterly that LSL is a stupid language that, despite being proficient in C++ or C# or whatever, they can't get their heads round it because it lacks all manner of functionality (notably arrays) on which they've come to rely.     Indeed, they frequently seem more concerned to vent about LSL's deficiencies than to listen to suggestions about how to accomplish particular tasks using the tools LSL does provide.

Of course, I have no idea how many people who come to LSL from a background in other languages don't complain because they find it easy to pick up, despite its differences from what they're used to, and it may well simply be, and I suspect is, the case that my impressions are skewed by the vociferous minority.

I've always seen scripting as giving prims instructions about what I want them to do, bearing in mind that prims are pretty simple-minded critters, terribly literal and none too bright, who understand only LSL.  This means that I have to be careful to prepare and phrase my instructions in such a way that they translate readily from English to LSL, otherwise both the prims and I end up completely confused.

[Innula Zenovka]

9 hours ago, ellestones said:

where Phil is correct is when neither of them read the manual, don't bother getting any training. Just sit down at their keyboards and start typing based on what they know already and what they can work out for themselves from their own reading of the wiki and existing scripts they may find

in which case the person with some other coding experience will probably get their inworld door to open and close a bit sooner than the other person. Sometimes not, as the other person finds a complete door script on the wiki first

I'm not disagreeing with you here, but your example -- inworld doors -- is one where I think we know something of the history.

I started in SL in 2007, and started scripting a few months after that, largely because I lost patience with paying what seemed to me over-inflated prices for door scripts that didn't properly work.   How difficult, I rather rashly asked myself, can opening and closing a door actually be, even when it is linked to the rest of the house?

A lot more difficult than it looked, it turned out, and only achievable with  scripts that now seem like horrendously complex kludges but were, at the time, pretty much state of the art -- I'm thinking of the Timeless linked door script in particular.     I thought that was great, since it did what I wanted, but it seemed  a hell of a performance to just to make the door open and close, and I was sure there was a simpler way to do it.

As it turned out, there was, and a few months later, in November 2007, Void Singer showed us how to do it in a few lines of code -- http://forums-archive.secondlife.com/54/a7/220597/1.html .   At the time it seemed like magic -- I didn't understand how it worked at all but it did, and at the time, that was good enough for me.   Later on, as the question of how it worked nagged at me, Void showed immense patience in explaining it to me (and to other scripters, I know) and, as a result, I and lots of others now have a reasonable handle on how rotations and frames of rotational reference work in Second Life.  But from what Void's said, before she and Lex Neva worked out the technique no one else in the SL scripting community seemed to know of it.

We saw something similar with positioning avatars without using pose balls.   I think Piero Padar must have used the technique in his proprietary Perfect Sitter kit but it was only when Strife Onizuka posted his UpdateSitTarget userfunction in the forums (now in the wiki in the llSitTarget example)  that other people realised how to do something that now seems pretty intuitive and simple (at least to a reasonably experienced scripter).    

I think my point is that plenty of people -- whether skilled in other languages or not -- tried to make working doors, with varying degrees of success, but it wasn't until SL had been going for a few years -- and heaven knows how many door scripts that sort of worked later -- that Void discovered the right way to do it.   `   

So in this particular case at least, I think the person with no scripting experience who wants to make a working door and consults the wiki or asks in the Scripting Forum for help is probably going to end up knowing how to make the door, and with some understanding, at least, of why it works some years before the person with coding experience works it out on their own.

Edited December 24, 2018 by Innula Zenovka

[Parhelion Palou]

52 minutes ago, Innula Zenovka said:

So in this particular case at least, I think the person with no scripting experience who wants to make a working door and consults the wiki or asks in the Scripting Forum for help is probably going to end up knowing how to make the door, and with some understanding, at least, of why it works some years before the person with coding experience works it out on their own. 

Is that because the person with coding experience never checks references or talks to anyone else? That seems unlikely. I'd say the person with experience is likely to be well aware of the advantages of examples or reference materials, and to have a better idea how to find and use them. I also don't like the idea that the best way for coders to take on a new language is to have their memory wiped.

This thread has been comparing newbie programmers with programmers with a little experience. The only ones likely to be smug and think all languages behave the same would be someone who has only learned one language. Anyone who has already learned a few computer languages knows that they don't necessarily work the same. Finding the differences and what you can do with the new language is the fun part.

Edited December 24, 2018 by Parhelion Palou
replaced 3 words with 1 ... efficiency improvement

[Innula Zenovka]

13 minutes ago, Parhelion Palou said:

Is that because the person with coding experience never checks references or talks to anyone else? That seems unlikely. I'd say the person with experience is likely to be well aware of the advantages of examples or reference materials, and to have a better idea how to find and use them. I also don't like the idea that the best way for coders to take on a new language is to have their memory wiped.

 I was simply responding to the hypothetical example provided by ellestones, in which 

Quote

neither of them read the manual, don't bother getting any training. Just sit down at their keyboards and start typing based on what they know already and what they can work out for themselves from their own reading of the wiki and existing scripts they may find

and try to write a door script.

My point was that what actually happened when people with and without coding experience tried to write door scripts is that it took about three years for anyone to work out out to do it properly.    Once Void did work it out, and posted the basic example, then people started to appreciate and study the principles behind what was, at the time, a complete revelation -- that it was possible to do well, in only a few lines of code, something that previously taken dozens of lines to do badly.    

Now that the knowledge of how LSL handles rotations and frames of rotational reference is out there, it all seems pretty straightforward to use.  But my point was that, in the specific example of how to get doors to work, it took some three or four years for the scripting community in general, no matter what their background, to work out how to do it.   

[Phil Deakins]

And yet doors did open and close long before Void came up with an improved method. I wonder who got them to open and close

Incidentally, there's no "proper" way to open and close doors. There are better ways to do things though.

[Phil Deakins]

12 hours ago, Parhelion Palou said:

I also don't like the idea that the best way for coders to take on a new language is to have their memory wiped.

I totally agree. The idea is absolute nonsense, although Maddy did say that it was BASIC programmers who needed their memories wiped according to a university, and not all programmers. Nevertheless, that's absolute nonsense too.

Like many people, I started with BASIC, because that's what came with my first computer. Then I was straight on to 6502 machine code. Since then, I've programmed in various languages as needed, all of which benefitted greatly from originally learning to write programmes - in BASIC.

Edited December 25, 2018 by Phil Deakins

[Qie Niangao]

Not that it much adds to the topic, but as I recall, the attention to improved door scripts was a bit "necessity the mother of invention" arising when the ancient Prototype Linked Door script was broken by a Linden update that shrank the length of an object's description field that the script had used for nonvolatile storage of (unnecessarily complex) position and rotation data. (I vaguely recall that the shorter field length was itself necessary to defeat a lag-inducing "combat" exploit by the same self-proclaimed scripting genius who brought us "!quit" copybot "protection".)

Also, FWIW, I recall Strife's UpdateSitTarget being a late stage of a series of explorations in using the then-new llSetLinkPrimitiveParams() to manipulate already-seated avatars. Lex Neva played a huge role in the task of reverse engineering the weirdly different geometry of the sit target and the actual seated position of the avatar. Learjeff Innis also played a crucial role with his Easy Sit Target Positioner. (Even I got into the act with a little curve-fitting and words of encouragement.)

What's most interesting about this, to me, is the way the scripting forum used to work as a way for scripters to coordinate solutions to common problems.

[Qie Niangao]

Incidentally, for years and years MIT required new CS majors to learn Scheme in the course of working their way through the programming concepts of the venerable Structure and Interpretation of Computer Programs. That's not explicit contrary evidence but nonetheless I suspect Maddy's BASIC de-programming "no-requisite" at MIT may be apocryphal.

Also, I'd counsel caution in debating semantics of "function" in programming. It's an overloaded term, but its main use is to distinguish between subprograms that (only?) return values (functions) and those that perform side-effects (procedures). There are "functional languages" that require pure functions to have no side-effects (which may or may not include fragmenting the heap with any local state garbage). Such formal distinctions may sound like idle semantics but there are real performance implications for optimization and processor architecture.

[Innula Zenovka]

On 12/25/2018 at 8:39 AM, Phil Deakins said:

And yet doors did open and close long before Void came up with an improved method. I wonder who got them to open and close

Incidentally, there's no "proper" way to open and close doors. There are better ways to do things though.

Before Void's script (which, as I recall, was based on work she and Lex Neva had done together), I'm pretty sure the Timeless script was the only widely-used way of opening and closing linked doors, and it was obvious even to me that opening and closing doors couldn't possibly require so convoluted a process as that script entailed.     

Sure, they worked, more or less. but I don't think that now anyone with any scripting experience would make a door that wasn't based on the underlying logical of Void's script.    Before then,  people were struggling to find a simple and effective way of making hinges, and coming up with solutions that worked under some circumstances but not others, or were horribly complicated   

Now we've got the basic equation,  though, it's all pretty simple because Void's example exposes the fundamental logic behind SL hinges.   

 

 

 

[Phil Deakins]

As I said - the are better ways

The "proper" way to open a door is to create script that opens it. Some methods are better than others for various reasons, but they are all "proper" ways as long as they do the job

 

[truthcommission]

On 12/19/2018 at 1:21 PM, autonug said:

Sorry if its a wrong forum to ask this question but most forums are either for  builders or for scripters

I have spent around 10 months in SL and am amazed how most for things we see and use in-world are created by residence itself and not some particular team of developer like most other games. I wanted to start producing something myself. I was wondering which of Builder or Scripter option has better demand/supply ratio to dive in, as scripting in SL or building in SL will both be new to me and I want to start with one at the moment. I personally have felt there are a lots of builders compared to scripters, so scripting can be a better choice, but I can be wrong.

About me:- I am a pre-final year university student doing graduation in computer science and engineering, I have no experience in 3-d modeling/building, I have a lot of experience in writing programs in C++ and python, but always eager to learn more

Sorry again if its a wrong forum and please let me know where to post these kind of queries in future.

“Learn to script” is the answer you’re looking for.

When it comes to content creation, the scripter is at the top of the totem pole. Builder classes such as 3D modeler, texture artist, sound designer and animator are all subordinate to the scripter. Without code, their creations are nothing; especially on the marketplace.

 

Here are some comparisons between the builder and scripter:

 

-          Builders and artists are a dime a dozen. Scripters who can write very sophisticated code are rare by comparison and are in much higher demand and can therefore, charge higher premiums.

-          Scripting has a high learning curve and requires thinking algorithmically which most builders find difficult to grasp. Learning Photoshop is easy and can be done within a few weeks. Mastering a programming language takes considerably longer as you’re essentially learning a new language. A person who can code well but produces mediocre textures will still come out ahead of the talented artist who can’t code at all.

-          It is all too easy to have your work stolen in SL whether you’re a 3D modeler or musician due to the need for media to be transferred locally to the viewer and thus, can be accessed in a myriad of ways. Scripters enjoy more security as their code is stored server side.

-          When working in collaboration of others, builders assume all the risks as they must give their work full perm to the scripter in order for the scripts to be probably installed and tested. If the scripter decides to turn and run with the builder’s work, the builder is screwed. Scripters, on the other hand, never have to give their script openly to the builder as the scripts themselves are always set to no mod.

-          Scripters can implement backdoors into their code to ensure compliance with the terms of agreement during a collaboration. If a builder, for an example, decides to cut off the scripter from all future proceeds, the scripter can disable the functionality of the product being sold through the utilization of backdoor code. Builders have no equivalent recourse should a business partner go rogue.

-          Code can be repurposed for other things whereas builders must usually start from scratch when making original artwork. This is advantageous for the scripter on projects that are more conducive to OOP type of programming. Take the collaboration between a scripter and a builder on a motorbike project, for an example. As all motorbikes share the same properties, once a script has been completed, it can be reused for all subsequent motorbike products with a few variable adjustments. The builder, on the other hand, must usually start from scratch for any new motorbike project that goes beyond a simple re-paint. The workload for a builder remains constant whereas the amount of work required by a scripter levels off considerably with each new motorbike while making the same amount of profit.

-          Whenever LL makes alterations to LSL which can cause errors, the builder must get in touch with the scripter to update the code. If the scripter is nowhere to be found, the builder is screwed unless they have the source code (highly unlikely). The number of major brands that have ceased operations due to their scripter having left SL are legion.

-          The free resources available to the scripter looking for assets such as 3D models, textures, music, sound fx, etc. are incredibly vast. For the builder who needs something more sophisticated than an open door script, the opposite is true. This makes the scripter truly independent compared to the builder.

-          Thanks to machine learning architecture found in modern software, scripters can make up for shortcomings in other areas. The scripter may not be as talented as a dedicated artist, but they don’t have to be a Leonardo Da Vinci to produce work that is “good enough”. Third party Photoshop plugins, Substance Alchemist, Adobe Dimension/Fuse, DAZ 3D, and Quixel Suite now make it possible for anyone to create work of acceptable quality with just the presets offered. To code an ambitious project, you DO have to be the equivalent of a Leonardo Da Vinci. For the builder, there’s no software available to SL to help them write code beyond just the wiki; which is written for programmers anyway.

-          The system requirements to code in LSL are low for scripters. Whereas builders require a beefy system to run multiple Creative Cloud apps plus 3D software, a scripter can get by with just a sub-notebook that can load notepad.exe. Testing of scripts can be done with the lowest graphic settings on the Additi grid unless avatar customization HUDs are involved .

 

While there are always exceptions, a good rule of thumb is if you want to make something that just looks nice, be a builder. If you actually want to make money, be a scripter.

 

[Pussycat Catnap]

The skill set is radically different.

Your education will prepare you for scripting. The scripting language here reads like "imagine if you were planning javascript back in 1996 and decided to make the wrong choice on every last single possible decision about the language... The developers of LSS basically set out with the goal of "how can we make the worst possible scripting language anyone could image, as a sort of cautionary tale to CS-majors" and they succeeded beyond their wildest dreams...
- That said, knowledge of languages like JavaScript or ActionScript can be very helpful to learning LSL, especially things like keeping track of events - though they will also be very helpful in zeroing in on it's flaws.

 

An education in 3D modeling for video games would prepare one for building objects. Basically if you always wanted to work for Pixar, but wanted actual job security... you'd be G2G here... unlike real world 3D modelers, SL builders can actually make money and not have to have a reserved spot at the unemployment line... And I say that knowing that most SL builders make nearly nothing... which is still better than working in the 3D modeling industry... If you kid is ever debating career choices between "rap-singer that plays an accordian and works for the county circus" and "professional 3D modeler", tell them to get the real job and run off to the circus... But if they insist on 3D... maybe they can make minimum wage on SL.

 

 

Edited January 4, 2019 by Pussycat Catnap

[Phil Deakins]

18 hours ago, truthcommission said:

-          Builders and artists are a dime a dozen. Scripters who can write very sophisticated code are rare by comparison and are in much higher demand and can therefore, charge higher premiums.

There is a HUGE flaw in that logic. Builders and artists may be "a dime a dozen", but, once something has been created, it keeps on selling without ever needing to lift a finger again. On the other hand, a scipter who is "in much higher demand" has to keep on working or no money comes in.

Edited January 4, 2019 by Phil Deakins

[Wulfie Reanimator]

14 hours ago, Pussycat Catnap said:

Your education will prepare you for scripting. The scripting language here reads like "imagine if you were planning javascript back in 1996 and decided to make the wrong choice on every last single possible decision about the language... The developers of LSS basically set out with the goal of "how can we make the worst possible scripting language anyone could image, as a sort of cautionary tale to CS-majors" and they succeeded beyond their wildest dreams...

Out of curiosity, what are some specific flaws you're referring to?

Edited January 4, 2019 by Wulfie Reanimator

[Phil Deakins]

1 hour ago, Wulfie Reanimator said:

Out of curiosity, what are some specific flaws you're referring to?

I don't agree with Pussycat's evaluation of LSL, but there is a huge flaw in one function. Stupidly, LL claims that it performs as intended. Regrettably, I've forgotten what function it is lol. I'll see if I can find it.

ETA: I can't find it. It was to do with doing something with a list, when the list has only 2 elements. Whatever it was, it works fine as long as there are more than 2 elements, but when there are only 2, you have to perform an extra step. If I remember correctly the step is performed by the function when there are more than 2 elements, but you have to do it yourself when there are only 2.

Anyway, it's huge flaw that we discussed in the LSL Scripting sub-forum.

Edited January 4, 2019 by Phil Deakins

[Wulfie Reanimator]

2 hours ago, Phil Deakins said:

I don't agree with Pussycat's evaluation of LSL, but there is a huge flaw in one function.

Even if you could name the function, that wouldn't be an argument. Pussycat and I are talking about the language itself, its environment, goals, features, and how it's designed. One "stupid" or broken function doesn't encompass any of those subjects.

Edited January 4, 2019 by Wulfie Reanimator

[Pussycat Catnap]

We can start with the lack of actual arrays. The limits of 'list' make it very hard to deal with even small blocks of data with only a few hundred entries - whereas any normal scripting language I could pass around objects with tens of thousands with a structure like that of JSON.

The lack of some very basic things you find in a modern language, like a switch statement.

The failure to properly handle memory allocation and reporting

The fact that I can perform operations in the declaration of something that is global.

The fact that I often even have to declare globals...

That I can't wrap an entire body of code into a single object and . reference it from somewhere else.

For example, I can pull in jQuery in javascript with a simple:

$.( object ).( object or function).(etc)

anonymous functions:

$.( object ).( object or function).({ do some stuff});

I lack inheritance - so I can't really bring in something like a library kept on a CDC somewhere.

- That's a simplistic list of complaints. You could basically run down the list of things one can do in JavaScript, JQuery, with ajax calls, JSON, node.js, React, and so on and so forth and find things that are just missing...

Or if present, overly complex to work with... like how people have to hack list to resemble arrays.

 

[animats]

If we had Javascript as a scripting language, we'd have incredibly bloated scripts.

You can hook up a LSL script to an external server. That's how CasperVend, CasperLet, etc. work. I've used that; I have some objects talking to a program in Go running on a Dreamhost server. LL could offer some kind of hosting service where they sold server space for such things. If we want more powerful scripting, it's got to be somewhere else than on the overloaded sim machines. But is there really much demand for that from people who 1) need external computation and 2) aren't able to set up their own server?

My main frustration with LSL is handling events that don't happen. With llSensor, you either get a "sensor" event or  a "no_sensor" event. Works fine. But for HTTP requests, you get "http_response" or nothing. You don't reliably get an event on a timeout. Same for "dataserver". Pathfinding has the same problem, although there, it's a bug.

So all those requests have to be wrapped in timeout and retry logic. In a language with no callbacks, references, closures, promises, or futures. The LSL to system interface for async requests should guarantee some kind of response every time.

 

[Qie Niangao]

2 hours ago, Pussycat Catnap said:

The failure to properly handle memory allocation and reporting

This is the big thing to me. I don't really care about the syntax or paucity of language constructs; it would be nice to have a "switch" statement and structured data and etc, but meh, it's more feature-ful than assembly. But that's the thing: memory handling in assembly is completely predictable, which is especially important in a seriously memory-constrained environment. In LSL, though, it's only by reverse-engineering the runtime that we have any idea what memory is allocated when, and production of garbage is a total black box.

On the plus side, AFAIK all scripts that fit in memory when Mono was new still fit today, and that's critically important, but particularly in LSL's tight memory environment it sure would help to know and test all the possible ways a particular script might leak garbage and exhaust memory, and that's simply not completely knowable now.

[Qie Niangao]

2 hours ago, animats said:

But is there really much demand for that from people who 1) need external computation and 2) aren't able to set up their own server?

If we're honest with ourselves, there's not that much demand for scripts at all, let alone things that stretch the current LSL environment. Most SL users are happy to look at the pretty pixels and have vendors from which to buy more pretty pixels. A handful enjoy riding scripted vehicles. Many use scripted HUDs to configure their scripted heads and avatars and hair and shoes. Maybe open and close a door or teleport to and from a skybox. Many of those scripts are off-the-shelf or minor variants that have been around for years and years. Only extreme outliers require real computation or storage.

As much as I abhor the prospect of NPCs populating SL, it is the one application of Animesh that might finally do something interesting with external services. I don't really expect many scripters to get into the weeds with tensorflow, etc, but one might imagine some folks being entertained by digital assistant interactions with the ghastly things.

[Phil Deakins]

21 minutes ago, Qie Niangao said:

it would be nice to have a "switch" statement and structured data

Not long ago I'd been thinking exactly that, and then I found that it exists in Firestorm. I was so pleased that I posted about it.

[Selene Gregoire]

On 1/3/2019 at 2:19 PM, truthcommission said:

Without code, their creations are nothing; especially on the marketplace.

Not every creation requires a script. Not really a good idea to insult creators that don't always make something that needs a script.