Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prepack helps make JavaScript code more efficient

prepack.io

Post reply on HN
Print view View original

161–170 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#161

Post by RangerScience »

devrandomguy wrote: post #135
maaaats wrote: post #103

Earlier quoted context omitted.

They could use some proper, standard license, though. Then people wouldn't complain. Like Apache license.

The licenses that you are thinking of, are all related to copyright, not patents. Patents are a completely different beast. I personally think that patents have no place in contemporary society, but that's just, like, my opinion, man.

I know of at least two things that I think are pretty reasonable and (probably) patentable: Apollo Diamond's vapor deposition process, and those north/south printable magnets.

That said, I think I broadly agree with you about software patents; one reason why is that they're the glitter of intellectual property.

If you buy an Apollo diamond or one of those magnets, the use, possession, modification, etc of those items are not covered by the patents on the diamond (AFAIK, IANAL). With software patents, it seems to be the case that the "final product" IS covered by the patents.

This seems like it makes the presence of two separate categories pretty damn clear.

Re: Prepack helps make JavaScript code more efficient

#162

Post by tadeegan »

bpicolo wrote: post #141
matt4077 wrote: post #88

Earlier quoted context omitted.

Closure compiler optimizes code size, while this optimises code execution.

I see that it claims that, but that's not entirely true. The closure compiler does a variety of perf optimizations as well (e.g. inlining). Closure is really a great compiler, it's just a shame it doesn't interact well (that is, at all) with the modern JS ecosystem.

As someone who works on Closure Compiler, this is one of my biggest gripes with the project. Things are getting better though! CC now supports node's module resolution algorithm. It works pretty well with Es6 imports but not so well with CommonJS (mostly because the exports are impossible to statically analyze).

Within Google, CC is heading towards being a an optimizing backend for other less painful languages such as Typescript (tsickle) and the yet-to-be-released J2CL compiler.

CC does pretty well with these examples (our debugger is not quite as flashy): https://closure-compiler-debugger.appspot.com/#input0%3D%252...

Re: Prepack helps make JavaScript code more efficient

#163

Post by eropple »

derefr wrote: post #153
slavik81 wrote: post #134

Earlier quoted context omitted.

If I can't trust the justice system to interpret a simple contract plainly, then I don't have a chance of actually understanding the legal implications of a more complex contract.

I don't understand this perspective. The justice system is like a computer. It has no common sense; it has no "Do What I Mean" button. You have to write things out in full explicitness, for it to do anything predictable/sensible at all. And just like with explicitness in programming, explicitness in a contract doesn't translate to "more things that could go wrong"; it's instead fewer degrees of freedom . More things…

I get what you're saying, but calling it "like a computer" is a little misleading and feeds that weird habit amongst technical people of assuming that The Letter Of The Law is all that matters, when really it's the boatload of precedent, moral justification, and historical context that informs that law.

It ain't hard fact until a judge says it is, and even then it can be moved with a big enough lever. That that specificity reduces axes of freedom on which to have what you think is obvious be not obvious is why I upvoted you, because that's the super important part everybody ignores.

Re: Prepack helps make JavaScript code more efficient

#164

Post by franciscop »

vmasto wrote: post #142
franciscop wrote: post #124

Earlier quoted context omitted.

No, I have done and pubpished an article about how gzip works with JS and the result will compress pretty well. Not better than the code, but I would guess within the same order of magnitude.

JavaScript parsing is still a huge bottleneck. 1mb of it will still take 1 whole second to parse in V8 (note: just to parse it, not actually evaluate or run it!).

I think this is (so far) for snippets. I agree otherwise though

Re: Prepack helps make JavaScript code more efficient

#165

Post by derefr »

eropple wrote: post #163
derefr wrote: post #153

Earlier quoted context omitted.

I don't understand this perspective. The justice system is like a computer. It has no common sense; it has no "Do What I Mean" button. You have to write things out in full explicitness, for it to do anything predictable/sensible at all. And just like with explicitness in programming, explicitness in a contract doesn't translate to "more things that could go wrong"; it's instead fewer degrees of freedom . More things…

I get what you're saying, but calling it "like a computer" is a little misleading and feeds that weird habit amongst technical people of assuming that The Letter Of The Law is all that matters, when really it's the boatload of precedent, moral justification, and historical context that informs that law. It ain't hard fact until a judge says it is, and even then it can be moved with a big enough lever. That that speci…

