skysight-inc/HackerNews huggingface dataset:
> Learn something else.

No. I've never understood the anti-[language] viewpoint. Wouldn't it be great to have every language available in every ecosystem? Why bother with web assembly when we could just replace JS with python because that's what _I_ want.

[1] Let's be honest, This is every language. There are some stupid, stupid, STUPID parts of JS that everyone enjoys pointing out. And... since everyone points them out, nobody actually uses them.

[2] It happened and they changed the root cause within a week. I would view that as a pretty good ecosystem. Now take a look at python 2 vs 3. Almost 8 years later, and we still need: http://py3readiness.org/

[3] Every language.

[4] Just because people talk loudly about something, doesn't mean most people use it. 90% of the internet still runs on jQuery: http://trends.builtwith.com/javascript/javascript-library
Where is this app running? Is it only on devices you control, or is it running on devices you don't control (i.e. users' phones, computers, etc.)?

If it's running only on devices that are fully in your control, the solution is easy: make the app authenticate with your API using a large, cryptographically secure-random secret key [1].

But if it's the latter, what you're asking for is generally not possible. A competent actor can reverse-engineer your app to extract any API keys or secrets or other tokens that you'd embed it your app, and thereby masquerade as your app [2]. But, as with nearly everything, it's a trade-off. Obfuscating your secret may cut down on the amount of casual requests to your endpoints, but treat this as a developer convenience, and not as a security mechanism.

[1] https://www.owasp.org/index.php/REST_Security_Cheat_Sheet#Au...

[2] https://rammic.github.io/2015/07/28/hiding-secrets-in-androi...
Vinegar + sweetener is the or a fundamental flavor in a number of things, including barbecue sauce, ketchup, coleslaw dressing, several salad dressings, some pasta sauce and chili-type sauces, cocktail sauce, some pickles, and so on.

By that I do not mean "those evil bastards are sticking sugar everywhere", I mean that this is a standard culinary technique. It may be overused and we may consume too much of it, but it is an old technique. It is also one of the answers to the question "how can so much sugar be everywhere but not everything tastes sweet?" Vinegar is one of the bigger answers to that question. (Even ignoring the fact that we can end up very adjusted to the sugar flavor, it is still amazing to me that some things can literally be half sugar by mass and not taste sweet.)

I also mention it because if you want to cut sugar out of your life, this is definitely one of the easiest places to miss a significant quantity. It's pretty easy to make yourself a great salad and accidentally slather it in vinegared sugar.
Python is wonderful for business logic and scientific computations. HTML/JavaScript is wonderful to make beautiful interactive user interfaces.

So at the moment, I am using PyQt/PySide and load my HTML/JavaScript/ReactJS GUI in a webview with a simple bridge object between my Python code and the JavaScript code.

As soon as I need native interactions with the file system, etc., I am using Python, which is robust and proven (and I am used to it). For example, if I need a dialog to save a file, I just use QFileDialog.

At the end, because of a clear separation between the GUI and the computation/system interactions with the bridge object, I just need a different bridge object to have everything running fully online.

One point is of course that I am not developing for phones and tablets, I package everything with pyinstaller for the good old desktop users.
I agree that the last column of the chart is pretty much worthless. The one that tells the amount of gas left in the tank is good to know.
That's easy to check, it not only shows you any dependencies of dependencies (of dependencies) when you install, but it also exists in a package.json which you can easily browse.

For example, the String.prototype.endsWith package referenced above relies on 0 other packages.

Another micro-module I've used, clean-stack[0] is one line, and has 0 dependencies. (it just removes mostly unhelpful node.js stack trace entries). This is great example for me because it's just a regex. But, it's a regex that was just updated 11 hours ago because a new version of node added a new stack trace line that's not exactly helpful, and by updating this package, it will pull in that update, and I need to do nothing besides do a quick sanity check that nothing massively changed, and check that my tests still pass.

