skysight-inc/HackerNews huggingface dataset:
Machine learning: From science project to business plan
> In what sense was this not a victory for Haskell at the time the paper was written? You can always decompose any programming language L into a collection of X, Y, Z features and claim it's really about X, Y, Z instead of L, but is that a meaningful distinction?

It was the exclusion of a handful of popular languages that either strongly intersected with Haskell of the era (SML), or had other measurable contributions to make to prototyping capability (smalltalk, erlang, prolog). Including SML at the very least, would have let us know whether Haskell's laziness was a help or a hindrance, and including smalltalk would have helped us to know whether C++'s failings had to do with its reliance on OOP or something else (even in 94, C++ was one of the largest and most complex languages that had ever existed). But they weren't even on the table...a baffling decision given some of the languages that did make it in. It looks like a deliberate bias in language selection, and it makes it look like the conclusion was drawn before the study even began.
A change of mind isn't a refund. It's false or misleading advertising that is.
> if you just use C++ ... and only immutable structures, you get most of the "simplicity" of Haskell.

Huh? I cannot relate to this statement at all. C++'s memory model is not friendly for immutable structures.

The semantics of C++ are also substantially more complicated than those of Haskell. Although Haskell has some fairly powerful type-level machinery (if you choose to use it, which you needn't), the value-level semantics are extremely simple across the board. Essentially everything in the entire language is just straightforward syntactic sugar over lambda abstraction/application and constructor application/matching. It gets more complicated (like C++) for high-performance library authors who need to peek under the hood at low-level memory operations, but 99% of users are insulated from that.
> You shouldn't hire people who don't give enough of a shit to take the big picture into account.

Even if you care, you can't know the entire story. I work for a small company, tiny compared to Google, but often we run into someone proposing a change that backtracks on a strategy decided 2 years ago. Luckily it was encoded in a design document or else, how would anyone new find out about it?

New people want to know the big picture, but the best way to do that is to write about your decisions as you are making them, and give them some sort of searchable record.

Personally, I love Github because while you don't have formal design docs---you do have a history of the entire argument of why a feature should be implemented, followed up with a history of all the breaking changes caused by it, and the final reversion. It's great to plunge into a codebase, and see how did we get there, before deciding to propose something.

Have you ever been on a team, and proposed something only to hear "yes we tried that, it failed for X,Y,Z reasons... but no we never noted down starting this 6 month initiative down anywhere except my head".
Fair enough. So are there any further treatment indications, e.g. such as a way to get oxygen sensitive bacteria other than a pill? Likely would help my digestion whatever the cause.

A doctor who examined my tinnitus actually suspects it's nerve damage. However, it may well have been due to the bike accident, so it's hard to tell.

No muscle twitches that I'm aware of. More tension.
This attitude strikes me as very SV/HN and while I can appreciate certain elements here, the answer is the typical one - "It depends."

Rather than regurgitate what most people here already said, let me list a few programming projects, domains, and tasks where at least thinking about design if not writing design documents or spending days, weeks, or months figuring it all out is worthwhile.

* Programming Languages

* Databases

* Operating Systems

* Medical Devices

* Safety Equipment

* Streaming containers/formats

* Encryption

* Security

* Manufacturing/Robotics

* Aerospace / Space

* App Dev Frameworks

* Game Engines

I could go on.

The point here is that there are plenty of things where thinking about it up front is beneficial, if not required, especially if some combination (but not limited to) the following are true:

* Lives are at stake

* Changing it later would be hard (programming languages are an egregious offender, I won't name names)

* Customer adoption will completely derail or forbid architectural changes

* Fixing it will require essentially doing it again from scratch

* Changes will force the creation of patches that will incrementally kill the project or slow future development

Frankly, I think we have too many things that are poorly designed. Most projects I see in nearly any domain are mostly set in stone once time and money is added to the mix. Everyone talks about redoing or fixing things, but it rarely happens except for minor changes. As projects scale up, few people can afford to constantly back out lots of changes and rearchitect everything. Those that do usually fail or don't get a good ROI, and those that don't change fail anyway.

I've worked with all kinds of people and though there are people I have great admiration for, I can safely say that 99% of them are idiots and have no business being programmers. I know it sounds harsh, but I've been doing this a long time and have worked with all kinds of people. Too often I see the programmer's equivalent of an illiterate child that gets pushed through high school. So no, I don't trust people to do the right thing, I merely trust most people I work with to not act maliciously. Most of all, I don't trust myself. As the progression goes as a programmer - your code sucks -> my code sucks -> all code sucks -> my code sucks but I'll live with it, hope it is better than most, and ask people smarter than me for help.

Most better developers I know do in fact right some form of design documents, even if it's just notes and justification why X or Y won't work, but Z "might" work. Many also take a lot of time to think about something before writing any code, but once they do, they actually finish much quicker with less bugs than the young programmers who want to "move fast." Of course none of this is universal, and as I said, it all just "depends." What do I know?
The entire article makes me shudder in disbelief.

It's aimed at people who don't know the difference between UDP and TCP (and possibly wet string). Yet he recommends they implement their own reliably protocol over UDP, and they avoid TCP because it's better to implement your own QoS?

Why not add obtaining PhD in quantum mechanics just to round it out? It wouldn't alter the odds of pulling it off overly.
Ask HN: If your job involves continually importing CSVs, what industry is it?
I was wondering if people still use CSVs for data exchange now, or if we've mostly moved to JSON and XML.
I see. It doesn't seem like the data used by the linked article provides any evidence for or against your hypothesis.

The data here is perfectly compatible with a contradictory hypothesis: upbringing does not matter and top schools/employers are good at selecting future high performers.

I'm not endorsing either hypothesis, but the data here supports the above just as much as your hypothesis (which is to say, not much).
I think you have a very myopic view of history. Things have never changed this quickly in known history. This is similar to how Anthropocene is killing of animal populations because they just can't adapt fast enough.

Industrial revolution somehow made it through via interesting social and market manipulations; it's not clear what it'll be this time.
I really like this metaphor. I have extremely negative feelings (bordering on hatred) for the increasing duration of copyright protection, but this sounds really, really good to me.

I could actually see the average person who doesn't care a bit about oppressive copyright terms actually getting behind this.

Edit: I want to qualify here that I'm assuming such a renewal system would incorporate fee increases that would make it economically impossible for any copyright "owner" to practically extend their copyright infinitely. Increasing the fee exponentially would probably be too steep a slope, but it gives you an idea of what I'm thinking, at least. The original "founders copyright" in the United States-- 14 years w/ a single 14 year renewal-- is alright with me in a no-fee arrangement. Beyond that, though, renewals ought to get very pricey and should be short term.

Longer copyright terms definitely deprives the social good for copyright to exist in perpetuity, but if an "owner" is willing to pony-up very large sums for the public coffers to obtain short term renewals I'm alright with that.
You had me until, "it's a really good signal when they pull out their phone and add it to a to-do list."

Because it's just one of many possible courses of action for staying organized. For all you know the guy added it to his to-do list on his way to the car, or maybe he employs some other mechanic. While you could argue that an interview is a showboating environment where one is expected to signal certain desireable traits, I personally resent that these attributes seem to manifest in recruiters as specific actions that reinforce their perceptions of a good candidate -- if someone is unconventional then how is looking for specific signals going to tell you anything useful about them?
Word 1.1 is the catalyst that got me to try Windows. I was familiar with word for DOS at the time, and the potential of proportional fonts and OS-level printer drivers caught my imagination - it was the future, I was sure. It didn't hurt that I got a promotional copy for cheap with Windows bundled. I still have the floppies around somewhere.

Many years later, and I'm still writing Windows programs. Excellent strategy on Microsoft's part.

Nice to see this hugely transformative software available in an archive.
Yes, absolutely. Id love to know what the author would have come up with. It helps understand how people perceive AI. It has become hard to see what the general perception is after working on it. He does shed some light but stops to change the subject.

And yes, it is hard to do. I once wrote what I thought was going to be a well received article on AI. I used Jobs analogy of "the bicycle of the mind" to make a point about how AI could end up turning the bicycle into a more powerful method of transport (I used a motorcycle). Thus supercharging our abilities even more. But decided not to publish it until things become more clear. I dont want to sell something that might turn out to be quite different to what most expect. Because who knows when/if the singilarity happens and how how it will impact us.
Damn. I disagree with all of your points.

Use UDP only if you satisfy all the following conditions:

* Don't care about loosing data
* Don't care about receiving data out of order
* Not sending stream of data but individual messages ( < 580 bytes)
* Don't care about the other side of the connection being dead or terminated, and not knowing about it
Actually, sometimes people push changes because they intellectually think it's a better architecture or public API, but they can't survive as a fork.

They need the frequent bug fixes and upgrades from the mainline, so they really do waste their time if their changest is not approved.
Yes, great point. Automation != AI. Its a common mistake.
> this study was a victory for higher order functions and ADTs with pattern matching.

So, the bread and butter of Haskell?

There are few languages that do these two things nearly as well as Haskell. All of them are ML derivatives. Haskell, OCaml, and F# come to mind.

Rust has almost-as-good ADTs, but no higher order functions. A number popular of languages support both of these concepts, but not nearly as natively or conveniently.
Indeed; as I've heard it ordered: 6 parts gin and a moment of silence for the vermouth.
I am also curious, but just to share my own insight on this, I've actually looked into a lot of CSV providers and they all seem to cater towards raw data with less semantics compared to the type of data that we would normally see through JSON or XML.

For example a lot of CSV data is used for plotting/visualization, because all they have is numbers. If they had more metadata they probably would have ported them to JSON.

Another observation: A lot of CSV dumps online are really that: data dump. It's a huge size file that's meant to be used after downloading, not for streaming like JSON/XML. You don't see many JSON apis that return huge size data, but it's common to see a lot of huge sized CSV files.
A Question I Ask New Entrepreneurs
People have just as much access via youtube for cooking tutorials but people are _not_ flocking to be chefs. For the cost of a Macbook you can definitely get a pretty decent kitchen + laptop and also literally feed yourself delicious meals... it's the money that brings people to tech. Full stop. I always tell my friends that I got lucky that my passion also happened to pay well. Because if I wanted to be a chef, the road is much harder to make the same money.
What is most interesting to me is a general purpose robot arm (or pair of arms) that is geometrically similar to human arms so it can be trained by a human. And that is designed not to unload a dishwasher, but is designed to do basically anything it is trained to do. Which can include not only unloading the dishwasher, but doing the whole process of getting dishes cleaned and put away, laundry cleaned and folded and put away, and any number of other household tasks. And probably most importantly, it can make robot arms.
University of the People NON PROFIT, TUITION-FREE Accredited Online American Uni
I appreciate the comparison. My field is computational biology, and the latest edition of ESL has some specific, relevant examples, which is what drew me to it in the first place. I'm currently working on getting my statistics background up to par, and then I'll be choosing an ML textbook. However, your note about ESL focusing on frequentist models gives me pause about my original choice, as it would seem to me biological applications naturally lend themselves to Bayesian methods. I think in the end I'll have to crack open several books to decide. Thanks for the input.
You don't know everything, and if you do, your replacement 3 years from now won't.

Engineering is a process to solve problems at its core. Fundamentally, you cannot solve problems without know on what the the questions are.
Manishearth's response [1] plus Cargo [2] hits on a lot of great things about Rust.

[1]: https://news.ycombinator.com/item?id=13268955

[2]: http://doc.crates.io/
Testing JavaScript Logging Programs
I am seeing the same issue. I am running Chrome on Mac. Works fine in Safari though.

Chrome Version 55.0.2883.95 (64-bit)
macOS Sierra 10.12.2
Alt-right gonna keep shoveling billionaire propaganda and/or InfoWars/Unabomber beliefs onto every and any memetic channel, because shouting lies loud/often enough is sadly rewarded by changing sentiment in low-fact environments. (Doesn't really work so well on HN because of pervasive motivation for fact-challenging and argumentativeness.)
Unleashing auto learning AI on lost languages (Egyptian hieroglyphics, Indus valley civilization glyphs, etc ) should yield breakthroughs. Or so I think
What is the part number to an o2 sensor for a nissan altima 2002 3.5 se?
I’m trying to purchase the o2 sensor but I am trying to be exact on which one it is. It’s bank 2 sensor 2. I have the FSM but I’m not sure if it contains the part number. If it matters I have the SES light with the DTC p0158
Webcomponents are not even close to winning (but I want to see that happen). As far as I know React is winning and vueJS is going strong. I have not seen much projects using web components.
How many times have you needed such a thing?

Most video / phone interviews are assumed to be ephemeral.

People take notes as it happens and that's about it.

Deliberate recording by either party might be off putting for A LOT of people and cause people to be more nervous then they need to be.
Every home network I've seen ends up using the home router itself as a forwarding DNS server as configured through DHCP.

That said, I doubt home routers are de-pritoritising UDP to any extent, or it would be a big topic of discussion among gamers.
Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.
Show HN: Dice.css
Edward Snowden’s Escape from Hong Kong [audio]
Yeah from what I've read the two most effective predictors of employees were work-sample and GMA tests(basically IQ).
Yet another secured s o c k s 5 _ p r o x y
Written in Go.

I'm still testing it though.

URL: https://goo.gl/KkQCfN

It's made for extend (You can add your own encryption method, or just use it as a go package), but it naturally slower (3~4 times at least?) than other pure pro.x_i,e_s.

Just hope it will help somebody who wants to make a proxy for themselves but hate to deal with the network.

(URL Shortened for Anit-SearchEngine)
On the loopback port, sure.

I work on protocols that use sketchy wifi on mobile units that roam among access points. Sometimes they roam into RF black holes. TCP is all kinds b0rk3d for what I am doing.
That seems like a strange conclusion to reach. Humanity is per-capita less violent than ever, despite probably the highest per-capita small arms density in history. My suspicion is that the techniques available for individuals to kill each other has little impact on their proclivity to kill each other. Of course, that says nothing about the impact of increasingly effective large-scale weapons (nuclear/biological/chemical) on the proclivity of organizations like governments to kill people.
The article plays fairly loose with its own arguments.
For example, while an expert system/predictor likely gets the medication right more often than the human, the actual shelving, counting, and management of the physical medications is totally beyond the reach of present and near future robots. For example: no robot or AI knows how to recover of a customer accidentally spills a cup of coffee on a shelf. (Further into the future, anything will happen!)

Similarly, while I am impressed by the Google self driving technology, the Uber version seems like a dangerously underdeveloped imitation that breaks as many rules as a bad human driver.

I think AI is powerful and important, but nowhere near where the singularity fan boys say it is.
Interesting, thanks - I wasn't aware of this text.

But according to your link, ESL isn't a prototype of ISL, but a more 'advanced treatment'. The R applications in ISL seem like they might be very useful, though.
UDP doesn't cause things like not knowing if the other end is gone. You're being kind of ridiculous.
> If your homegrown protocol backs off slower than TCP, some router configurations will drop your packets first.

I think that's only if you're being less responsive to congestion signals (drops, ECN marks), and you're using more than a fair share of bandwidth or trying to use any available bandwidth. Fixed but low rate flows (eg. VoIP) shouldn't be penalized until the link is congested with so many flows that the VoIP is trying to use more than 1/N of the bandwidth.
I've always felt that the ribbon is much less scannable than the menus in previous versions of Word. I've learned to deal with it like everybody else, but I still don't think it's an improvement.
I've seen some forms made with PDFs with js in them. A painful experience for sure.
I'm getting the impression that you're mostly only taking the endpoints into account. There's tons of stuff happening in between the peers: having worked on specialty routing equipment, I can add that the prevailing philosophy was that generic UDP packets were lower quality-of-service than TCP. That is, if the router was under high load, UDP would be dropped before TCP.
Processor Architecture 101 – the heart of your PC
i think it's more about performance. Wechat ha HUGE amount of users in China, an low level socket connection would get better performance than a standard HTTP request
Coding Standards Horror Story
I've ridden a few converted bikes and a few purpose built e-bikes. In my opinion the purpose built ones are far better than any conversion I've ridden. In fact I now own a Gazelle.
or to actually convert HTML to markdown: https://github.com/leeoniya/reMarked.js

disclaimer: mine
I am currently working on a project for a client in real estate management. They are aggregating data from state licensing agencies, insurance rating agencies, etc., and there are a lot that only provide CSV data. I imagine on the other side of the fence there is some guy or gal managing all this info in Excel, and CSV is the easiest path for the data to flow out.

Previously I worked for a company that provided a dashboard for small businesses to manage their listings (Yelp, Facebook, Google, Tripadvisor, etc). For multilocation clients, for initial setup we needed a list of all locations, addresses, phone, etc., and not a single client said "here's our api, grab the data in JSON format". Instead, we always got a CSV. We eventually gave them a CSV template file for them to copy/paste into.
Wait, what?

In what way has Manhattan fixed the problem of expensive housing?
My favourite version of "stupid user error"/PEBKAC/ID-10-T is 'layer 8 error'...
What aspect of finance? Or rather, who are you getting the CSV from and what do you do with it?
This is not even close to being true. People get hired into top companies all the time.
That's a less than ideal solution. As another comment mentioned, you are screwing over legit email addresses with things like +. Better is to use better tooling. For sending email, I would use SendGrid or an alternative.
Understanding the computer science underpinnings are fairly useful. For instance, what if you are unhappy with the rendering speed of React? Rather than faff about complaining about it, you can just pull out your textbook, re-read that chapter on graph algorithms and you too can implement your own virtual DOM that calculates the least set of changes to apply to the directed graph that is the browser DOM.

That's how we end up with projects like Preact, Inferno, etc.

Now does that mean you need to read the latest papers, and be a proper computer scientist? Nope. I find that reading papers from the 70s and 80s will take you pretty far. Just rip and reapply to new circumstances.

I am a web developer.

A lot of code that I write is 'good', but its hardly clever or original---it's a simple reapplication of old practiced done 100 times in desktop GUI applications, now applied to the web.

I found that a lot of old-school GUI developers never really crossed over to the web, so a lot of that knowledge has been lost to the community at large. You can still find it in text books though :)
Im thinking of the specific use case for doing interviews over the web. People typically use Skype which provides poor resolution. In this case they would be fine with the local recording.
Lifting bodies into space is the expensive part, unfortunately, so a mass approach won't work.

However, once the elites get too greedy, and the masses too marginalized, there will be riots and civil war, so the smart ones will go for the "grow the pie just enough" approach.
UDP is connectionless, it just sends data to <somewhere>. Doesn't care if that somewhere is online, or available, or exists at all.