skysight-inc/HackerNews huggingface dataset:
Hi.

Thank you. I have read the wikipedia entry but I have to say that DRY seems obvious to me. Is this really a thing? Am i missing something? I just try to write code that is easy to read. And I try to reuse code as often as it makes sense.

That list of books looks good by the way. Thank you
It doesn't help if the DNS provider has multiple servers, and they're being attacked. You need unrelated DNS providers, and not the same unrelated DNS servers others are using.
http://stateofjs.com/

If you're really unpatient, I'll click on the first link for you[0]...which reveals the popular frameworks. This is based on real data since it's a survey, not just one or two comments on HN.

[0] http://stateofjs.com/2016/introduction/
How so?

IPFS so only as resilient as you are good at dodging DMCA notices.
Another avenue for picking up some work and potentially new client or even full time {remote} jobs is signing up for email list at place like http://nextspace.us/ and other coworking shops. I don't know about others but nextspace.us has (or used to have) a members-only internal email group where people (founders and such) ask for some one off help with scripts and such for a fee. It seemed like a good way to get some small work, but most importantly, business contacts.

Because it's not a totally anonymous place, the groups seemed to have much less douchebags.
> Anyone who has been a freelancer has dealt with the random, uncalled for threats from clients to give you a bad review or try to suspend your account.

This. Totally. Several times, at 3/3 platforms where I've been working (for over two years now). Surprisingly (not), they (the clients) can do this and get away with it any time, but I (the freelancer) can't.
Actions of one (presumably) manager guy doesn't reflect company as a whole. Yelp/facebook/etc. isn't for rating how company deals with freelancers. Don't be childish.
It is bad from a client data perspective as well.

If the freelancer has more than one client and they are "multi-tasking" by working on multiple projects and have apps like email, chat screens , web pages open etc and forget to shut them dowm before the automatic screenshot is taken, information will "leak" between one client and another.
That's kind of the point. That is exactly what's happening in the research community, plus the inefficiency of people stepping off the mapping process as soon as they find some mechanism that might slightly slow disease progression, and then focusing on that rather than something that might clean up the damage instead of slowing it down.

Not enough of the research community is doing the other thing, the repair and reversion of differences between old and young tissues carried out in advance of full understanding, so as to aim at cures rather than delay.

Alzheimer's, funnily, is in a much better position than most other age-related diseases because a large chunk of the mainstream of the research effort is actually directed towards a repair-of-the-differences approach - removal of amyloid via immunotherapy in this case. That choice of strategy isn't true for heart disease, diabetes, dementia, etc, etc. If we want to see cures for age-related disease, there must be a sweeping change in the research community's high level strategy, towards repair of fundamental damage that distinguishes old tissues from young tissues, and away from tinkering with the disease state to slow it down or to compensate for some of its effects.
Basic can mean very different things depending on the purpose, audience and market the app is targeted at.

If you're building simple CRUD apps for a business audience both Rails and Spring Boot would be good choices for instance.

In terms of front-end development I'd suggest vanilla JavaScript and HTML5. Keep things simple. A basic web app doesn't need any complex framework.

That said Angular, React.js and Vue.js are equally valid choices for building complex applications but each of them is way beyond a 'basic web app' scope in my opinion.
This. You can't turn an aircraft carrier on a dime but if you get it turned around in time you usually win.
One consideration I'd like to point out is how the audience changed over time. I'm not saying anything like "HN is getting worse every year", but rather that it started at a startup accelerator, before startup accelerators were popular and at a time when startups weren't as popular as they are now. The crowd was more insiders at the beginning, and insiders may have more insight into what will / won't succeed from their experience.

Another point, and I wish I had data but this is purely anecdotal, is that it seems like the side project --> startup transition is happening less. People are content making small side projects, doing hackathons, etc but not making that business their life (upsides and downsides to this).
Inside the Tech World’s Hottest New Bar
Most Smalltalks didn't really have great code completion (or code completion at all), and when they did, a lot of it had to do with the verbosity of method signatures removing a lot of ambiguity. Don't get me wrong, Smalltalk has some really cool features, but they did it by having a workflow completely different from static languages, and trying to imitate Smalltalk's environment in a language not designed from the ground up for it (ie, python or perl or whatnot) would be a lot harder. The fact that it's hard to write language tools in general doesn't change the fact that it's way harder to write an IDE for a dynamic language than it is for a static one.
There is a real cost to properly modeling your domain in the type system. You have to conform with the constraints of the type system, there is higher cognitive overhead, it can cost more up-front (which can cause missed deadlines), etc.

Also, there are cases where using strings is more appropriate than using enums. Where passing a blob is preferred over guaranteeing the correctness of the blob's structure. Where "null" really is better than an Option type.