Is-reachable on the other hand (a simple module to check if a hostname is reachable), has 6 direct dependencies, with 2 more dependencies of dependencies. Altogether that module adds up to about 300 lines of code (including it's 8 dependencies).

That's not massive, that's not even much at all for a server-side system. And if that module ever goes under, re-making it would be trivial. So there really isn't much of a downside to using it (especially if I vendor my dependencies, which anyone should be doing for a production application)
My Obsession With Chess
Sure, but since that's clearly not the case here, why bring it up?
Continous Deployment of Rails with SemaphoreCI
> The Puritans thought sex was a wonderful thing within Christian marriage

Ok.

> Contrast this with Catholics

Who also think sex is a wonderful thing within Christian marriage.

> who still require celibacy of priests in 2016

"Celibacy" means "not being married", requiring priests to be celibate (which, strictly speaking, Catholics do not [0]) is orthogonal to beliefs about whether sex is wonderful within Christian marriage.

[0] The Catholic Church does not permit priests to marry, but does not bar married men from ordination to the priesthood (it does bar married men from ordination to the episcopate, however.) The Latin Rite of the Catholic Church has a particular discipline which requires that only unmarried men may be ordained to the priesthood, a discipline that was adopted to deal with particular disciplinary problems that arose during the Middle Ages, but which has never been held to be theologically necessary (and which isn't applied within the Church outside of the Latin Rite.)
Yeah I'm pretty sure Emacs can be made to do anything.

I love that idea and I keep telling myself I'll go back and give give it another try sometime. Would love to get really into org-mode, etc.

It's just that Vim is so comfortable! ...like a nice old pair of Goodyear welted shoes.
Frank Lloyd Wright Interviewed by Mike Wallace [video]
There are languages where non-developers can make SOMETHING happen (like make the monkey dance[1]). There are languages where non-programmers can't -- you have to be SOME kind of programmer, good or bad, to make C do something other than look at you unkindly.

1) http://programmers.stackexchange.com/questions/221615/why-do...
The biggest problem with our health, however, is still Obesity. Just as the fat were mislead by being made to believe that "low fat == healthy" these people will be similarly think "low carb == healthy" and proceed to get obese on low-carb foods.

Face it, if you're a healthy weight, by body-fat percentage, you don't have to worry about fructose vs glucose or fat vs carbs.

Americans need to put their forks down. We need to start holding the overweight and the fat accountable for their expensive lifestyle choices.
Wow, seriously impressed by the regular progress on each step. Great "documentary".
The Macintosh Clone Era
I would wonder how long a vapor state would last, before precipitating to liquid, and then freezing into it's final solid form.

I bet the time scales for those phase transitions wouldn't be incalculable, even if gross estimates.

So, if the moon were a vapor bubble suspended in a vacuum, how long would that last? And how long for the heat to radiate out of it?

Sounds like that process would be pretty uniform, and dependent mostly on composition. But the uniformity of the temperature bleed would contribute to the maintenance of a stable orbit.
I'm so sorry, but I simply cannot resist:

Yo Dawg, I heard you like cache invalidation problems! So I put a cache invalidation problem in your cache invalidation problem.
Machine learning algorithms written in Perl 7.
Search for SimCity in this item: http://www.joelonsoftware.com/articles/APIWar.html

It's kinda strange for an OS to be maintained for a long time with that style of backwards compatibility....
>> lifelong damage to their health.

It's only lifelong damage if you don't change your diet and lifestyle. The world is filled with people who were morbidly obese and have made the changes necessary to reverse the damage and live far more healthy lives now.

The way you put it, it sounds like an irreversible course akin to a death sentence, which it most certainly is not.
I would be genuinely curious what the development methodologies for Chauffeur look like, if anyone can point me in the right direction.
I apologize if I'm being too harsh, but I see these arguments over and over again and I don't think they result in anything beneficial. The thing we should be fighting is not-invented-here syndrome and only re-invent things that which cannot be improved upon for one reason or another.
So where are the masses of serious C#/ Java/ <pick-your-language> developers using transpilers to write the logic of their web applications?

I think it is catching on with C++ game developers, who want to be able to run the same codebase natively or in the web browser. The Unity 3D game engine has built-in support for this using WebGL, for example.

I don't know if CLR or JVM languages have been successfully transpiled to the browser using asm.js / WebAssembly (it wouldn't be very efficient at all, so I doubt that will ever be popular).
>> Spend 50 hours building anything substantial with JavaScript and you'll get a good handle on...

