[Void]

Originally Posted by Argent Stonecutter

[...]
Keeping them working in the Mono implementation of LSL means that EVERY subtraction, division, or other non-commutative operation in LSL now has an unnecessary "swap" in front of it. Every piece of code in SL is effected. There is no way that you can describe that outcome as "good".[...]

there, we agree

It's a good thing that this kind of behavior is undefined, and that programmers don't depend on it. It provides no benefit. Writing code that does depends on it makes that code harder to understand. Don't do it.

here, we must disagree.... the behavior is defined whether it's documented or not, and working around it because there is no formal standard means limitations... one of them is spotlighted in functional languages, simultaneity. two more are being highlighted here, portability, and understandability.... size and speed aren't even really runners up in the grande scheme of things at this level.

(I found two images I wanted to post last time... here's the second)

[Argent Stonecutter]

Originally Posted by Void

here, we must disagree.... the behavior is defined whether it's documented

If it's not documented, it's not defined.

Functional languages are a side issue because they don't have side effects.

You NEVER actually need to write an expression that depends on order of evaluation. NEVER. You can ALWAYS split it into two statements. ALWAYS.

I only brought up performance because the reason it's "informally standardized" at all is because of a performance hack. My point is that it's not even justified on that basis because the end result of that hack was that EVERYONE'S code is bigger and slower.
ObOnTopic:

[Richie Waves]

[Johnnie Carling]

Originally Posted by Richie Waves

They own that too. BP is one of the larger producers of Solar equipment.

[Tess Whitcroft]

The Piaggio Ape ([ˈape pjaddʒo]; ah-peh; Italian for bee[1]) is a three-wheeled light commercial vehicle first produced in 1948 by Piaggio.

Piaggio Ape - Wikipedia, the free encyclopedia

Tess

[Void]

Originally Posted by Argent Stonecutter

If it's not documented, it's not defined.[...]

so since it is documented it is defined? =D

[...]You NEVER actually need to write an expression that depends on order of evaluation. NEVER. You can ALWAYS split it into two statements. ALWAYS.[...]

of course you can... but why should you need to?

[...]My point is that it's not even justified on that basis because the end result of that hack was that EVERYONE'S code is bigger and slower.

in LSL? yes I agree
in general, if there was only one convention in use between languages? no

and spice you say?

[Grandma Bates]

Desperately wishing I could embed the video here:
my name isn't actually ryan stop calling me that | the last one omfg

Here is a direct link to the video:
http://vt.tumblr.com/tumblr_m5kvzko35U1r6g7k5.mp4

There is a shorter version on you tube, but it cuts off the last one, which is the best...

To compensate here is a picture:

[Argent Stonecutter]

Originally Posted by Void

so since it is documented it is defined? =D

It wasn't documented when Strife came up with his hack.

of course you can... but why should you need to?

Because it makes the code easier to understand by the next person.

in general, if there was only one convention in use between languages? no

Yes.

Pretty much all languages let you nest if statements with single statements in alternation blocks without explicit block bounds (begin/end, {/}, ...). Pretty much nobody sane does that for deeply nested if statements, because it makes it harder to understand the code.

Just because you can do something, it doesn't make it a good idea.

ObOnTopic:

[Brianna Ort]

[Richie Waves]

[Johnnie Carling]

[Argent Stonecutter]

[Richie Waves]

[Argent Stonecutter]

[Walker]

[Brianna Ort]

[Walker]

[Richie Waves]

[Richie Waves]

[SpaceCase]

[Mad Mouse]

[Tess Whitcroft]

[Walker]

[Walker]

[Lexxi Gynoid]