And conversely, there are companies who hire crappy developers or don't give their good developers enough time to learn the idioms and best practices of their tools.
New World Hackers, responsible for the recent Dyn attack, has retired
Code is prose, maybe, but there are definitely lots of different types of prose, and I don't think code would be one of the types of prose that has protagonists, comedic characters, and damned villains (or if it is, it should not strive to be so). In other words please this recurring code is like great literature kick is really irritating.

maybe one off scripts should be like lyric poetry though.
Nobody else has said it, but I guess I should then...

Does anybody else find it odd that this mans real name is: Shadi Al'lababidi

However, his UpWork profile is: Shadi Paterson

I've seen this done quite a bit when companies (especially the American kind) ship their support overseas, but are either too embarrassed to let their workers use their real names OR justify such actions by saying: "Some Americans will find it difficult to say your name" (or in other implicit scenarios, because your name is Muslim-sounding - or X-sounding - will associate you with terrorism/other-ism).

Imagine the world we live in, where in order to do a job (or get work), you have to literally change your REAL name to appease to the demographic.

Whether Shadi did this of his own accord or was instructed to by UpWork to 'passively appeal' to the hiring-clients, it is quite a shocker to see it YET AGAIN.
You raise an interesting point; in comparison, Product Hunt is essentially the opposite.
Fantastic! I had a similar experience in the mid 90s, though I wrote a Zork clone :)
Stan (http://mc-stan.org/documentation/) is arguably the most advanced language. It's especially pushing the bounds of doing automatic variational inference, for the scenario where your model does not have a nice conjugate form that would be amenable to Gibbs sampling. It's not quite reached what I would say is production-quality, but some of the best people in the world of computational Bayesian methods (e.g., Michael Betancourt, most of David Blei's lab, etc.) are working on it.
Aww shucks. Thanks for the shout out.

I realize reading this again that I owe a more significant writeup -- I started one not long after this and wasn't happy with how it was shaping up. Maybe I'll have another go at it.

Since writing that comment two years ago I've added a couple more examples consistent with the ones in the original post.

One thing I keep seeing is how teams seem to think that the planning stage of this kind of work involves figuring out how to shove the problem into the big-data platform du jour instead of figuring out how to solve the problem that has the business need. When they're working with the platform, and hitting the inevitable and unplanned for performance issues (because, you know, just shove the node to the hadoop cluster and it'll magically take care of that), the solutions never tackle the algorithmic bottlenecks but instead seem to focus on messing with the platform or changing platforms, or changing run-time languages or throwing more hardware at it.

If you are having trouble taking the nuts off your wheel to change a tire, using a bigger hammer or a blow torth isn't going to help. Take the time to find the wrench, of the right size, and then things will work much better.
How to become the Elon Musk of X
Are you implying that ADHD is not a real condition?

If so, what makes you think this is the case?
> Bonds are also the rich man's way of getting paid by governments.

Unless the government, which has the power to break the agreement, breaks the agreement.

The history of finance is well-woven with the thread of sovereign defaults.
I took a look. Main feedback is it's just an info page with email addresses... You need a webapp, a platform, signups, etc., if you want people to consider participating. Something that can be put up in a couple hours does not instill confidence that it's a serious thing. Just my opinion.
This falls under not repairing enough of the damage. If the view is that delaying Alzheimer's to let people die from heart disease a couple of years later is great, well, that's a problem. It isn't great. It isn't sufficient. It is taking an entirely too narrow a focus. It is deliberate aim at a worse outcome rather than a better outcome. Cures, not postponement, across the board must be the strategic goal - it is a shirking of responsibilities to shrug and say it is good enough to push off a disease for the year or two that would reduce its mortality rate if all other conditions kept happening at the same level as today, rather than aiming higher.
I don't think that there's a single "best way" to learn anything:

- Different people have different learning styles, so what works for one person may not work for another. For example, I get much more out of reading books than from watching lectures.

- Different people have different amounts of time that they can devote to learning, and have different limits on how long they can keep their attention up.

- Different people have different backgrounds. If you're a mathematician who is learning to code, you might want to approach it very differently than a novelist learning to code.

- Different people have different financial situations. So advice like "enroll in this bootcamp that costs $6000" might not be possible for you.

Also, if you're looking for recommendations for specific resources, you need to specify which programming language you're interested in learning.

So unless you tell us more about yourself, your background, your goals and what you've already tried, you probably won't get information that's useful to you.

One thing that I think is universal: to learn to code, you must write code. You can't just read books or watch videos, you need to actually do the exercises (which may seem very simplistic and boring at first) and get them to run correctly. Learning to debug is an integral part of learning to code, since even fairly simple programs are hard to get right the first time.
Swift on Linux
For frontend, I prefer PolymerJS with vanilla JS. The way it scopes CSS/HTML/JS is cleaner, and this is the right direction. (I never use ReactJS.. but it might be similar).

