There is just so much awesome stuff in this article. Finite State Entropy and Asymmetric Numeral System are completely new concepts to me (I've got 7 open tabs just from references FB supplied in the article), as is repcode modeling. I love that they've already built in granular control over the compression tradeoffs you can make, and I can't wait to look into Huff0. If anyone outside of Facebook has started playing with it or is planning to put it into production right away I'd love to hear about it.
Another way to put it might be to say that because neighborhoods near the center are more valuable and attract more people, they also tend to attract other desirables, and that those other desirables tend to further drive up their value. When you rent in New York, you pay for location. A big part of the location equation is your commute. Another huge chunk of it is your neighborhood. And because the two are heavily correlated, commute time by itself tends to track total value of location quite accurately, to the point where on average every minute in reduced commute results in a $56/month increase in rent.
I think you can reframe this debate pragmatically and widen its applicability significantly: At what point is "bad" code more effective than the alternatives. If you get down into a debate about "best practices" you'll have to concede that anyone writing the code the author is talking about might be using "best practices" in some explicit way, but isn't "following best practices", which are designed to avoid precisely the difficulties he outlines. On the other hand, it's true that most code out there is bad code, and that heavily architecting a system with bad code can be even more of a nightmare than more straightforward bad code. The real question is, when should scientists favor bad code? I'm a huge fan of best practices and of thoughtful and elegant coding, but I could see an argument being made that in most circumstances, scientific code is better off being bad code, as long as you keep it isolated. I'd love to see someone make that argument.
My vote is for electron, although I'm following how React Native develops really closely. From what I've seen, the best new "Desktop" apps tend to be built with electron. We've been using it in production and, despite having to make pull requests for framework-level bugs fairly regularly, we've haad a pretty good experience overall, and far better than anything else we've tried - although, as I said, we have yet to seriously look into React Native. Also, by cross-platform I'm assuming you mean OS X, Windows, and Linux. If you also want to include mobile, then there are so few options there's no longer any real reason to debate.
> They may arrived at the guidelines using ML, but it's possible that their guidelines wouldn't be right for the types of emails you are sending out.
This is a great point, and it's something that users ought to consider with nearly every application of machine learning that ends with a definite recommendation to the user. Machine learning can be used to solve many many different types of problems - when it comes to solving problems related to human interaction, the insights that it has will tend to function more like the rules for running an effective business-focused popularity contest than the rules for crafting meaningful emails to every possible audience. That said, if you happen to be sending a business email and want nothing more than to improve the likelihood of response, this seems like a great tool for the job.
I agree completely but I guess I also don't mind it. But I also wouldn't mind "The Art of Woodworking: Tables You Can Build Yourself" - I suppose it depends on your tolerance for buzz words. I'm bombarded with them all day long so perhaps my tolerance is growing.
Yeah, I'm surprised the Neo4j team hasn't made more of an effort on this. I've run into lots of memory issues with it as well, and although there are reliable, fairly straightforward solutions to most of these problems, the team doesn't seem to be particularly interested in making sure that the defaults are robust enough to handle a reasonable workload. When your database fails on you for making a reasonable query request on a light workload, you can't help but feel troubled. There's a lot to love about Neo4j, but they've got a lot of work to do if they want to win over the developer community as a whole. There may be enterprises that get reassured by a huge price tag and a whole bunch of salespeople at their beck and call, but I don't know any of them. Every engineer I know who is willing to pay for software is either expecting a completely new kind of product or expecting to have an awesome experience with a free version of the tool before being willing to commit even a few bucks a month.
Kind of shocked nobody mentioned this, even if it is a bit of an aside, but umm, I've been dying for anything at all from Gary Bernhardt - I don't even know what to say except that it makes me hope however unrealistically that will one day get something like the magnum opus that is "Destroy All Software" from him again.
To this point and the point below about undergrads and specialized knowledge: yes, you're absolutely right. I should not have said that undergrads don't have the specialized knowledge to teach. Plenty of undergrads make great TAs, and teaching assistants are a critical part of the learning process at most universities. What I should have said is that courses are not taught by (the role of the teacher is held by) undergraduates but by professors and graduate students, who are responsible for the planning, content, and instruction, and for the TAs that assist them. The only point I'm trying to make is that graduate students are given substantial full-time-equivalent jobs and that there place and role in the university ought to reflect this.
Many of the comments so far revolve around whether graduate students are students or not, as if being a student and an employee are somehow mutually exclusive or the fact that graduate students also take classes mean they must be equivalent to undergrads and ought to be given the same treatment. Clearly this is not the case. Acquiring the specialized knowledge that a PhD entails requires tremendous sacrifice (and, in the case of PhDs hoping to become professors, it often ends in tremendous disappointment). Universities have two primary functions - conducting research and teaching. This is the job of the university. Undergraduates don't have the specialized knowledge required to teach or to contribute substantially to research. Graduate students, however, do both of these jobs. Indeed, they are absolutely essential to the functioning of the university. And while the average time to completion for science and engineering doctorates hovers around 5 years, it's not uncommon to find humanities PhDs who take 8 years or more to complete their dissertations. This isn't because they're lazy. This is because the competition for academic posts is brutal, the expertise expected of them is vast, and, more to the point, because they're busy working. Universities are subjecting students to increasingly unjustifiable tuitions and pocketing massive profits couched as expanded endowments. Pretending like graduate students are just really smart, really old, really slow-to-catch-on interns and not a part of their extremely lucrative business operations just adds insult to injury.
I worry about breaking Stack Overflow into pieces - I think it functions extremely well as the be-all and end-all for copy-paste code bandaging. But AI is a perfect place to draw a dividing line and create a question and answer culture uniquely appropriate to AI. As Stack Exchange continues to look for ways to expand the brand by fragmenting their own universe I can only hope they'll choose as wisely as they did this time.
I don't mind the OOP-functional debate. I think that encouraging developers to try out radically different approaches to programming and to regularly reconsider their implications is extremely healthy for the ecosystem as a whole even if there is a tendency to pendulum-swing too far in one direction before swinging too far in the other with only brief pause in a reasonable center. What I think isn't particularly helpful is reducing OOP to inheritance. I hardly ever have the chance to program in Ruby anymore (though I think it's quite a beautiful language and love the Ruby community), but I still find Sandy Metz's Practical Object-Oriented Design in Ruby to be an incredibly insightful look into "the good parts" of OOP. And for some really thoughtful OOP and functional discussions, watch Gary Bernhardt's Destroy All Software (check out, for example, "Functional core, imperative shell". I wish he was still producing screencasts every week. Even his parody talks elevate the programming conversation to levels that it's hardly ever able to reach otherwise.
Wow. If the "critical" temperature for superconductivity really does turn out to be determined by the density of electron pairs, as it now seems, I absolutely cannot wait to see what kind of theoretical frameworks end up coming out of this discovery.
This response is precisely what has made insecticides so incredibly dangerous for world agriculture. Documentaries like "The Vanishing of the Bees" and "More than Honey" do a great job highlighting just how criminally negligent the agriculture industry as a whole has been to bees. What I haven't seen is an analysis of how devastating the large-scale destruction of insect populations is to the world's ecosystem. We are essentially decimating the most productive food-producing species in the world and expecting not to have to pay for it in spades down the road.
I believe the assertion is that in order to maintain the bee population at the level necessary to meet demands on agriculture given the extraordinary rise in the death rate of both individual bees and entire colonies, the beekeeping industry has had to import far more colonies per year.
I like this response. It seems like jamwt is actually trying pretty hard not to be biased. If I were at Dropbox, I'd probably also want to point out that just about every competitor that's been listed here is a Dropbox copycat. On the other hand, we all know that great copycats come along all the time and do something new much better than the original. The real question about the value proposition for Dropbox is how its value proposition stacks up against competitors. I can't speak to Box and I don't think OneDrive has much going for it beyond being attached to the Microsoft ecosystem (which makes it the default winner for a whole bunch of Microsoft-oriented people and companies and the opposite for just about everyone else). On the other hand, Google Docs, Spreadsheets, etc., gives Google Drive a really strong position for eating into Dropbox. I haven't made up my mind yet - I've found a lot I don't like about Dropbox, but I've also found Google Drive to be riddled with problems, both from a UX standpoint and in terms of the basic architectural layout. If Dropbox does the right things over time, they can continue to offer the best value in the market - I'm just not sure I've seen them doing that recently.