Traditional JavaScript benchmarks • Hacker News Board

Re: Traditional JavaScript benchmarks

#41

Post by debaserab2 » Sun, Dec 18, 2016, 7:57 AM UTC

SomeCallMeTim wrote: post #39

debaserab2 wrote: post #35

Earlier quoted context omitted.

Thats still a fraction of the overall software engineering world. There's a lot more in the world than websites and phone apps that need code to run. That's not taking away from its importance, that's putting it into perspective. I'm not an anti-javascript snob either (I'm not sure what that actually means), I just think it's a bit hyperbolic to call javascript the most important thing happening in software engineeri…

> I'm not an anti-javascript snob either (I'm not sure what that actually means), Having been one, and having argued with several, it generally means: * Looking at how JavaScript started vs. where it is now. * Complaining about the ways that the backward compatibility requirements of the language can lead to obscure bugs, e.g., auto-coercion on "==" comparisons can end up with surprising and sometimes bug-causing res…

I don't have complaints about javascript. I'm a web developer. I also use React, it's awesome and makes developing a rich user interface much easier. It's not a silver bullet for anything though. Isometric web development is great, but sometimes I think it's more of a solution in search of a problem than an actual problem (it's great that I can render server side, but do I need to? not usually). React native is great, too (if you're smart enough to plan your app ahead of time the right way). Overall though, these are fantastic toolchain improvements that reduce development cycles when used properly. That's all they are though.

I still don't think it's the most important thing to be happening in software engineering. It's a fundamental change in how people use javascript. That's it.

> If you count all of the code to run apps, servers, and web clients, I think you do hit the majority of code out there, at least if you're counting the number of developers working on it. I think you would hit a majority just with web client side. It seems like everyone and their sister does web development. With all three domains it seems trivial to hit 50%, and I think 80% is still a reasonable estimate. A quick search finds no statistics on this, though. :|

Um, not even a little bit. My oven, microwave, and dishwasher all run on code. They have since the 90's. Including my car. I can understand how you could perceive the majority of code written to be for web development as a hacker news reader, but there's a wide world of programming that extends far beyond what your perceiving.

Re: Traditional JavaScript benchmarks

#42

Post by fnordsensei » Sun, Dec 18, 2016, 6:28 PM UTC

SomeCallMeTim wrote: post #40

fnordsensei wrote: post #31

Earlier quoted context omitted.

I guess it comes down to what you mean by "important". I for one hope that airplanes, power plants and medical machinery are all programmed with something else.

I never claimed that JavaScript was or should be used in any of the above. Just that it's "important in software engineering", by which I mean it's used or usable by people in 80% of the actual jobs in "software engineering." I'd probably prefer to see a language like Go or Rust in critical systems. Self driving cars come to mind as well, but probably anything IoT or otherwise infrastructure related. But I think thos…

I didn't mean to imply that you made such a claim. It was just a way to point out an alternative interpretation of "important." That is, some things may be of greater importance even if there are fewer of them.

It's nitpicking really, I understand that you had a particular perspective on what "important" meant in this case.

Re: Traditional JavaScript benchmarks

#43

Post by SomeCallMeTim » Tue, Dec 20, 2016, 9:40 PM UTC

debaserab2 wrote: post #41

SomeCallMeTim wrote: post #39

Earlier quoted context omitted.

> I'm not an anti-javascript snob either (I'm not sure what that actually means), Having been one, and having argued with several, it generally means: * Looking at how JavaScript started vs. where it is now. * Complaining about the ways that the backward compatibility requirements of the language can lead to obscure bugs, e.g., auto-coercion on "==" comparisons can end up with surprising and sometimes bug-causing res…

I don't have complaints about javascript. I'm a web developer. I also use React, it's awesome and makes developing a rich user interface much easier. It's not a silver bullet for anything though. Isometric web development is great, but sometimes I think it's more of a solution in search of a problem than an actual problem (it's great that I can render server side, but do I need to? not usually). React native is great…

> My oven, microwave, and dishwasher all run on code.

The quantity of code being written for devices like that is not high, and the quality is almost universally crap. Bad enough that I'm pretty certain 99% is written by a hardware engineer who needed to get the product to work but who had no clue about software engineering.

I've worked with people who write code for cars, and I've done embedded work. One developer can support dozens if not hundreds of products over a career. I still stand by the fact that most software engineers fall into the categories I'm talking about, if only because one software product might require 100-10,000 developers work on it for years, while your microwave probably took one person a month (and an actual software engineer should have been able to write the code in a couple of hours).

I'm not counting by number of devices. I'm counting by number of software engineers. And even if you count the hardware engineers who don't know the first thing about software engineering, I don't think you'd come close.