skysight-inc/HackerNews huggingface dataset:
It's fair to point out that young people will lack experience and understanding that older people have but there is such a thing as ageism in the opposite direction -- against younger people -- and your post comes across as such.

I am closer to 30 than 20 but I was closer to 20 than 30 when I was first introduced to NoSQL.

I enjoyed using PostgreSQL prior to NoSQL and I continue to enjoy PostgreSQL.

What got me exited about NoSQL when I first heard about it had nothing to do with SQL being "old". If I thought that "oldness" was a disadvantage -- which I don't, because it's not -- I wouldn't be using an operating system that has it's roots in the 70's and my workflow would not have been command-line-centric.

What got me exited about NoSQL was:

- The prospect of serialisation and deserialisation of data without having to rely on an Object-Relational Mapper. The relational model is great for the right kind of data, but the reason we have ORMs is that we are trying to cram data into a model that doesn't quite fit it. This has worked to varying degrees of success or failure. When NoSQL was introduced, PostgreSQL did not yet have native support for JSON, and having fields hold stringified JSON meant that you wouldn't be able to query that data using SQL, so having stringified JSON in a relational DB is not optimal. PostgreSQL has since gotten native support for JSON but here I am talking about when NoSQL was introduced.

- Map-Reduce. If it's a good fit for Google, I should investigate it to understand how to use it and to see if it had a use for me. Even if it would turn out to not bring any advantages, I would have learned it and I'd know to re-investigate it in the future if I needed something like it in order to scale a project that got a lot of traffic.

- Document-oriented instead of tables makes it possible to model data without having a strict schema.

Certainly someone with more experience might have been able to tell why one or more of these were actually not such a good reason, but MY POINT IS that I had actual reasons for being excited about NoSQL and none of my reasons had anything to do with hipsterism, ageism or anti-oldness to do. This is why I think your post is ageist, because rather than consider that we might have well-thought-out reasons to want to learn about NoSQL, you automatically jumped to the simple, overly broad, and frankly outright offensive, explanation that you did.
Yes, mobile apps are on the way, it mentions in the faq
Except it doesn't make sense if the JS code expands to a number of machine instructions that would take longer to transfer over the network than the transfer and parsing of the JS code combined.
In Support of Free Speech (Shopify defends keeping Breitbart as a client)
Something like this will hopefully get the point across on how to handle "multipart/form-data" forms. It will print the content of the upload to the server's stdout.

https://play.golang.org/p/DiNGdl27kE

You can use curl to test it out (it assumes a file called "foobar.txt" is available):

curl -v -F upload=@foobar.txt localhost:8080/upload
How many times do we have to go over this?

stocks are a random walk.
HFT it - get a server near in network terms to the Twitter servers that handle Trumps tweets; use the millisecond advantage to buy ahead of the other bots, ...
I have codes too, feel free to drop me a message for one :)
Stock options
Surely applies to all salaries in the countries, though?
> Both are electives

This is critical, because it makes them actually price-sensitive. You can't choose not to have heart disease, though.

Free markets have a bunch of conditions on their efficiency that are often ignored by advocates and don't always apply: must be plurality of non-coordinated buyers and sellers, must be feasible for participants to determine quality of goods (Akerloff's "lemons"), must be low barriers to entry, must be feasible for participants to choose not to do a transaction, and so on.
Modernizing our Progressive Enhancement Delivery (with HTTP2 and service workers)
> Considering things from the point of view of the immigrant, the current h1b system seems to me like the only route to immigration for a person who is not exceptionally skilled or wealthy or connected. So there are definitely people who would like to immigrate who would lose out if it became an auction.

Sure but the point isn't to provide a side door for immigration, it's supposed to be for filling short falls in labor that cannot be accommodated locally.

> I'm not saying those people should necessarily be a major consideration, but you did say "everyone besides companies trying to get cheaper labor".

