Its a pity that javascript is so in-grained in client-side web now, as its really a terrible bytecode... Hell, failing the above, I would have liked to see Lua as the default client-side language, rather than Javascript (for reasons I will mention shortly), but of course that will never happen now that Javascript has been the default for fifteen years.
The reasons I would like Lua as the default language, besides the fact that LuaJIT is very fast (certainly for number crunching code, especially if you use the FFI to operate on low level structs (I mean, without calling into C) - the FFI is also one of, if not the, simplest FFI I've seen in any language[1]), it is, at least under my impression, a much more consistent language, while being just as flexible, easy to learn and dynamic. The thing I dislike most about Javascript is that it has lots of little gotchas and inconsistencies. Having said that, though, perhaps Lua does too and I just haven't used it enough yet to get bitten by them. Then again, it didn't take long for this to happen in Javascript, so Lua does at least seem to be a little friendlier.
[1] Actually, I think Factor's FFI is similarly simple, if my memory serves me correctly
That said, I'd give a higher priority for the language in my browser to be safe: some kind of correctness guarantee would be nice. Or even, while we're at it, some kind of way to analyze the script and say "this script GETS from urls x,y, and posts data d to z"
local ffi = require("ffi")
int = ffi.new("int")
int = 10
print(int)
fsm = my_dsl[[
start: foo
stop: quux
foo -> bar
foo -> baz
bar -> foo
baz -> quux
]]{ foo = function()
code for foo here
end,
bar = function()
code for bar here
end,
baz = function()
code for baz here
end,
quux = function()
code for quux here
end
}
fsm.run()
DEFINE(Traits.Position)[[
float x;
float y;
float z;
]]
DEFINE(Traits.Movement)[[
float x;
float y;
float z;
]]
DEFINE(Behaviors.do_movement){
input={Traits.Position, Traits.Movement},
output=Traits.Position,
frequency=0.01,
-- Update entities position
fn = function (pos, mov)
local delta = dark.timedelta
new_pos = Traits.Position.new()
new_pos.x = pos.x + (mov.x * delta)
new_pos.y = pos.y + (mov.y * delta)
new_pos.z = pos.z + (mov.z * delta)
return new_pos
end}
-- Create a sample entity
local entity = Entities.new()
entity.add(Traits.Position, {1.0, 0.0, 0.0})
entity.add(Traits.Movement, {0.0, -1.0, 0.0})
I definitely agree with the above.
Gilad Bracha complains about this at http://gbracha.blogspot.com/2011/03/truthiness-is-out-there....
I'm beginning to believe NativeClient and PNaCl (LLVM on NaCl: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf) has the best shot at becoming this.
Google is already including NaCl in Chrome developer builds, so I wouldn't be surprised if they enabled it in releases by the end of the year, and started releasing Native Client applications soon after.
http://blog.chromium.org/2011/02/native-client-getting-ready...
Hopefully this was an inaccurate impression, because NaCl could have a huge impact on both the client and server
The best path to adoption would be for Google to very aggressively push NaCL as a Flash-like plugin. If they could get adoption -- through Unity3d on Facebook or something like that -- perhaps they'd win in the long run. If they just keep it part of Chrome it seems rather hopeless.
The problem is not that NaCl is insufficiently secure, but any vulnerability will be spun as "Google making your system insecure". I think an independent group doing the same thing would be no more or less secure, but wouldn't have the baggage that would come from being seen as a component of a much bigger entity.
Me too, although the biggest hurdles seem as much political as they are technical.
My hope is that Google can strong-arm NativeClient into active use, forcing otherwise recalcitrant browser makers (Mozilla, Apple, Microsoft) into adopting it.
I won't get into the details because there's tons of information out there (http://www.chromium.org/nativeclient/reference/research-pape...), but code must be compiled using a special NaCl compiler, then before it's executed the client runs it through the NaCl verifier to ensure it's safe to execute.
Of course it's possible there are bugs in NaCl, but Google won't enable it in Chrome by default until they're very confident it's secure.
It's possible that the design could be flawed, but the same is true for browser implementations and mobile application sandboxing.
1. More language independence
2. Great performance for games, video (think implementing codecs without the need for browser support), and for crazy things like this.
3. Most importantly, the ability to run actual desktop-like apps in the browser at near-native speeds, instead of the mess that is currently required to get web apps to behave like desktop apps. (Nowadays Rails and friends are hiding most of this mess, but it's still there.)
Strange that people actually think Java would be the saviour. Feel free to keep continue to use Java applets if you think they're superior tech, they should still be well supported.
1. When a user starts loading a page (read 'web app') the browser spawns a new JVM for that page. How long does this take? You can bring it down to the price of a fork if you keep a JVM running at all times.
2. Instead of running javascript that's embedded in the page, you compile and run Java/JRuby/Jython. Better yet -- have the server precompile the embedded code and send you the bytecode. Load it dynamically into the JVM and run it in the page's thread. With a modern JVM you get JIT for free and the code runs at near-native speeds.
3. Want long-running background tasks? No problem -- the JVM code can start its own threads. Suddenly AJAX, and all the other stuff we use to make web apps behave like desktop apps becomes trivial.
4. User leaves the page / web app? Kill the JVM.
You can actually call methods in a Java applet from Javascript and vice-versa. It just doesn't seem to be used very much:
http://download.oracle.com/javase/tutorial/deployment/applet...
> time java HelloWorld
Hello, World!
java HelloWorld 0.28s user 0.06s system 135% cpu 0.248 total
* Takes way too long to load the JVM. Deal-breaker for many sites.
* Horrible (AWT) and complicated (Swing) UI toolkits that ignored any look-and-feel parity with the rest of the web site or even the web browser itself.
* The environment is controlled by Oracle. I don't think they're looking to compete with JS, Flash and Silverlight. Thus web applets (except for niche internal apps) are dead, RIP.
It's called the desktop and offers all the native and low-level stuff you can possibly imagine.
And the only people that want to see it, are the ones who have forgotten about it.
Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.
Actually, I'd say it's called 'mobile'; The desktop failed to solve the sandboxing problem.
> And the only people that want to see it, are the ones who have forgotten about it.
As a desktop-turned-mobile developer, I haven't forgotten anything.
Simply put, I want a future in which we aren't forced to re-implement our applications multiple times for disparate, proprietary mobile platforms.
I already lived through that on the desktop. The only reason I haven't embraced the web for application development is that the technology stack is, by comparison, hobbled.
> Maybe there is a middle ground between desktop software and browsers, but personally I'd like to keep them apart.
Treating the browser as the sacrosanct temple of HTML, CSS, and JavaScript is throwing away the limited opportunity browsers have to pre-empt Android and iOS as a first-class, standardized application platform.
1. The function of the desktop, the browser, and the mobile is not the same thing.
2. Desktops have not failed, as you claim, in sandboxing/security/virtualization; (especially when compared to browsers).
3. Turning the browser into the desktop (low level APIs), is in turn re-implementation of the desktop.
It wouldn't suck.
It seems that the plan for Qt 5 is to move the enitre Qt toolkit over to the "QML first" model - that is, QML becomes the default way to create interfaces, for both mobile and desktop apps, and native widgets are only used when you require them. They also want to better integrate webkit and web content. In a recent Qt desktop app of mine, I was already doing this: QML + webkit + native backend for the heavy lifting and it works very well. Be awesome to have it as the default in all environments.
FWIW, I think QML/JS would have made a greate HTML/CSS/JS alternative.
The HTML/CSS/JS dev model is fine as it is, there's no need to hope for nirvana grass-is-greener frameworks that don't exist. Learn HTML5 like the rest of us.
Web apps more or less solve all these problems (code can't be completely browser-agnostic, but it's close). Why not add also the benefits of desktop apps?
However, with more high-level code, in general there shouldn't be such a need. For example, RPython is very high-level, but is compiled into very efficient C. The same could be done for JavaScript (and to some degree already is).
The part I don't understand is, what environment does the Kernel need to think is there, and how is that done in JS?
- Loads the linux binary and the root memory disk image into 'memory' at the expected addresses (0x100000 and 0x400000, respectively)
- Sets the interpreted x86 CPU's EIP to the kernel's entry point
- Initializes additional requisite register state
- Starts execution.
Take a look at load_binary() and start() functions.
[edit] rickard already discussed this here: http://news.ycombinator.com/item?id=2555552
Fabrice uses this to implement an x86 interpreter -- it could not be done efficiently without typed arrays. However, it is still slow -- imagine what kind of advances could be made if a common bytecode was established that would be JIT'd by the JavaScript VM, and could be output directly by the emulator.
This is why so many people want to see the browser execution environment offer more complete, low-level APIs instead of high-level APIs locked to HTML/CSS and legacy browser technology. Efficiently supporting high-performance, high-complexity systems such as an x86 emulator (or a video game, or custom font rendering, or even an application framework) absolutely require efficient low-level APIs.