OSX has a larger userbase of Plan9 fans, I think, including a number who run plan9port on it (Rob Pike has said that he uses such a setup). So the bits that you can't get Plan9-ish might rankle someone. Windows isn't any better, but there aren't many people trying to make Windows feel anything like Plan9 in the first place, so nobody's too disappointed about it.
My current obsession is finding a way to filter an image to display using the sharp MZ-series character set:
http://www.sharpmz.org/mz-700/codetable.htm
Very interesting symbol table for its time. Japanese so, it's like they always wanted emoji.
Yep. just compile it to javascript/asm.js and you get basically native speed, same security sandbox as javascript, and all the same problems with the web; the vast majority of which have absolutely nothing to do with javascript.
While I believe you are correct in that supporting more languages by won't fix the issues people have with developing for it as they would really want the APIs/frameworks for those languages and in that regard compile to JavaScript tools would better serve them since the only secure way to give developers multiple API's to work with is through a translation tool.
But several people seem to insist that's a poor solution. It sounds like they want direct support for other languages in the browser but how can they securely directly support other languages?
Yes, wanting some other language in the browser is a very common wish on hacker news. It's just completely and utterly impractical in real life.
Even if you found some way to get some other language into the browser without translating to javascript; (and this has been done before. remember vbscript?)...
the new guest language has to co-exist with any javascript that might also run on the page, share the same memory, share the same dom objects, share the same GC, and avoid all the multiple potential nasty browser crashing bugs that could result from trying to do that. And you have to ship the runtime for that language along with the browser, or as sigh another plugin. And guess what, no backwards compatibility.
Given that, you then have to cope with the fact that javascript's GC might not totally make sense for your language, and do all the workarounds that requires.
Compiling to ASM.js gets around this by essentially giving you a low level VM whose bytecode just happens to look like javascript, and whose behavior when interpreted as javascript happens to be correct. When run in firefox, the code is short circuited and ahead-of-time compiled. It doesn't have to deal with the javascript GC since it allocates a heap for the guest program ahead of time as well.
This is really cool if you think about it. You get javascript's more or less secure sandboxing, you get access to all the apis, you can interact just fine with existing javascript libraries, with about the lowest amount of overhead you can get just short of the NaCl approach (which is basically just a revisit of activeX)
The only downside to all this:
it's not the web.
This is not web. It runs in a web browser, but it's downloading a blob up front, ahead of time compiling, and playing a raw executable inside a browser host.
There's considerable advantages to zero-install programs and games. But you know, exchanging one kind of opaque inaccessible blob in a webpage for a different kind that just happens to not need plugins is not that great.
Accessibility is a good thing, and we shouldn't be too eager to throw it away for the shiny.
the performance and memory bottleneck in the web is not, as it is commonly believed, javascript, or html.
It's the increasingly complicated DOM, and CSS3 layout model.
Web Apps go slow, and this gets blamed on javascript because that's the language you happen to be writing in. (or wronging in). But the slowness you get usually comes from the constant triggering and retriggering of giant byzantine relayout and compositing algorithms from what you might think is reasonably written code.
it's THAT problem that facebook's react library is aimed at... fixing? no, reducing. Write reasonable JS, and let the library optimise DOM interactions.
Every new feature of HTML5 and CSS adds some weight to those enormous piles of sand the browser has to shift around.
Binary formats would not fix that. Bytecodes wouldn't fix that. Different languages wouldn't fix that. Javascript is fine. it's the DOM and CSS that need to be fixed.
33k sounds like a lot.
I should think a game like this today would be more like 3k, or maybe 10k at most + engine code + content.
Nowadays you see, it's wasteful to write an engine from scratch for a game like this. It was needed then, but it's a solved problem now. If you wrote 33k for a commander keen clone I'd wonder what you were doing.
This is a philosophical problem.
What is the difference really between:
1. a prewritten engine, and
2. some hypothetical language
each where you write commander keen with 3k loc.
Where the hypothetical language has all the same stuff as the engine, it's just locked away behind a level of abstraction.
if you could write commander keen in 3k of javascript (with the aid of all the stuff that's in a browser) How is that different from writing 3k of C with nothing but this entire commander keen engine already written and ready to go?
But isn't it interesting that people would find that easy to use, despite being modal? This suggests that the conclusion from the article - to avoid modes - misses the point.
imo not any more than hitting ctrl-f in notepad to bring up the search dialog is a mode trigger. Meaning I guess technically it is one but I don't parse it as such.
Note that on Mac and Windows, at least, you can trivially do this remapping. I do it on all my computers.
On a Mac, the keyboard preference pane in system prefs has a "modifier keys" section, which is bizarrely separately configurable for the built-in keyboard vs. a USB keyboard on their laptops. On Linux, the configuration is different for the VT vs. window managers.
It's configurable per-keyboard because not all keyboards have modifiers laid out the same way. Mac keyboards have the bottom row ordered Ctrl, Alt, Cmd; Windows keyboards are ordered as Ctrl, Win, Alt. So, if you're using a Windows USB keyboard on an Apple laptop, you'll often want to swap Cmd (= Win) and Alt on the USB keyboard, but leave them alone on the internal one.
I thought for a moment you'd "stolen" my idea. (stolen in quotes, because I never told anyone, and ideas can be arrived at independantly, why not?)
The idea I had was extending ansi codes to contain specific instructions for NES graphics hardware, along with a special NES rom that could decode them from say, some audio signal via the microphone port, or controller port 2 keys, or whatever input is most convenient.
Such an ansi protocol extension would include things like sprite graphics, tile graphics, sprite positions, in addition to the normal character mode telnet stuff that maps naturally to the NES's tile based background graphics.
That would be pretty neat.
It would let you put a modem attachment on an NES and dial into a server to play games remotely. Such games could even be multiplayer by nature, with a centralised server infrastructure kind of thing.
You can steal it now if you want. I'm not likely to act on it any time soon.
