Intellectuals are no different from anyone else - they live in the same reality and must be judged by their results. I don't think anyone would disagree that PL theory, as a body of work, has produced a set of languages whose penetration in the real world is oddly small both given (a) the investment in these technologies, and (b) the many real advantages of typed higher-order programming.
As a general pattern, usually when I see this outcome explained, it takes the form of blaming the user. We wouldn't let anyone else get away with this excuse, so why should intellectuals be treated as a privileged class?
To be anti-intellectual is to judge intellectuals more harshly than they deserve. To be pro-intellectual, also a cognitive bias, is to judge them more leniently than they deserve. In a world whose bias is generally pro-intellectual, it's easy for a neutral assessment to seem relatively anti-intellectual, but perhaps what you are perceiving is not an exceptional bias but the absence of a systemic bias which you've grown used to.
PL theory, as a "body of work" has produced a wide range of languages ranging from Agda to Scala to Java. Some of these have actually seen use! Everything from classical music to Justin Beiber. TAPL, for example, is certainly not limited to the less popular languages: it talks about the foundation for Java-style types as well. Some of the same people working on ML and Haskell are also behind designs of Java and C#.
The point of a language like Haskell is to be expressive and useful, not to appeal to a large base population. Popularity and industry uptake are not the only measures of success. (This is, coincidentally, one of the things I don't like much about Berkeley's graduate program, or at least the systems lab I spent a bit of time in: they did seem to think industry uptake to be the only metric that mattered.)
Beyond languages, PL theory serves the role of all theory: it's the foundation upon which everything else is built. Things like the JVM memory model are based on the theory themselves and designed with tools stemming directly from that theory. Sure, the average programmer on the street is never going to use a theorem prover, but they will use the JVM where the memory model has been verified with one.
All this reminds of nothing more than the usual arguments that Linux is a complete failure because nobody uses it on the desktop. But I think that argument is not true even if you limit yourself to "Linux on the desktop is a failure": sure, not many people use Linux on the desktop, but the ones who do find it very useful and are exceptionally productive. Same principle applies to PL theory and functional programming languages.
There are many different ways to have an effect in the world, and the most obvious and direct one is not necessarily best. Even if it feels best.
(Also, it is a serious overstatement to attribute Java and C# to PL theorists. Gilad Bracha is not James Gosling. PL theorists have contributed to some extensions to these languages. Typically, the extensions that confuse people and make them feel stupid.)
The difference between the foundation and a foundation is enormous, because (with your very large expensive foundation) you are asking programmers either to program without knowing the foundations of their work, or to learn a large and challenging body of mathematics.
And you know, higher-order typed programming is good enough that it's almost worth it. For most potential customers, however, learning PL theory does not seem to be worth it. Nor are they comfortable in programming in Haskell, a very powerful and complex environment, without understanding it.
It's this "the customer is just wrong" attitude that makes some of us sense an area ripe for disruption. Pride goeth before a fall.
Doesn't this apply to syntax as well?
It would certainly be an interesting practical experiment to try to adapt a conventional syntax to the same semantics, or even to discard Hoon and create a more conventional language targeting Nock (which Urbit would have no trouble running).
PL research just hasn't had much affect at all on mainstream programming.
It's too bad. The PL world has a lot of good ideas. It's unfortunate they try to make them totally inaccessible.
Worse still that industry has no interest in raiding the PL world. A lot of the languages that have been designed are perfectly usable by mere mortals and a real step up from languages coming out of industry.
Compare OCaml and Java in 1996. OCaml (then Caml Special Light) was clearly the better language. Why didn't anyone get to use it?
Tikhonj is right about this kind of "anti-intellectualism." But pro-intellectualism is a bias as well.
I'm a PL theorist, and I disagree.
Who cares about your opinion on PL theory, its practitioners, and its textbooks? Is internalizing your hate for TAPL necessary for understanding the semantics of Urbit and related technologies? Why don't you just state succinctly what your ideas are and let them stand on their own merits.
That being said, I have no idea what your ideas are. Your website is unintelligible. Ironically, one of the things PL theory provides is a common vocabulary amongst practioners, which helps us communicate. I shouldn't have to learn a new alphabet (or in your parlance, a set of runes?) to figure out what new ideas you bring to the table. That kind of stuff is just not interesting to me. It's like if you 'rejected' English and wrote the rest of your work in Esperanto.
We may mean different things by "practitioners." I mean programmers. Unfortunately, your vocabulary is not common to programmers and shows no signs of becoming so.
Mine isn't either. But at least I've only been trying for a week. I know it seems strange to introduce new designs in the 21st century - most people assume, rightly of course, that everything worthwhile got figured out in the 20th.
Why I disagree with your disparaging remarks aimed at PL theorists is irrelevant.
The Urbit documentation should say what Urbit is, why it is important, and how to use it. Your disparaging remarks do not help to answer these questions. In fact, they do the opposite by antagonizing many readers and unfortunately giving you the appearance of a crank. Therefore, you should remove the remarks.
Knocking down PL theory does not boost Urbit up.
> We may mean different things by "practitioners." I mean programmers. Unfortunately, your vocabulary is not common to programmers and shows no signs of becoming so.
This is flamebait.
> I know it seems strange to introduce new designs in the 21st century - most people assume, rightly of course, that everything worthwhile got figured out in the 20th.
This is a strawman, and a particularly odd thing to say to someone who is also interested in advancing the state of the art.
Yes, there is a purpose to the disparaging remarks. The purpose is to make this asymmetry apparent.
Academia in the late 20th century is something of a footnote to the great achievements of the 19th and early 20th. In this golden age of science, peer disparagement was more or less universal. It is only in the second half of the 20th, the golden age of grants as it were, that genuinely criticizing your peers becomes a faux pas, and team-building becomes the essential skill for a practicing scientist.
But wait, I'm not your peer at all. I guess I forgot that...
I'm afraid I don't have anything else to add to this discussion. Good luck with your endeavors.
The attacks on TAPL too are seemingly weird, because arguably it's one of most thudingly concrete and down to earth books on types ever written. The whole book is about applications to real world problems and reveling in the fact that one haven't read it seems very asinine.
All I would say is, s/types/PL theory. Let's take your statement as true and stipulate that TAPL is in the top 1% of down-to-earthness of books on PL theory. Is it in the top 1% of down-to-earthness books on, say, Java? If not, what does this tell us about PL theory? You have read TAPL, right?
PL theory is a beautiful system and I've never said otherwise. TAPL is also very good at keeping doors open. But so are many things. PL theory is not the theory of programming, any more than TAPL is the doorstop. It is a theory of programming and a doorstop.
Yes I have read TAPL, it's sitting on my desk right now. I'm not even sure what you're trying so say, the fact that a book on type system design doesn't have advice on Java* seems perfectly natural to me. A book on goat husbandry doesn't have advice on Rails development. What are you trying to say?
> PL theory is not the theory of programming, any more than TAPL is the doorstop.
This is the strawmen that you're arguing against that seems bizarre to many people. PL theory is not so much about the lambda calculus and Hindley-Milner as it is about applying rigor and discipline to the study of programming languages. And yes, sometimes that involves learning the mathematical formalism.
* Chapter 19 in TAPL actually does have an implementation of Java's type system.
What you're asserting is that without this system of rigor and discipline, there can be no other rigorous and disciplined way of defining programming languages. For one thing, this flies in the face of everything we know about the philosophy of mathematics.
I think my way of defining programming languages is pretty rigorous and disciplined. I'll continue to think that until you or anyone can identify some sloppy ambiguities. I note also that my foundation fits on a T-shirt and yours needs a math textbook...
Here, you can look at my axioms and identify anything unrigorous or undisciplined about them:
https://github.com/urbit/urbit/blob/master/Spec/nock/5.txt
A bunch of people have written compatible implementations from the spec, which is the RFC world's general sanity test.
Obviously you never met any of these people, but you will find many negative stereotypes coming to mind. Are many of them true? Perhaps they are. Was the old Versailles full of charming, brilliant, talented, wonderful people? It most certainly was.
You might also have some stereotypes of PHP programmers. Perhaps they're true as well. No set of human beings is without patterns of fault. However, the PHP programmer is a peasant and cheerfully accepts the daily rain of mockery that falls on his head. He knows he is not above being laughed at, indeed he knows he is laughable, as all human beings are in some way laughable.
The distinctive feature of a privileged class, always and everywhere, is that it can't accept being mocked. Unfortunately this always increases the temptation to mock it, which I agree is a low and unproductive pastime. But anything to make type inference seem fun...
Some PLs, are therefore academic in the same sense that Esperanto is academic, and are rightly criticized for that. They may be "perfect languages", but the fact they are not widely adopted is conclusive proof that they're a failure, at least in some respects. Sometimes this failure could be mere marketing; usually it's much more than that.
Often the financial backing is very conservative. It does not like to take risks. So they go with what is familiar.
Second, I can't think of a single academic I know that set out to create "the perfect language". Often one is created to explore an idea. That does not mean the language isn't incredibly valuable for the lessons it provides - but it likely was never meant to hit mass adoption.
Hence "academic". Design for idea exploration rather than widespread adoption is a crucial property of a language, and a valid target for criticism.