I don't mind MY JavaScript. It's everyone else's that drives me bonkers. Tracking down things in JS is a timesuck of epic proportions. Much of the time, it just isnt't any fun.
> that _doesn't_ do this kind of thing

Why does that matter to anyone?

> you'd need a source language that offers much better static guarantees than the typical language that a JIT compiler is written for

Java and C# are both statically, strongly typed languages where JITs are the dominant implementation.

Almost by definition, it's impossible to write a JIT compiler that outperforms AOT compilation without looking at runtime data, because AOT compilers have a lot more time to look for difficult static optimizations. The reason JITs can keep up is because they have access to information that an AOT compiler does not.

> And there's no need to use statistics to optimize anything at runtime when your ahead-of-time compilation step already emits optimal target machine code.

This is simply untrue. For example, it's not possible to statically determine whether a function should be inlined or not. However, a JIT can see that it's used in a hot loop and dynamically inline.

For any language, no matter the type system, runtime information will always be a superset of compile-time information. There will always exist optimizations in a JIT that aren't possible in an AOT compiler.

> Java is as dynamically typed as it gets: `instanceof`, downcasts and reflection, all conspire to reduce the usefulness of static type information to zero.

Idiomatic Java code doesn't use these features heavily. Just because it's possible to wipe out type information doesn't mean that the vast majority of code that an AOT or JIT compiler sees won't be strongly typed.
> This is a discovery process, I'm writing this document to help myself understanding golang and maybe help others.

First: I took a brief look through this, and I didn't see anything that jumped out as wrong. It's a pretty comprehensive document, especially for someone who says they're just starting out, so kudos to James for writing it!

That said, from my experience in teaching Go classes and workshops for beginners, comparing embedding to inheritance is usually a bad idea. It's not that there aren't similarities, but in my experience it prompts new Go programmers to write unidiomatic Go code when they think of embedding in that way. They end up embedded structs the way they'd use inheritance in object-oriented languages, and since Go isn't really intended as an object-oriented language, it makes for unidiomatic code.

The main use cases of inheritance in OOP are accomplished by interfaces in Go, not struct embedding. But at the same time, the main benefits of embedding come from embedding interfaces - embedding structs is almost an afterthought in the language. In fact, I tend to advise people against embedding structs altogether. There are a few cases where it's worthwhile to embed structs, but the use case for embedding interfaces is much more powerful.

My advice for Go beginners: use interfaces more than you think you need to, and forget that struct embedding is even possible. This rule of thumb helps to write more idiomatic Go code when you're just getting started, before you have a feel for what that really means.
Okay. I will just make a new account. Welcome to the internet, newb.
Gifs are great to explain visually.

The gif on this page is really bad at it.

Slow it down. I have watched it loop 5 times in the last 30 secondes and I still cannot tell what it is without reading the text. I feel dizzy.
That is largely because you need to squeeze more than one orange to get one glass of orange juice.
Mobile Development or Machine Learning?
I'm studying Computer Engineering, I just finished my freshman year and I feel really happy about my choice of uni (I'm european, so sorry for my bad english). I've been developing android apps for the last two years (nothing professional, just for fun). I find it really gratifying and rewarding. Being curious, this summer I studied Machine Learning mostly through the course on Coursera and exercises on Kaggle. I enjoyed it, but I didn't find as rewarding and fun. Working only with datasets simply isn't as exciting to me. My question is: being Machine Learning so popular now and in the near future, would it be wise to focus my attention (and possible future career) on it? I know it doesn't sound very specific, but I feel like I have to make up my mind on which technology I should study so that I can make a career out of it.
If you had 20 pounds to lose, you weren't healthy. You were fooling yourself. Healthy people aren't carrying around 20 extra pounds of fat.
Not so much a software bug, but back in my early days (late 1990s) supporting an office network in London there was a computer where the mouse was making the cursor behave erratically during roughly the same period every afternoon. We swapped out the mouse, the controller card, even the computer - effectively replacing all the physical equipment - and nothing seemed to stop it. We went through all sorts of ideas - too near the microwave, heavy fax machine usage, someone's mobile phone - until we realised that it was optical mouse, and the sun would shine through that window each afternoon at the same time and screw up the sensor in the mouse. We stuck a bit of cardboard to the side of the desk and it never happened again.
Well put mate. It's just too convenient to experiment/develop manipulation of people's perception of reality in such a context (ISIS). Who can complain about it without risking being called a which, oops, a terrorist?
I don't know, but that's been the plan for New Shepard since the beginning.

