[susan_hall]

There have been some fantastic conversations on Hacker News about type systems. I've learned a lot about the different arguments for dynamic typing, versus strict typing, versus gradual typing. Java's type system may or may not have represented new thinking when it was under development in the early 1990s, but it certainly seems a bit dated in the year 2016. The limits of the Java type system have been discussed both here on HackerNews and also elsewhere, many times.

For those who want to consider arguments against Java's style of strict typing, 2 things I would recommend include "Agility & Robustness: Clojure spec, by Stuart Halloway":

https://www.youtube.com/watch?v=VNTQ-M_uSo8

He offers a chart that shows the strengths and weaknesses of strict typing versus unit tests versus the run-time checks offered by Spec. It's worth a look.

The discussions around gradual typing have been interesting, but to see how far the limits of this can be pushed, I would suggest everyone check out the Qi/Shen programming language:

https://en.wikipedia.org/wiki/Qi_(programming_language)

"Qi makes use of the logical notation of sequent calculus to define types. This type notation, under Qi’s interpretation, is actually a Turing complete language in its own right. This notation allows Qi to assign extensible type systems to Common Lisp libraries and is thought of as an extremely powerful feature of the language."

This next quote is from someone who has spent a long time experimenting with different Lisps:

"Qi (and its successor Shen) really push the limits of what we might call a Fluchtpunkt Lisp. I suspect it requires a categorization of its own. A few years ago I was looking for a Lisp to dive into and my searching uncovered two extremely interesting options: Clojure and Qi. I eventually went with Clojure, but in the intervening time I’ve managed to spend quality time with Qi and I love what I’ve seen so far. Qi’s confluence of features, including an optional type system (actually, its type system might be more accurately classified as “skinnable”), pattern matching, and an embedded logic engine based on Prolog, make it a very compelling choice indeed."

http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/

Mark Taver, who created Shen, posted a comment and then turned it into an essay here:

"The underlined sentence is a compact summary of the reluctance that programmers often feel in migrating to statically typed languages – that they are losing something, a degree of freedom that the writer identifies as hampering creativity. Is this true? I will argue, to a degree – yes. A type checker for a functional language is in essence, an inference engine; that is to say, it is the machine embodiment of some formal system of proof. What we know, and have known since Godel's incompleteness proof [9] [11], is that the human ability to recognise truth transcends our ability to capture it formally. In computing terms our ability to recognise something as correct predates and can transcend our attempt to formalise the logic of our program. Type checkers are not smarter than human programmers, they are simply faster and more reliable, and our willingness to be subjugated to them arises from a motivation to ensure our programs work. That said, not all type checkers are equal. The more rudimentary and limited our formal system, the more we may have to compromise on our natural coding impulses. A powerful type system and inference engine can mitigate the constraints placed on what Racketnoob terms our creativity. At the same time a sophisticated system makes more demands of the programmer in terms of understanding. ...That said, not all type checkers are equal. The more rudimentary and limited our formal system, the more we may have to compromise on our natural coding impulses. A powerful type system and inference engine can mitigate the constraints placed on what Racketnoob terms our creativity. At the same time a sophisticated system makes more demands of the programmer in terms of understanding. The invitation of adding types was thus taken up by myself, and the journey to making this program type secure in Shen emphasises the conclusion in this paragraph"

http://www.shenlanguage.org/library/shenpaper.pdf

I'm only quoting two favorites of mine, but of course I could post a hundred examples, all making a similar point. Java's style of strict typing is both weak and incomplete, and yet overly rigid at the same time. It's worth noting how many other strategies exist, that deliver more robustness, with greater flexibility.

[mncharity]

Both the Qi and Shen pages on Wikipedia were deleted last year.

https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio... https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...

Deletionpedia doesn't currently have them. The Internet Archive has snapshots:

http://web.archive.org/web/20141211005007/http://en.wikipedi... http://web.archive.org/web/20150102045719/http://en.wikipedi...

This is a long-standing problem (decade plus). Wikipedia deletionism interacts badly with research programming language pages. They tend to get deleted for "lack of notability", failing the test of "someone other than the people involved, wrote about it on a sufficiently high-profile piece of dead tree". And the pages face a recurrent threat of "heads you get deleted, tails we flip again in a few years". Some pages have been through deleted/recreated/deleted-again cycles. Some language communities manage to scrape together notability, others browbeat the deletion nominator, but it seems most pages get deleted. Fixing Wikipedia appears intractable.

Absent a wiki associated with something like LtU, creating an alternate wiki has been beyond the capabilities of the programming language research community. Which ends up reflected in balkanization - for example, people working on category theoretic type hierarchies in different languages, being unaware of each others' work. Shoemaker's children.

[pjmlp]

The day we loose the Internet it will many times worse than Alexandria's library fire.