John Backus: turd pusher

https://en.wikipedia.org/wiki/Von_Neumann_programming_languages
https://en.wikipedia.org/wiki/Talk:Von_Neumann_programming_languages

Backus tried to pass this off as scientific, but he was really passing turdware onto unsuspecting goyim.

It was the foundation for funding a whole class of programming language: the functional language with lazy evaluation.

Haskell and ``FP'' are also ``high-level abstract isomorphic copies of von Neumann architectures''.

declarations ↔ computer storage cells
pattern matching ↔ computer test-and-jump instructions
lazy evaluation ↔ fetching, storing instructions
expressions ↔ memory reference and arithmetic instructions.

The ``von Neumann bottleneck'' should be considered a financial bottleneck for ``PLT'' ``research''. ``Eliminating'' it with FP allows researchers to get grants for almost anything, without having to demonstrate any real-world benefits, because they say Backus already demonstrated them.

http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf

The genesis of Haskell
In 1978 John Backus delivered his Turing Award lecture, “Can programming be liberated from the von Neumann style?” (Backus, 1978a), which positioned functional programming as a radical attack on the whole programming enterprise, from hardware architecture upwards. This prominent endorsement from a giant in the field—Backus led the team that developed Fortran, and invented Backus Naur Form (BNF)—put functional programming on the map in a new way, as a practical programming tool rather than a mathematical curiosity.

you know what's really weird. Haskell was actually good in the early years.

>>2
It's even better now.

``Eliminating'' it with FP allows researchers to get grants for almost anything, without having to demonstrate any real-world benefits

Why does any kind of academic research require any form of real-world application? Academic research exists to increase the body of knowledge to mankind. Real world applications of this knowledge is merely a side effect and not the purpose of doing the research.

>>4
this. engineering is about applying science to real world, science is about understanding things

>>4
>>5
This all good, but in the real world you have something called economy and business. You need to produce results which can be used. This applies to both science and engineering. No one puts money into a sink with no benefits.

>>6
yeah, the lack of immediate results that can be monetized means that something is completely useless and we should stop doing that. abstract math? logic? theoretical physics? we don't need that shit. large hadron collider? fuck that, we must produce more android appers.

>>7
No, actually it means that it needs to produce results within X years depending on the business model. Obviously some things are done from tax money which means there are no such strict restrictions. However most shit with big budget needs to have an application within X years, etc. That's how modern society works.
There is no need for sarcasm, I understand your point and I even agree with it to a certain degree, but unfortunately that's how things work. Limited resources = limited opportunities.

>>4
There is nothing in this paper about ``increas[ing] the body of knowledge to mankind''. It is entirely about alleged real-world benefits to ``functional programming'' which have been proven wrong again and again.

People have been trying ``functional programming'' for more than 50 years and not one of these benefits has ever been validated.

https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf

>>6

No one puts money into a sink with no benefits.

People do because of the power of the scams. They say it makes programming cheaper, faster, more reliable, more secure, and the programs run faster.

Meanwhile, they don't do any research on normal (imperative) programming. Most of the real-world concurrency and proof techniques are from the 1970s and had nothing to do with the Backus or lambda calculus forms of FP. Functional programming takes the most money and produces the least value.

>>7
Backus wanted ``appers'' to be able to code. He said ``functional programming'' would make programming cheaper and more reliable. The fact that Haskell even exists is proof that he was wrong.

but the plain fact is that few languages make programming sufficiently cheaper or more reliable to justify the cost of producing and learning to use them.

``Functional programming'' is only suitable for toy problems like the recursive Fibonacci sequence and recursive factorial. Any time you add IO or error handling, ``functional programming'' falls apart.

Even Haskell was a toy language until they used the 1970s approach to imperative programming from domain theory. state -> (state, result) is straight out of the 1970s.

>>1
Are you seriously going to sit there and argue that nobody has ever made practical use of first-class functions in the entire history of programming?

🦆🦆 🐔

>>10
``First class functions'' are influenced by the lambda calculus, but have nothing to do with lazy evaluation, the idea of ``harmfulness'' of assignment, ``equational reasoning'', ``bottom'', ``pure functional programming'', ``referential transparency'', or any of the other failed ideas found in Haskell or Backus's paper.

``First class functions'' are about implementation. It's all about pointers and heap-allocated data structures. This concept fits well with traditional ``imperative'' programming. It is not in conflict with it, as those who are getting millions of dollars in grants would have you believe.

Creating a false conflict allows them to obtain grants and also to hold back mainstream programmers and programming languages because ``first class functions'' became associated with the failed and wrong-headed ``functional programming'' idea. If Backus didn't create this artificial conflict, it's possible that ``first class functions'' would have become mainstream in the 1970s or 1980s (around the same time as OOP, another form of heap-allocated data structures), which means there would be no reason to fund ``functional programming'' at all. In fact, if this was taught properly, as a result of implementation instead of complicated theory, honest people wouldn't even want to be ``functional programmers''.

