Hierarchies of Programming Languages and Software Types

[lpetrich]

Who will steal Android from Google? – Steve Yegge – Medium Much of that article was about how developing for Android can be very difficult, and how someone might eventually take over Android by providing a nicer development framework.

But the author claims that at Google, the programmers have hierarchies of programming languages and software types. From the most to the least glamorous there:

1. C++
2. Java
3. Python
4. JavaScript

and

1. Search
2. Ads
3. Apps
4. Tools
5. Frontends

I can guess what some of these assessments are based on.

For programming languages, it's fastest to slowest, with JavaScript likely being tainted by being frontend. C++ is also the most challenging to write for, since it does not have behind-the-scenes object management, as the others do.

For the software types, it's most to least data crunching. For searching, Google's software maintains a snapshot of Internet content that covers just about all of the more accessible parts of the Internet. This must be continually updated, and Google's software must extract the most relevant search results from this. For ads, Google's software decides on which ads might be most relevant for which searchers by looking at what they searched for. The others are not quite as clear for me.

 

[Juma]

Who will steal Android from Google? – Steve Yegge – Medium Much of that article was about how developing for Android can be very difficult, and how someone might eventually take over Android by providing a nicer development framework.

But the author claims that at Google, the programmers have hierarchies of programming languages and software types. From the most to the least glamorous there:

1. C++
2. Java
3. Python
4. JavaScript

and

1. Search
2. Ads
3. Apps
4. Tools
5. Frontends

I can guess what some of these assessments are based on.

For programming languages, it's fastest to slowest, with JavaScript likely being tainted by being frontend. C++ is also the most challenging to write for, since it does not have behind-the-scenes object management, as the others do.

For the software types, it's most to least data crunching. For searching, Google's software maintains a snapshot of Internet content that covers just about all of the more accessible parts of the Internet. This must be continually updated, and Google's software must extract the most relevant search results from this. For ads, Google's software decides on which ads might be most relevant for which searchers by looking at what they searched for. The others are not quite as clear for me.

Javascript is not tainted ”for being frontend”, why would it? On the contrary: It is ”tainted” because it is a shitty language.
The only reason that it has becone standard is: used in webpages, need no tools, typelessness (makes it easy to code and hell to debug).

Javascript is a virus that are destroying software development: alluring vecause so many thinjs they know hiw to use it and dangerous because if the shitty systems it creates.

One of the biggest joke are the trend to write safety critical system on node.js...

 

[lpetrich]

Javascript is not tainted ”for being frontend”, why would it? On the contrary: It is ”tainted” because it is a shitty language.
The only reason that it has becone standard is: used in webpages, need no tools, typelessness (makes it easy to code and hell to debug).

How does it compare to Perl or Python or Ruby? All three share with JavaScript a lack of explicitly declared variable types.

BTW, there's something called TypeScript, something that one compiles into JavaScript -- and named after its explicit types.

 

[Phil Scott]

Javascript is not tainted ”for being frontend”, why would it? On the contrary: It is ”tainted” because it is a shitty language.
The only reason that it has becone standard is: used in webpages, need no tools, typelessness (makes it easy to code and hell to debug).

How does it compare to Perl or Python or Ruby? All three share with JavaScript a lack of explicitly declared variable types.

Here's a revealing example of their differences in philosophy:

Javascript:

>> function foo(x,y) { return x + y }
>> foo(1)
<- NaN

>> foo(1,"2")
<- "12"

Python

>>> def foo(x,y):
...   return x + y
... 
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes exactly 2 arguments (1 given)

>>> foo(1,"2")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Both languages are untyped, but Python will bail on the computation if things look awry, much as in the Lisp tradition. Javascript will coerce implicitly and plough on as best it can. In the "foo" example, I define a two argument function but first call it with one argument. Javascript treats all arguments as optional, and sets the missing "y" to null. When it tries to do the addition, it coerces the null to a "NaN" and then follows floating point arithmetic (Javascript only supports floating point numbers). In the second case, it coerces 2 to a string and does concatenation. In both cases, Python borks.

I've never programmed in Perl, but I believe it favours implicit coercion much as with Javascript.

BTW, there's something called TypeScript, something that one compiles into JavaScript -- and named after its explicit types.

Typescript transpiles to Javascript. There are loads of languages which do this nowadays, and the ubiquity of web applications means that Javascript is becoming a standard compiler target.

