Wikipedia:Miscellany for deletion/Portal:Haskell (programming language)

Portal:Haskell (programming language)

Portal:Haskell (programming language) (edit | talk | history | links | watch | logs)

Portal:Java (programming language) (edit | talk | history | links | watch | logs)

Portal:Python (programming language) (edit | talk | history | links | watch | logs)

Narrow topic area: a particular programming language. The selected content is general mathematics and programming articles (like natural deduction, partial function, higher-order logic), which has nothing specifically to do with Haskell. Leviv ich 07:22, 24 March 2019 (UTC)

Note: the Java and Python portals have been added to the original nomination per the question below. Please see my comment below. Leviv ich 17:20, 24 March 2019 (UTC)

Question: There are other programming language portals: Category:Computing portals. Are they endangered as well? --Ancheta Wis   (talk | contribs) 10:43, 24 March 2019 (UTC)

Good point. I see Java and Python portals in the category and have added them here, with a note below. Leviv ich 17:20, 24 March 2019 (UTC)

Please Keep. --Ancheta Wis   (talk | contribs) 10:32, 24 March 2019 (UTC) : Haskell is a difficult language to learn in part because

1. The skilled people who write about Haskell are generally researchers who embed their research-level knowledge in their documentation about Haskell, so that the portal has to cover the significance of those topics as well. Note that a real language such as Haskell enlivens the research-level, advanced, general statements; they aren't just theoretical; they highlight what is easy and what is hard.
2. The less-skilled write about even narrower knowledge which is partial in nature, making their documentation even less useful than the research-level knowledge. The selected articles allow us to embed what we learn about Haskell into the general knowledge which we gain when learning this specific language.
3. The concise nature of the Haskell language, together with the precision of the error messages from GHC, make learning the language difficult for people who are inexperienced in functional programming. Thus the topics selected are necessary background.
   • For example, I had to add in material about the Girard-Reynolds isomorphism to make the Haskell Core understandable; Core is really the implementation of Girard-Reynolds, but the existing articles do not yet state this because of factors 1 and 2 above.
     • Natural deduction is part and parcel of sequent calculus, again a necessary part for proving that one's Haskell will run.
     • Higher-order logic is part and parcel of Higher order abstract syntax which is very easy to express in Haskell, making Haskell an ideal language for implementing embedded Domain-specific languages, because they are partial in nature. But Haskell is concise, so that the achievement of creating an eDSL, while actually significant, may look small to to a non-participant, as might Haskell itself.
       • Some features of Haskell might not seem useful, since there is seeming redundancy in the use of :: (meaning has type) and the fact that type inference is automatable in the Hindley-Milner version of the Haskell type system; but when the Girard-Reynolds version of the Haskell type system was introduced, then :: became 'necessary', in order to disambiguate some types which were otherwise undecidable. --Ancheta Wis   (talk | contribs) 10:41, 26 March 2019 (UTC)
