elegant v leet

[irihapeti]

sometimes I write a code and I go hmmm! can I make it even more inline (meaning obscure) than what I wrote already. Then I go: yuusss !!! and then like:

 

integer on;
float WAIT = 3.0;


touch ( ... )
{
   llSetTimerEvent((float)(on = !on) * WAIT);
}

 

(:

+

i get into a big argue this one time about elegant v leet. Other person argue the above codes is elegant. I argue that is leet. They argue that is the same thing. That elegant == leet.

I say No. bc like they are not wearing any shoes and they got a hole in their sock. So is obvious that a person with a hole in their sock knows nothing about elegant. No matter how leet they maybe think they are

other person goes wahhh! and I say: Is true !! And I am the winner of the argue. I am the winner bc they start rub their head after that and gave up

jejejjejje (:

[Rolig Loon]

With the exception of the three unexecuteable dots ( . . . ) in the parameter field for touch ( ), I don't see anything very unusual in that bit of code. That's how I would write a toggle switch too.  Anything more expanded than that is wasteful, and that is quite readable.  I find it much easier to write and follow inlined code than code that is spread out too far.

If I had to choose my favorite lines of obscure code -- admittedly perhaps a bit too obscure -- they would be this snippet I put in a dialog menu a while ago ...

        for(b = gMenuPosition + len + Last - 1 ; (len < 12)&&(b < All); ++b)        {            Buttons = Buttons + [llList2String(gNames,b)];            len = llGetListLength(Buttons);        }

It worked beautifully AND was compact.

[Nova Convair]

The OP's example is quite normal to me. So it's not elegant nor leet.

Roligs example is surely not normal. Things I need quite a while to decode them are not elegant. So it must be leet.

 

[irihapeti]

for ( b = gMenuPosition + len + Last - 1;       ((++len) <= 12) && ((++b) <= All);       Buttons += [llList2String(gNames, b-1)]    );

 

(:

[irihapeti]

am teasing a little bit (:. I start with a pretty simple example

Rolig post quite a good one. I just leet it some more

hopefully other people will post some little codes so we can have a go at them

just for fun (:

and never know but maybe some new people reading will go ooo! I can maybe learn something about logic programming style on here and how maybe can be applied to their own LSL (: 

[Rolig Loon]

Yeah, I agree it's not normal and I chastise myself appropriately.  Still, I'm kind of proud that it works.  :smileytongue:

I had the advantage of learning to write LSL scripts when Void Singer was still here among us.  She has a distinctive style that some people have called deliberately arcane but which has a very strict internal logic.  It uses a naming convention for variables and functions that leaves do doubt about what type of variables are involved and what their purpose is, and it draws on a toolbox of hacks and bit-shifting methods that reduce some common messy tasks like multipage dialogs to fairly compact, fast code. 

I don't go very far in following Void's example because I do agree that it's hard to read. You have to be Void to feel comfortable writing that way. (Apologies to Void if she's lurking.)  At the same time, however, I have been forced to really dig into scripting logic by having to unpack her code.  I've had many "Aha!" moments when  I've solved one of her scripting puzzles and realized that I understand bit masking or the order of conditional operations or typecasting in new ways. 

[Madelaine McMasters]

---

irihapeti wrote:

sometimes I write a code and I go hmmm! can I make it even more inline (meaning obscure) than what I wrote already. Then I go: yuusss !!! and then like:

 

integer on;float WAIT = 3.0;touch ( ... ){   llSetTimerEvent((float)(on = !on) * WAIT);}

---

integer ON = 1;integer OFF = 0;Integer I_AM = OFF;float WAIT = 3.0; // secondstouch (...) {if (I_AM == ON){    llSetTimerEvent = WAIT;    I_AM = OFF;}else { // I_AM == OFF)    llSetTimerEvent(0); // turn off timer 

I_AM = ON;}

If I were to compile something like what you wrote on my production C compiler for the little microprocessors I've used throughout my career, it would probably run 100 times slower than what I wrote (if we ignore the function call). Compact source code doesn't necessarily yield compact machine code. On a computer that hasn't got a hardware multiplier much less floating point, that clever * WAIT can cost hundreds of cycles. In my example, there is no mulitplication, only integer math and comparisons. All ARM processor instructions have the ability to be executed conditionally, so sometimes an if() costs less than any alternative to it. That's not the case in my example, but it happens.

In code, as in art, elegance is subjective. If my goal is to write code that's easily understood and maintained by those who follow behind me, I'm happy to skip the clever tricks. I can enjoy those as much as the next girl. But, I don't want to get phone calls at 10pm, so I try to write code that needs no explanation. Elegant code conserves precious resources. One of the most precious is human time.

These days I write code for myself. I consider it elegant if it works.

;-).

[irihapeti]

yes agree. It depends a whole lot on the compiler/interpreter. Is said that the best thing a programmer can ever learn is how their compiler/interpreter actual works

like for example in LSL Mono

if (i >= 0) is way faster to execute at runtime than

if (~i)

as you mentioning the first compiles to a simple machinecode jump/branch instruction

the second compiles to a function which has to be executed each time