> To be kind, we’ve spent several decades twisting hardware to make the FP spherical cow work “faster”, at the expense of exponential growth in memory usage, and, some would argue, at the expense of increased fragility of software.
There is not one iota of support for functional programming in any modern CPU.
Am I crazy, or did he just give a really good definition of monads in programming? I think that it benefits by not letting itself get bogged down in Category Theory nomenclature which doesn't actually matter when programming.
https://www.facebook.com/199535516767620/posts/4006006656120...
Do we know how to do context sensitive / intra procedural analysis and scale it to millions of lines of code ?
One example is the open source tool Infer, which we run on very large bodies of native and Java code at Facebook. http://fbinfer.com
This is a bit awkward for me as I've paused the development of HLearn and emphatically do not recommend anyone use it. The main problem is that Haskell (which I otherwise love) has poor support for numerical computing. I've tried developing an alternative standard library to improve the situation (https://github.com/mikeizbicki/subhask), but Haskell's type system isn't yet powerful enough to do what I want. I'm sure the type system will have the needed features in 5-10 years, and I'd rather wait and do it right.
If you have any questions, I'd be happy to answer them.
Most readers seem to be misinterpreting Mike as anchoring off other popular programming languages of today, whereas he's looking for language features for which there's (a) no consensus that they'll actually be good when they exist, and (b) don't yet exist. (I'm highly skeptical of dependently typed programming.)
I think that there's a case to be made that numeric programming in Haskell, relative to the state of the art of today rather than the year 2100, really isn't so great – but my concerns are very different than Mike's, and revolve around libraries rather than type system features.
Source: have done a bit of Haskell in my day.
Which of these companies is "better" really depends on your preferences. For example, do you want to leave the US? If so, Google may be the best as it has numerous office in Europe. Do you need lots of holiday time to see the family you relocated from? If so Facebook is the best to work at as it gives you 4 weeks PTO straight up. Do you want a closed office? Only Microsoft will give you one.
I've knowledge of Google, Facebook and Microsoft (mostly through coworkers). My thoughts:
In terms of work/life balance:
- While Google has a very diverse selection of engineering offices throughout NA, Europe and Asia, Facebook and Microsoft are more limited away from their headquarters. For example in Europe, Google has engineering roles available in London, Paris, Zurich, Warsaw, Aarhus, Stockholm and Ireland. Facebook has roles in London and Dublin alone. Microsoft only London.
- Facebook does 21 days PTO from hire, Google does a seniority based system starting at 3 weeks/yr and ending at 5 weeks/yr (after 5 years employment), Microsoft does a similar seniority system but with less PTO (can't remember the number).
- I haven't heard any major horror stories from any of them in terms of overtime.
In terms of what it's like to work there:
- Microsoft actually gives you an office. Google and Facebook are into the open floor plan thing.
- My impression is that Google and Microsoft do treat engineers/products in the more "traditional" way. The company is structured as a hierarchy, you take a potential project/feature up the chain, get it approved, it's pushed back down the chain. Facebook seems to be less hierarchical and small groups are given more autonomy.
- Google is very very large and very (for a web tech company) old. It has a lot of internal technology that's not available elsewhere and it's built to make it easy to build extremely large systems. Microsoft has a lot of technology but its business is mostly selling it rather than building products on top of it. Facebook is a relatively new company and has a lot of cool shiny stuff.
- Google and Microsoft have a very diverse (in the case of Google extremely diverse) set of projects and a reasonable degree of internal mobility. A standard engineer at Google can work on Android, transfer to YouTube, then decide they'd like to work on Google Flights or Cloud. Microsoft is similarly diverse (Azure, Windows, MS Office for a few examples) but I believe it may be harder to move around internally. Facebook has plenty of mobility but not as many choices of product to work on (Facebook, Instagram, WhatsApp, Oculus unless I'm missing something). The products are monolithic (Facebook's "YouTube" competitor is Facebook itself) so there's still a lot to do in terms of engineering work but you can't really do a totally different thing like you can at MS (desktop software to cloud) or Google (cat video hosting to mobile OS).
- In terms of moral things like data collection and net neutrality, Google and Microsoft, despite certainly not being perfect, seem to be quite clearly ahead. While Facebook makes it near impossible to see your data, let alone delete it, Google allows you to permanently delete it or prevent it from being stored at all (https://myactivity.google.com/myactivity). Microsoft was the first big company to challenge the US government when it tried to use a court order to gain access to data stored outside the US.
There's also a vast range of engineering projects, from VR through video, mobile apps, machine learning, compilers and programming languages, operating systems, on to data centers.
I would make a conjecture that it's also true for Lisps (quality of std lib is poor often) and other powerful libraries.
On other hand, languages of simpler kind, like Java or Python, have more adequate std libs.
It's because, for a really powerful language std lib has to be opinionated. And people understand that but they can't agree on something. So they live with whatever common denominator. And lost a lot of traction there.
A counterexample is Clojure where std lib is very nice if heavily skewed towards FP, reinforcing my point.