It's considered to be the only good idea of ``functional programming'' because it didn't come from ``functional programming'' research launched by Backus in 1978. You need to know how people understood the concept before the invention of domain theory.

http://www.cs.cmu.edu/afs/cs/user/jcr/ftp/gedanken.pdf
http://cs.uwaterloo.ca/~dberry/FTP_SITE/reprints.journals.conferences/Berry1971BSretentionOR.pdf

By inventing domain theory, they disguised these implementation concepts (garbage collection, stacks, pointers, thunks) as complicated math and changed an implementation conflict (the efficiency of heap vs stack) into an ideological conflict (``functional'' vs ``imperative'').

You see this again with Haskell. They tried ``continuations'' and ``stream-based'' I/O before deciding on plain old imperative I/O. Now ordinary imperative programming is functional because they used the monad with the 1970s state function concept.

>>6,8
I can agree this is true for R&D firms of high technology businesses. I cannot say the same for public universities. The expression of "ivory tower scholars" are named for scholars who have highly specialized knowledge who do not associate in real world practical applications of the knowledge.

>>9
Functional programming is about distinguishing functionality in terms of pure and impure functions. I'm sorry if you cannot understand the utility of being able to distinguish them.

>>13

Functional programming is about distinguishing functionality in terms of pure and impure functions.

This is another myth. You have to actually read what Backus wrote, without falling for the marketing/scamming. Most of his scam was disproved in the 1970s and 1980s, when people wasted years trying to implement it. Even the name ``functional'' is a marketing/confidence trick, which associates ``it functions'' or ``it works'' in your mind. OOP started becoming popular after people were disillusioned with FP and the empty promises of its followers.

We only hear about successes, but I found at least 10 separate ``functional programming'' CPUs (not including Lisp computers, which is not ``FP'' in that sense). All of them were slower than ``von Neumann'' processors. When you compare them to array or vector processors, the distinction is even greater. The FP scammers were trying to destroy array processor research. Even today, they tell you linked lists are ``more mathematical'' than arrays. They also hate arrays because neural networks were superior to symbolic AI.

What you really mean (distinguishing side effects) has been around since the 1950s. This is why some languages distinguish between functions and subroutines/procedures. The Lispers got rid of this distinction and invented the ``impure function''.

>>14
Functions in functional programming are related to functions in mathematics. All they do is relate a set of inputs to a set of outputs where each input is related to exactly one output. It's no more complicated than that.

>>9
What is there to prove wrong about functional programming? It's a form of programming that makes use of functions.

>>15
Functional programming is part of the domain theory scam. Domain theory disguises ``lambda calculus'' as ordinary math.

When ``functional programming theorists'' say ``lambda calculus'', they don't mean Church's formalism (strings of symbols with rewrite rules). They really mean the ``mathematical objects'' of domain theory.

After examining the appalling type structure of conventional languages, using the elegant tools developed by Dana Scott, it is surprising that so many of us remain passively content with that structure instead of energetically searching for new ones.

Scott was the inventor of domain theory. The ``elegant tools'' Backus used are the fundamental concepts of domain theory.

An object x is either an atom, a sequence <x1, ... , xn> whose elements xi are objects, or ⊥ ("bottom" or "undefined").

Backus introduced bottom from domain theory into programming.

Lazy evaluation also comes from domain theory.

>>17
That's fantastic!

>>18
It's scamtastic.

>>19
Scam my anus

Bump to a great thread where Haskellcucks have sucked cock once again.

>>4
Because "knowledge" already implies a real-world application. Otherwise it's information.

>>22
yea go ahead and try to make that argument but you're seriously lacking in life experiences if you think that is possible. That's why you're blue pilled. Come back when you find out how wrong you are. I'll wait.

>>22
Why do you distinguish information and knowledge? Information is knowledge and knowledge is information. They are synonyms.

>>24
Because information may be false, useless or indecipherable. Knowledge, on the other hand, is power, ie something applicable to real world.

>>25
I still don't see the difference. There are plenty of people with false, useless and indecipherable knowledge. Information = knowledge.

>>26
You're dividing by zero here, that's why. "Putting your dick into a blender and turning it on will cause rainbow and unicorns to appear" is obviously not knowledge because it doesn't come from experience, is untrue and will lead to unexpected results if you tryto apply it. It does not teach you anything about dicks, blenders or rainbows. However, it is obviously information as it can be learned, stored in memory, transmitted etc. Thus, knowledge is a strict subset of information.

>>27
It does, in fact, teach you about the interaction between dicks and blenders.

>>28
Nope. Wrong information is not knowledge.