For backend, I prefer Play + Scala over Ruby/Python because of the static typing.
Um. Good morning? Didn't Germany call for a ban of combustion engines by 2030 just two weeks or so ago? These graphs are wildly optimistic if that happens.
> ... always watch out for red flags and get out of the deal as soon as you see them.

...and keep your fingers crossed that the client doesn't leave a negative review for you - or that s/he doesn't do worse, as it happened in the case of the OP.
> Why invent a new one and not use JSX?

JSX is a new templating language too. It not standard; it not JavaScript.
> Because the hype will be with the new, and auto makers will be perceived as "old" even if they release electric cars, which will be tough because they're already behind Tesla.

Much like how Red Bull completely replaced Coca-Cola.

Or that time Microsoft was replaced on the desktop by Ubuntu.

Or that occasion when the Segway killed off bicycles.
Because mirroring content on IPFS is trivial and transparent to the consumer. All it takes is a single user (or an arbitrary number) outside of US jurisdiction and the content is more or less DMCA-immune.

The equivalent is not practical in traditional HTTP, where content at risk of being taken down is scraped from the server and that snapshot-in-time is hosted as a mirror, generally at a different domain.
Powerwall doesn't make a lot of sense. It's about 30-40% more expensive than other batteries that were on the market when it came out.

And, while Tesla cars might be bragworthy and worthy of showing off to your friends, house batteries are not. All that really matters is cost and efficiency.
You are clearly fond of democracy as a solution to conflicting social goals. Democracy has some nice properties, but also downsides: notably it can only try a single solution at a time.

The idea behind decentralized architecture is: instead of trying to find a better way to agree on one thing, how about we assume from the start that different people will want different things? What do we actually need to agree on?

In the old days we had to agree on everything, because it was technologically infeasible to coordinate plans more than a few times per year. If you need to move bodies to communicate, democracy is what happens.

But we live in a new time where messaging is close to free, so we don't have to agree on everything ahead of time. In a totally decentralized world, we wouldn't have to agree on anything ahead of time. I would meet you in the forest and our respective AIs would go to work helping us quickly and safely negotiate an entire legal framework and set of treaties governing our interactions.

I don't think we will ever get there, I think it will always be a mixture of decentralized and centralized norms. But right now the decentralized architecture is brand new, so it has a huge headroom for growth, so it just makes more sense putting effort into it.
You are exactly right. Same exact thing is happen to me too.
I second Dan's advice of blogging more.

I'm a very average HN commenter. I do put in effort in writing here, trying to be civil above all and sharing my experience where it could be of interest. But I'm not Alan Kay, I've never rewritten a distributed deep learning system in Haskell using a genetically optimized Paxos consensus protocol, and my entrepreneurial experience is a loose string of "don't do this" case studies at best... So my comments certainly won't make anyone's "Best of HN" list.

Last week, after the news broke that Salesforce walked away from buying Twitter, I was about to write a HN comment about what Twitter could do. The text got long enough that I decided to expand it into a Medium post instead: https://medium.com/swlh/twitter-could-be-the-next-mozilla-e7...

To my surprise, the post has 28,000 views and 755 recommends so far. If I had written it as a HN comment, it would have got maybe 5-10 upvotes and perhaps spawned a short discussion thread about how unrealistic my idea was. (Please don't bother to criticize the content of the blog post in replies here -- I'm just using it as an example of blog vs. comment.)

I love reading HN discussions... But maybe there could be a site that slots between the HN and Medium formats, and lets you expand your comment into a blog post with minimal friction? Call it "HN Long-Form" or whatever. Ideally it would interface with the HN comment system so that you could mark your comment with something like "Promote to long-form" after you've written it. That would create an editable post on the long-form site. You could then later expand your comment there, and publish it on the long-form comment aggregator site. (Maybe I should just build this myself and see if it feels right.)
Credit markets dependent on oil survived the "superspike", the decline of output from several Middle Eastern countries, the rise of US secondary and Canadian oil production, the substitution of natural gas for oil in power generation, and the resulting oil glut. Those were fast events, a few years at most. Conversion to electric cars is going to take a few decades.

Anyway, batteries are not an energy source, just storage. Somebody has to build generating capacity.
Ask HN: How can I make your life easier when reviewing a PR?
If you were assigned a PR, what could the submitter do to make your life easier and reviewing process less painful?
Those sound like positive recommendations to me! I guess it's a matter of what you read into it, but I'd be a lot more suspicious of the returns of a fund if the guy running it had a rap artist lifestyle.
Thanks for a great link, but it's only JS – meaning all other backend frameworks were not included in the survey.
> Destroying value is not such a big deal since after all value can always be created.

