javascript vs lua

let's say i might be working on something ``secret'' and i want to embed a scripting language that isn't too off the wall for end users. i hear luajit is kinda fast and v8 is really fast and speed would be quite nice since user scripts might be called hundreds of thousands of times in short timeframes

i've heard javascript has better semantics and is generally more pleasant to use, but i want /prog/'s opinion so i don't fuck up and regret it later

>>40
Well, at least the Jews aren't gonna be after me!

>>36
1. it's one of the most widely deployed languages ever, and it is easy to hate on popular things
it's easy to hate on things that suck, and oh wait
2. the language design has a few bright spots
like what? probably shit that other languages have done better, even before javascript existed

>>37
and yet a lot of people still think it's a good language and get hard over the fact that mozilla is dead-set against accepting native support for other languages in the browser (unless it's javascript-derived shit, that is). i hope something like nacl will take off but i'm not getting my hopes up. so now if you want to use FIOC or sepples, that ``designed in less than 3 days'' language is now a ``designed in less than 3 days'' virtual machine with a ``designed in less than 3 days'' feature set. except now it uses 10 times as much ram as native code and runs 1/5 the speed if even that.

>>42
You wanna see some really slow ass shit? Trying using Prolog.

secret dubs!

>>42
2. the language design has a few bright spots
like what? probably shit that other languages have done better, even before javascript existed

some things i like about js

1. first class functions. almost every other functional and "scripting" language has this also, of course.

2. json. compact representation of maps/dicts/hashes/"objects" and arrays literals is quite nice

JEWSON

sgddsgfgsfd

>>43

to be fair, most prolog programs are compactly expressed brute force search with worst case exponential time. Although I could see well written code taking a while to run, given everything that is happening under the hood.

>>27

1. An object is not a number.
2. not a number plus not a number is not a number.
3. Therefore, an object plus an object is not a number.

easy peazy!

>>49
i would expect an object plus an object would be a type error unless addition is overloaded by the programmer... which is yet another thing javascript fails at having

>>50


a = {};
b = {};

a.valueOf = function(){ return "Type" };
b.valueOf = function(){ return "Error" };

a + b;
=> "TypeError"

fixed!

>>49
Here is what my C view on the same thing...

"A value is the /meaning/ of an object (considered as a particular
type).  The key word here is /meaning/ - a 'value' is an
abstraction, an idea, not something that can be held in a
program, but a point in an abstract value space that follows
certain rules (eg, mathematical addition, etc).


It's true that bit patterns stored in objects are used to
represent values (again, under a particuilar type).  However, the
value itself -- the "meaning" -- is something that does not
depend on any object for its existence:  an unchanging, abstract
idea (such as, for example, the number 3).


When the Standard says an expression yields a certain value, what
that means is the program produces something whose "meaning" is
the same if the abstract value were stored into an object that
has the same type as that of the value.  (All values in C
programs are effectively indexed by what type they are.)  More
concretely, an expression like


   21 + 21


yields the same value (ie, the same meaning) as is held by
the variable 'x' (an object) after


   int x = 42;


Viewed from this perspective, what is produced by evaluating an
expression has the same meaning as some bit pattern stored in an
object.  Because it has the same meaning, it is the same value.
To say that another way, objects do hold patterns of bits that
represent values, but values don't depend on objects for their
existence -- if something has the same meaning as a certain bit
pattern would if held in an object, then that is the same value
as the object would have, whether an object is present or not.
(As always, subject to the necessary qualifications about types.)
"

>>49
2. not a number plus not a number is not a number.


typeof (NaN + NaN)
=> "number"

that's right, "not a number" is a "number"

>>53

yes. Type tree:


number
|- not a number
   |- object

Okay, but who really cares about these addition edge cases? Yeah, the plus sign is overloaded with meaning. That's because the natural expectation for adding two strings is concatenation.

But is it so obvious with arrays? Do you want to concat them, sum them, or treat them as strings (and therefore, concat them)?

And what about objects? Are you comparing them as hashes, or as an instance you want to extend with another (concat)?

There is an underlying logic to it in Javascript (valueOf, toString), so it's only incomprehensible until you take the time to comprehend it. But more importantly, there's no reason to have an expectation, because only an idiot would think the + should be expected to read your mind about what you want to do.

What happens if you put aluminum foil in an inkjet printer? I don't fucking know man, but that's a retarded idea, because printers are intended to work with paper. In theory you could do it, but you'd be a dumbass to do so. There are other ways to get ink onto surfaces that don't present the same limitations due to streamlining.

>>55'
But is it so obvious with arrays? Do you want to concat them, sum them, or treat them as strings (and therefore, concat them)?
because only an idiot would think the + should be expected to read your mind about what you want to do
wouldn't be an issue if there were a dedicated string concatenation operator, and if array -> string required an explicit conversion. then + wouldn't have to read your mind

And what about objects? Are you comparing them as hashes, or as an instance you want to extend with another (concat)?
for +? what?

>What happens if you put aluminum foil in an inkjet printer?
NaN

dedicated string concatenation operator
Oh, you mean like . in PHP, the veritable pinnacle of language design?

+ is absolutely fine. It sums numbers and concatenates strings. Really, that's not too complex for you to remember, is it?

The rest of it is the not the result of + being broken, but of type coercion being tricky. Making sure the values coming in are within expected bounds is a bread and butter programming task. + doesn't deserve any of type sanitation's backlash.

Lua is JS done right. It's pretty obvious.

>>57
+ is absolutely fine. It sums numbers and concatenates strings.

But addition is commutative and concatenation is not.

Tcl.

>>29
use map/filter/reduce

js is functional, don't treat it like C and get angry.

js has lots of problems, but libs like underscore.js make almost all of them go away.

>>59
So what? Javascript expressions are evaluated left to right.

>>58
but Javascript is a much better Scheme. Lua doesn't even try!

>>63
In fact, Lua just mooches off Python nowadays. Seriously, FIOC of all things?

>>63

once you start using all of lua's features, it gets a little insane. you can write some functions, start mapping tables, mapping iterators, composing iterators with functions, using coroutines to abstract complex algorithms as iterators, have multiple algorithms passing values back and forth to each other, using composed functions to apply filters to their inputs and outputs. The ease of functional programming is there, but there is also the convenient data entry. And it's fast, which is nice. The lack of static typing makes things hairy once it gets large though. More time is spent debugging and testing. But it can be nice for doing some quick table crunching. Although it doesn't come close to perl for text processing.

>>64

eh, you should learn more about lua.

it does look a lot like python at a glance though. It has some of it's features, while others are missing. Using immutable tupples for keys would have been nice. There are work arounds, but they aren't necessairly as convenient or as efficient, which is a drag.

>>65,66
i would rather have forced stringification of keys destroying my object references

Lua's equals and not equals operators are fucked up

>>69

why? because of overloading? or is just the ~= ?

>>70
Of course it's just the ~=. People here are retarted this much.

>>71
maybe it's because it doesn't fuck with the operands beforehand

>>72
You're wrong.
~-san totally fucked the shit out of ==-kun, and it's how ~=-chan was born.

>>73
bitches don't know bout my #

Lua is the coolest scripting language.

But scripting languages are kind of lame. Mostly because of the whole "mutable objects" thing. They tends to only go part way down the functional rabbit hole and I find that to be awkward.

>>1
both suck, end thread

>>76
check dubs, end thread

>>76
javascript does NOT suck, ``faggot''

$ lua
Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
x = 1
x
>>
>> ;
stdin:3: '=' expected near ';'
WTF is this shit? Do I have to wrap everything in a print() call just to see what something evaluates to?

>>79
= x