IIRC it's more of something for millionaires that want to be "among the first" to get into "space".

Again, i'm not sure how viable it is, but that's been their public message. They even have a few videos on youtube advertising it

https://www.youtube.com/watch?v=-YJhymiZjqc
How would people merge code in a large codebase? Copy / Paste?
Ask HN: Is it ageist to judge an older applicant for lack of achievement?
So, this is a question that I've been pondering lately based on recent interviews. The position I am interviewing for is entry level for us, but not entry level overall. We look for 2+ years of experience for candidates. It is not unreasonable for a candidate with significantly more experience to apply for this position, though rarer (typical candidates have 2-7 years professional experience).

Is it ageist or unfair in some other way to judge a candidate with a dozen or more years of experience for not having progressed past the level of capability that we expect from people filling this role?

I try to be very conscious about making a hiring suggestion based solely on merit and suitability for the role, but I do not claim to be perfect.

On the one hand, it shouldn't matter if someone took two or twenty years of experience to get to where they are if they are both equally capable now.

Of course, we also look for people who have the potential to grow out of the position. It's hard to consider the person with twenty years of experience to be equally capable of continued development as the person with two.

It would not be unreasonable to make a career of this position, just moving up from $position_title_I to $position_title_II and so on, rising in seniority. I don't think we'd be satisfied with someone who was satisfied with that, though.
http://www.bankrate.com/finance/auto/dispelling-two-pesky-ca...

> The good news is that the "low fuel" light comes on when there's anywhere from 1 to 2 gallons left, which is plenty to keep the pump safe.

Yeah, but you pretty much have to be under 1 gallon for it to be an issue.

Similarly, for what the OP mentioned:

> But modern fuel pumps have a protective screen or porous sock-like cover that catches any contaminants before they enter the fuel system. And those small bits that might get through would normally be caught by a second filter closer to the engine.

The location requires a filter to avoid that problem, regardless of fuel level. xD
While I have seen such a distinction (see my sibling comment), I think it has peaked, and is on the decline. Furthermore, it has more often been outspoken members of one group excluding the other rather than systems researchers or theoreticians not calling themselves "computer scientists."
Wireshark let me find out that Unity's WWW class ignored request HTTP headers on iOS, causing our usage of S3 to fail. I worked around the problem by switching to URI based authentication.

