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

JavaScript Conquered the Web, Now It’s Taking Over the Desktop

wired.com

Post reply on HN
Print view View original

221–230 of 270 posts

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#221

Post by catnaroek »

smallnamespace wrote: post #219
catnaroek wrote: post #213

Earlier quoted context omitted.

> Of course, but how does it know which functions to inline? Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) > That's not true--a JIT could optimistically replace with a concrete realization. You'd have to roll back an unsound optimization in the middle of a hot loop. I'm pretty sure that's not what you want. > it is possible to speed up…

> Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) But then you're just guessing. Isn't that also inelegant? Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that…

> In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input.

Sure, but I'm interested in what the program does on all meaningful inputs, not a specific one. Otherwise, I'd just precompute the answer and hardcode it.

> I don't see how that isn't equally applicable to writing code to fool your JIT.

AOT compilers are supposed to provide feedback to the programmer about what the program means (e.g., inferred types, type errors). JIT compilers are not.

> I don't really understand why optimistic heuristics bother you so much.

Um, because they can be wrong, and then you need to fix errors, which makes the system more complex?

> Seems like you just have an aesthetic preference.

Yes, for simplicity, and for thinking before writing code.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#222

Post by freyr »

zeveb wrote: post #175
alexwebb2 wrote: post #130

Earlier quoted context omitted.

I can't believe this is the top comment. Let's go point by point: 1) JavaScript has its warts and its gotchas like anything else (okay, maybe a few more). So what? Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Same goes for just about any other language. Focusing on the weird edge cases might make for a nice blog…

> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Spending 10,000 hours building things with JavaScript sounds like a pretty good definition of Hell. JavaScript is an actively, abusively bad language. It's not that it has a few warts: it's nothing but warts. Its fundamental design flaws are obscured only by its supe…

> It's a really bad, tasteless language.

It's really not that bad. It's actually a good language, and getting better all the time. See? We can go back and forth, without any substance.

But seriously, modern JS is not that bad.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#223

Post by lloyd-christmas »

Udik wrote: post #215
lloyd-christmas wrote: post #174

Earlier quoted context omitted.

> There are plenty of times where you want == FWIW, I've never used ==

FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.

> I'm used to javascript enough to think in advance

I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons:

1) debugging someone else's code is a lot more time consuming than debugging your own

2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code

3) the docs are simpler to write and easier to read.

It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality:

  function doStuff(a, b, c) {

      if (!c && b instanceof Function) {
          c = b;
      }
      c()
  }
"`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it."

I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#224

Post by freyr »

rbanffy wrote: post #88
segmondy wrote: post #27

Earlier quoted context omitted.

See the spotify client, popcorn time, visual studio code. these are javascript. They run great.

Have you checked how much memory they use? I know we have 8-core laptops with 16 gigs of RAM, but, still, it's excessive.

Any idea why the memory usage is so high? Is it related to the Electron/Chromium platform, or bad application design?

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#225

Post by smallnamespace »

catnaroek wrote: post #221
smallnamespace wrote: post #219

Earlier quoted context omitted.

> Small functions and higher-order functions are the most natural candidates. (The two categories greatly overlap in most cases.) But then you're just guessing. Isn't that also inelegant? Let's play devil's advocate: how do you decide the cutoff on function size for inlining? Well, you would profile a bunch of programs with various cutoffs... now all you have is a heuristic, and MLton will inline some functions that…

> In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input. Sure, but I'm interested in what the program does on all meaningful inputs, not a specific one. Otherwise, I'd just precompute the answer and hardcode it. > I don't see how that isn't equally applicable to writing code to fool your JIT. AOT compilers are supposed to provide feedback to the…

> Um, because they can be wrong, and then you need to fix errors, which makes the system more complex?

Yes, but I don't understand why compiler complexity concerns you, so long as the whole thing works. AOT compilers are also extremely complex, and are also full of heuristics.

You seem really hung up on the fact that an optimization can be rolled back at some point, but why should you care? JIT optimizations can be 'wrong' in the same way that caches can miss. It the right engineering solution to eliminate caching, over some belief that one should never be 'wrong' anywhere in a program, even though the eventual answer is always correct?

This might matter in system with real-time performance demands, but then you should be equally concerned about the garbage collector, for example.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#226

