Live data from Hacker News

Prepack helps make JavaScript code more efficient

prepack.io

221–230 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#221

A long time ago there was a theory about using Guile (the GNU Scheme) as a general interpreter for languages using partial evaluation: you write an interpreter for a language in Scheme, use a given program as input, and run an optimizer over the program. This turns your interpreter into a compiler. I played around with the concept (making a Tcl interpreter), and it even kind of worked, often creating reasonably reada…

What you're talking about -- writing an interpreter that's optimized into a compiler -- is actually coming in the soon-to-be-released Java 9. Check out Graal and Truffle. I'm pretty excited to play with it at some point. Prepack reminds me more of a "supercompiler," because it focuses on partial evaluation rather than optimization.

Your "supercompiler" phrase made me think about what happens if you start applying the partial evaluation over and over. Of course nothing happens... unless you know something more than what you knew before. Which you might! That in turn made me think of the Wolfram Language, which feels like this to me – you declare things, and as the set of declarations continues the language starts to "know" more things, and your statements become more concrete. This is interesting because it's all automated, you can undo things, change them, implicitly loop them by considering multiple possibilities.

I'm not sure you could take Prepack and do this. But it sure seems interesting. A kind of partial evaluation coding notebook... not so unlike a symbolic spreadsheet I suppose.

Re: Prepack helps make JavaScript code more efficient

#222

Earlier quoted context omitted.

I was right there a year or two ago developing portable native client things for my project, Linux on the Web (I was able to get vim and python running). Projects like that can pioneer a whole lot of new techniques and infrastructure that can be very easily applied to whatever technology is eventually going to win out.

@dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates. @rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person. I'm curious what you thought was downvote-worthy of my original post pre-edit? I get it, rules are rules, and this is a matt…

Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.

Re: Prepack helps make JavaScript code more efficient

#223
post #143

Earlier quoted context omitted.

Some people think so. Others aren't so sure. US courts have not yet ruled on it. However, even the people who DO think an implicit grant exists would mostly agree that the implicit grant is not sublicensable, which makes it a horrible mess and probably unusable. An explicit grant is strongly preferable, IF people can agree on the terms. Facebook's terms are on the harsh side, but there's clear advantages to it existi…

> US courts have not yet ruled on it. They sort of have. A patent has to be a major and "dominant" part of the implicitly licensed tech for it to be granted. Basically - all existing case law says that you get some rights from implicit grants but it's also far less than explicit ones like FB's

Not only does not all of the case law say this, that's not even what that case was about nor what that language said: http://en.swpat.org/wiki/Implicit_patent_licence#USA

Re: Prepack helps make JavaScript code more efficient

#224
post #196

Earlier quoted context omitted.

> US courts have not yet ruled on it. They sort of have. A patent has to be a major and "dominant" part of the implicitly licensed tech for it to be granted. Basically - all existing case law says that you get some rights from implicit grants but it's also far less than explicit ones like FB's

Thanks for the info.

Careful. I don't know what his motivations are, but the info is misrepresenting both the context and the meaning of the language he references: http://en.swpat.org/wiki/Implicit_patent_licence#USA

Re: Prepack helps make JavaScript code more efficient

#225
post #143
post #96

Earlier quoted context omitted.

False: an implicit patent grant means that by open sourcing a piece of software you imply that people can, you know, use it.

Some people think so. Others aren't so sure. US courts have not yet ruled on it. However, even the people who DO think an implicit grant exists would mostly agree that the implicit grant is not sublicensable, which makes it a horrible mess and probably unusable. An explicit grant is strongly preferable, IF people can agree on the terms. Facebook's terms are on the harsh side, but there's clear advantages to it existi…

If you license something under BSD and continue to license under the BSD, the question of sub-licensing seems moot.

Re: Prepack helps make JavaScript code more efficient

#226

Earlier quoted context omitted.

@dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates. @rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person. I'm curious what you thought was downvote-worthy of my original post pre-edit? I get it, rules are rules, and this is a matt…

Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.

[deleted]

Re: Prepack helps make JavaScript code more efficient

#227

Earlier quoted context omitted.

@dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates. @rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person. I'm curious what you thought was downvote-worthy of my original post pre-edit? I get it, rules are rules, and this is a matt…

Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.

I'm not sure how you can leap to conclusions about my tone of voice from textual comments? One user @rattray is even citing quotes from the rule book to me here, and somehow I'm the one being condescending? But hey, regardless of the situation, nobody deserves to be insulted like this! You can do better, man. I can give you the benefit of the doubt; I suspect you wouldn't ever act this way in person to anybody.

I also don't see how any sort of purported victimhood would be unsubstantiated (I just don't happen to take website comments from strangers all that seriously): I'm just trying to talk about WebAssembly, and this troll spends their Friday night posting these kinds of inflammatory comments on nearly-dead threads from the beginning of the week. :(

As a reminder, you're breaking the very first rule -- "be civil" -- since we're sticklers about the rules here. You are acting very rude!

Re: Prepack helps make JavaScript code more efficient

#228

Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!

Thanks for posting here Nikolai.

In terms of the development status, does the current codebase generally work with React?

I'm happy to throw this at my codebase and report bugs, but whether React itself (which is ~95% of my bundle size) is expected to work (unlike some other optimising products) would say a lot about what the expectation might be.

Re: Prepack helps make JavaScript code more efficient

#229

Earlier quoted context omitted.

@dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates. @rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person. I'm curious what you thought was downvote-worthy of my original post pre-edit? I get it, rules are rules, and this is a matt…

Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.

Actually, it turns out that at the time you posted this, you couldn't even see the contents of my original post that was downvoted because it was flagged and hidden via the moderators, so I'm not sure how you can even comment at all on why it was downvoted in the first place.

Ridiculous leap to conclusions here!

Re: Prepack helps make JavaScript code more efficient

#230
post #81
post #79

I hate to bring this up whenever I see a Facebook project, but it still warrants saying: the patents clause in this project, like in others including React, is too broad. I really wish they made a "version 3" that limited the scope of the revocation to patents pertaining to the software in question, e.g. Prepack, React, rather than a blanket statement that covers any patent assertion against Facebook. While I suppose…

IANAL, but most likely: nothing. Less likely: Facebook counter-sues you for patent infringement and (maybe?) has a slightly better case as long as you keep using it. Your lawyers tell your engineers to rewrite everything without Facebook technologies and it's all a big pain in the ass and you regret ever suing Facebook for patent infringement.

Would the same still apply to the output of the programs, e.g. could you keep the optimized code generated by Prepack?
Post reply on HN