We Keep Coding

Why isn't it good non-compile scripting languages to use for intensive calculations?

I was reading a ebook about web technologies and I found this.
JavaScript is a language in its own right (theoretically it isn't tied
to web development), it's supported by most web clients under any
platform, and it has some object-oriented capabilities. JavaScript is
not a compiled language so it's not suited for intensive calculations
or writing device drivers and it must arrive in one piece at the
client browser to be interpreted so it is not secure either, but it
does a good job when used in web pages.
Here my problem is why we can't use JavaScript for process intensive calculations? It doesn't describe in the book. However, I have use JavaScript for mobile applications too, In some we have done very large calculation. How non-compile languages effect on this?

Two parts to this.
In a non-compiled language, you have to take a hit to compile or interpret it. Optimisation can reduce the cost of that, ie cache the result of the compilation, though of course that introduces complexity and uses up memory.
The other side is after a program is compiled, the result can be tweaked and specifically optimised for a particular purpose.
You have to consider the context though, one calculation to isolate a particular Calibi-Yau space was estimated to need 4 years to complete on the best super computer available at the time. So your definition of big and the guy who wrote the article might not be comparable. Course they could be one of those micro-optimisation types...
With modern compiler/interpreters and the most optimised code you can write, has to be a real edge case for this to be significant, and pre-compiled code is pretty much a given in those scenarios.

Python over JavaScript? (Facts, please) [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I recently learned JavaScript an all of the sudden I hear about Python...
Should I go learn Python or just stick with my basic JavaScript knowledge?
If you have some "facts" I would love to hear them! Like efficiency, difficultylevel and so on, an so on...
Thanks :)

The two are generally used quite differently. Javascript is primarily used as a client side scripting language vs python which is a server based language. So in a website you could use both. But not sure if this is what you were wondering.

If you're just learning a language, then there is none better than Python. It's an easy language to pick up. It's well documented. It's associated with a large, active, and friendly community. Since it's a scripting language, you can easily try stuff out and immediately see the results. You can also build up from programming basics, starting by learning functions and then moving into classes.
Javascript is the bane of many a programmer's existences. It's easy enough to learn, and is good for small scripts which is what is was designed for. But once you start making anything big, it becomes hard to keep track of. That's why language modifications like CoffeeScript, Typescript and Dart have emerged.
As noted by spinon, these programming languages were used in very different ways. Python is a general scripting language, which can sometimes be used to do server-side work. Javascript used to be solely used for building interactivity on web pages. Nowadays, however, it also becomes popular in server-side and desktop applications as Node.js.

The key fact is that Javascript is very hard to ever change (because of billions of old implementations existing in browsers), so design errors made in early (and frantically hurried;-) stages are still with the language today. (See Crockford's Javascript: the good parts for a reasonable discussion by a JS expert and enthusiast about the good and bad parts thereof). This might change if something like a use strict; directive ever makes its way into ECMAscript (though programming in ways that support old, and often buggy, browsers, will still be like pulling teeth -- like writing Python code that runs unchanged all the way from Python 1.0 to 3.1 would be!-).
Python is deployed in more traditional ways, so gradual language changes have enhanced it over the years (it was also designed with less hurry, and [[arguably, not "a fact";-)]] ended up with a better design from the start, in many respects).
As a result, Javascript (so far) has not enjoyed much success "server side", where programmers get a choice (even though they still have to use JS for "browser side" code). But there's nothing intrinsic to that. JS is by far the most widely deployed language in the world (those billions of browsers...), huge investments are made in it by many companies and open source groups in competing implementations and supporting frameworks (Python's no slouch at that either, but the difference is still there), practical improvements (speed, warnings) keep piling up on JS's side as a consequence (even though the language proper can't improve).
With strict self-imposed programming discipline (enforced e.g. by Crockfor's "lint" program for JS) and a good supporting framework (jQuery, Dojo, Closure, ...) and tools (Firefox has maybe the best add-ons for JS tracing and debugging, but other browsers are rushing in that direction too), JS has become usable in recent years. Probably one of these days a fast server-side implementation (probably with "use strict;" or the like enforced, once that's officially blessed;-) will start gaining a substantial foothold, just because so many web programmers already have some JS knowledge (they have to, to make good web apps).
Note that much of JS's bad rep (beyond the acknowledge "bad parts that can't be removed";-) comes from stuff that doesn't really "belong" to JS as a language: buggy implementations, the mess that the HTML DOM can often be (esp. with buggy browser impementations), etc. There is no reason a future server-side deployment should reproduce these maddening defects!-)