That's correct though I was specifically thinking from the perspective of the USA, its citizens/permanent residents, and its corporations (both those trying to get H1-B applicants and those that aren't).
I have an important homework assignment due this afternoon
at 5PM and it isn't working. Can you download it from here
{dropbox-link} and get it working by then?

IMO, the ideal response to this is to send back a quote at triple your usual hourly rate.
"Precompiling JavaScript?

Every few years, it’s proposed engines offer a way to precompile scripts so we don’t waste time parsing or compiling code pops up. The idea is if instead, a build-time or server-side tool can just generate bytecode, we’d see a large win on start-up time. My opinion is shipping bytecode can increase your load-time (it’s larger) and you would likely need to sign the code and process it for security. V8’s position is for now we think exploring avoiding reparsing internally will help see a decent enough boost that precompilation may not offer too much more, but are always open to discussing ideas that can lead to faster startup times."

Surprised there was no mention of webassembly, which does exactly this.
what is the usage of your type if you can not check them through the compiler ?
That's a fascinating perspective. Thanks for sharing!
It actually works suprisingly well.

After all, no JS engine out there would really tune their engines to benefit benchmarks at the expense of real-world performance.

Even with all the dynamic ability that something like JS gives you, most devs still create an object to store stuff, then don't change it. That means that an aggressive policy of "compile it as it is, and bail if it changes" ends up working much more often than it doesn't.

And in the cases where it doesn't, falling back to the "compile it dynamically" isn't going to be any slower than if they did that first, so it's basically a free optimization (as long as the compilation doesn't take that long).
I would say to organizations that directly support people, be it Direct Relief, The ACLU, or Charity: water.

Other good options are FIRST, Girls Who Code, and The Geek Group, all orgs that focus on STEM Education and getting people into the STEM fields.

Just to name a few groups to directly counterbalance his behavior.
Here's a proxy: buy a 1st-gen iPad, turn JS off, and then use it to browse the site.

If it crashes the device, you're way off.

If it's appreciably slow or clunky, find ways to improve it.

Iterate until it's fast and usable.
I am surprised at just how much faster the iPhone is than the next nearest Google device (a laptop). I haven't used an Android device for a long time, but I hear the "Apple is overpriced" so often that I assume someone has been checking this out.
It's directly loadable using a GUI too (eg sqlitebrowser.org), for anyone that prefers the graphical approach.

And yeah, it had all kinds of interesting stuff I've downloaded over the years in mine. Now cleared. ;)
I agree with your conclusion (that tech companies will move), but don't agree with your reasoning.

It is exactly the opposite. Capital crosses borders much more easily than human capital. There are all kinds of impediments for human capital moving (visas, lack of money for travel, ties to families and friends). That is why, if it becomes even harder (because of travel restrictions), that tech companies will move.
I think hindsight will reveal that the things that make a "distributed company" successful are really the same things that make a "localized company" successful. I think it's just that having all employees on-site probably makes it easier for companies to "fake it" and stumble into success through sheer grit and determination. Probably a lot of times even when they have less-than-adequate (but highly motivated) human resources.
> something something democracy.

> The country is run (roughly) on something resembling democracy and equality. If, instead, the ethos changes to "more power to people who pay more", we give up any pretence at democracy. We might as well just advertise that politicians are for sale.

What's not democratic about optimizing need based upon projected tax revenue? Are we discriminating against "poor companies"? Would you classify companies that allow their employees to work remotely doing the same? (ex: I'm sure Google can pay more for a remote employee than any local company in Podunk USA).

I personally have no horse in the H1-B race. I don't employ any nor do I intend to apply for visas. The vast majority of citizens and permanent residents in the USA are in that group as well. It's in their interests to raise the price of said foreign labor. I'd say that's very democratic and keeping the price of it artificially low is short changing democracy.
Separating models like this is a hint that you may need another app. It has happened numerous times with me now that my models.py gets large and unwieldy, I spends a hour breaking it all out and then I realise my one big God app needs to be 3 smaller ones.
I've meet one programming manager with 0 programming experience (but he was a Mech Engr). His team loved him, they got real work done, he prioritized things for them effectively, and he helped insulate them from the b.s.

