Given that WASM reached MVP in February, has anyone spent any time trying to work through the viability of using WASM to actually learn / teach higher level aspects of assembly with WebAssembly?
After going through a bit of material, it seems that it's still aimed at C/C++ development (perhaps due to the potential state of flux that still exists?) and there is no real material that talks about using WASM directly as far as learning assembly programming principles.
WASM is (at least could be) uniquely suited to learning, and teaching, assembly itself in a very universal manner that could later be extended to specific hardware, if desired. Learning WASM itself could be valuable for the general effort going forward and writing interesting and uniquely optimized programs.
It might even be neat to see interest in things like the old demo scene resurrected with WASM...
I'm not sure if Wasm is ideal for learning first things about assembly language. While it distills many of the basic operations available in modern CPUs, it also is a somewhat more high-level abstraction. For example:
It is a stack machine.
It has an infinite set of virtual registers.
It has structured control flow.
It provides no access to the stack.
It provides no access to code.
It is typed.
It will probably gain other more high-level features in the future.
Many of these are prerequisites to making Wasm safe and portable, which in itself is very unlike ordinary assembly languages.
(I happen to agree with those who say that "WebAssembly" is a bit of a misnomer -- both the "Web" part and the "Assembly" part, actually. It was a play on JavaScript previously being called "the assembly language of the web" for its ubiquity.)
WASM is just like regular processor assembly, but... for web :-) The same way 99.9% of people don't need to learn assembly if they don't want to, one doesn't need to learn WASM.
WASM will be very useful if you wanna jump into low level stuff and especially if you will deal with compilers. WASM will be a convenient way for someone to port, for example, the backend of a C++ compiler to work in the browser. So the same GCC/LLVM you compile to x86/x64/ARM/etc, will be able to compile for web as well.
Notice that besides the name Web "assembly", this has not too much to do with CPU architeture like x86 or x64. So "learning assembly with WASM" doesn't need one will be learning the "bare metal". Sometimes can be a little confusing.
Related
I'm wondering how much benefit a CRUD-centric web application can benefit from Haskell's type system, particularly when the front end is built with a Javascript MVC framework like AngularJS which passes around typeless data objects.
It seems to me that as soon as you transform Haskell datatypes into JSON objects which you pass to a heavy JavaScript MVC framework layer, the benefits of having Haskell's type system as part of the web stack start eroding dramatically, as there is no way to let the type checker ensure the type-integrity of the data flow through the whole web application.
For example, you could change the database schema and the associated Haskell types, but the type checker won't be able to tell you what parts of the JavaScript MVC front-end need updating as well. I see this as a problem.
Am I stating the problem correctly, and if so, what advice could Haskell web application developers give on this point?
We've been wrestling with this exact same question quite a bit since we recently started a project with a substantial javascript front end. My anecdotal observation has been that we have a lot more bugs in the javascript application than we had with previous applications that just used Snap and generated HTML with Heist. We haven't decided on anything yet, but here are some of the possible solutions we've been considering:
Thin Javascript Wrapper
CoffeeScript
TypeScript
Dart
These are pretty unsatisfying solutions to me. The improve slightly on Javascript, but don't come close to giving me the things that I get with Haskell.
Much more functional and type safe front-end language
Fay is a proper subset of Haskell that compiles to Javascript. It definitely has some appeal, but doesn't give you access to all of Haskell. Last I heard it didn't support type classes, which I imagine would become an obstacle pretty quickly.
Elm
Roy
The problem with these solutions (as well as with the previous group) is that if your back end is written in Haskell, you still have the impedance mismatch because your front end language is not Haskell. This makes your code less DRY because you have to end up defining the same data structures in Haskell and the front end language. And when you change them in Haskell, you don't get errors indicating where your front end code needs changing. The app just breaks.
Compile Haskell to Javascript
The new game in town here is ghcjs. This is a very promising project, but I don't consider it to be viable for production at least until GHC 7.8 is released. That will hopefully happen within the next week. Once 7.8 is out the door, you still have to take into consideration that ghcjs is still very new. And even in the hypothetical scenario that it was 100% feature complete and the first release worked perfectly, you still have to remember that a fair amount of infrastructure has to be built before Haskell+ghcjs is as effective as high level javascript frameworks like Angular, Ember, etc.
UPDATE September 2016: Now, almost three years after I originally wrote this answer, GHCJS has improved greatly. There is still room for more improvements, but I have used it for production applications and it worked very well. It's especially powerful when combined with the Reflex FRP library that makes it much easier to build reactive UIs.
Generate Javascript from Haskell with an EDSL
If you have a relatively constrained problem, it might be possible to do all your application work on top of an EDSL that generates javascript. We already have the fantastic jmacro package to take care of the low level concerns of generating Javascript. You could leverage that and generate code that uses whatever other javascript libraries are appropriate for your application. That could be javascript + jquery, D3.js, or even code using a higher level javascript framework like Angular or Ember. I tend to think that Angular would be much easier to generate code for than Ember because of its simplicity and stronger encapsulation.
Greenfield a bytecode VM designed for functional languages in the browser
This is just a pie in the sky idea of mine. I don't think it's really practical because it would take a huge amount of work and be very difficult to gain adoption. But I like to at least mention the idea for completeness. Others have pointed out that asm.js is almost like this already. That may be the case, but it would be nice to have things like tailcall optimization designed into the VM level from the start.
In my opinion, easy solution - generate typescript interfaces from haskell data declarations(or another api scheme descriptions) and use TypeScript for front-end part.
it gives the opportunity to work on a project for people who do not know haskell, but who knows Javascript.
For example
data RpcResponse = RpcResponse { number :: Int, string :: Maybe String }
compile to
interface RpcResponse {
number : number,
string?: string
}
and function parseRpcResponseJson has Typescript type
parseRpcResponseJson(response: string): Option<RpcResponse>;
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.
Assuming a team of developers are equally comfortable with writing Javascript on the server side as they are with Python & Twisted, when is Node.js going to be more appropriate than Twisted (and vice versa)?
Twisted is more mature -- it's been around for a long, long time, and has so many bells and whistles as to make your head spin (implementations of the fanciest protocols, integration of the reactor with a large variety of other event loops, and so forth).
Node.js is said to be faster (I have not measured it myself) and might perhaps be simpler to use (if you need none of the extra bells and whistles) exactly because those extras aren't there (kind of like Tornado in the Python world -- again, I have never measured relative performance).
So, I'd absolutely use Twisted if I needed any of its extra features or wanted to feel on a more solid ground by using a more mature package. If these considerations don't apply, but top performance is a key goal of the project, then I'd write a simple benchmark (but still representative of at least one or two key performance-need situations for my actual project) in Twisted, Node.js, and Tornado, and do a lot of careful measurement before I decide which way to go overall. "Extra features" (third party extensions and standard library) for Python vs server-side Javascript are also much more abundant, and that might be a key factor if any such extras are needed for the project.
Finally, if none of these issues matter to a specific application scenario, have the development team vote on relative simplicity of the three candidates (Twisted, Node.js, Tornado) in terms of simplicity and familiarity -- any of them will probably be just fine, might as well pick whatever most of the team is most comfortable with!
As of 2012, Node.js has proved to be a fast, scalable, mature, and widely used platform. Ryan Dahl, creator of Node.js quotes:
These days, Node is being used by a large number of startups and established companies
around the world, from Voxer and Uber to Walmart and Microsoft. It’s safe to say that
billions of requests are passing through Node every day. As more and more people
come to the project, the available third-party modules and extensions grow and increase
in quality. Although I was once reserved about recommending it for mission-critical
applications, I now heartily recommend Node for even the most demanding server
systems.
More formally, the advantages of Node can be classified as:
Great community: It can be said that no other platform gained such community appeal in such a short period of time, it has hundreds of contributors and thousands of watchers in GitHub, and is being used by giants like Yahoo! (Manhattan project), e-bay, LinkedIn, Microsoft, and Voxer.
NPM: Although having a relatively small core, Node has lots of packages available to extends its functionality to anything you may consider! Its all automated and being developed and extended actively, think of PyPI (pip).
Scalability and Speed: Node's architecture and single threaded nature allows high scalability and speed. Specially after 0.8 release, its speed got really faster (benchmarks), which can be confirmed by a lot of large businesses using Node. The V8 core of it is also constantly getting better thanks to the current browser war.
JavaScript: The core language of Node (JS) fits better for such server side usages, specially lambda functions, dynamic objects, and easy JSON serialization are JS highlights which really fits well in cases that speed and scalability counts. (Python has all of them but these are really better and more powerful in JS).
Deployment: Because of its wide usage, a lot of really good sites provide tools for easy and powerful Node deployment, including: Heroku, Joyent, Cloud9 and a lot more.
Therefore, Node seem more powerful and with a lighter future, so if there isn't any constraint to use it (like existing code, servers, team capability), it is recommended for any new collaborative network project aiming high speed and scalability.
Recently there is a lot of projects that pushes Javascript into other directions: as a general purpose scripting language (GLUEScript, Rhino), as an extension language (QTScript, Adobe Reader, OO Macros), Widgets (Yahoo Widgets, MS Gadgets, Dashboard), and even server-side JS & web frameworks (CommonJS, Helma, Phobos, V8cgi), which seems obvious since it is already a language widely used for web development.
But wait, everything is so new and nothing is really mature. However JS is around for almost 15 years, being as powerfull as any other scripting languages, being standardised by the ECMA, and being a mandatory technology for web development.
Why did it take so much time to gain acceptance into other domains than web browsers?
Douglas Crockford, who has done much to help people use JavaScript productively, also has a very clear picture of the things that hold JavaScript back. You can pick up a few of the points at JavaScript: The World's Most Misunderstood Programming Language. See also his lecture series Crockford on JavaScript.
The proliferation of Javascript as a viable language for heavy applications development isn't as old as the langauge itself... atleast it's definitely more recent than 15 years.
Mainly, it's popular and heavily-utilized right now due to the proliferation of AJAX and frameworks like jQuery/mootools/protoypes/scriptaculous and largely because browsers support is improving in compatibility, performances and whatnot.
Take, for example, Node.js which is built on V8 (which didn't exists until Google made Chrome) which strikes up the javascript performance bar so high that you can make high-performance networked applications on top of it dead easy.
So, IMO, it's because people jumped on the AJAX bandwagon that made JavaScript now suddenly becomes so much more awesome and spanning out to other areas.
There are some big flaws in the language surrounding code reuse - in particular, all code is executed in a single namespace, and there's no language-level support for importing other code. Plenty of enterprising library authors have worked around this on the client-side, due to necessity, but these problems are big ones to avoid when implementation choice is a language.
There is also not a single standard implementation of the language - Rhino is the most prominent, but it's not the most advanced in the days of SpiderMonkey, JavaScriptCore and V8. This shouldn't be as much of an issue with a standardized issue, but there's still a problem that non-browser JS code is unlikely to work with all JS engines, and very likely to be targeted to a single engine (Node.js depending on V8 is the most prominent example of this).
These problems have kept JS libraries from being written outside the browser, and since nobody writes non-browser JS libraries, writing non-browser JS becomes that much more difficult.
Things are changing - in particular, the CommonJS group has created a module spec that allows for better code reuse, which is already being used in Node, and are working on better specs for packaging JS code.
Language adoption is as much about the auxiliary libraries as it is the language itself. In the case of Javascript, there's a dearth of libraries for doing things like I/O and other standard requirements for fully-fledged use.
8 years ago I tried to have a brief look at JavaScript to see if I should learn more or not about it. I didn't. Why? I thought it would die within 2-3 years.
But thanks to JQuery and other JS frameworks it has gained very much reputation the last couple of years.
It's also associative. Do cars drive on water, do airplanes land on highways? JavaScript have always "belonged" to browsers, even though you could use it for non-browser related stuff.
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).