{"id":1271,"date":"2018-06-06T20:12:48","date_gmt":"2018-06-06T20:12:48","guid":{"rendered":"http:\/\/sdi.thoughtstorms.info\/?p=1271"},"modified":"2018-06-06T20:12:48","modified_gmt":"2018-06-06T20:12:48","slug":"expression-in-programming-languages","status":"publish","type":"post","link":"https:\/\/sdi.thoughtstorms.info\/?p=1271","title":{"rendered":"Expression in Programming Languages"},"content":{"rendered":"<p>Source: <em><a href=\"https:\/\/www.quora.com\/If-Clojure-is-one-of-the-most-expressive-languages-of-today-and-has-similar-expressive-power-as-Common-Lisp-which-goes-back-to-early-80s-can-we-say-that-the-field-of-programming-languages-hasnt-progressed-much-in\/answer\/Phil-Jones\">My Quora Answer<\/a> : <\/em><\/p>\n<p><b>If Clojure is so expressive, and is basically Lisp, hasn&#8217;t there been any progress in expressivity in the last 50 years?<\/b><br \/>\nWell, as Paul Graham put it quite well, Lisp started as a kind of maths. That\u2019s why it doesn\u2019t go out of date. Or not in the short term.<br \/>\nYou should probably judge the evolution of expressivity in programming languages by comparing them to the inventions of new concepts \/ theories \/ notations in maths (or even science), not by comparison to other kinds of technological development like faster processors or bigger hard drives.<br \/>\nWhat I\u2019d suggest is that it turns out that function application is an amazingly powerful and general way to express \u201ctell the computer to calculate something\u201d.<br \/>\nOnce you have a notation for defining, composing and applying functions (which is what Lisp is), then you already have an extraordinarily powerful toolkit for expressing programs. Add in Lisp\u2019s macros which let you deconstruct, manipulate and reconstruct the definitions of functions, programmatically, and you basically have so much expressive power that it\u2019s hard to see how to improve on it.<br \/>\nYou can argue in the case of macros that, in fact, while the idea has been in Lisp for a while, the notation and semantics is still being actively fiddled with. We know that macros in principle are a good idea. But we\u2019re still working on the right language to express them.<br \/>\nPerhaps we can also argue that there\u2019s still room for evolving some other bits of expressivity. Eg. how to best express Communicating Sequential Processes or similar structures for concurrency etc. In Lisp all these things look like functions (or forms) because that\u2019s the nature of Lisp. But often within the particular form we are still working out how best to express these higher level ideas.<br \/>\nNow, the fact that functions are more or less great for expressing computation doesn\u2019t mean that the search for expressivity in programming languages has stopped. But it\u2019s moved its focus elsewhere.<br \/>\nSo there are three places where we\u2019ve tried to go beyond function application (which Lisp serves admirably) and improve expression :<\/p>\n<ul>\n<li>expressing constraints on our programs through types.<\/li>\n<li>expressing data-structures<\/li>\n<li>expressing large-scale architecture<\/li>\n<\/ul>\n<p>These are somewhat intertwined, but let\u2019s separate them.<br \/>\n<b>Types<\/b><br \/>\nTypes are the big one. Especially in languages like Haskell and the more exotic derivatives (Idris, Agda etc.) Types don\u2019t tell the computer to DO anything more that you can tell it to do in Lisp. But they tell it what can \/ can\u2019t be done in general. Which sometimes lets the compiler infer other things. But largely stops the programmer shooting themselves in the foot. Many programmers find this a great boost to productivity as it prevents many unnecessary errors during development.<br \/>\nClearly, the type declarations in languages like Haskell or Agda are powerfully expressive. But I, personally. have yet to see a notation for expressing types that I really like or find intuitive and readable. So I believe that there is scope for improving the expressivity of type declarations. Now, sure some of that is adding power to existing notations like Hindley-Milner type systems. But I wouldn\u2019t rule out something dramatically different in this area.<br \/>\nOne big challenge is this : by definition, types cut across particular bits of computation. They are general \/ global \/ operating \u201cat a distance\u201d. One question is where to write this kind of information. Gather it together in standard \u201cheader\u201d files? Or spread across the code, where it\u2019s closest to where its used? What are the scoping rules for types? Can you have local or \u201cinner\u201d types? Or are all types global? What happens when data which is typed locally leaks into a wider context?<br \/>\n<b>Data Structures<\/b><br \/>\nLisp\u2019s lists are incredibly flexible, general purpose data-structures. But also very low-level \/ \u201cprimitive\u201d.<br \/>\nI don\u2019t really know other Lisps. But it seems to me that Clojure\u2019s introduction of both a { } notation for dictionaries \/ maps. And a [ ] notation for data vectors has been useful. Complex data literals can now be constructed out of these by following the EDN format. And it\u2019s given rise to things like Hiccup for representing HTML and equivalents for other user-interfaces or configuration data. EDN is pretty similar to the way you define data in other contemporary languages like Javascript\u2019s JSON etc. So it\u2019s not that \u201cradical\u201d. But it\u2019s nice to have these data structures completely integrated with the Clojure code representation.<br \/>\nCan we improve expressivity for this kind of data representation language?<br \/>\nI\u2019m inclined to say that things like Markdown or YAML, that bring in white-space, make complex data-structures even more human readable and writable and therefore \u201cexpressive\u201d than even JSON \/ EDN.<br \/>\nIn most Lisps, but not Clojure, you can define reader-macros to embed DSLs of this form within programs.<br \/>\nSo Lisps have highish expressivity in this area of declaring data. In Clojure through extending S-expressions into EDN and in other Lisps through applying reader-macros to make data DSLs.<br \/>\nCan we go further?<br \/>\nBy collapsing data-structure into algebraic types, Haskell also comes up with a neat way of expressing data. With the added power of recursion and or-ed alternatives.<br \/>\nThis leads us to imagine another line of developments for expression of data structures that brings these features. Perhaps ending up like regular or context free grammars.<br \/>\nOf course, you can write parser combinators in any functional language. Which gives you a reasonable way to represent such grammars. But ideally you want your grammar definition language sufficiently integrated with your programming language that you can use this knowledge of data-structure everywhere, such as pattern-matching arguments to functions.<br \/>\nHaskell, Clojure\u2019s map representation, and perhaps Spec are moves in this direction.<br \/>\nBut for real expressivity about data-structures, we\u2019d have a full declarative \/ pattern-matching grammar-defining sub-language integrated with our function application language, for things like pattern matching, searching and even transformations. Think somewhere between BNF and JQuery selectors.<br \/>\nShen\u2019s \u201cSequent Calculus\u201d might be giving us that. If I understand it correctly.<br \/>\nA third direction to increase expressivity in defining data-structures is to go beyond custom languages, and go for custom interactive editors (think things like spreadsheet grids or drawing applications for graphics) which manipulate particular recognised data types. These increase expressivity even further, but are very domain \/ application specific.<br \/>\n<b>Architecture<\/b><br \/>\n\u201cArchitecture\u201d is everywhere. It describes how different modules relate. How different services on different machines can be tied together. It defines the components of a user-interface and how they\u2019re wired up to call-back handlers or streams of event processors. \u201cConfig files\u201d are architecture. Architecture is what we\u2019re trying to capture in \u201cdependency injection\u201d. And class hierarchies.<br \/>\nWe need ways to express architecture, but mainly we rely either on code (programmatically constructing UIs), or more general data-structures. (Dreaded XML files.)<br \/>\nOr specific language features for specific architectural concerns (eg. the explicit \u201cextends\u201d keyword to describe inheritance in Java.)<br \/>\nOO \/ message passing languages like Smalltalk and IO do push you into thinking more architecturally than many FP languages do. Even \u201cclass\u201d is an architectural term. OO languages push you towards thinking about OO design, and ideas like roles \/ responsibilities of various components or actors within the system.<br \/>\nTypes are also in this story. To Haskell programmers, type-declarations are like UML diagrams are to Java programmers. They express large scale architecture of how all the components fit together. People skilled in Haskell and in reading type declarations probably read a great deal of the architecture of a large system just by looking at type declarations.<br \/>\nHowever, the problem with types, and OO classes etc. is that they are basically about \u2026 er \u2026 \u201ctypes\u201d. They\u2019re great at expressing \u201cthis kind of function handles that kind of data\u201d. Or \u201cthis kind of thing is like that kind of thing except different in these ways\u201d.<br \/>\nBut they aren\u2019t particularly good to express relations between \u201ctokens\u201d or \u201cconcrete individuals\u201d. For example, if you want to say \u201cthis server sits at address W.X.Y.Z\u201d and uses a database which lives at \u201cA.B.C.D:e\u201d, then you\u2019re back to config. files, dependency injection problems and the standard resources of describing data-structures. Architecture is treated as just another kind of data-structure.<br \/>\nYes, good expressivity in data-structure helps a lot. So EDN or JSON beats out XML.<br \/>\nBut, really, it feels like there\u2019s still scope for a lot of improvement in the way we talk about these concrete relationships in (or alongside) our programs.<br \/>\nOK, I\u2019m rambling \u2026<br \/>\n<b>tl;dr : function definition \/ application is a great way to express computation. Lisp got that right in the 1960s, and combined with macros is about as good as it gets to express computation. All the other improvements in expressivity have been developed to express other things : types and constraints, data-structures and architecture. In these areas, we\u2019ve already been able to improve on Lisp. And can probably do even better than we\u2019ve done so far.<br \/>\n<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Source: My Quora Answer : If Clojure is so expressive, and is basically Lisp, hasn&#8217;t there been any progress in expressivity in the last 50 years? Well, as Paul Graham put it quite well, Lisp started as a kind of maths. That\u2019s why it doesn\u2019t go out of date. Or not in the short term. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[356],"class_list":["post-1271","post","type-post","status-publish","format-standard","hentry","category-opinion","tag-programming-languages"],"_links":{"self":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/posts\/1271","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1271"}],"version-history":[{"count":0,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/posts\/1271\/revisions"}],"wp:attachment":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1271"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1271"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1271"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}