skysight-inc/HackerNews huggingface dataset:
i strongly suggest JS user to learn and use mout. A lightweight & simple alternative to lodash/underscore (and a spiritual successor of mootools)
Wasn't Vice City was the Grand Theft Auto of 2002/03? ;)

More to the original point, the first GTA remains along with Age of Empires one of my all-time favourite games. It's easy to forget in light of the franchise it became what a novel and crazy little game that was.
> It's likely that Alexander would have taken over Italy had he lived a couple more decades.

At the height of the greek empire, it's pretty much a given that alexander would have easily conquered italy. But there was no real reason to as italy/rome back then wasn't really worth conquering compared to egypt, persia, india... I suspect had alexander lived long enough, he would have move further into india and maybe even into china. Not sure how successful he really would have been, but it's an interesting "what if".

> History is full of civilizations that fought bravely against invaders and were destroyed. It's also full of examples of civilizations that surrendered and thrived. It's a hard pill to swallow that "cowardly" surrender can often be objectively better than "stubborn" bravery.

The most poignant example of this is Catholic Europe and Islamic Khwarezmia when Genghis Khan sent his emissaries to each. The leader of khwarezmia had the emissaries tortured and killed and refused trade relations with genghis khan. The pope "surrendered" to genghis khan and established trade relations with the mongol empire. Khwarezmia got destroyed. Italy/Europe got direct trade with the largest empire in the world and got immensely rich which kicked off the italian renaissance and the rest is history.

Of course there are counterexamples as well like the english stubbornness against the spanish empire ( the destruction of the spanish armada ) and most relevant to us, the american revolution.

The key seems to be, if you are going to be stubborn against a major power, be damned sure you can win.
I got into Vue because it was much easier to approach coming from a back-end (Python/Flask/Jinja or PHP/Symfony/Twig) perspective. It made it easy to adopt small pieces and learn as I went. React probably allows this sort of thing, too, but the documentation for Vue pointed it out first thing. Since I've started working with it, I haven't gotten a compelling reason to change to react or angular.
lodash and moment are poor choices to showcase. lodash is mostly moot with ES6 and beyond. date-fns is a cleaner version of moment.
I grew up in a rural area and had the same experience with math and tech as you. I don't think whether or not I was in a rural area was a significant factor in encouraging or discouraging an interest in tech.
Sounds cool. Went to your website on Chrome on Android and it is buggy. I get 404s everywhere. More specific, when I click the carousel--showing SF example pay--left or right.

Like I can do a better job than that.
It might be because Musk is a hypocrite, with vested interests and a dubious relationship with the truth.

Just a couple days ago Musk tweeted out he would enable 'full self driving features' in August. It was a craftily worded, trivial statement, and basically means that people who paid for FSD would get a few minor upgrades.

Nonetheless, several dozen media outlets happily, uncritically gave him some free advertising, with many falsely implying or reporting outright that Tesla's would actually be able to drive themselves come August.

Did Elon get upset about that? Of course not. Lie, distort and pander all you want, so long as you're saying nice things about Tesla.

Say something negative about Tesla, though, and it's off to the Ministry of truth with you.
You absolutely never need to put that disclaimer on a forum post. You could outright claim to be a lawyer providing legal advice and there would be no worries.
It's very much in the same state that VB was, or even "Excel programming" is today: it certainly works and it certainly produces a lot of business value. It's just that the downsides appear further down the road; maintainbility and scalability issues, or intrinsic conversion causing data loss. That kind of thing.

Every time someone waits for an Electron app to load, or watches it eat their ram? That gets added to the prejudice scale. Every overly-slow page load that eats mobile battery. The feeling that "it doesn't have to be this way" is very strong.
The best way to iterate and do stuff with enums that I know is this way:

enum {
FOO_A,
FOO_B,
FOO_C,
NUM_FOOS,
};

struct FooInfo {
int kind; // FOO_??
const char *str;
const char *long;
};