Python’s a good second language to learn after JavaScript, as they have a reasonable number of similarities, e.g.
they’re both memory-managed
they have similar data structures — JavaScript’s objects and arrays are much like Python’s dictionaries and arrays
they’re both used quite a lot for web-related work — JavaScript in the browser and in server-side contexts like node.js, Python in web frameworks like Django.
However, Python’s object-oriented... stuff is quite different to JavaScript’s protoype-based object-oriented stuff.
If the only programming you do is manipulating web pages within the web browser, then Python won’t be of any direct use to you (only JavaScript runs in browsers at the moment). But learning another programming language generally gives you new ways to think about the languages you already know. Learning Python could help you write better JavaScript.

JavaScript is usually used as a client-side scripting language - that is, it gets downloaded and executed by your browser. Python, however, is usually not coupled to the web. it can be used as a server-side scripting language, and for scripts and applications of any kind. But it is not a client-side language, and is therefore not directly comparable to Javascript, which has an entirely different audience.
Looking at the language level, Javascript is terrible and dysfunctional (hard to debug, clumsy object-orientation) while Python is beautiful and expressive. This is, of course, subjective :-)

Javascript is primarily for client-side ( browser ), Python is primarily used for server-side - so they serve different needs ( disregarding the Python to JS converters and all ).
I would recommend learning Python though, as it influenced ECMAScript and the syntax is very similar, both are object oriented, both are great languages.
2018 Update: I would still recommend learning Python over Javascript as a first language because it's just that much of a more beautiful, elegant language... although Javascript can now be used for both server-side and client-side thanks to node.js thus making it more useful all-around.
http://hg.toolness.com/python-for-js-programmers/raw-file/tip/PythonForJsProgrammers.html

IMO Python may be easier to learn (having taught both to intro classes).
Also, one major annoyance of JavaScript is that in runs in your browser. This inherently makes it much harder to debug problems.
In terms of a production-level language, Python is more of a general purpose programming language, while JavaScript is targeted at building dynamic web applications.
If you want to get into programming, you should definitely learn a more general purpose language such as Java or Python.

For what purpose? Javascript is king in some circles (web development, for instance).
Javascript and Python are not mutually exclusive. Why not learn both?

JavaScript and Python are both great languages that are geared toward different problems.
JavaScript knowledge is invaluable when dealing with the web, writing web pages, and poking around in html DOM.
Python is a scripting language that is great for a host of things on any machine.

It depends.
Do you want to program in a language that specifically targets web browsers? Stick with Javascript
Do you want to write... well anything besides for web browsers? Learn Python.
Python is an excellent beginner language that's not just a beginner language. Google uses it, NASA uses it, and many, many other organizations use Python.

Along with Python generally being server-side and JavaScript client-side, Python was designed to not only be easy to learn, but also easy to read, and to encourage a more productive environment.

If you need to ask, then I would say no since you don't have a need in mind for its usage.

Should writing Javascript be avoided in favour of GWT/WebSharper or some other abstraction?

I'm curious what's the view on "things that compile into javascript" e.g. GWT, Script# and WebSharper and their like. These seem to be fairly niche components aimed at allowing folks to write javascript without writing javascript.
Personally I'm comfortable writing javascript (using JQuery/Prototype/ExtJS or some other such library) and view things like GWT these as needless abstractions that may end up limiting what a developer needs to accomplish or best-case providing a very long-winded workaround. In some cases you still end up writing javascript e.g. JSNI.
Worse still if you don't know what's going on under the covers you run the risk of unintended consequences. E.g. how do you know GWT is creating closures and managing namespaces correctly?
I'm curious to hear others' opinions. Is this where web programming is headed?

