>>43
I just spent 2 hours finding why my script stopped with Wrapped Native exception and rewriting it several times.
apparently you can't alias functions at all. Here example of this 'sanity'
id=document.getElementById;<--this should work..in theory
function c(a){return id(a)};<-- this is a normal function call
alert(c('code')) <--fails. Firefox errors anytime you try this.
Name:
FrozenVoid2010-07-05 7:46
>>44
use this instead:
function id(x){return document.getElementById(x)}
>>48
Overall, a pretty crappy question on >>38's part.
Name:
Anonymous2010-07-05 10:47
It's always a tradeoff between safety, speed, flexibility/ease of use.
The higher level you go, you lose some control regarding low-level optimizations. The fastest ``language'' would be writing everything in your platform's assembler. It should only be done when you know something is a major bottleneck and rewriting it will give you a major performacne increase (examine the disassembly of the code your compiler generated). Going higher level than assembly, you have C, which is basically portably assembly - you still have to manage memory yourself, but the compiler performs register allocation for you, and it can be portable, if you don't abuse too many platform-specific features. Neither asm or C are very safe, they're as safe as you make them be - if you understand how to write secure code, they both can be safe. If you go higher than C, you get the usual high-level languages like: C#, Java, C++, Haskell, Common Lisp, Scheme, Erlang, Javascript, ML, O'Caml, Smalltalk, Python, Perl, PHP, Ruby and so on. Each of those high-level languages have certain properties which when implemented can give them certain performance and safety characteristics. Most real general-purpose languages let you link to native code which can be written in C or Asm or other languages for performance or interoperability reasons. They may even allow callbacks or they can embed or allow themselves to be emebedded in code written in other languages. When it comes to those performance/safety characteristics, languages which are statically typed (the types are known at compile-time) tend to be faster as the data is usually kept unboxed (in C, arrays are just buffers or data, integers are unboxed, and so on), while dynamically typed languages don't type their variables, instead the data itself is typed, which means that in a properly dynamicly typed language(like Common Lisp or Scheme), most data has some tag bits of sort from which you can determine the type, and not only that: you could completly walk the entire data structure (in a debugger for example) and be able to completly see all the referenced data (this is possible in statically typed languages as well, but you would require all the debug info and a damn good debugger). There's also another extreme of statically typed languages which infer the types for you, so you don't have to declare them(like in C), languages like Haskell, ML, O'Caml belong in this category. Such languages trade some flexibility for safety and in the case of a good compiler, they can give you extra speed as well. Type inference assures that your program is well-typed, so it catches typing errors at compile-time. Type inference is possible in dynamically typed languages as well (for example a Common Lisp compiler can infer types to some degree), but such languages tend to be designed to have functions which can take very wide variety of types as parameters, so such kinds of type inference as more limited than the ML ones (in ML, the language is constricted in ways that make full type inference possible, while in most Lisps, user flexibility is more important than the possibility to have full type inference). Keep in mind safety is not compromised in such languages, just that type-checks are performed at runtime (unless you decide to compile in an unsafe mode which omits typechecks at runtime(or the compiler infers the type and omits the checks itself, or the user specifies the type manually in a type declaration), at the risk of crashes if the code is not properly written). In another side of the spectrum, you have dynamically typed languages with autoconversion like PHP and Perl, which think that there's no such thing as true errors and will attempt to munge the input to make sense, even if it's erroneus - such languages are also hard to compile to native code and tend to be interpreted, they are not safe languages, but the usual outcode from the lack of safety is people being able to exploit the vulnerable code (see all those owned servers that run PHP applications).
My personal choice here is to pick the most flexible high-level language which I could find, with good speed characteristics, with good implementations and good metaprogramming support. For me it was Common Lisp, but if Lisp is not for you, and you want some imperative C-like language, you could try D or C#. My applications are usually reasonably fast, I can easily profile, debug and disassemble the generated code in my implementation, and when I locate the bottlenecks I first eliminate any algorithmical errors (reducing complexity) and if that is not enough, I can help the compiler generate better code with some declarations. In the case it's something very speed sensitive, I can just write that part in C in the first place or write it in ASM if the C compiler can't do a good job (think matrix multiplications, vector transforms and things which are handled well by SIMD instructions in modern CPUs). Most C and Common Lisp implementations that I know of allow you to embed asm inline or via the linker or FFI.
So OP, learn languages on all sides of the spectrum with difference performance and flexibility characteristics and use the ones the job require, switch tools when needed and mix code from different languages, maybe even make your own mini-compilers to generate code for you(this is a lot of fun to do in Lisps as you can skip all the syntax lexer/parser junk and get straight to code generation!).
the tl;dr being:
Use high-level languages for most of the code, preferably a high-level language which gives you lots of flexibility and has good (a) implementation(s). Profile it, examine compiler output (disassembly), write critical parts in C or Assembly (inline or just link it somehow) if just optimizing the algorithm or compiler hints (in the high level language) are not enough. This way you can get the best of both worlds.