I agree that Javascript is a terrible language (though it's got nothing on BASH). The folklore is that it was designed in two weeks as a crude way to do trivial hacks in pages served by Netscape Navigator. It was not designed as a mature programming language, and on at least one occasion, its creator Brendan Eich started a talk by apologising for his creation.

There's no real reason why a frontend language should be slow. In the early days of Web 2.0, Java was in the race with applets, the breezy Flash was dominant, and Microsoft was volunteering Silverlight. Javascript has ended up winning, but there's still plenty to play for, now that WebAssembly has been standardised.

 

[bigfield]

with JavaScript likely being tainted by being frontend

I assume this is because frontend is the easiest work to do.

 

[James Brown]

with JavaScript likely being tainted by being frontend

I assume this is because frontend is the easiest work to do.

Sounds right. At a fast-food restaurant, there are more cashiers than there are burger-flippers, and there are more burger-flippers than there are store managers.

But which job is more "glamorous"?

 

[bigfield]

with JavaScript likely being tainted by being frontend

I assume this is because frontend is the easiest work to do.

Sounds right. At a fast-food restaurant, there are more cashiers than there are burger-flippers, and there are more burger-flippers than there are store managers.

But which job is more "glamorous"?

"Frontend", at Google and other software firms, refers to the job of developing user interfaces for software. It's relatively easy programming work in that the programming logic is (typically) fairly straightforward, while the hardest part is arguably designing the interfaces before any code is written.

 

[Phil Scott]

To defend my frontend colleagues, it depends entirely on the application. If you're in the business of complex visualisation, your frontend might have all the hard algorithms. If you are creating the latest in web based desktop publishing, your frontend might have all the hard algorithms. On the other end, if you are just trying to get a database to be web accessible, your backend might be paint-by-numbers. I know plenty of Java programmers who think that writing business logic is pleasant drudgery.

The frontend has some glamour in that more code than ever is destined to run there, and there are still open questions on how to implement guis on a platform that is full of cruft from the days it was intended simply to render documents. So we witness the churn of new frameworks whilst witnessing the likes of Facebook's react that uses a DOM diffing algorithm that effectively allows the programmer to write a gui like a computer game interface but now aggressively limiting the power of stateful computation. That has got a lot of hacker attention.

I couldn't speak for Google, but I wouldn't take general lessons from them, nor assume any crude ranking of languages. And while Javascript may be a crappy language, C++ and Java aren't exactly visionary, one expressly designed to piggy back off the other which was expressly designed to piggyback off C and Simula.

 

[Loren Pechtel]

Javascript is not tainted ”for being frontend”, why would it? On the contrary: It is ”tainted” because it is a shitty language.
The only reason that it has becone standard is: used in webpages, need no tools, typelessness (makes it easy to code and hell to debug).

The typelessness isn't that bad, it's it's willingness to plow on through garbage that makes it such a pain. Also, the debuggers in the browsers are nowhere near as good as what we have in proper development environments.

I'd love a testing plug-in for Javascript that would make it as strict as hell about syntax.

 

[Underseer]

Here's a revealing example of their differences in philosophy:

Javascript:

>> function foo(x,y) { return x + y }
>> foo(1)
<- NaN

>> foo(1,"2")
<- "12"

Python

>>> def foo(x,y):
...   return x + y
... 
>>> foo(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes exactly 2 arguments (1 given)

>>> foo(1,"2")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in foo
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Both languages are untyped, but Python will bail on the computation if things look awry, much as in the Lisp tradition. Javascript will coerce implicitly and plough on as best it can. In the "foo" example, I define a two argument function but first call it with one argument. Javascript treats all arguments as optional, and sets the missing "y" to null. When it tries to do the addition, it coerces the null to a "NaN" and then follows floating point arithmetic (Javascript only supports floating point numbers). In the second case, it coerces 2 to a string and does concatenation. In both cases, Python borks.

I've never programmed in Perl, but I believe it favours implicit coercion much as with Javascript.

BTW, there's something called TypeScript, something that one compiles into JavaScript -- and named after its explicit types.

Typescript transpiles to Javascript. There are loads of languages which do this nowadays, and the ubiquity of web applications means that Javascript is becoming a standard compiler target.

I agree that Javascript is a terrible language (though it's got nothing on BASH). The folklore is that it was designed in two weeks as a crude way to do trivial hacks in pages served by Netscape Navigator. It was not designed as a mature programming language, and on at least one occasion, its creator Brendan Eich started a talk by apologising for his creation.

There's no real reason why a frontend language should be slow. In the early days of Web 2.0, Java was in the race with applets, the breezy Flash was dominant, and Microsoft was volunteering Silverlight. Javascript has ended up winning, but there's still plenty to play for, now that WebAssembly has been standardised.

Wait, but if a language is bad because it's easy to shoot yourself in the foot because the compiler/interpreter assumes that you know what you're doing, doesn't that make C++ the worst of the listed languages?

 

[Phil Scott]

Wait, but if a language is bad because it's easy to shoot yourself in the foot because the compiler/interpreter assumes that you know what you're doing, doesn't that make C++ the worst of the listed languages?

Sure. Though I'm not signing on to that metric.

We're comparing apples and oranges a bit in the OP. C++ is unique in that list. It's the only one that would be described as a systems language, and I only ever compare systems languages to other systems languages. And the thing is, if you're not a systems language, then it's really easy to be better than a systems language in terms of safety.

I mentioned Lisp before, and I'd also like to mention that Lisp can reasonably be called a systems language: it was, in fact, the systems language on the Symbolics machines, present right down to the metal. And Common Lisp still has plenty of escape hatches into the land of the footguns, where one can enjoy all the same horrors of segmentation faulting and memory corruption that C programmers routinely enjoy, and as a bonus, can write super fast code that works with the equivalent of void pointers.

I'd guess that Google are mostly using C++ for writing stuff like Chrome, which has to feature a blazingly fast Javascript runtime, and C++ can only write that sort of code out of the four listed. This isn't simply a matter of speed. Only C++ can realistically be used to write a memory manager, since that requires escaping any memory management model that's being imposed by your runtime, and so necessarily requires going unsafe (unless you've got the sort of crazy powerful type system or formal verifier that we still don't see outside academia).

 

[Loren Pechtel]

Wait, but if a language is bad because it's easy to shoot yourself in the foot because the compiler/interpreter assumes that you know what you're doing, doesn't that make C++ the worst of the listed languages?

Programs, like ships, sink in the C.