So, while it's rare there are certainly managers out there who can.
For remaining salaries it's even more humiliating.
The designer of REBOL, not surprisingly, is a pretty interesting and impressive fellow.

https://en.wikipedia.org/wiki/Carl_Sassenrath
America is not a democracy. It is a representative republic.
Hmm. Usually browsers cache the raw CSS and JS assets - could that be improved so that browsers cache the compiled CSS/JS? That wouldn't help for the first load, of course - but quite a lot for sites like newspapers which are not SPAs but bundle a metric ton of JS cr.p for each page load.

edit: Chrome actually does that, as mentioned in the article - but what about Chrome Mobile and Firefox/Safari/IE?
It doesn't need to be right every time, it needs to beat the market. I am not saying that I know that it does beat the market, but it would be interesting to know if it does.

All you have provided is proof that it is sometimes wrong, which is not surprising at all.
The original formulation of Baumol's cost disease is that it's a relative effect caused by increasing efficiency in automatable fields making non-automatable fields look bad.

If a job has to be done by a human in the West, of course it's expensive compared to those that have either been outsourced to cheaper humans or turned over to machines.

The "exchange rate" between human-produced goods and machine-produced goods looks worse and worse over time. The classic example is whenever you hear someone describing "flatscreen TVs" as a lavish expense. They're not. All TVs are flatscreen and you can get perfectly adequate ones for under $100. Whereas ladies' haircuts can easily exceed that - after all, it's a job you can't export to the Far East. And a college education costs several hundred televisions.
Go read the other comments. This is not an insulator. It will take a source of heat and start radiating that heat at a certain frequency where our atmosphere happens to be transparent. And because our atmosphere is transparent, there isn't at heat at that frequency outside so this "window" in your house is effectively one way.

Also, the demonstrated energy transfer density of this stuff is high enough that the area of your roof is enough cooling to make a series dent in your cooling cost.
Although it is hard to believe that JS code would be exactly the best compression for those machine instructions.
That is true, but only during GC itself. Refcounting causes these issues every time the reference is copied.

For malloc, the benefit with a compacting GC is that the free memory will always be in a contiguous segment. Therefore, a malloc operating is similar to a stack allocation in that all you need to do is to move a single pointer. Without a compacting GC, you need to search a tree whenever you want to allocate memory.
> We decided against a checkbox because users already have too many checkboxes, and mostly don't understand any of them.

How did you decide that it was too many? Also, if users don't understand any of them, what's the big deal about one more checkbox?

This was a bad decision IMO and it's the kind of thing that is causing nobody to use UWP. There are so many stories out there of people trying to use UWP for their project and then turning back when they realize how restricted the sandbox is.

Honestly, doesn't it seem a bit absurd that UWP apps can talk to anything else on my network except for Win32 processes on my own computer?

If Windows Phone were a thing, I'd probably be building UWP apps already. Mobile devices are the only place where I accept these types of restrictions, but it's mostly because I have no choice. If Microsoft comes out with a phone that can run Win32 apps, I'd switch to that in a heartbeat because then I could get full Chrome with extensions and I'd be able to do things like run uBlock, quick javascript switcher and all my other favorite extensions. (Yay freedom!)
The sense I get is that it's an elaborate way to soften people up for abandoning their ISPs and going with Google Fiber. There's a whole system of alerts and pages for basically saying 'LOL ur internetz sux', and it's plausible to me that they'd get that in place in markets they've not currently entered yet.
That means less than you would think as a container with the same setup and no meta material at night would also drop below ambient temperature.
When I see amazing pictures such as these, I feel that it's just extraordinary how far we've come as a species in some regards, despite all the dark stuff going on.
I didn't mean to deride CS terminology, but in TFA it's incoherently thrown around like someone who wants to sound like an expert but can't make solid case for anything and keeps changing their mind about what concepts even apply. I'm not sure where you were going with the trust and interviews thing, but I wouldn't hire the author of this piece (turns out its not one author though, it's a wiki).
well that's not going to scale on wordpress now is it!
Don't make it sound harder than it is. Each of these is 30-40 hours of work for undergraduate students. You don't have to quit your job and join a monastery to study compilers. It's interesting, challenging and fun for those of us into computing; and it pays back the time spent learning.
Good point, but to be fair, author probably doesn't have any control over this, as this is default for all Medium blogs. It's another question why Medium decided it is a good idea to ship almost 80k lines of Javascript code for a page whose only purpose is to display a blog post.
WebAssembly doesn't give you access to DOM APIs, so it's not like you could rewrite Angular in wasm, for example. Most load time/parse time discussions are in the context of web frameworks, but they're typically not able to benefit from the performance improvements of WebAssembly, particularly given the overhead of moving data into and out of the wasm context.
argüman: Argument Analysis Platform
The Disease of More
Richard Feynman Lecture - Los Alamos from Below (lecture NOT audiobook)
It's a shame they didn't pick a solution like RhodeCode(which is written in Python) at that point.