Post by catnaroek »

smallnamespace wrote: post #225
catnaroek wrote: post #221

Earlier quoted context omitted.

> In particular, there exists a version of P' that is faster than the statically optimized version of P on your program's input. Sure, but I'm interested in what the program does on all meaningful inputs, not a specific one. Otherwise, I'd just precompute the answer and hardcode it. > I don't see how that isn't equally applicable to writing code to fool your JIT. AOT compilers are supposed to provide feedback to the…

> Um, because they can be wrong, and then you need to fix errors, which makes the system more complex? Yes, but I don't understand why compiler complexity concerns you, so long as the whole thing works. AOT compilers are also extremely complex, and are also full of heuristics. You seem really hung up on the fact that an optimization can be rolled back at some point, but why should you care? JIT optimizations can be '…

> Yes, but I don't understand why you compiler complexity concerns you, so long as the whole thing works.

Because I find it easier to trust simpler systems than complex ones.

> AOT compilers are also extremely complex, and are also full of heuristics.

Yep, those heuristics are annoying too. (But less so than the ones JIT compilers use, because at least they don't involve temporarily breaking my program.)

> unless you've profiled it and see this having a real adverse effect on overall performance?

How many times do I have to repeat that what annoys me is the excessive complexity?

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#227

Post by cygx »

threatofrain wrote: post #201
zeveb wrote: post #175

Earlier quoted context omitted.

> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on them, and you'll be good to go for the next 10,000 hours. Spending 10,000 hours building things with JavaScript sounds like a pretty good definition of Hell. JavaScript is an actively, abusively bad language. It's not that it has a few warts: it's nothing but warts. Its fundamental design flaws are obscured only by its supe…

I don't understand why people say javascript is such an awful language. The "Wat" video previously posted features of a few javascript idiosyncrasies, but I think most people would consider such obscure syntax combinations to be ill mannered, and most people understand to be very careful around type conversions. At a higher level of organization, the language begins to matter less and less, and what matters more are…

I don't understand why people say javascript is such an awful language.

Frankly, because from a language design perspective, it is - or at least used to be: Bad scoping rules (implicit global declarations by default, function instead of lexical block scope if var is present), weird implicit conversions, no good story for code reuse/object extension so everyone doing anything complex had to cook up their own version, ...

Nevertheless, I actually enjoy programming in Javascript ;)

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#228

Post by goatlover »

lloyd-christmas wrote: post #223
Udik wrote: post #215

Earlier quoted context omitted.

FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.

> I'm used to javascript enough to think in advance I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons: 1) debugging someone else's code is a lot more time consuming than debugging your own 2) actually fix…

Multiple dispatch would be a cleaner approach for languages that support multiple versions of doStuff.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#229

Post by qwer »

goatlover wrote: post #216
qwer wrote: post #198

Earlier quoted context omitted.

DSLs are actually common in javascript. JQuery, one of the most popular libraries in all of javascript is mostly a DSL for DOM manipulation. Lodash/underscore is mostly a DSL for list manipulation. Admittedly, JS doesn't have operator overloading, but I personally think that's a good thing.

Operator overloading in Python made the Pandas library possible where you can treat a DataFrame syntactically like you can in R, which is really nice for data science.

"Made it possible", or "made it look like R"? add() vs. + is just a mild inconvenience IMO compared to the inconvenience of overloading abuse that I normally see ( like sqlalchemy IMO). I'd personally rather know what to expect from an operator.

Re: JavaScript Conquered the Web, Now It’s Taking Over the Desktop

#230

Post by woah »

vetinari wrote: post #179
woah wrote: post #42

Earlier quoted context omitted.

I use a network simulation software inside of lubuntu inside of a VirtualBox inside my Mac. VirtualBox is a stream of headaches, and you suffer a big performance hit. What I wouldn't give for the software to serve an http/css/js interface so that I could run it with docker or natively instead.

Make sure that the virtual machine has "paravirtualization interface: kvm" setting for linux guests, that the guest tools are installed and if you really use network, adapter type: virtio-net doesn't hurt. And also, that you have enough RAM. Then, virtual machines in VirtualBox are fine.

Thanks! Good samaritan :)
Post reply on HN