This kinda makes me think about the transition from writing machine code by hand to using a compiler. Did people feel similar at the time that they didn't understand the machine code that the compiler was writing for them?

▲

netburst an hour ago | parent | next [-]

> ... they didn't understand the machine code that the compiler was writing ...

This is a bold assumption and inconsistent with my knowledge of history. High level languages allowed better management of complexity and reduction of tedium. The common complaint was that compilers produced less efficient (slower and/or larger) code, not that the output was more complex. It was[1] normal to read the compiler's output, which was generally assembly or another intermediate representation. After all, a compiler is merely a tool for translation from one language to another. Additionally, early compilers often were not optimizing compilers; the code they generated was simpler than handwritten programs.

1: And still is, for some of us!

▲

qayxc an hour ago | parent | prev | next [-]

Very good question!

The problem assembly programmers had with compilers wasn't that they wouldn't understand the generated machine code - it was that the generated code was often bad (as in unoptimized and bloated) and didn't justify the resources required to run the compiler. As hardware got more complex and powerful, compiler got much better, and operating systems became the primary layer between hardware and applications, assembly became more niche. Nowadays it's pretty challenging to beat the compiler at generating efficient assembly and writing a program in assembly would consist primarily of OS and library API calls anyway.

There are definitely parallels there. The only obvious difference I can see is that both high level language code and assembly are unequivocal in their meaning (as in you can determine what gets executed), whereas natural language is not.

▲

curt15 an hour ago | parent | prev | next [-]

The key difference is that the procedure for transforming source code -> machine code is fully explainable by anyone with access to the compiler source code. There are no statistical estimations with black-box parameters involved.

▲

Tadpole9181 2 hours ago | parent | prev [-]

Yes!

Each step in abstraction we've made had people who felt uncomfortable at the level of magic they were accepting. At one point in the 70s/80s, traditionalists were arguing that C itself was too high level. Then in the 90s and early 00s, that languages like Python and garbage collection were absurd: a "good" programmer doesn't need them and they give up too much control. Then as web development ramped up, people entered the "Javascript is slop" phase into "React is slop" phase.

Anytime the barrier to entry is reduced and some skill or profession becomes more focused on output than the ego of the professionals, you can bet a counter-culture of people will rise up to oppose it. It's a threat to their sense of "betterness" and/or the (perceived) value of their career.

	▲	netburst an hour ago \| parent [-]
		While elitism and ego have certainly played a role in the dialog since the beginning of computing, this perspective conflates those issues with the very real technical arguments against the listed technologies. C and other contemporary languages had their limitations; you were sacrificing flexibility and potentially speed for a more pleasant and maintainable development experience. Garbage collection dates from long before the 90s and has always been controversial, in no small part from differing tastes and opinion on whether other memory management techniques are truly more difficult. The assumption that these technologies lowered the barrier to entry may be the crux of much of the argumentation.