Afair it was because at the time decision was beeing made it wasn't open source, as it is now.
From the article:

"Chrome 42 introduced code caching — a way to store a local copy of compiled code so that when users returned to the page, steps like script fetching, parsing and compilation could all be skipped. At the time we noted that this change allowed Chrome to avoid about 40% of compilation time on future visits, but I want to provide a little more insight into this feature:

1. Code caching triggers for scripts that are executed twice in 72 hours.

2. For scripts of Service Worker: Code caching triggers for scripts that are executed twice in 72 hours.

3. For scripts stored in Cache Storage via Service Worker: Code caching triggers for scripts in the first execution.

So, yes. If our code is subject to caching V8 will skip parsing and compiling on the third load."
Looks like press freedom has got progressively worse over the last 10 years in this country: https://en.wikipedia.org/wiki/Press_Freedom_Index
Actually this is probably thanks to Safari's JS engine. From the graph [1] it seems that Safari is roughly 3x faster than Chrome parsing and compiling JS code on the same Macbook Pro.

[1] https://cdn-images-1.medium.com/max/2000/1*dnhO1M_zlmAhvtQY_...
Supercharging Mobile Back End Development Using Ngrok and OpenResty
Instapaper in 31-hour outage, says it needs a week to restore all data
That is a completely subjective, relative measurement. How does one teach another how to objectively tell if someone is smart and getting stuff done?
The U.S. government seems to be worse than the others.

For instance when Europeans hear how much it costs to build a subway in the U.S. often they are shocked. Heck, the Green Party in my town got shocked when it heard how much it costs to build a bus shelter.

Also government is involved in healthcare in other countries too. The difference is that our government spends more than the others and then the private sector spends more money on top of that.

Thus government itself is not a problem so much as the U.S. government is particularly broken.
Gig economy worker wins workers rights battle
Announcing Angel v1.0.0-beta (Dart server-side framework)
Improving SAP's fuzz testing [pdf case study warning]
Essentially, yes.
I meant I have a hard time guessing what that number would be for a programmer in Denver at various income levels.
I find comments like these worse than the original low-effort comments.
Consider also how many first-party Netflix clients exist for so literally thousands of different devices. TVs / consoles / set-top boxes / mobile / computers, each with at least a few platforms...not counting internal tooling.
> author probably doesn't have any control over this, as this is default for all Medium blogs

The author made a statement

> Ship less JavaScript

They chose to post on medium, they could have posted the content anywhere. They chose to give us the above lesson, while ignoring it. Do as I say, not as I do.

> it's another question why Medium decided it is a good idea to ship almost 80k lines of Javascript code for a page whose only purpose is to display a blog post.

