“What next?”

Again my pet ignored language&#x2F;compiler technology issue goes unmentioned: data layout optimizations.<p>Control flow and computation optimizations have enabled use of higher level abstractions with little or no performance penalty, but at the same time it&#x27;s almost unheard of to automatically perform (or even facilitate) the data structure transformations that are daily bread and butter for programmers doing performance work. Things like AoS-&gt;SoA conversion, compressed object references, shrinking fields based on range analysis, flattening&#x2F;dernormalizing data that is used together, converting cold struct members to indirect lookups, compiling different versions of the code for different call sites based on input data, etc.<p>It&#x27;s baffling considering that everyone agrees memory access and cache footprint are the current primary perf bottlenecks, to the point that experts recommend considering on-die computation is free and counting only memory accesses in first-order performance approximations.

Grayson&#x27;s very first answer to &quot;what&#x27;s next&quot; is &quot;ML modules,&quot; a language feature probably few people have experienced first hand. We&#x27;re talking about ML-style modules here, which are quite precisely defined alongside a language (as opposed to a &quot;module&quot; as more commonly exists in a language, which is just a heap of somewhat related identifiers). ML modules can be found in the mainstream ML family languages (Standard ML, Ocaml) as well as some lesser known languages (1ML, Manticore, RAML, and many more).<p>It&#x27;s really hard to do justice explaining how amazing modules are. They capture the essence of abstraction incredibly well, giving you plenty of expressive power (alongside an equally powerful type system). Importantly, they compose; you can write functions from modules to modules!<p>(This is even more impressive than you think: modules have runtime (dynamic) AND compile time (static) components. You&#x27;ve certainly written functions on runtime values before, and you may have even written functions on static types before. But have you written one function that operates on both a static and a dynamic thing at the same time? And what kind of power does this give you? Basically, creating abstractions is effortless.)<p>To learn more, I recommend you read Danny Gratzer&#x27;s &quot;A Crash Course on ML Modules&quot;[1]. It&#x27;s a good jumping off point. From there, try your hand at learning SML or Ocaml and tinker. ML modules are great!<p>[1]: <a href="https:&#x2F;&#x2F;jozefg.bitbucket.io&#x2F;posts&#x2F;2015-01-08-modules.html" rel="nofollow">https:&#x2F;&#x2F;jozefg.bitbucket.io&#x2F;posts&#x2F;2015-01-08-modules.html</a>

One big problem we&#x27;re now backing into is having incompatible paradigms in the same language. Pure callback, like Javascript, is fine. Pure threading with locks is fine. But having async&#x2F;await and blocking locks in the same program gets painful fast and leads to deadlocks. Especially if both systems don&#x27;t understand each other&#x27;s locking. (Go tries to get this right, with unified locking; Python doesn&#x27;t.)<p>The same is true of functional programming. Pure functional is fine. Pure imperative is fine. Both in the same language get complicated. (Rust may have overdone it here.)<p>More elaborate type systems may not be helpful. We&#x27;ve been there in other contexts, with SOAP-type RPC and XML schemas, superseded by the more casual JSON.<p>Mechanisms for attaching software unit A to software unit B usually involve one being the master defining the interface and the other being the slave written to the interface. If A calls B and A defines the interface, A is a &quot;framework&quot;. If B defines the interface, B is a &quot;library&quot; or &quot;API&quot;. We don&#x27;t know how to do this symmetrically, other than by much manually written glue code.<p>Doing user-defined work at compile time is still not going well. Generics and templates keep growing in complexity. Making templates Turing-complete didn&#x27;t help.

I&#x27;d say the elephant in the room is graduating beyond plaintext (projectional editor, model-based editor).<p>If you think about it so many of our problems are a direct result of representing software as a bunch of files and folders with plaintext.<p>Our &quot;fancy&quot; editors and &quot;intellisense&quot; only goes so far.<p>Language evolution is slowed down because syntax is fragile and parsing is hard.<p>A &quot;software as data model&quot; approach takes a lot of that away.<p>You can cut down so much boilerplate and noise because you can have certain behaviours and attributes of the software be hidden from immediate view or condensed down into a colour or an icon.<p>Plaintext forces you to have a visually distracting element in front of you for every little thing. So as a result you end up with obscure characters and generally noisy code.<p>If your software is always in a rich data model format your editor can show you different views of it depending on the context.<p>So how you view your software when you are in &quot;debug mode&quot; could be wildly different from how you view it in &quot;documentation mode&quot; or &quot;development mode&quot;.<p>You can also pull things from arbitrarily places into a single view at will.<p>Thinking of software as &quot;bunch of files stored in folders&quot; comes with a lot baggage and a lot of assumptions. It inherently biases how you organise things. And it forces you to do things that are not always in your interest. For example you may be &quot;forced&quot; to break things into smaller pieces more than you would like because things get visually too distracting or the file gets too big.<p>All of that stuff are arbitrary side effects of this ancient view of software that will immediately go away as soon as you treat AND ALWAYS KEEP your software as a rich data model.<p>Hell all of the problems with parsing text and ambiguity in sytnax and so on will also disappear.