Right, you can't actually "rules lawyer" in real law; there is a spirit of the law that informs connotation of the text where edge-cases are concerned.

A good lawyer tries to phrase their contracts et al to expose the connotation of the relevant laws in the text, so that you don't need to read the laws, only the text. Sort of like explicitly including default parameter assignments to a function.

Re: Prepack helps make JavaScript code more efficient

#166

Post by eropple »

derefr wrote: post #165
eropple wrote: post #163

Earlier quoted context omitted.

I get what you're saying, but calling it "like a computer" is a little misleading and feeds that weird habit amongst technical people of assuming that The Letter Of The Law is all that matters, when really it's the boatload of precedent, moral justification, and historical context that informs that law. It ain't hard fact until a judge says it is, and even then it can be moved with a big enough lever. That that speci…

Right, you can't actually "rules lawyer" in real law; there is a spirit of the law that informs connotation of the text where edge-cases are concerned. A good lawyer tries to phrase their contracts et al to expose the connotation of the relevant laws in the text, so that you don't need to read the laws, only the text. Sort of like explicitly including default parameter assignments to a function.

Yeah, totally--I knew you knew, just didn't want the implication to leave room to well-actually.

Re: Prepack helps make JavaScript code more efficient

#167

Post by warent »

shuzchen wrote: post #123
chime wrote: post #114

This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html ) and it ballooned to 1400+ lines of junk: (function() { function fib(x) { y = Date.now(); // the useless line I added return x 42) x = fib(10); global.result = x; })(); I understand Date might not be acceptable for inner loops but a lot of my code that deals with scheduling would benefit significantly if…

It's not a useless line, because prepack has no idea what Date.now() does (there are no guarantees in javascript that it hasn't been replaced with another function). It might mutate some global state somewhere, so the resulting code needs to call Date.now() as often as it would've if fib(10) was called. Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparativel…

"prepack has no idea what Date.now() does" isn't quite true, because there's a typeof check happening on the return to ensure it's a number, meaning that some assumptions are definitely being made.

Re: Prepack helps make JavaScript code more efficient

#168

Post by developer2 »

chime wrote: post #114

This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html ) and it ballooned to 1400+ lines of junk: (function() { function fib(x) { y = Date.now(); // the useless line I added return x 42) x = fib(10); global.result = x; })(); I understand Date might not be acceptable for inner loops but a lot of my code that deals with scheduling would benefit significantly if…

Doesn't this make Prepack completely unusable? Surely it should try to apply its optimizations to each block of code, and for each block where the "optimized" version results in more lines of code - or perhaps better, more operations - the optimizations are thrown out, keeping that block of code untouched?

It makes no sense to use an optimization tool that does the exact opposite in cases it cannot handle. In no world is 1400 lines better than 10.

Re: Prepack helps make JavaScript code more efficient

#169

Post by dmead »

NTillmann wrote: post #5

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

How do you validate your program transformations? In school I wrote a haskell to clojure translator that also does AST transforms (some of which unpack syntactic sugar). However, my only way to validate the transforms was that the input program passe the "same" unit tests as the output program. Do you have any insight into this?

Re: Prepack helps make JavaScript code more efficient

#170

Post by jaredklewis »

slavik81 wrote: post #134
eropple wrote: post #128

Earlier quoted context omitted.

That "pile of explicitness" replaces a pile of implicitness wrapped up in case law and statutes that are relevant to any case that arises but you don't know about . Because what you read in a license is not what matters--how do you know you understand them as they will be interpreted by a court of law? What do you not know that you do not know? (This is why companies have legal teams.)

If I can't trust the justice system to interpret a simple contract plainly, then I don't have a chance of actually understanding the legal implications of a more complex contract.

You seem convinced that your interpretation of a "simple" contract is the only obvious one and that any other interpretation is unecessarily convoluted. But I don't think that is the case at all. Simplicity almost always comes at the expense of clarity, which is why simple documents like the MIT license or the US constitution produce so many conflicting interpretations. Not because there are bad actors; just because it is unclear.

If you ask a lawyer what is best, they will likely recommend a professionally drafted license like the Apache License v2. Just as you may not understand every aspect of a doctor's diagnosis or prescription, it may not be feasible to understand all the relevant statutes and case law. But I think it makes more sense to defer to expertise advice than to bury one's head in the sand.

Post reply on HN