static const struct FooInfo fooInfo[NUM_FOOS] = {
{ FOO_A, "FOO_A", "The A of all the foos" },
{ FOO_B, "FOO_B", "The B of all the foos" },
{ FOO_C, "FOO_C", "The C of all the foos" },
};

for (int i = 0; i < NUM_FOOS; i++) {
printf("Got #%d, %s. Description: %s\n",
fooInfo[i].kind, fooInfo[i].str, fooInfo[i].long);
}

More goodies:

// if you want to use them as bitmasks
// (but only few enums are used this way)
enum {
FOO_A_BIT = 1 << FOO_A,
FOO_B_BIT = 1 << FOO_B,
FOO_C_BIT = 1 << FOO_C,
};

// if you want to make strings out of C symbols, you
// can also use a macro like this:
#define FOOINFO(name, long) { name, #name, long },
static const struct FooInfo fooInfo[NUM_FOOS] = {
FOOINFO( FOO_A, "The A of all the foos" ),
FOOINFO( FOO_B, "The B of all the foos" ),
FOOINFO( FOO_C, "The C of all the foos" ),
};
The way the article's written, it's putting much more emphasis on the slight and sporadic outperformance of boys in math, rather than on the much stronger and more consistend outperformance of girls in language. That's the problem with the agenda, IMO.

Edit: as mlthoughts2018 points out, the title could as well be:

"Boys, increasingly abandoned in English class, turn to math as a domain in which they can be rewarded for success-- especially in rich, white suburbs."
10 Useful Snorkeling Tips for Beginner Swimmers
Statistics – the rules of the game
>Most language features, really.

Name a few.

>terrible "prototype" system

>malice that is "this"

It sounds like you are talking about ES5, not ES6+
Technically true, but in practice, the culture matters. JS ecosystem is what it is - based on past and current experience, you can't expect efficiency coming from there.
I can't speak to Facebook's intentions or policys(I don't use big blue app at all), but many sites use tools like Full story to discover bugs or watch a customers user journey to discover flows that aren't working well. Some portions of the page are automatically filtered(inputs with type=password), and the rest depends on the team being very thoughtful about marking sensitive portions of the screen as such.

It's a very manual process, but probably one of the most powerful tools for improving user experience I've ever seen. And typically for most businesses, you are keeping these sessions for 2 weeks or thirty days at most.
Never read Masters of Doom but this excerpt about id Software in John Craddock's new book Rocket Jump was a fascinating long read:

http://www.shacknews.com/article/101156/rocket-jump-quake-an...

I grew up in this era so I'm certainly enamored by the nostalgia trip but I have a lot of respect for the team at id, it's fascinating to read about all of the mundane aspects of ray tracing and compressing color palettes enough such that a game like Doom or Quake could actually work. id probably did more than any other company at the time to make programming seem like an alternative subculture instead of a science and to make games these dark and moody experiences that were a blast to play (especially with friends via LAN).
Yeah, I was also missing some measures and discussion of absolute performance (both girls vs boys, and rich vs poor).
"Javascript is literally killing the Earth" might be the most HN comment I've ever read
I get it that the author works for Bit, but it's really not necessary to throw in their own product both at the beginning and as an "honorable mention" at the end. It's much more genuine to just say "hey, we make this and want you to know about it" and carry on.
But not now. Find a major company that is not critically overleveraged thanks to near net negative interest rates few years ago. Now there is a chance that effective rates will go all the way to eighties era numbers next decade, and the next debt crisis may also be close.
2003 was the sweet spot, I always thought. I still have a usb stick with a portable copy of Word 2003 on it from somewhere, that I pull out when Word 2016 starts crashing and locking up.
Are you more front or back end with the JS? You said full stack, but I could also see that being backend C# with frontend JS.

I also prefer printed books. The book second edition is personally my favorite, of course. :) it’s actually at the printers right now, so will be available in hard copy in just a few weeks. The O’Reilly book is also good but leans a bit more towards the experienced systems dev. It may work for you, it may not. I bought a copy of “Beginning Rust” by APress, I remember it being fairly solid.

