Very basic volume script - why does it not work?

I'm just curious.....what processor is that for? I've never seen any MACHINE CODE OP that did ALL of that. Now, some MACRO ASSEMBLERS, yes. But not machine code. You seem to use them interchangeably above. They aren't the same.

For example. Motorola 6502a 8-bit CPU instructions:

LDA $C030 ; LDA is the LoaD Accumulator instruction, it is being used in Absolute addressing mode. This is the opcode mnemonic for hex (AD 30 C0).

The above quoted snippet looks like more than one machine instruction to me. Even x86 XMMS 128-bit vector register instructions can't do all that in a single opcode.

My point is that people starting out shouldn't have to. Learning good programming style and habits is far more important, in my opinion, than learning a specific language's/platform's idiosyncrasies, early on.



So? Pascal has For loops, too, ya know. Learning the syntax of one versus the other isn't going to hobble anyone from learning the other one later on. Technically, the same thing is true of BASIC. It is simply a matter of syntax.

Also, if you're going to hold up Strife's optimizations as examples, I don't think I would consider those "normal idioms of the language".



Well, see, that's part of the problem here. I wasn't suggesting Pascal as a language for learning LSL, just as a STARTING LANGUAGE to learn programming, which was what was said in the post I responded to. It also wasn't just for Piggie, either, but anyone else who reads the thread who might be interested in other STARTING LANGUAGES for the same reason.



Even with the hundreds of thousands of lines of code I have written, I RARELY have had to deal with optimizations, either using Strife's, or making my own. I use the list optimization hack for LSLVM, but it doesn't work anymore with the Mono VM, so I stopped using it. Even then, I only used it when it was prudent to do so. The vast majority of the time, readability and maintainability of my code trumps optimizations. If I HAVE to use them, then I make their use as abundantly clear as I can in the comments.

My point is that, for most starting scripters, I don't think the choice of language for learning programming is going to make them any more or less capable of learning obfuscations in any particular language, including LSL.

No, it's NOT a matter of syntax. The difference between C-style expression-based for loops and Pascal or BASIC iterator-style for loops is deep, fundamental, and important.

I didn't hold up Strife's idioms as examples of normal idioms, I brought one up as an example of something that people are likely to have to deal with. I brought up "for" loops as "normal idioms".

I prefer something like Smalltalk or Logo, myself. Fewer bad habits to unlearn.

I routinely tell people not to use them unless they know enough to know they have to. I'm NOT saying you have to use them, I'm saying you WILL run into them as you work with LSL. This is not saying they are necessary, good, or required. Just that they are inevitable, and you need to understand them.

For what the vast majority of scripters use them for, yeah, it is simply a matter of syntax.

10 FOR I = 0 TO 9

For I := 0 To 9 Do

for (i=0; i <= 9; i++)

I'm well aware that the point of the C-style for-loop can be extended in horrible, complex ways, which is why I avoid using it in those ways. Hell, you can put the whole contents of the loop inside of the for () construct, if you want. Even had an instructor in college ENCOURAGE doing it. "It's there, you might as well use it!" Asshat.



Yeah, but you didn't start out talking about "normal idioms". You started off with Strife's code optimizations (calling it "not complicatedd", to boot) and "Duff's Device" as examples. Hence:





I liked Smalltalk, too. Never really got to use it much, though. Still prefer Object Pascal to it, even though there are some things I would like to add to the language for my own uses.



Not sure where you think I am arguing otherwise, but whatever. Yeah, you will run into them, eventually. May even want to use them. I would much rather someone come into experiencing them from a background of good habits to recognize them for what they are.

And it can be used in many obvious, easy to understand, and straightforward ways that don't map into a simple fixed-bounds linear iterator. These are not "horrible", or "complex". Viz:

for(i = 1; i < MAXINT; i *= 2)
if(bitmap & i)
do_something_with(i);

No, I started off with one specific example of code that they were likely to run into. A relatively simple one, that I would expect anyone reasonably skilled in the art of programming to understand. I didn't say it was a "normal idiom".

Smalltalk, by the way, is expression-based. In fact it's not just expression based, it's fully reflective. And yet it's a great first language.

If loops are significantly more complicated than iterators, I would rather write them out as statements using while() or do while (), because as the complexity grows, so does the obfuscation of the C for() construct.

So, yes, I give you that it can do more than the Pascal or BASIC "For" iterator, and that the difference is fundamentally important, however, for what MOST people are going to use it for MOST of the time, as a simple loop iterator, the differences ARE simply syntactical.



