irihapeti Posted December 16, 2014 Share Posted December 16, 2014 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 areother 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 upjejejjejje (: Link to comment Share on other sites More sharing options...
Rolig Loon Posted December 17, 2014 Share Posted December 17, 2014 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. Link to comment Share on other sites More sharing options...
Nova Convair Posted December 17, 2014 Share Posted December 17, 2014 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. Link to comment Share on other sites More sharing options...
irihapeti Posted December 17, 2014 Author Share Posted December 17, 2014 for ( b = gMenuPosition + len + Last - 1; ((++len) <= 12) && ((++b) <= All); Buttons += [llList2String(gNames, b-1)] ); (: Link to comment Share on other sites More sharing options...
irihapeti Posted December 17, 2014 Author Share Posted December 17, 2014 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 (: Link to comment Share on other sites More sharing options...
Rolig Loon Posted December 17, 2014 Share Posted December 17, 2014 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. Link to comment Share on other sites More sharing options...
Madelaine McMasters Posted December 18, 2014 Share Posted December 18, 2014 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. ;-). Link to comment Share on other sites More sharing options...
irihapeti Posted December 18, 2014 Author Share Posted December 18, 2014 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 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now