4. The topics I selected were useful not because they appear general, but because they are applications of the topics needed to better learn Haskell. Thus that which appears narrow (for example Haskell itself) expands in significance. Note that a topic which appears small to us in this era, such as long division, a topic which was master's - degree level in the Middle ages, was once a research topic:

   ... the design of computing systems can only properly succeed if it is well grounded in theory, and that the important concepts in a theory can only emerge through protracted exposure to application.—Robin Milner --Ancheta Wis   (talk | contribs) 14:48, 25 March 2019 (UTC)

   • Constructivism (philosophy of mathematics) was chosen because it is the philosophy-put-into-practice of a software developer, as is Intuitionistic type theory and Intuitionistic logic. They are quite practical, and more than theoretical, in other words.
   • Alpha equivalence, Beta reduction, and Eta conversion are basic for Haskell; you can't proceed without them, as Chris Allen has shown.
   • Anonymous functions, or better, lambdas are part of Haskell.
   • Continuation-passing style is a part of Haskell which means that functional reactive programming can be implemented in Haskell.
   • Curry-Howard isomorphism and the Girard-Reynolds isomorphism are fundamental to Haskell
   • Currying is a part of Haskell.
   • Declarative programming and Denotational semantics are only part of what is needed to code in Haskell
   • Domain-specific language -- covered above
   • Effect systems can be coded in Haskell. See Oleg Kiselyov's work, coded in Haskell, on extensible effects
   • The Exponential object is a notation to express higher level type application to other types, which is allowed in Girard-Reynolds (the Haskell core)
   • Expression (computer science) and Expression (mathematics) are integrated into one concept in this language, which points to the implementation of Girard-Reynolds (the Haskell core). Expr is about seven lines of Haskell code (a sum type) in Haskell Core.
   • Function types are First-class citizens in Haskell
   • Hash consing
   • Higher-order abstract syntax -- covered above, but Higher-order functions and Higher-order logic are part and parcel of any Haskell implementation of some Domain-specific language (some specific situation -- you can think of this as a Business Case)
   • The Hindley–Milner type system is decidable, and has been part of Miranda and Haskell since their early days. This is the reason that Haskell can automate type inference.
   • Intuitionistic type theory -- covered above
   • Intuitionistic logic -- covered above
   • Kan extensions allow us to carry along the data so that we can call by need, a practical part of both effectful programming (i.e. monads) and lazy evaluation.
   • Lambda calculus definition, Lambda calculus, and Lambda lifting allow us to exploit Lazy evaluation when we need it along some axis of the Lambda cube. Note that the specialization to some Topos allows us to skip past the infinities that some other languages would force us to step into, but which lazy evaluation allows us to skip.
   • Linear logic is Girard's resource-oriented logic, which is a basis for Effect systems
   • Monad (functional programming) was first implemented in Haskell
   • Natural deduction -- covered above. Note that it is groundwork for the normal forms which get produced by alpha, beta, and eta transformations covered above.
   • Normal form (abstract rewriting) is a fundamental part of a Haskell thunk, but weak head normal form doesn't even have an article yet
   • Partial application, and Partial function are discussed above. They are built-in to the Haskell language with a consistent grammar which doesn't even need to identify them as special cases, they are first-class citizens of the language. Now compare to other functional languages which have to create special machinery. 16:44, 24 March 2019 (UTC)
   • Partially ordered sets are fundamental to any Haskell type. They need to be derived via natural deduction, bottom-up for each topos.
   • Pointfree programming is either very high-level (via Higher-order type classes) or very low-level (via natural deduction). As an example, the point-free implementation of Map-reduce (call it mr) of Google fame is one line in Haskell: mr = (. map).(.).foldr --credit: Udo Stenzel's derivation. ghci consumes this without complaint. Other languages implement it with thousandfold (or more) increases in lines of code. --16:44, 24 March 2019 (UTC)
   • Polymorphism (computer science) can be implemented by the Girard-Reynolds isomorphism, implemented largely in Haskell Core, which is typed (colloquially termed Big Lambda) in less than 20 lines of Haskell. --Ancheta Wis   (talk | contribs) 16:44, 24 March 2019 (UTC)
   • Purely functional data structures, and Purely functional programming can exploit lazy evaluation while using some interpreter such as ghci to prove that the Haskell code is correct for the denoted cases (which could be infinite in number).
   • Rewriting -- the transformations from one form to another (e.g., the alpha, beta, eta discussed above) while remaining assured of correctness. This in particular is a difficult concept to grok because the different forms can morph from one to the other, and the skilled practioners seem to have this ability of fluent translation, while remaining mathematically correct, to the despair of anyone trying to follow their code. --Ancheta Wis   (talk | contribs) 16:44, 24 March 2019 (UTC)
   • Scott continuity describes a mapping between posets, which are the elements of the type system being implemented in the Haskell code. For example, "two particularly notable examples of Scott-continuous functions are curry and apply." Their cartesian closed category cannot be a foreign concept to a Haskeller. --Ancheta Wis   (talk | contribs) 13:53, 24 March 2019 (UTC)
   • Sequent -- discussed above
   • Sequent calculus -- discussed above, as the framework for expressions which surround a Turnstile --Ancheta Wis   (talk | contribs) 16:44, 24 March 2019 (UTC)
   • SECD machine (an abstract machine) for implementing Lambda calculus
   • Side effect (computer science) -- not a part of Haskell, unless you seek one
   • Strictness analysis -- there is an operator which tells the compiler to reduce the expression right away, absolving the coder of the responsibility of carrying along its weak head normal form (the lazy instance). --16:44, 24 March 2019 (UTC)
   • Subobject classifier -- a necessary part of a topos. A classifier might be reducible to a Boolean function, but the Subobject classifier is allowed to be even more general (ala higher order type theory (HoTT).). This kind of classifier is a predicate in Gottlob Frege's sense as it includes semantic meaning. --Ancheta Wis   (talk | contribs) 13:44, 25 March 2019 (UTC)
   • Supercombinator
   • Syntactic closure
   • System F -- see Girard-Reynolds
   • Tail call -- one strategy for handling thunks
   • Thunk -- a fundamental part of Haskell, discussed above
   • Turnstile (symbol) used in sequents above
   • Type classes were first used in Haskell
   • Type constructors reside on the left hand side of a declaration, while data constructors reside on the right hand side of a declaration, and can be sum types or product types. --Ancheta Wis   (talk | contribs) 16:44, 24 March 2019 (UTC)
   • The kind of Type inference which Haskell offers depends on the Type system it implements; Haskell at one time supported only Hindley-Milner, but now offers a version of System F --Ancheta Wis   (talk | contribs) 16:44, 24 March 2019 (UTC)
   • Intuitionistic Type theory is a basis for Haskell
   • Unified Modeling Language can depict Haskell code, because it has arrows. This defines graphs and allows Graph rewriting. --Ancheta Wis   (talk | contribs) 16:44, 24 March 2019 (UTC)