Oh come on. You're going to tell me that "someone reasonably skilled in the art of programming is going to understand" a HIGHLY specific HACK for a particular scripting language? If I had never seen LSL before, I wouldn't know what the hell it was for; somehow, I doubt you would, either. Reasonably skilled in *LSL* programming, maybe.

Let alone the fact that, with Mono, they will be USING it not at all, and encountering it less and less, if at all.



Yes, I am aware of it, thanks. The reasons I liked it were the fact it was FULLY object-oriented (which is one of the transformations I would like to add to OP), and the fact that it was fully reflective. I don't know if I would consider it a "great" first language, myself, though. Being a statement-oriented developer, I don't care as much for its base syntax; I tend to like code that reads as it does and does as it reads.

The example I gave is no more complex than the simple linear iterator. You can't even SEE the slippery slope from here.

No, they'll probably go WTF the way I did when I first saw it. But it won't require more than a brief explanation to "get" it. It's not "you're not expected to understand this" territory.

It's going to take some time before it's advisable to compile all LSL scripts as Mono, if that ever happens.

SmallTalk's code reads as it does and does as it reads better than just about any algorithmic language I know of, including Pascal.

What part of "significantly" is unclear?



So? What does that have to do with initial choice of learning language? I mean, for you to use it as an example of why Pascal (or any other statement-oriented langauge) is "problematic"? I bet if Piggie asked about it, coming from BASIC, he would "grok it" with a brief explanation, too.



O.o You're kidding, right? Who DOESN'T compile the vast majority of their LSL scripts under Mono? I admit that I am a slow-adopter, but even I have pretty much switched all of my scripts that I put out now to Mono.

If there's some highly important reason why we shouldn't, I would hope someone would say something, and soon. So far, I haven't encountered any problems or heard of some reason to avoid doing so.



On that point, I will have to simply disagree. I find it significantly less readable, comparatively.

The part where it's relevant to the example I gave.

The baby duck effect.

Me. Mono is undesirable for scripted attachments and vehicles because the overhead of marshaling and unpacking a Mono script on sim crossing is significantly higher than LSL. It also has a higher startup cost on rezzing a new instance for the same reason.

There are situations where Mono is a clear win, but not for the kind of script I typically work on.

I kind of thought that this was likely going to be a concern since Mono was announced, but it wasn't until Seal quantified the effect last year that I've been really concerned. Since then I've been pretty regularly commenting on it.

Except that it wasn't, since your example wasn't significantly more complicated than a simple linear iterator.



Wouldn't apply in this case, there are no other options at the moment. I don't particularly like C/C-based languages, either (as if you couldn't tell... <.<, but I make do. So does everyone else.



Makes sense, and I remember hearing about it some time ago (like last year), but isn't this issue more well-documented? I haven't seen anything about it in a long time.



I would say a LOT of situations.



Is there a specific JIRA or Wiki entry on it? If not, there needs to be one, "regular commentary" aside.

Yes, that was my point. That there's a HELL of a lot of useful space between simple linear iterators and the slippery slope.

But people keep seeing things through the filters of their baby-duck language.


I don't know, ask LL.

Two situations:

1. When the Mono script is below 16k, or it's CPU-intensive, AND it's in a prim that doesn't have to cross sim boundaries very often, AND it's in a prim that isn't rezzed very often.

2. When perfomance of LSO is simply inadequate.

I thought about a Jira but, well, it's not a bug and LL is not going to roll back.

Oh? Like who? If you are insinuatingly referring to me, I started out with MITS BASIC and 8080 machine code, entered via switches on the front of an Altair 8800a (ie, HAND-assembled). As such, I don't think it applies.



Well, you said you comment on it "pretty regularly". I figured you'd at least know where the info was on the subject, even if it was your own.



I'd say those are two rather large categories of situations, with lots of examples.



Who says JIRA is only for bugs? <.<

If I meant you I'd have said so. My first language was Algol-60 on coding pads, because I didn't have regular access to a computer until '76 or so. I don't recall any of it now. But we were talking about new programmers, not you or I.

Indeed. They don't happen to intersect with pretty much anything I do, though, so (popping back a few messages) I don't use Mono for pretty much anything.

Even still, I would recommend people try similar/different languages anyway; it can be educational with respect to the differences, as well as their strengths and weaknesses, and they can apply that knowledge to new languages, like LSL. Maybe they will even find something new and different that they really like on the journey.

That's why I made the suggestion in the first place.