Should JavaScript be avoided in favor of X? By all means!
I will start with a disclaimer: my answer is very biased as I am on the WebSharper developer team. The reason I am on this team in the first place is that I found myself a complete failure in writing pure JavaScript, and then suggested to my company that we try and write a compiler from our favorite language, F#, to JavaScript.
For me, JavaScript is the portable assembly of the web, fulfilling the same role as C does in the rest of the world. It is portable, widely used, and it will stay. But I do not want to write JavaScript, no more than I want to write assembly. The reasons that I do not want to use JavaScript as a language include:
There is no static analysis, it does not even check if functions are called with the right number of arguments. Typos bite!
There is no or a very limited concept of libraries, namespaces, modules, classes, therefore every framework invents their own (a similar situation to that of R5RS Scheme).
The tooling (code editors, debuggers, profilers) is rather poor, and most of it because of (1) and (2): JavaScript is not amenable to static analysis.
There is no or a very limited standard library.
There are many rough edges and a bias to using mutation. JavaScript is a poorly designed language even in the untyped family (I prefer Scheme).
We are trying to address all of these issues in WebSharper. For example, WebSharper in Visual Studio has code completion, even when it exposes third-party JavaScript APIs, like Ext Js. But whether we have or will succeed or fail is not really the point. The point is that it is possible, and, I would hope, very desirable to address these issues.
Worse still if you don't know what's
going on under the covers you run the
risk of unintended consequences. E.g.
how do you know GWT is creating
closures and managing namespaces
correctly?
This is just about writing the compiler the right way. WebSharper, for instance, maps F# lambdas to JavaScript lambdas in a 1-1 manner (in fact, it never introduces a lambda). I would perhaps accept your argument if you mentioned that, say, WebSharper is not yet mature and tested enough and therefore you are hesitant to trust it. But then GWT has been around for a while and should produce correct code.
The bottom line is that strongly typed languages are strictly better than untyped languages - you can easily write untyped code in them if you need to, but you have the option of using the type-checker, which is the programmer's spell-checker. Why wouldn't you? A refusal to do so sounds a bit luddite to me.

Although, I don't personally favor one style over another, I don't think that abstraction from Javascript is the only benefit that these frameworks bring to the table. Surely, in abstracting the entire language, there will be things that become impossible that were previously possible, and vice-versa. The decision to go with a framework such as GWT over writing vanilla JavaScript depends on many factors.
Making this a discussion of JavaScript vs language X is fruitless as each language has its strengths and weaknesses. Instead, do an objective cost-benefit analysis on what is to be gained or lost by going with such a framework, and that can only be done by you and not the SO community unfortunately.
The issue of not knowing what goes on under the hood applies to JavaScript just as much as it does to any translated source. How many people do you think would know exactly what is going on in jQuery when they try to do a comparison such as $("p") == $("p") and get back false as a result. This is not a hypothetical situation and there are several questions on SO regarding the same. It takes time to learn a language or framework, and given sufficient time, developers could just as well understand the compiled source of these frameworks.
Another related aspect to the above question is of trust. We continuously build higher level abstractions upon lower level abstractions, and rely on the fact that the lower level stuff is supposed to work as expected. What was the last time you dug down into the compiled binary of a C++ or Java program just to ensure that it worked correctly? We don't because we trust the compiler.
Moreover, when using such a framework, there is no shame in falling back to JavaScript using JSNI, for example. It's all about solving the problem in the best possible manner with the tools at hand. There is nothing sacred about JavaScript, or Java, or C#, or Ruby, etc. They are all tools for solving problems, and while it may be a barrier for you, it might be a real time-saver and advantageous to someone else.
As for where I think web programming is headed, there are many interesting trends that I think or rather hope will succeed such as JavaScript on the server side. It solves very real problems for me at least in that we can avoid code duplication easily in a web application. Same validations, logic, etc. can be shared on the client and server sides. It also allows for writing a simple (de)serialization mechanism so RPC or RMI communication becomes possible very easily. I mean it would be really nice to be able to write:
account.debit(200);
on the client side, instead of:
$.ajax({
url: "/account",
data: { amount: 200 },
success: function(data) {
..
}
error: function() {
..
}
});
Finally, it's great that we have all this diversity in frameworks and solutions for building web applications as the next generation of solutions can learn from the failures of each and focus on their successes to build even better, faster, and more awesome tools.

