Comment by tonyg
8 years ago
Rob Pike, in his own words, claims that programmers at google are "not capable of understanding a brilliant language", and that this is the reason why Go is designed the way it is.
The full quote:
> The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
-- Rob Pike, 2014, at ~20m50s of https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
That's been my experience at Microsoft. I'd love to start a new project there in F#. And I think the kids there would eventually grasp it and create better code. They're certainly smart enough. But it would take a while to unlearn OOP. My first year or two of F# code was complete crap. So given average tenure of a fresh grad bigcorp employee is a couple of years, it would not be worth it. I think this is a good decision though an unfortunate reality by Rob Pike.
A solution might be to change the hiring process to test FP concepts instead of OO, or to use a lisp- so users do not need to learn a complex type system in addition to FP.
If they are using C# (I'm making that assumption - I could be mistaken), the type system in F# isn't a huge leap in terms of learnability. It wasn't that way in my experience, anyways.
The learning curve seems to be with other aspects - like where the hell do I put my I/O? Error handling? How do I trace (or write) all these functions that are piped or composed together? Questions like those are what I tend to see. Both personally and when pointing other people to F#.
1 reply →
I think it would be easy enough for the go compiler to support macros, while keeping them disabled by default. There could be a cli flag for go build that enables macros. It would be easy to have a company-wide rule to keep macros disabled. It would be trivial to prevent code with macros from passing CI if that was one of your organizational requirements.