Who cares? Why not simply stop using such shitty services?
Fair enough, thanks for the pointer :)
oooh yes, quite often :)
Surely the purpose of language is to get published?
Soemthing I've wanted for a long while is the ability to warm the codegen cache. It should be possible to instruct the browser to load and parse JavaScript so that on subsequent page loads execution can begin immediately. This would work really well with the model that Sevice Workers are moving towards.
Guccifer 2.0: Game Over
Lunar Eclipse and Green Comet Make for Busy Friday Night in the Sky
JavaScript performance on Android have been lagging behind iOS for years now. (https://meta.discourse.org/t/the-state-of-javascript-on-andr...)
CI and deployment tools have matured a lot. I'd call them development tools.
Isn't a H-1B a form of indentured servitude? As in, if you change jobs you lose your visa?

If yes, you don't get the competent ones but the cheap ones who have no choice. The good ones work on their terms for whomever they please.

Edit: combine that with kls's answer about incentives, and you see why this visa system isn't quite working.
Arby’s Restaurant Group confirmed a massive card breach hit its stores
Yeah, Safari has stupidly fast startup times compared to Chrome. It's one of the big things that they are working on in their engine.

It's been a bit, and I'm going from memory here, so forgive me if i'm wrong, but...

V8 is introducing a new "interpreter" mode to help here so that the page can start being interpreted ASAP and no JIT overhead needs to force the system to wait until it's done a first pass. And in the long run they want to pull out 2 of the JITs in their engine to simplify the process and speed up the first execution (along with reducing memory usage, and simplifying the codebase to allow for faster and easier additions and optimizations).

It's a great move, but it means that things are going to get slightly worse before they get better.

The "old" V8 had 3 compilers, "Fullcodegen", "crankshaft", and "turbofan" [0]. The current V8 has those 3 + Ignition [1], so it's just adding more on now. But over time they will be removing crankshaft and fullcodegen and it will leave them with a really clean and fast engine [2].

If anyone is interested, [3] is a fantastic talk on this and other plans they have for V8, and it's very accessible for those who don't know a thing about JS engines.

(sorry about the links to google sheets here, it's the only place I can seem to find the infographics)

[0] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...

[1] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...

[2] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...

[3] https://youtu.be/r5OWCtuKiAk

edit: Removed comment about edge, it was more assumption than anything.
Garbage list from a garbage site.
Access to DOM APIs isn't part of the MVP, but it is listed as a high-level goal[1] and is specced as a future feature[2].

[1] https://github.com/WebAssembly/design/blob/master/HighLevelG...
[2] https://github.com/WebAssembly/design/blob/master/GC.md
This article is right about one thing: managers should avoid mechanical metrics (lines of code cranked, bugs fixed, etc.) as a way of measuring developer competence.

Many developers are good at figuring out constraints and optimizing around them. It's a game for us. We're more productive when we're playing that game on behalf of our businesses and customers than on our own behalf. But if you award us points (dollars) based on optimizing metrics for ourselves, we'll probably do it. At the very least we'll have to spend mental energy resisting the temptation.

These kinds of metrics inevitably generate perverse incentives.

It's true that developers should remember that debugging code is harder than creating code. We should avoid creating code that is right at the limit of our cognitive capacity to understand. When we do create code like that, we've created code that's a stretch to debug.

There's a management corollary: don't use the most ingenious incentives you can imagine to motivate your krewe. You'll have a hard time debugging the incentives. And your krewe may exploit your buggy incentives in the meantime.

And, in both cases, imagine what will happen when your super-clever code or incentive scheme is handed off to your successor.

Oh? You want to keep doing exactly what you're doing now for the rest of your career? OK, go for it.
I guess an argument could be made that this would only maximize short-term tax revenue, and only tax revenue that is, as you said, collected from income taxes, which might or might not correlate to the guest worker's long-term direct and indirect contributions to the federal budget (and the American economy in general).
yes indeed. It looks like the iphone 7's time is around 150ms (Safari), whereas my galaxy s7 takes well over a full second (Chrome).
Its a combination of that and Apple's A10 chip being significantly faster than the top Qualcom chips at single thread: http://www.tomsguide.com/us/iphone-7-benchmark-results,news-...