I have three big practical issues I have with websharper and other compilers that claim to avoid the pain of Javascript.
If you won’t know Javascript well you can’t understand most of the examples on the web of using the DOM/ExtJs etc., so you have to learn Javascript whatever. (For the some reason all F# programmers must be able to at least read C# or VB.NET otherwise they cannot access most information about the .net framework)
On any web project you need a few web experts that know the DOM and CSS inside out; would such a person be willing to work with F# rather than Javascript?
Being tied into the provider of the compiler, will they be about in 5 years’ time; I want full open source or the tools to be supported by Microsoft.
The 4 big positives I see with these frameworks are:
Shareing code between the server/client
Having fewer languages a programmer needs to know (javascript is a real pain as it looks like Jave/C# but is not anything like them)
The average quality of a F# programmer is a lot better than a jscript programmer.

My opinion for what it's worth is that every framework has its pros/cons and a project team should evaluate their use cases before including one. To me any framework is just a tool to be used to solve a problem, and you should pick the best one for the job.
I prefer to stick to pure JavaScript solutions myself, but that being said I can think of a few cases where GWT would be helpful.
GWT would allow a team to share code between the server/client, reducing the need to write the same code twice (JS and Java). Or if someone was porting a Java client to a web UI, they may find it easier to stick to GWT ( of course then again it may make it harder :-) ).

I know this is a gross over-simplification, because there are many other things that frameworks like GWT offer, but here is how I view it: if you like JavaScript, write JavaScript; if you don't, use GWT or Cappuccino or whatever.
The reason people use frameworks like GWT is not necessarily the abstraction that they give--you can have that with JavaScript frameworks like ExtJS--but rather the fact that they allow you to write web applications in something other than JavaScript. If I were a Java programmer who wanted to write a web application, I would use GWT because I would not have to learn a new language.
It's all preference, really. I prefer to write JavaScript, but many people don't.

What optimizations do modern JavaScript engines perform?

By now, most mainstream browsers have started integrating optimizing JIT compilers to their JavaScript interpreters/virtual machines. That's good for everyone. Now, I'd be hard-pressed to know exactly which optimizations they do perform and how to best take advantage of them. What are references on optimizations in each of the major JavaScript engines?
Background:
I'm working on a compiler that generates JavaScript from a higher-level & safer language (shameless plug: it's called OPA and it's very cool) and, given the size of applications I'm generating, I'd like my JavaScript code to be as fast and as memory-efficient as possible. I can handle high-level optimizations, but I need to know more about which runtime transformations are performed, so as to know which low-level code will produce best results.
One example, from the top of my mind: the language I'm compiling will soon integrate support for laziness. Do JIT engines behave well with lazy function definitions?

This article series discusses the optimisations of V8. In summary:
It generates native machine code - not bytecode (V8 Design Elements)
Precise garbage collection (Wikipedia)
Inline caching of called methods (Wikipedia)
Storing class transition information so that objects with the same properties are grouped together (V8 Design Elements)
The first two points might not help you very much in this situation. The third might show insight into getting things cached together. The last might help you create objects with same properties so they use the same hidden classes.
This blog post discusses some of the optimisations of SquirrelFish Extreme:
Bytecode optimizations
Polymorphic inline cache (like V8)
Context threaded JIT (introduction of native machine code generation, like V8)
Regular expression JIT
TraceMonkey is optimised via tracing. I don't know much about it but it looks like it detects the type of a variable in some "hot code" (code run in loops often) and creates optimised code based on what the type of that variable is. If the type of the variable changes, it must recompile the code - based off of this, I'd say you should stay away from changing the type of a variable within a loop.

I found an additional resource:
What does V8 do with that loop?

Why is JavaScript sometimes viewed as a low level language?

Inspired by this question.
I commonly see people referring to JavaScript as a low level language, especially among users of GWT and similar toolkits.
My question is: why? If you use one of those toolkits, you're cutting yourself from some of the features that make JavaScript so nice to program in: functions as objects, dynamic typing, etc. Especially when combined with one of the popular frameworks such as jQuery or Prototype.
It's like calling C++ low level because the standard library is smaller than the Java API. I'm not a C++ programmer, but I highly doubt every C++ programmer writes their own GUI and networking libraries.

It is a high-level language, given its flexibility (functions as objects, etc.)
But anything that is commonly compiled-to can be considered a low-level language simply because it's a target for compilation, and there are many languages that can now be compiled to JS because of its unique role as the browser's DOM-controlling language.
Among the languages (or subsets of them) that can be compiled to JS:
Java
C#
Haxe
Objective-J
Ruby
Python

Answering a question that says "why is something sometimes called X..." with "it's not X" is completely side stepping the question, isn't it?
To many people, "low-level" and "high-level" are flexible, abstract ideas that apply differently when working with different systems. To people that are not all hung up on the past (there is no such thing as a modern low-level language to some people) the high-ness or low-ness of a language will commonly refer to how close to the target machine it is. This includes virtual machines, of which a browser is now days. Sorry to all the guys who pine for asm on base hardware.
When you look at the browser as a virtual machine, javascript is as close to the (fake) hardware as you get. That is the viewpoint that many who call javascript "low-level" have. I think it's a pointless distinction to make and people shouldn't get hung up on what is low and what is high.

A lot of people say this because the objects and structures provided in JavaScript are about as simple as you can get. To develop any sort of real functionality, you have to use an external library. Low level is a bad way to put this, because it already has a meaning in computer science. A better way to say it may be that it's without built-in libraries.
Compare this with Java, where the actual language really doesn't do a whole lot. Trying making an array without an ArrayList, or access the file system without the IO libraries. Most languages are more than just the basics, they come with this extra functionality.
With JavaScript, the only real power we get comes from the APIs that are introduced by the browsers and aren't part of the language. Things like DOM manipulation and Ajax are supplied by the browser.
It may be better to summarize all of this by saying that with a language like Java, you can get started doing some serious work without having to download third-party libraries, but with JavaScript, you either have to download a library or write a library of your own.

"Low" here has the same meaning as in the sentences "The number of casualties suffered in the first world war was low," and "Reduced-fat ice cream is low in calories." It makes sense when there's an obvious point of comparison, but out of context, it is simply absurd.

I don't view javascript as a low level language. A lot of functionality and user experience boosters are provided by it. Maybe others may view it as such simply because users can turn it off in their browser options, but it's a hugely robust language that virtually runs the web on virtually all types of browsers...

It's not, it may be as low-level as you can get in normal browser programming, but its on par with functional languages like Scheme or Python.
I think the great lacks of Javascript are lack of name spaces or packaging and no threads

It's low-level compared to the GWT and similar toolkits, but it's not a low-level language in the larger scheme of things. The features it offers are very high-level: closures, dynamic typing, and prototypical inheritance are just a few examples of its high-level features.

It's considered to be low level by a number of people who prefer writing java to generate javascript then writing javascript(ie they dislike it fairly or unfairly). A lot of people complain about java these days but despite the lack of static type checking most people would probably consider ruby and python easier to write in most cases (java being a fairly simple static language-which are much harder to design well without large built-in feature sets then a simple dynamic language).
Few people would call python or ruby low level compared to java and if people were forced to target a python or ruby vm its hard to imagine that a java to python/ruby compiler would become as popular as gwt.
In closing javascript has an image problem(people sometimes think of languages as getting more difficult as they become more low level and vice versa).