Blitzscaling 08: Eric Schmidt on Structuring Teams and Scaling Google

It is hard to encapsulate what is unique about a language in a pithy one-liner. This one is the best I could come up with so far. And yes, I am also annoyed by hyperbolic claims and titles, for example I remember a paper claiming a "Language for Cloud Services" (not sure whether they specifically mentioned AWS). Turned out to be a minimalistic FP language with rudimentary concurrency support. Applicability to cloud services was an obvious extension left to the reader. Grmph. > Is it really true? Yes, I believe it is true. It has taken me many years to figure this out, and I realise that it is highly non-obvious to the point of being startling and yes, seemingly over-the-top. The "About" explains it a little bit further: > By allowing general architectures, Objective-S is the first general purpose programming language. > What we currently call general purpose languages are actually domain specific languages for the domain of algorithms. Maybe this should also go on the home page? Anyway, a super short and also still pithy and incomplete justification: All current mainstream programming languages are descendants of ALGOL. The ALGOrithmic Language. And that's not just a naming thing. I talk about this in much more detail here: "Can Programmers Escape the Gentle Tyranny of Call/Return?" ( [link] ) In short, we started using procedures to both compute results, which was what we used computers for in general when we started this CS thing, and then incidentally also to organise thos

This implies there's something else that's not "procedures/calls" out there, i.e. subroutines. What else is there, can we name one of them? Subdividing a big problem into a set of smaller problems is not just some specific way of programming, it's not even a specific way of factoring a system. It's universal, as in the entire Universe essentially is factored this way. We have areas of "widening" cohesion and coupling (implementation) and areas of "narrowing" cohesion and coupling (interfaces, incl. argument/return types). These occur both horizontally and vertically as we move towards smaller and smaller problems to solve. Your actual CPU works this way, itself. So I'm very curious what we're talking about and why the dismissive attitude towards procedures i.e. "cobble it together out of procedure calls". In these conversations usually people just bring up something else that's also a procedure, but we call it something else, like "message passing to object methods". That's a useful metaphor at a higher level for sure. But let's not forget a method is just a procedure that runs and does things like any other procedure. ----------- Thanks for the great questions! I am particularly delighted by the slight incredulity expressed as to whether it's actually possible for there to be anything else. This has been my thesis for a while, that the call/return style has become so incredibly dominant that it is now largely synonymous with programming itself and thus something that is prog