There’s also a very neat book, “Step Ahead with Rust”, whose goal is to get you to learn the basics of the language well enough to be able to dive into other things. It skins over some stuff, but that also means it’s shorter, and therefore a bit simpler and faster than a more thorough book. It might appeal to you as well.
Why is the war hypothesis considered more likely than say a widespread, long lived contagious disease that had significantly higher mortality in males than females?
If there was a period of widespread warfare for sustained periods, it's hard to see how "clans" would continue to engage in warfare beyond say 50% loss of the fighting forces. Wouldn't some women have joined the clan fighting forces also if it was an existential struggle? Why wouldn't clans have submitted to their conquerors and joined forces against common enemies - which was the pattern in many historical accounts of widespread warfare.
Build a 2-pizza team
what are the arguments against moment/lodash being included in the "javascript stdlib" or the language itself? im sure there are good reasons, curious what they are.
React-native Windows (plugin for UWP)
Facebook didn't claim they don't record what you say.

They said very specifically they don't record what you say for advertising. It was specific enough that it almost seems an admission that they use it for something else.

However, there are plausible explanations for your spouse getting ads for things she's spoken with her phone in the room - for example, the patient googled the medication later or wrote about it on facebook, and facebook knows thay your spouse and the patient likely had a conversation based on location data showing that they walked down a hallway together.
Except they actually are talking about all the versions, including desktop apps.
You can't trust your parents to protect you
Is there a more legitimate source for this announcement? Seems like HN has fallen prey to fake news.
That's the one issue that would most likely rally his base.
I find it funny that youtube made a cool new tech specifically to render UI on tv's and yet it works like shit on any tv I encountered.
Please review and contribute your views on the TC39 Temporal proposal. There’s a polyfill to play with now...

https://github.com/tc39/proposal-temporal
React is a UI layer, but Angular was a full-blown framework with routing, services to handle business logic, and so on.

"Sucking just in a different way" is reductive to the point of meaninglessness; For example, if I'm broke, life sucks in some ways, and if I'm a billionaire, life sucks in different ways, but still usually people clamor to be wealthier rather than poorer.

