Coding Emacs's M-x in Lisp - <AUTHOR> http://aaronhawley.livejournal.com/26901.html

<comment><USER2> I don't know about anything Emacs internals but what a strange remark: "I recently wanted to change how `M-x' works. The command behind it is called `execute-extended-command'. It is written in C. This is disappointing for my desires to tinker, but not all together surprising either. It is a pretty central piece of the Emacs infrastructure."

It being a central piece of infrastructure I would expect it to be written in a higher level language for better maintainability.

<comment><USER3> But since it is a pretty stable and simple structure it is written in a lower level language for either stability or performance or opacity.

</comment></comment><comment><USER4>
        (if (and (not (null suggest-key-bindings))

My C-oriented brain screams bloody murder at this. (I still want to learn Clojure.)

<comment><USER5> It's because you are missing the other part of the and

      (if (and (not (null suggest-key-bindings))
               (null executing-kbd-macro))

      if(not(null(suggest-key-bindings)) && null(executing-kbd-macro))

Does that help?

<comment><USER4> No. I mean, I understand it just fine, I just hate the structure of it. Something about it causes revulsion, something that would probably go away if I actually sat down and learned lisp.

<comment><USER5> you'll end up with the inverse problem when you go back to infix notation though - be warned! when I see func(arg) I feel like I am on the inside of a star fruit.</comment></comment></comment></comment>


Gap between asm.js and native gets narrower with float32 optimizations - <AUTHOR> https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/ <comment><USER2> The original blog post is well worth reading:

[https://hacks.mozilla.org/2013/12/gap-between-asm-js-and- nat...](https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native- performance-gets-even-narrower-with-float32-optimizations/)

</comment><comment><USER3> Oh look another JS vs native benchmark...

I still think we're missing the point; we're focusing on the wrong benchmarks. We're putting too much emphasis on JS speed, when in reality most web apps are behind native because of lack of (perceived) graphics performance.

The shortcut out of this requires a greater variety of GPU-accelerated CSS transitions/DOM changes, as well as easier computations and DOM manipulations off the main thread, which cause horribly noticeable UI hiccups. Web Workers are still too primitive (e.g. no DOM access whatsoever) and slow (e.g. no shared memory).

Not saying it's unimportant to improve JS's CPU performance; just saying that we're focusing too much on the wrong battle in the war against native.

<comment><USER4> WebGL anyone? This is what does most of the heavy lifting in the main asm.js use case: games.

I am still waiting to see a UI framework built using asm.js and WebGL. Maybe even a existing native framework ported over, something like WPFe(Silverlight) might be about as difficult as a game engine to port.

Asm.js still has no solution to shared memory threads, which will be an issue for any modern game engine I would imagine.

<comment><USER5> >Asm.js still has no solution to shared memory threads, which will be an issue for any modern game engine I would imagine.

This feels to me like the elephant in the room, not just for asm.js, but for JS in general. We have Web Workers, and that _sounds_ like a solution, so it dampened the discussion of parallelism on the web. But in a _lot_ of situations, Web Workers just don't cut it. Copying memory back and forth is just too inefficient.

<comment><USER4> I agree, I can appreciate the idea of share nothing threading(web workers) which is more like multi-process rather than multi-threading, it's probably the better model for much of the threading use cases out there. However there are performance critical scenarios where lightweight shared memory threads will always win and will be required if it is to be a valid compile target for c/c++ coded bases.

<comment><USER6> If there's a way to do zero-copy message passing in web workers (or equivalently, overhead-free transfer of object ownership between threads), shared memory may be unnecessary.

<comment><USER7> This is available in recent versions of Chrome and Firefox, on the form of Transferable objects: [https://developer.mozilla.org/en- US/docs/Web/API/Transferabl...](https://developer.mozilla.org/en- US/docs/Web/API/Transferable)

<comment><USER5> That helps, but it still means you can only have the data on one thread at a time. What would be a _massive_ help would be if you could split a buffer into non-overlapping views, and transfer each view to a separate worker. Some algorithms would still be challenging or impossible to implement this way, like parallel prefix sum algorithms, but it would still greatly widen the number of things you could do in parallel.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Some thoughts/questions about asm.js

1) I understand the C/C++ -> LLVM -> Emscripten -> asm.js process. But I heard they're also working on supporting GC languages (like Java and Go). How would this work exactly? Wouldn't they first have to port the entire JVM or Go runtime into asm.js? And every time a Java/Go -> asm.js program is downloaded, it would basically also download the entire JVM/Go runtime as well?

2) Would it be possible to use GUI frameworks (like Qt for C++ and maybe Swing for Java in the future) to build GUIs and directly output to canvas?

<comment><USER9> Qt running in the browser :

[http://badassjs.com/post/43158184752/qt-gui-toolkit- ported-t...](http://badassjs.com/post/43158184752/qt-gui-toolkit-ported-to- javascript-via-emscripten)

JVM running in the browser :

[http://plasma-umass.github.io/doppio/about.html](http://plasma- umass.github.io/doppio/about.html)

Anything is possible in the browser.

<comment><USER10> Anything is possible in brainfuck too. You can also do all your coding in just C++ templates.

Doesn't make it a good idea.

<comment><USER11> Yes, if only using the browser as a platform also had other benefits... Oh, wait!

<comment><USER10> I fail to see the benefit of building a jvm to run in a javascript engine.

I would rather see effort to develop a better language than JS for the web. Now someone will bring up emscripten and dart...

<comment><USER11> > _I fail to see the benefit of building a jvm to run in a javascript engine._

That's because you picked a very specific example to suit your argument.

How about seing the benefit of building games to run in the browser with near native speed? Or something like Mathematica? Or an image editor, etc etc...

</comment></comment></comment></comment></comment></comment><comment><USER12> The article doesn't have much depth, unfortunately. I like asm.js but I'm still hoping for Dart support in Firefox and other modern browsers.

<comment><USER13> AFAIK, Dart can run on bare JS without any extra support.

<comment><USER14> Dart2js does not currently implement the whole language. Integer/float semantics and support for large integers don't work (it seems like they didn't implement them manually, so it just falls back to doubles?), and there are probably other things I don't know about missing.

I should point out that emscripten and many other JS-targeting compilers (like JSIL) emulate int64 semantics directly so that apps using them _do_ work. It's kind of strange for the Dart team to have not gotten this right yet when Dart is at 1.0.

<comment><USER15> > Integer/float semantics and support for large integers don't work (it seems > like they didn't implement them manually, so it just falls back to > doubles?), and there are probably other things I don't know about missing.

That's going to be really unfortunate if pages start relying on the proper behavior and become Chrome-only as a result...

<comment><USER16> That's not really the problem. Web developers have learned from the past and don't just build web-pages for one browser only. On the contrary... Developers now sometimes need to support outdated browsers with little market share (IE8 for example), instead of actively pushing the users to upgrade.

The discrepancy between Dart and JS numbers is mostly an issue for the developers. When they deal with numbers in specific ranges, they need to run dart2js more frequently (to test if their code works) instead of relying on Dartium (and its F5 development cycle).

After 2 years of Dart development, numbers have rarely been an issue in practice. Developers know when they deal with numbers > 32/53bits and work around it.

<comment><USER17> Web developers know too well the trap of testing only on one browser, which when Dart comes to Chrome, will be Chrome. Testing all input data in a space that exceeds the integral domain of double is hard. Murphy says there will be bugs in other browsers when one's app tests "work in Chrome".

For a wannabe-cross-browser, wannabe-standard (Ecma has a sorry history of proprietary standards: C#, OOXML) language pushed by a super-rich big company with what? 60 or more engineers on the project, optics must matter. Why not fix the bignum-not-emulated-in-JS bug? It's easy, GWT has BigInteger emulation code in JS lying around the Googleplex. Just plug that in if the code needs it.

The obvious risk remains what I cited in HN two years ago: Google letting dart2js be sub-standard, using all its strength and leverage to promote Dart in combination with DartVM, letting users of other browsers "blame their browser" when things don't quite work as well as in Chrome.

Given market share among browsers currently, I think this will backfire, but it could inflict collateral damage too -- on developers as well as on users. And it just plain looks bad. People expect better of Google, and they ought to.

/be

<comment><USER18> You must realize how different the situations are between Java BigIntegers and Dart integers.

<comment><USER17> Please, inform me, if you are not trolling on the cheap.

[https://www.dartlang.org/articles/numeric- computation/](https://www.dartlang.org/articles/numeric-computation/)

[http://docs.oracle.com/javase/7/docs/api/java/math/BigIntege...](http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html)

Both arbitrary precision immutable integer types. If some corner case differs, my point stands. Google has more than enough engineers on Dart to do the work of writing a bignum library in JS, if they can't find one to use that someone already wrote.

/be

<comment><USER18> I'm definitely not trolling. I truly thought you would understand the basic difference.

Big integer support in Dart is not an issue of writing a bignum library. That's already been done. The difficulty is in supporting the single integer type in a way that's performant for numbers < 2^53

Java has fixed width ints, Dart has infinite precision ints. In Java when dealing with ints, you're always in the int domain, and when dealing with BigIntegers you're always in the BigInteger domain. In Java operations on ints can overflow. In Dart operations on ints don't overflow - internally, if the result doesn't fit in an machine int a bigint is returned.

In JavaScript you have a few choices when implementing infinite precision ints: 1) Use a single bigint type for all ints, which will be incredibly slow. 2) Use two types for ints, the built-in number and a BigInteger class. This means a lot of expensive type and overflow checks that slow down basic numeric operations. 3) Don't implement infinite precision ints.

Compile-to-JS languages can use static analysis to do better. dart2js already uses type inferencing extensively to eliminate type checks where it can, but eliminating the checks for ints would require range propagation which is much trickier, and doesn't work in a lot of cases.

<comment><USER17> "I truly thought" you would not raise a question to which V8/Dart people already know the answer. Range prop is not the only solution.

Use JIT techniques to speculate profitably that most ints fit in JS doubles. This can be done in JS-hosted VMs, just as in machine-code-generating native VMs.

Again, this is extremely old hat to the Dart/V8 folks. See, e.g.

[http://mraleph.tumblr.com/post/24351748336/explaining-js- vm-...](http://mraleph.tumblr.com/post/24351748336/explaining-js-vm-in-js)

In SpiderMonkey, we augment JIT techniques with online type inference that distinguishes int from double. The same type inference could add bignum to the speculative tower. See

[http://rfrn.org/~shu/drafts/ti.pdf](http://rfrn.org/~shu/drafts/ti.pdf)

This avoids most of those checks that you _assume_ are too expensive (and by assuming, so casually fork Dart semantics).

Here is a JS version of [Hackett&Shu, PLDI 2012], from @pcwalton:

[https://github.com/pcwalton/doctorjsmm/](https://github.com/pcwalton/doctorjsmm/)

Can the full JIT+TI approach to bignum/double/int perform well enough for dart2js? Better find out, because forking semantics is just the wrong thing.

Another road not taken: we hear "can't wait for JS to get better", but Dart started at least by 2010, possibly earlier.

[http://wiki.ecmascript.org/doku.php?id=strawman:bignums](http://wiki.ecmascript.org/doku.php?id=strawman:bignums)

could have been proposed and actually worked into ES6 by now, but the Dart team was in stealth mode (Dash) for too long. Still, better late than never. There's time for ES7. Who from Google will actually do the work in V8 and with Ecma TC39?

/be

<comment><USER18> This is sounding less and less like just plugging GWTs BigInteger implementation into Dart, which is exactly my point when I said you must know the difference.

<comment><USER14> Using a GWT BigInteger for all dart2js integers would work just fine and provide correct semantics, but if it doesn't meet their performance bar, that's a failure of design - not an excuse for cutting corners and shipping a dart2js that produces wrong behavior.

This could have been accounted for with a better language design, but it wasn't.

<comment><USER17> Could have been accounted for in language design, dart2js effort, bignums-for- JS effort, or some combination of the last two. I don't want to assume a conclusion, but the lack of a fix for [http://code.google.com/p/dart/issues/detail?id=1533](http://code.google.com/p/dart/issues/detail?id=1533) is a problem, even if there's no immediate fix. It is fixable.

/be

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> I wouldn't say asm.js is a spin-off. In fact it's a strict subset of JavaScript, though designed to be used as a compiler target rather than directly coded. The web browser can then execute the code in a highly optimized (hopefully, eventually near native performance) fashion.

Brendan Eich talks a lot about this in a recent presentation: [http://www.infoq.com/presentations/web-evolution- trends](http://www.infoq.com/presentations/web-evolution-trends)

<comment><USER20> How is it a strict subset when they already added Math.imul and now Math.fround?

<comment><USER15> Math.imul and Math.fround are in the ES6 draft, which has consensus and cross- vendor support: [https://people.mozilla.org/~jorendorff/es6-draft.html](https://people.mozilla.org/~jorendorff/es6-draft.html)

<comment><USER20> As in, not in IE 11?

<comment><USER15> I see no indications that IE will not implement ES6, as they're on the committee and participating.

</comment></comment></comment></comment></comment><comment><USER21> Are we calling asm.js a "spin-off" now?

<comment><USER22> Yes, "spin-off" is not a good description. But I guess the article wanted to make things less technical in the title.

</comment></comment><comment><USER23> The reason this improves performance is documented at [https://blog.mozilla.org/javascript/2013/11/07/efficient- flo...](https://blog.mozilla.org/javascript/2013/11/07/efficient- float32-arithmetic-in-javascript/) \- float32 typed arrays and more efficient emulation of C++ float32 arithmetic seem to be the main things.

</comment><comment> alok-g Could someone please explain me where mankind is going currently in software development:

Here is my current understanding (approximated heavily to allow seeing the big picture) and presented in non-linear chronological order:

== Note: I am genuinely trying to construct the big picture. Please help me understand and not offer just plain criticism that does not teach me. ==

1\. There were multiple processors and operating systems. Programming languages like C created with the idea of writing programs once and just compiling for different platforms. But alas, systems were still too different to handle with a common code base. Many languages like C++ came along, but do not provide cross-platform libraries for many things like GUI development. Third parties libraries did, but native UI/UX not achieved still?

2\. Java created with the idea of writing programs once (and even compiling to the byte code once) and running everywhere, thus solving compatibility issues C and C++ had across platforms. But alas, writing once and running everywhere were still too different in a common code base (Is this true?), especially with mobile devices coming along that bring different UI/UX requirements. Also native UI/UX was not achievable (Is this true?).

In the meanwhile:

A. Installation of software on the local machine (aka caching it locally) and constantly updating it was a pain. Automatic updates popularly used but unpatched machines still exist.

B. Browsers came along with static pages, then gradually added more and more interactivity.

C. Machines and networks became fast enough to install the software live from a website when a user visits and remove it when the browser cache is cleared.

So now:

3\. Applications start getting developed in Javascript (and other technologies) inside a browser. Native UI/UX still performs better on mobile (and on desktops too in my experience). Browsers still struggle somewhat with standardization.

4\. The legacy code from #1 above is now being connected to #3 above allowing even operating systems and VMs to run inside the browser.

So now we may have C++ code (originally designed to compile natively) now converted to Javascript running inside a browser, that interprets/JIT's that Javascript to run natively on the machine/OS, where the browser itself is written in C++ or so, runs as a visible or hidden layer on the top of the OS or VM, which by itself is written on C++ or so, and finally runs on the processor on which the original C++ code was designed to run on.

While I certainly appreciate the flexibility of flows this offers, I am still trying to make sense of all this from the progress made by mankind as a whole. What is the ultimate problem that we are trying to solve? Compatibility between platforms and uniformity of experience across them? Improvements made to the software development processes (better languages)? Loading programs securely into the local machine (caching) instead of installing?

No matter which direction I think, it seems to me that if mankind were to think these through, and were not to have the purely historical elements in the picture, the problems we have should "technically" have been solvable more easily than the path mankind has taken.

Again, I am seeking help and inputs to understand this better, not underestimating the value of efforts made by people around the world, or criticize any such effort including asm.js.

<comment><USER24> I think your comment would be clearer if you could answer the question "what would seem to be a better alternative?".

Google's PNaCl is more elegant since it doesn't involve js-that-is-also- bytecode but it accomplishes essentially the same task.

Creating a new cross-platform UI framework would be essentially recreating HTML5 anyway, so I don't think there would be a big advantage there.

<comment><USER6> A cross-platform UI framework would look almost nothing like HTML5. The document model is a significant hindrance to widget-based UI design that is just barely beginning to be worked around with new CSS and HTML features that still lack browser support.

UI design benefits from a completely different structure than text-oriented documents -- layout managers, containers, spacers, grids, reusable components, nearly all missing from current browsers.

<comment><USER25> >UI design benefits from a completely different structure than text-oriented documents -- layout managers, containers, spacers, grids, reusable components, nearly all missing from current browsers.

Oh, but it's coming soon, via both JavaScript and Dart:

[http://www.polymer-project.org/](http://www.polymer-project.org/) [https://www.dartlang.org/polymer-dart/](https://www.dartlang.org/polymer- dart/)

<comment><USER26> Reimplemented 20 years after they were common on every platform.

<comment><USER27> so?

<comment><USER6> So it demonstrates how much more difficult UI design is using HTML5 versus every other UI design option out there. It's often worth it for the platform independence, but we could've done _much_ better if we designed a UI markup format from scratch.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Throwing away all of the advantages of dynamic scripting is not the answer. We just need better webgl support in browsers.

<comment><USER29> What advantages would those be? Do they still apply when compared to a modern strongly-typed language with type inference and typeclass-like functionality, like Scala?

<comment><USER30> The big advantage of dynamic typing is that your code only needs to be correct on the code paths that are actually taken. That's important for the web, which is full of browser specific hacks, polyfills, feature detection, etc.

Consider the difficulty of doing static type checking for a property like window.localStorage. Its type depends on the runtime environment, and may not exist at all. So static type checking against one browser environment doesn't give you much assurance that your code will type check in other browsers. You really do need to do type checking at runtime.

<comment><USER31> Yeah that's what polymorphism is for. window.localStorage would just be the interface, the underlying concrete type is irrelevant.

<comment><USER30> window.localStorage doesn't exist in (for example) IE 7, and it may or may not exist in IE8 depending on the domain. So you can't rely on the interface being the same.

<comment><USER31> Plenty of libraries written in statically typed languages add features which may not be supported on legacy platforms. There are ways to deal with this. In version X you provide a way to let the client know that function Y is not supported on the current platform.

It's not like the web is some completely different animal, it's just an example of poor/little standardization and a design which has not evolved well over time.

<comment><USER30> My point was not that static typing makes this stuff impossible, just more awkward and difficult.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> If you disagree with the following opinion please don't down vote me instead enlighten me.

Frankly I don't see the point of compiling C/C++ to JavaScript. If you'r using C/C++ you might as well compile to machine code, it's not like you gain anything by compiling to JavaScript.

<comment><USER33> What tom said; also typing a url in a browser is a lot easier than installing something. This might sound silly but for the typical computer user (and even many nerds!) it makes a big difference.

</comment></comment><comment><USER34> *for very specific types of applications.</comment>


Twitter is killing Twitter to save Twitter - <AUTHOR> http://www.wired.com/2015/06/twitter-project-lightning-timeline/

<comment><USER2> upvote just for the headline .. i agree with the article too ..</comment>


Online JSON Viewer - <AUTHOR> http://jsonviewer.stack.hu/

<comment><USER2> any way to launch it with the json in the url?</comment>


The Trump Tax Cut versus Universal Basic Income - <AUTHOR> https://evonomics.com/trump-tax-cut-versus-universal-basic-income/ <comment><USER2> "Everyone gets it, the poor, the rich, the middle class, the deserving and the undeserving alike. You, me, Rupert Murdoch, Beyonce, and the homeless man sleeping in the gutter get exactly the same cash payment. It is nothing if not equitable and fair."

The fairness isn't about who gets it...it's about who pays for it. If Beyonce gets $100 in UBI, but then has to pay out $10,000, it's not really that 'fair'.

The whole problem with UBI is the long-term, not the short-term. We will probably see a slight increase in prosperity in the short-term.

However, as more and more people start to rely on it, there will be less people to tax. Not to mention the inflation this will cause. It's actually a decrease in pay for the rest of us because our money won't go as far.

I would rather see our money go toward educating people to be more self- sufficient.</comment>


Don't Believe The eBook Anti-Anti-Trust Spin - <AUTHOR> http://mikecanex.wordpress.com/2012/03/11/dont-believe-the-ebook-anti-anti-trust-spin/

<comment><USER2> publishing in its present form is dying, How many publishers would last to the next decade is the question.

Apple and Amazon is creating marketplaces for content creators(authors, musicians, app developers, trainers, film makers) and they are more efficient in distribution, reach and money made by authors themselves.</comment>


Images: Future Firefox fitting in - <AUTHOR> http://www.news.com/2300-1016_3-6214085-1.html?tag=nefd.also <comment><AUTHOR> I sure hope they fix the problem of FF bogging down when using JS dense applications like Google Docs/Mail. I have to shut down FF and restart on a regular basis to keep my system from slowing down to a crawl.</comment>


Ask HN: How do you feel when the Internet insults you? - <AUTHOR>

So easy for the Internet to be negative to your comments/blog posts/tweets/whatever.
How do you feel when you are the target of negativity or attack or insult?
Do you take it on board, does it hurt your feelings at all? <comment><USER2> One of my basic life strategies seems to be: either don't do something, or do it and don't be sorry. I use this all the time, for all kinds of things.

For example, I'm not insightful when it comes to dressing myself. Recently I wasn't sure whether it would be OK to wear black socks with shorts. I thought about it, and decided it was OK, so I do it. Someone might try to give me a hard time about it, but it wouldn't sting unless they thought of something I hadn't.

Or when I write something online, I try to think about how I would talk if the readers were in the same room. I try to be compassionate and fair. I try to think whether what I'm saying is just. Often, the draft doesn't survive the process because I realize I'm just angry or want to be snarky. But if I re-re- read it and I'm OK with it, then I say it, and whatever happens will happen.

Maybe someone will catch me in an error. Then I'll feel bad and apologize sincerely and try to do better, but try not to beat myself up too much. Everyone makes mistakes. No big deal.

If you form the habit of asking yourself whether what you're doing is OK, I think it vaccinates you somewhat against both shallow criticism and self- doubt.

</comment><comment><USER3> I made a pull request for a plugin I used frequently. They didn't like my changes so I deleted my pull request. For that I was accused of not being open source, so I deleted my GitHub account. Then they mocked me further. I almost killed myself! I still haven't created another GitHub account.

<comment><USER4> Not being aware of the situation I cannot comment on the bulk of your post, other than to say that I hope you are OK now?

I'm always cautious about pinning anything I do online to an identity - HN is actually about the only site I use where I post under my own name. Largely this stems from not wanting to make mistakes and avoiding any possible future public repurcussions. I truly wish anonymity was more embraced on sites like GitHub. For instance, I think the ability to hide your identity from others when submitting a pull request would strongly encourage people to contribute, which could only be a good thing.</comment></comment>