On-screen keyboards displayed Chinese after visiting a system menu. We freed the async operation when the system menu "canceled" the keyboard operation (it wasn't supposed to be even displaying), but apparently the system had a use-after-free bug. I worked around the problem by switching to a 4 entry LRU allocator, keeping the past 3 or 4 canceled operations around untouched (1 would've probably sufficed, but I'm paranoid.)

A WinRT API to check internet connectivity would exit(3) our app without error messages or related callstacks - but only if the Charm bar was open for more than 10 seconds, assuming you called it once per frame on the main thread. I had to bisect our history to figure that one out - and repro in a new test app to confirm it was the real cause.

EDIT: Third party injected DLLs crashed our app at least twice - once for some monitoring software on a coworker's computer (crashed when closing file handles as build tools tried to clean up and exit), once for an old Microsoft Word IME that predated the Win8 app sandbox who's restrictions it was violating. The monitoring software was uninstalled, the IME I couldn't think of a reasonable workaround for and left to Microsoft to fix.
Why are their charts always an image file? There are so many easy to use charting libraries with sorting, formatting, etc. Even easier to use out of the box with no need for async data...
>Yeah. But humans haven't had fresh fruit available all year round until recently.

Which humans? There are many tropical regions where fruit is available year round.
Why Pioneers Have Arrows In Their Backs: https://steveblank.com/2010/10/04/why-pioneers-are-the-ones-...
I don't think you know what you're talking about.
PHP, up to version 4 at least, was hardly even a language. More like a collection of macros.

Javascript, despite a few ugly gotchas, is an elegant language with a few simple rules that allow for an impressive degree of freedom and flexibility.
The Perverse Incentive of Google AdSense
Wasn't there some news recently that sleep deficiency is positively correlated with heart disease?

Something like this http://www.nhs.uk/Livewell/tiredness-and-fatigue/Pages/lack-...

There was also some news recently that working in a place that grinds coffee causes lung cancer http://www.npr.org/sections/thesalt/2016/04/15/474325037/cof...

Probably if the sabre-toothed tiger gets you before the age of 35 you won't get cancer or heart disease. But if you live long enough and the cancer doesn't kill you the chemotherapy will.
Fine. Name a better stack then and suggest ways this one can improve.
The automotive world and software engineering are very far apart. There are very few people who are truly at home in both. What Apple does is consumer grade, not safety critical. Let's just take EMC. I'm sure Apple does think about that, but that is nothing compared what you have to do for a car.
No. Javascript frameworks/tools change every few months, by the time you finish a project, everything you used has been superseded by something new. Last year's expert is today's luddite. Change at that pace is unsustainable for long term support of applications.
Ah ok, fully agree on that people should explore alternatives... (I'm trying to get people on Signal and Wire, instead of Skype/Whatsapp/FacebookMessenger/Viber/...)

As someone has highlighted above, though - there is the coordination problem, that everyone (or at least most people) would have to migrate. (But then - it's happened: Friendster, orkut, ...)
My biggest issue with these apps is the inability to share memory. If I have Viber, Slack, Atom and regular Chromium open at the same time, they all consume copious amounts of memory which I assume is due to the constant overhead layout/JS engines need to keep resident per app.

If I'd somehow opened all these as tabs on Chromium, they would plug into Chromium's already-allocated shared data structures and the memory consumed would be quite lower. I can have Facebook Messenger, Deezer and Gmail open alongside 10+ other tabs at all times, but once I start Slack and Viber alongside Chromium (or Skype for Linux Alpha, or Visual Studio Code, or Black Screen, or any of these trendy hybrid-web-desktop apps), Linux starts screaming and swapping things around; as a result, everything becomes sluggish.

Also, the apps themselves feel a bit laggy even when they have all the memory they need. I know the comparison is not fair, but using, say, Code::Blocks or QtCreator (which are full-blown IDEs) with Atom, I can feel input response differences for some reason.

I have a low amount of RAM on my home PC and I plan on upgrading it, so you can say that my hardware is the problem, but clogging up memory like that is always a waste.

As a test, I just opened Popcorn Time. Right after startup, it uses 200MB of resident memory. The whole GNOME shell + the Xorg process consume around 280MB combined on my PC. That's insane. Yes, it looks beautiful, but it's nothing you can't do with Qt these days. It also supports JavaScript. QML is not hard to learn. It's available for Windows, Linux, OS X, and even mobile. Ditto for GTK+ 3: Vala is beautiful, practically C#, and good enough for at least the UI layer of your app, if not for the whole thing. Qt and GTK+ are both open source and LGPL, which means you can freely link to them even if you develop proprietary software.

I just don't see such a need to make today's apps so bloated (and I don't consider "people have enough memory nowadays" a valid argument). If it's an one-off app made by a small team, or for fun, the trade-offs may be worth it. But for Slack, or Skype for Linux, or VS Code, wouldn't it make sense to put more developer time on it and have a much more performance-conscious application?