Angular's UI update mechanisms were(are?) miles worse than React. The prototype-based inherited scopes contained a ton of gotchas compared to React's prop-passing. The $watch mechanism inherently scaled poorly - changes were not localized and required going through all watchers! What's worse, the (primitive) mechanism to localize changes - local scope $digest, was essentially unused by the base framework and by pretty much any app developers(the documentation and the base directives would all use scope.$apply(), which caused a global digest, going through all watchers). There were several micro-DSLs that you had to learn in order to do iteration, filtering, sorting, etc. "Filtering" was a mess, leading to Ben Nadel's articles about it(e.g. https://www.bennadel.com/blog/2766-stateless-filters-don-t-a...). There are practically no lifecycle concepts that are exposed to the developer, leading to a lot of confusion on when a directive is instantiated and rendered, with a reliance on implementation details. Angular used a ton of confusing jargon - controllers(a directive provided by the framework), services/factories/providers(singletons with varying control over their instantiation), filters(actually formatters...), and so on. The name doesn't match what you would expect from it.

React improved on all of these things. While it has its own shortcomings(e.g. explicit passing of props leading to lots of boilerplate code), those exist for meaningful tradeoffs. This is why Vue and React are competing products, but they're both a massive step forward from Angular.

(Disclaimer: I haven't used "Angular", just AngularJS, but presumably calling React the new Angular means we're talking about AngularJS).
Since the underlying tech is React Native (Vue Native) and Nativescript (Nativescript Vue), here's a comparison (albeit written by someone from Progress/Telerik, who maintain nativescript): https://www.quora.com/What-are-the-key-difference-between-Re...

It doesn't touch on the Vue integration, since that's relatively new.
FWIW, this matches my experience. Large new enterprise systems have JWT all over the place.

My first pass counterargument to this is: great! You also have FAANG’s security budget and know how to find and resolve bugs like the FB OAuth2.0 tokens being replayable from 1 relying party to another, right? No? Oh.

The general subtext being: that’s nice but you know nothing of their rationale, underlying work that went into securing it, etc; so if you’re picking up a token metaformat without the massive work behind it, you’re just cargo culting.
This is really interesting. I put up the following weird job ad (not a real job ad). As I wrote it, I strongly imagined a man (to influence my choice of words):

>We are looking for an experienced frontend and backend developer, who is able to advise on architectural choices, gather and discuss requirements, make recommendations, and after approval personally implement solutions using the technologies of their choice. The ideal candidate will have already led a team, recruited junior and senior level developers, trained new developers, and should understand the market implication of choosing certain technologies as it relates to the cost of scaling the team. A mix of agile development practices with well thought out architectural planning is expected. IoT systems development experience is a plus.

You can see the results here:

http://gender-decoder.katmatfield.com/results/bf1fbc53-4e4c-...

Despite my methodology of strongly imagining a man, the gender decoder gave me the following result:

>This advert is feminine-coded

>This job ad uses more words that are subtly coded as feminine than words that are subtly coded as masculine (according to the research).

It specifically said:

>No masculine-coded words were found.

And

>Feminine-coded words in this ad

>understand

----------

I will open up a bit here (hence the throwaway). Actually I personally have trouble imagining a woman coder who has this kind of leadership experience with technology combined with personally coding experience of the type described. (I've never met one.)

I expect to have an extremely strong personal bias: if I got an application from someone named Julia, I would have a first impression that they are unlikely to really make the kind of deep architectural design choices I want them to make. My impression would be that they don't know what they're doing (essentially they have to prove otherwise). I would be less likely to trust them to select and train developers who are later hired for their team.

Let me put it this way: if I got fifty applications and didn't have more information than "I fit the description and have done this, when can we talk" I would "imagine" (bias) more into the obviously male candidates than the obviously female candidates, if the information I have in front of me does not actually mention it. In other words I'm actually legitimately biased.

Despite all this, apparently I coded the advertisement in a feminine way.

I think this shows that the tool is a poor judge of job ad bias. It does not identify genuine, very strong biases. Biases that will keep a woman from getting a call, if she deserves it. Biases that will keep her architectural suggestions from being taken as seriously as if a man had made them.

I'm sexist and this tool does not identify this. This makes it a poor tool.

-------

actually the tool should have identified "led" as "masculine-coded" because it is on their list: http://gender-decoder.katmatfield.com/about#masculine However the list encoded it as "lead" so didn't identify this word.
What the Internet Is, and Should Continue to Be
Or is it? ;)

https://en.wikipedia.org/wiki/To_Serve_Man_%28The_Twilight_Z...
The Security Token Derivatives Are Coming
Its actually practical to start using Vue in existing projects without a complicated transpilation process. It's not ironic, VueJS shines in both scenarios.
I disagree about lodash being "moot".

There are tons of things that lodash still provides that can't be easily replicated.

Just in the last month or so I've used throttle, debounce, uniqBy, memoize, get, and i'm sure more.

Sure, things like map, filter, find, reduce, etc... are made obsolete, and `Object.values` is a huge win to iterating objects or arrays with the same code, but lodash is far from useless.

And the way the library is structured, pulling in just one or 2 functions is fairly lightweight if you are using a bundler like webpack/rollup.
Is there documentation on the structure of the contents? Why is it a list of * followed by + and then a list with no prefix? See https://github.com/ESWAT/john-carmack-plan-archive/blob/mast... as an example.
Definitely not. Unless it's the godawful Mac client that doesn't work for most things, which is possible, since it's using UCWA under the covers.

The Skype for Business Windows client was barely reskinned from the Lync 2013 client. I think they are still only a couple dozen patch revisions apart on the version number.
One problem with the topic of Roman and Greek history is that there is too much of it to cover in a single book. I am forever looking for a single volume book that covers all the way from the founding of Rome, to the republic years, to the birth of Christianity, to the dark ages, and eventually to the fall of Constantinople, with no luck.

Sometimes even amazed that events like the Eastern Roman empire repelled Goths from Italy, and even managed to occupy Rome proper, for a few brief years, took place.
That doesn't really clarify your position. JSX is a syntax, why in the world does that cause maintainability issues? And that tweet is a massive straw man. It's poorly spaced, poorly written and YEARS after React came out it shows that people still don't understand the difference between separation of concerns and separation of languages.
> But this is the overall direction of the internet and social media the past few years. Less freedom, less openness and a move towards more of a corporate tv/news format.

So when are we nerds getting together to make a new internet?
what you described is an outlier.

For the vast majority of data visualizations that are of the standard type, d3 is a not a scalable way to do it. The lack of high level abstractions means developers can't be as productive can be, and the code base implemented for one svg visualization is likely not usable for another, unless you put abstraction wrappers around it, which is basically nvd3, or other d3 wrapper libraries..
> Note that we don't explicitly set [enum values] to be powers of two

> return 1 << static_cast<underlying_type>(o);

Relying on default enum values to and automagically converting these into power of two bit masks is very brittle, and can create unexpected bugs and interoperability problems. The mask values change if the enum changes, unused bits in the middle of the bitmask are hard to handle, and the bit order is assumed with the first item being the LSB. The last point is particularly relevant given the NES buttons example, because it uses a bit order opposite to how the controller data is usually read[1]. This article defines

#define BTN_A 0x01 /* 00000001 in binary */
#define BTN_B 0x02 /* 00000010 in binary */
/* ... */
#define BTN_RIGHT 0x80 /* 10000000 */

The standard controller[2] state is sent from a shift register in the controller one bit at a time. This is usually read by the program as 8 reads from the I/O port, and shifted into a button state bitmask. E.g. something like:

n = 8;
buttons = 0;
while(buttons--) {
buttons = buttons << 1;
buttons |= (CONTROLLER_1_IO_PORT & 0x01);
}

With the buttons being read in the order [A, B, ..., RIGHT], the recommended bitmask is:

BUTTON_A = 1 << 7
BUTTON_B = 1 << 6
/* ... */
BUTTON_RIGHT = 1 << 0

Obviously this is a minor mistake in a (probably untested) example. I just want to highlight how easily this type of "clever" - but brittle - coding style can introduce errors. Defining bit values (and other externally defined magic numbers) explicitly in e.g. a defined-to-be-canonical header file (which might be just those 8 #defines) is much safer and easier to debug/maintain. Then wrap those explicitly defined values into the C++ template for type safety or other fancy features.

[1] https://wiki.nesdev.com/w/index.php/Controller_Reading

[2] https://wiki.nesdev.com/w/index.php/Standard_controller
Technically, maybe. In practice, each language has its culture, its ecosystem. Its set of tools to pick from. Is it reasonable to expect the JavaScript Office will really just bind directly to all the native APIs it was using before, thus incurring only 7% penalty (+/- FFI)? Or is it more likely that it'll have web rendering shoved in everywhere, and then layers upon layers of off-the-shelf JS libraries, thus incuring more like 700% penalty in resource use?
Somebody using 'sugar'? It is not clear to me when or how this library is used...
> The only source seems to be what appears to be speculation by some person on IRC.

It's not just some person on IRC, it's the author. He's citing himself.
Learning Programming with Nim
2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.
In addition to the alternatives already mentioned I really like https://frappe.io/charts
a spiritual successor of mootools

After "smooshgate" I don't think that's a plus point.
While I admire what Ramda, Fantasy Land and such try to achieve, current Javascript runtimes just don't support that. Maybe javascript should be kept as C of Web and compile Reason or Purescript to Javascript.