5. I am constructing my reply, but I figured I had better post what I have typed to better withstand the onslaught. I would appreciate it if other editors were not to jump into the middle of my markup, but please post below this instead. --Ancheta Wis   (talk | contribs) 10:32, 24 March 2019 (UTC)
6. I find it illuminating that it seems necessary to justify what might seem obvious to some, namely the application of general concepts to a specific detail of Haskell; either the implementation from a general statement to the details in some Haskell code are not obvious enough, for the reader of the Haskell code, or the Haskell coder has not explained the code well. Unfortunately, the types might be situation-dependent: a type error in the Topos. For example we have a situation where the readers are encountering a situation which is not meeting a reader's expectations. This does not invalidate the Portal: One fundamental is that Portals are doorways to realms. What one person sees is not necessarily what another sees. One's belief system can color what one sees. That makes a portal a tool for the reader. But if our only mental tool is a hammer, we need not search for nails to pound down; maybe we can wait for a proper reframing for the Portal. --Ancheta Wis   (talk | contribs) 12:28, 24 March 2019 (UTC) I hesitate to lay this problem solely at the feet of the ghci REPL. The tools we seek remain to be found. Perhaps a reader of this Portal can be helped by its existence.
7. Note that deletion of other portals was predicated on an inverse reason. If this portal cannot survive on account of its breadth then this is a Catch-22. --Ancheta Wis   (talk | contribs) 13:09, 24 March 2019 (UTC)

References

• Delete this portal doesn't have a clearly defined scope, as most of the content relates to general topics in computer science or functional programming in general, rather than to Haskell in particular. As a result it would be better placed at another portal such as Portal:Functional programming. Portals aren't intended as aids to help people learn programming languages, if that is the intention then I'd suggest contributing to Wikibooks who have that sort of thing in scope. Hut 8.5 11:34, 24 March 2019 (UTC)

Please note that its scope is Haskell. I am trying to give the significance of the selected articles to Haskell, which is still in process. That ought to show its scope is quite broad. --Ancheta Wis   (talk | contribs) 11:58, 24 March 2019 (UTC)

In fact the Haskell Wikibook has a nice discussion of weak head normal form which if it were in the article (not to mention portal), would be deleted for lack of Reliable Sources. --Ancheta Wis   (talk | contribs) 12:02, 24 March 2019 (UTC)

One problem with a Functional programming portal is that it would be so general (by for example avoiding Haskell syntax) that its points would be vague. But for a specific language, such as Haskell, the expressions would speak for themselves, so to speak.

But ... the design of computing systems can only properly succeed if it is well grounded in theory, and that the important concepts in a theory can only emerge through protracted exposure to application.—Robin Milner --Ancheta Wis   (talk | contribs) 15:08, 25 March 2019 (UTC)

It is a type error to consider a Portal as an article; they do not share namespaces; the criteria for Portals, such as the Main page, the Help portal are different from articles. And yet we see the same mental habits carry across the namespaces. Please consider that other possibilities exist for the encyclopedia.

--Ancheta Wis   (talk | contribs) 17:06, 24 March 2019 (UTC)

• Nom's update: Per the question above, I added the Java and Python portals to this nomination. Any comments above are before the bundling. The arguments are common to all programming language portals: they are not broad enough to justify a portal under POG. For example, Python has only one picture (of the creator), and the Java portal similarly doesn't have useful pictures, except for the one mandlebrot sequence animation, there just aren't useful java pictures. (One picture is of Java's mascot, kind of PROMO.) Also, these portals should not be used to create a reference guide or a tutorial because WP:NOTHOWTO. I do appreciate the work that went into gathering the links relevant to Haskell but those belong in the article. A portal on Haskell (or any programming language) is not justified. Note we already have Portal:Software and Portal:Computer science (and maybe the former should be merged with the latter). Leviv ich 17:20, 24 March 2019 (UTC)
• Delete all the extensive keep argument makes a great case why the article needs work, not the portal. Portals are generally short overviews amd these topics are evidently not well suited to the portal approch when the keep argument is as long as the portal. Legacypac (talk) 17:59, 25 March 2019 (UTC)

  This argument is a catch-22; it is inconsistent to criticize the many portals which are up for deletion on account of reason A, and yet argue for the deletion of yet other portals on account of not reason A. --Ancheta Wis   (talk | contribs) 10:41, 26 March 2019 (UTC)