?! I'm not sure what you mean by that, but value is rather hard to create. Certainly the value in real estate and physical goods. Stock value and services are a bit more ephemeral.

But the reason Keyensian hole-digging makes sense is that labour is a wasting good - you can't store the output of people who would otherwise be unemployed, and having people unemployed does long term damage to productivity.
Upwork seems to always take sides with the company/client. It is terrible practice and very scary for freelancers that use upwork as primary income generator.
I had few challenges with upwork and it took weeks to resolve. Seems as freelancers have to walk on eggshells around upwork support or clients when issues arise.
I guess there is a huge opportunity for the next upwork.
Oh shit, I got it backwards: CHICKEN needs native threads! That way, you could implement fibers.

https://wiki.call-cc.org/man/4/faq#does-chicken-support-nati...
Theres no acceleration/deceleration, so I'm pretty sure there are many superior systems.
Ahyes, I'm so stuck in JS-o-world that I forgot there's an actual text format called HTML. Thanks :-)
Are you an experienced web programmer and already know how to manage migrations, CDN, REST apis, etc ?

If not, I would still go with Rails. Its massively productive, batteries included... and forces you to learn some practices that you can later take to other frameworks (migrations, asset pipeline, etc).

I dont know of any other framework that forces you to adopt these. On HN, you will find a lot of rhetoric against that - which may be true for experienced programmers.

But for sheer productivity from someone new to all this... Rails really cannot be beaten.

In the JS world, you will spend atleast a couple of days figuring out Requirejs vs AMD vs commonjs vs webpack vs browserify vs npm vs yarn.

I'm not so sure if it is worth it...unless learning JS frameworks was your goal all along.
I think you can build a simple web app very quickly using Create React App on the frontend, and a REST or GraphQL API on the backend.

One great thing about this architecture is that it can scale as the app gets more complex, since you can just add more components to the UI, and more fields to the GraphQL schema, without needing to re-structure anything.

I work on Apollo, a set of tools to make it easy to create and use a GraphQL API, and we have a hello world client [0] and server [1]:

[0] https://github.com/apollostack/frontpage-react-app
[1] https://github.com/apollostack/frontpage-server
You don't need to know what that is to use the languages :). In essence, functions always take one argument plus a "continuation," which takes the value that would have otherwise returned. This is called a trampoline. It's typically a compilation technique rather than a programming style.
Would your objection be appeased if he said "comes with the environment"?

IDK of any Python, Ruby, or PHP runtime that has Node's paradigm of single threaded + concurrent I/O.
When every minute is probably like $10k+ in "cost", I can see why you'd schedule every minute.
Most of the bondholders are pension funds and (re)insurers, which makes not getting paid have knock-on consequences for the rest of the economy.
The difference really is more in the architecture than in the programming model or the instruction set. SIMT programs, such as OpenCL kernels, can indeed be accelerated with SSE/AVX, but it is not that efficient (in silicon utilization). Intel's cores are fat cores optimized for single threaded programs. But if you don't care about single threaded performance and optimize for throughput in SIMT programs, the fat core is not a great idea. It is more efficient to hide latency to DRAM with computation rather than through caches, super-scalar and out-of-order execution, register renaming and so on. Expand Intel's SMT (hyperthreading) from 2-threads to 1024-threads, get rid of all the stuff that's there to hide latency and use the saved silicon area to add more cores, and you're looking at something that resembles a GPU.
Ask HN: Is it really that hard to iterate in Android Development?
I'm omitting the url to be fair to HN readers, nonetheless this is actually a promoting post to my latest blog entry. If this is unacceptable, feel free to bully me. :)

http://blog.dperini.com/android%20development/2016/10/23/my-approach-to-developing-software-fast-requires-improvements-android-edition

In this post, I am complaining about how hard it is to develop trivial UX in Android using what is enabled by the platform. I tried to share learned experience to be clear about what the existing hassles are. I'd be delighted to listen other people's experiences in this field.

Things that I am having trouble finding solutions are these (partial copy/pasta from the blog):

* A way to reduce amount of work to write new data models. (avoiding reflection is hard)

* A design pattern to express view state without modifying represented data. I don’t want to add view specific bool flags to a model. A state object that wraps the model without modifying it looks dirty but maybe a way to go. It seems dirty when a Fragment needs to persist that state instead of just the data model’s entity object.

* A client generator to be able to benefit from server docs in order to generate client calls (something more lightweight than Swagger and easy to inject into our own HTTP client).

* Much better Intent handling for push notifications and result expecting Activity transitions. Native Android approach looks hideous (or not).

* A way to optimize view count in a RecyclerView cell.

* A way to reduce build times. Multidex looks unavoidable.
That's why I think a war with the US and China would never happen. Too much debt wouldn't be paid and it isn't actually profitable.
Wealth taxes would be even fairer.