I like to read about various problems in language design, as someone who is relatively naive to its deeper intricacies it really helps broaden my view. That said I have seen a trend towards adding various bells and whistles to languages without any sort of consideration as to whether it actually, in a measurable way, makes the language better.<p>The downside to adding an additional feature is that you are much more likely to introduce leaky abstraction (even things as minor as syntactical sugar). Your language has more &quot;gotchas&quot;, a steeper learning curve, and a higher chance of getting things wrong or not understanding what is going on under the hood.<p>For this reason, I have always appreciated relatively simple homoiconic languages that are close-to-the-metal. That said, the universe of tools and build systems around these languages has been a growing pile of cruft and garbage for quite some time, for understandable reasons.<p>I envision the sweet spot lies at a super-simple system language with a tightly-knit and extensible metaprogramming layer on top of it, and a consistent method of accessing common hardware and I&#x2F;O. Instant recompilation (&quot;scripting&quot;) seamlessly tied to highly optimized compilation would be ideal while I am making a wishlist :)

[Aside: Why do I have the Whiley (<a href="http:&#x2F;&#x2F;whiley.org&#x2F;about&#x2F;overview&#x2F;" rel="nofollow">http:&#x2F;&#x2F;whiley.org&#x2F;about&#x2F;overview&#x2F;</a>) link marked seen?]<p>I was mildly curious why Graydon didn&#x27;t mention my current, mildly passionate affair, Pony (<a href="https:&#x2F;&#x2F;www.ponylang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ponylang.org&#x2F;</a>), and its use of capabilities (and actors, and per-actor garbage collection, etc.). Then, I saw,<p>&quot;<i>I had some extended notes here about &quot;less-mainstream paradigms&quot; and&#x2F;or &quot;things I wouldn&#x27;t even recommend pursuing&quot;, but on reflection, I think it&#x27;s kinda a bummer to draw too much attention to them. So I&#x27;ll just leave it at a short list: actors, software transactional memory, lazy evaluation, backtracking, memoizing, &quot;graphical&quot; and&#x2F;or two-dimensional languages, and user-extensible syntax.</i>&quot;<p>Which is mildly upsetting, given that Graydon is one of my spirit animals for programming languages.<p>On the other hand, his bit on ESC&#x2F;dependent typing&#x2F;verification tech. covers all my bases: &quot;<i>If you want to play in this space, you ought to study at least Sage, Stardust, Whiley, Frama-C, SPARK-2014, Dafny, F∗, ATS, Xanadu, Idris, Zombie-Trellys, Dependent Haskell, and Liquid Haskell.</i>&quot;<p>So I&#x27;m mostly as happy as a pig in a blanket. (Specifically, take a look at Dafny (<a href="https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;dafny" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Microsoft&#x2F;dafny</a>) (probably the poster child for the verification approach) and Idris (<a href="https:&#x2F;&#x2F;www.idris-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.idris-lang.org&#x2F;</a>) (voted most likely to be generally usable of the dependently typed languages).

All this and handling overflow still doesn&#x27;t make the list. Had it been the case that easy considerations for overflow were baked into C back then, we probably wouldn&#x27;t be dealing with hardware where handling overflow is even more difficult than it would have been on the PDP-11. (On the PDP-11, overflow would have trapped.) At the very least, it would be the norm for compilers to emulate it whether there was efficient machine-level support or not. However, that didn&#x27;t happen, and because of that, even Rust finds it acceptable to punt on overflow for performance reasons.

&quot;<i>Writing this makes me think it deserves a footnote &#x2F; warning: if while reading these remarks, you feel that modules -- or anything else I&#x27;m going to mention here -- are a &quot;simple thing&quot; that&#x27;s easy to get right, with obvious right answers, I&#x27;m going to suggest you&#x27;re likely suffering some mixture of Stockholm syndrome induced by your current favourite language, Engineer syndrome, and&#x2F;or Dunning–Kruger effect. Literally thousands of extremely skilled people have spent their lives banging their heads against these problems, and every shipping system has Serious Issues they simply don&#x27;t deal with right.</i>&quot;<p>Amen!

So Graydon works at Apple on Swift?<p>Wasn&#x27;t he the original designer of Rust and employed at Mozilla?<p>Surprised that this move completely went under my radar

The blurring of types and values as part of the static checking very much speaks to me.<p>I&#x27;ve been using Typescript a lot recently with union types, guards, and other tools. It&#x27;s clear to me that the type system is very complex and powerful! But sometimes I would like to make assertions that are hard to express in the limited syntax of types. Haskell has similar issues when trying to do type-level programming.<p>Having ways to generate types dynamically and hook into typechecking to check properties more deeply would be super useful for a lot of web tools like ORMs.

I would love to see some advancements into distributed, statically typed languages that can be run on across cluster, and that would support type-safe, rolling deployments. One would have to ensure that state could be migrated safely, and that messaging can still happen between the nodes of different versions. Similar to thinking about this &#x27;temporal&#x27; dimension of code, it would be cool to see us push versioning and library upgrades further, perhaps supporting automatic migrations.

Interesting to see the mention of effect systems. However, I am disappointed that the Nim programming language wasn&#x27;t mentioned. Perhaps Eff and Koka have effect systems that are far more extensive, but as a language that doesn&#x27;t make effect systems its primary feature I think Nim stands out.<p>Here is some more info about Nim&#x27;s effect system: <a href="https:&#x2F;&#x2F;nim-lang.org&#x2F;docs&#x2F;manual.html#effect-system" rel="nofollow">https:&#x2F;&#x2F;nim-lang.org&#x2F;docs&#x2F;manual.html#effect-system</a>

Fantastic article. This is the kind of stuff I go to Hacker News to read. Had never even heard of half of these conceptual leaps.

I would have preferred a more informative HN title, instead of a semi-clickbaity &quot;What next?&quot;, e.g.<p>&quot;The next big step for compiled languages?&quot;

It&#x27;s interesting that he doesn&#x27;t want to draw too much attention to actors while they are prominent in Chris Lattner&#x27;s manifesto for Swift [1]<p>[1] <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;lattner&#x2F;31ed37682ef1576b16bca1432ea9f782" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;lattner&#x2F;31ed37682ef1576b16bca1432ea9...</a>

I know I am basically dangeling meat into lions den with this question; How has PHP7 done in regards to the Modules section or modularity he speaks of?<p>I am interested in genuine and objective replies of course.<p>(Yes your joke is probably very funny and I am sure it&#x27;s a novel and exciting quip about the state of affairs in 2006 when wordpress was the flagship product)

I think at some point we will get to projection editors being mainstream for programming, and eventually things that we normally consider user activities will be recognized as programming when they involve Turing complete configurability. This will be an offshoot of more projection editing.<p>I also think that eventually we may see a truly common semantic definitional layer that programming languages and operating systems can be built off of. It&#x27;s just like the types of metastructures used as the basis for many platforms today, but with the idea of creating a truly Uber platform.<p>Another futuristic idea I had would be a VR projectional programming system where components would be plugged and configured in 3d.<p>Another idea might be to find a way to take the flexibility of advanced neural networks and make it a core feature of a programming language.

What would be a good book &#x2F; website to learn the concepts &amp; nomenclature in order to understand the advanced language discussions in HN like this one?

it&#x27;s interesting that Rust isn&#x27;t mentioned once in his post. i wonder if he&#x27;s disheartened with the direction his baby went.

I&#x27;m surprised build time wasn&#x27;t on the list.<p>Curious and can&#x27;t find anything: what&#x27;s the most complex golang program out there, and how long does it take to compile?

LtU thread: <a href="http:&#x2F;&#x2F;lambda-the-ultimate.org&#x2F;node&#x2F;5466" rel="nofollow">http:&#x2F;&#x2F;lambda-the-ultimate.org&#x2F;node&#x2F;5466</a>

About units and dimensionality, AdaCore tried something in Ada with GNAT : <a href="http:&#x2F;&#x2F;www.adacore.com&#x2F;adaanswers&#x2F;gems&#x2F;gem-136-how-tall-is-a-kilogram&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.adacore.com&#x2F;adaanswers&#x2F;gems&#x2F;gem-136-how-tall-is-a...</a> and <a href="http:&#x2F;&#x2F;www.christ-usch-grein.homepage.t-online.de&#x2F;Ada&#x2F;Dimension&#x2F;Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf" rel="nofollow">http:&#x2F;&#x2F;www.christ-usch-grein.homepage.t-online.de&#x2F;Ada&#x2F;Dimens...</a>

Extra credit for whoever implements logic proofs on concurrent applications.

whats wrong with software transactional memory?

No type system improvements to support concurrency safety?

Can someone edit the title to something clearer? Thanks!