• Merge all to Portal:Programming languages which is an appropriate scope for a portal and would allow the retention the scope of the concepts, etc. The individual content would not be vague, there would just be articles, etc. at the current depth selected from a wider pool. Thryduulf (talk) 20:14, 25 March 2019 (UTC)
• Delete all These pages have no content. Energy should be spent on improving the articles, not finding a way to extract pieces from elsewhere into a fan page. Naturally someone might like to add suitable links to Portal:Programming languages but there is no content worth merging. Johnuniq (talk) 01:18, 26 March 2019 (UTC)

  It is a type error to consider a Portal as an article; they do not share namespaces; if we were to consider portals as doorways to other types then a portal's brevity (as links) allows us to compress its message length, in order to express some 'higher content' for us. So the 'selected articles' need only be details which might serve the reader in their search for what matters to them alone. --Ancheta Wis   (talk | contribs) 11:00, 26 March 2019 (UTC)

• Keep: Haskell, Java and Python are widely different ecosystems, each with their own specificity. These should not be treated as fanpages. I think it's worth it to have places to collect a curated list of topics about each of those ecosystems. Merging them all under a general "Programming Languages" portal wouldn't cut it, IMHO. klɛz (talk) 08:34, 26 March 2019 (UTC)

Each of these topics would be a good featured topic within Portal:Programming languages Legacypac (talk) 08:45, 26 March 2019 (UTC)

If that's the case, should Portal:Programming languages be organized into subsection that cover stuff specific to particular programming languages? Subpages? I'm still new here, I'm not sure how this would work. In other words: is there a way we can organize the main programmin languages portal to still be a useful place for a curated list of articles regarding a particular ecosystem? People looking for information about Java-related topics may not care about thunks, as much as Haskell programmer won't probably care about the JVM. klɛz (talk) 10:24, 26 March 2019 (UTC)

• Keep I fail to see the point of having a single huge generic portal, which is itself brand new, and we are already discussing cramming everything into it. These languages are large topics and have large software ecosystems attached to them, that are entirely different from each other and have a single focus. The logical action would be to keep these portals, have more of them and link them to Portal:Programming languages in a hierarchy and expand on them. As regards their content, they may be new but over time they will be populated correctly. It is a real shame that portal's were not really pushed, as far as a know, if that is correct? They seem to provide a lower level of abstraction than articles and hence should be easier to find by the reader and navigate to an appropriate article that is within that subject. Reading the spec at WP:PORTAL, they are "Main Pages" for specific topics or areas. Taking the topic path, they are absolutely ideal for these three languages. Lets have more for C/C++ and C#. scope_creep^Talk 12:05, 26 March 2019 (UTC)

• Keep All of these programming language portals, per the detailed and thorough view of Scope creep above. Makes perfect sense. Also not particularly convinced by some of the generalized "I don't like it" notions for deletion herein in this discussion. I am also impressed with the rationales of Ancheta Wis in this discussion. North America¹⁰⁰⁰ 16:43, 26 March 2019 (UTC)

• Keep All largely per the comment made by Scope creep above. Further, given the portals section of this page, there exist portals for additional languages than those mentioned here, like C and .NET (which both contain notably more content than the Haskell, Java, and Python portals in their current state). These portals should be expanded, not all deleted. --HunterM267 ^talk 21:13, 26 March 2019 (UTC)
• Delete the Haskell portal that was originally nominated. The fact that such a long justification is made for keeping the portal is evidence that the topic is too complex, too detailed, too specific to be appropriate for a portal. We are not arguing about deleting the article, only about the portal. The other programming languages should not have been added to this nomination, because they will complicate the close. I may express a view on them within the next four days. Robert McClenon (talk) 03:54, 27 March 2019 (UTC)
• Comment - in relation to Robert McClenon's response above, I would support separating the deletion discussions for the Haskell portal and the Java / Python portal. My "Keep All" vote above stands, however, I would be slightly more inclined to argue that Java and/or Python are more deserving of a portal than Haskell. --HunterM267 ^talk 04:33, 27 March 2019 (UTC)

• Comment – Regarding, "The other programming languages should not have been added to this nomination, because they will complicate the close" above, yes, bundled nominations can obfuscate matters, sometimes leading to a WP:TRAINWRECK situation. It also opens doors to potential ambiguity and misinterpretation by closers, who could potentially incorrectly assume that an !vote for a single page (as per the above) applies to all pages. It's better to nominate separately, in my opinion. North America¹⁰⁰⁰ 04:39, 27 March 2019 (UTC)