Your Cart

Poets and Novelists

Imagine a natural language with some sort of upper limit on the number of its words that could be feasibly used in any given work. Perhaps the language was excellent for writing poems, essays and short-stories but became completely unworkable when it came to writing longer compositions like novels or sagas. Would such a language be worth learning?


Maybe learning such a language would be considered ideal for budding poets or for dedicated journalists without novelistic aspirations. More likely through, this limitation would be treated with suspicion and hesitancy since non-writers might still want to read a great novel periodically or at least keep alive the possibility of turning their hand to writing one down the track. A more serious concern however, would be realizing the dim prospects of such a language ever fomenting a fully-fledged, fizzing culture around its widespread adoption.


The great works of literature exert a disproportionately large influence on the language used in their creation. They have this happy knack of contributing new words, phrases and styles to the language, of inspiring generations of writers as well as help establish cultural myths and archetypes. Due to this effect, the mere possibility of creating long-form works emerges as fundamental to a language's credibility, richness and long-term evolution.


So too it is for a programming language for without the possibility of the language defining its sagas--expression in large-scale computational systems--the motivation for learning the language dims, perhaps even to the point of the language's eventual demise. Indeed, the imperative of seeing regular examples of computer-systems built predominantly with a given programming language, might be even more pivotal given the multi-author effort typically required. This suggests the following twin tenets for a programming language's cultural sustainability.


1. Any sustainable language fit for computational exploration must also be fit for computational construction.


2. The most highly sought-after coders posses dual expertise in both computational exploration and computational construction.


Both tenets represent unremarkable deductions in the context of a commercial organization deploying WL-based products but their wider relevance for all WL-usage is more bracing. What these tenets imply is that WL-usage as has been traditionally carried out throughout research, education or commerce no longer cuts the mustard. To put it in starker terms:


The most brilliant researchers revealing unknown computational phenomena ultimately muzzle their contributions without also fashioning these into package-based computational systems; the most talented educators inspiring with dazzling explanations ultimately cruel their students' employability without also imparting system-building skills while finally; the most valuable company-artisans ultimately short-change their enterprise without also translating insights into systems generating sustained commercial advantage.


What these provocations imply is a radical re-conceptualization in the way the WL is used. It means that it is no longer sufficient for educators, data-scientists or data analysts to possess 1. subject-matter expertise and 2. WL-exploratory expertise. Instead, what these provocations dare is that today's WL practitioners need a further string to their bow, namely, 3. Construction expertise as the means by which their computational discoveries can be sustainably injected into the wider world.


The opportunity here lies in extending WL's linguistic capability in computational exploration into the more uncharted terrain of computational construction. Inevitably, acquiring system-building skills involves inculcating new idioms and practices, but the barrier to acquiring these appreciably lowers if they can be attained via a natural extension of a familiar language. In a not dissimilar to the way "non-coders" originally became computational explorers because of the WL's innate literateness, the possibility now arises to "naturally" transform one's computational discoveries into sophisticated systems.


This positioning also upends the conventional wisdom of WL's developmental pathway: perform exploration and prototyping in Mathematica notebooks before re-implementing successful experimentation into faster, more industrial platforms that contain more mature and specialized system-building infrastructure. One cannot expect a single tool to perform the entire gamut of experimentation through to production; far better to instead connect up specialized, optimized tools--or at least this is how the conventional reasoning usually proceeds. The problem with such reasoning however, is that there are significant frictional costs associated with cobbling together disparate tools not only in terms of interoperability but perhaps even more importantly, such an approach carries with it, a certain pedagogical penalty.


It is the ubiquitous learning transfers that define the underestimated advantage of adopting a single, literate programming language for end-to-end computation. And perhaps the most compelling piece of evidence of the importance of this pedagogical effect is the rise of python over the last decade which is, in our view, a direct consequence of it being a programming language managing to combine both data analysis and system-building. The question being posed here is: can a similar transformation can occur with the WL? While a transition to building WL-based systems needs some key technologies and education pieces, also important is the general tenor of institutional support from the language's creators. Some recent signs are encouraging:


1. Wolfram Language re-badged as dedicated computing language


2. Free WL-engine for developers


3. Unit-testing framework refreshed


4. Documentation tools released


5. Introduction of a paclet repository


In comparison to other languages, the WL provides a superior and purer learning experience across most computational domains and yet, some educators are opting for python as the language of instruction due to its touted "versatility". Generally, a language's versatility encompasses a broad range of inherent qualities; its vocabulary, grammar, coherence, flexibility, succinctness--each no doubt extolled by respective adherents --but the versatility most relevant here, is sociological; put bluntly, more than any other language, learning python is more likely to land one a job.


It is essentially on this basis of job-readiness that a recent article explains the choice of python to teach a range of topics across applied mathematics. While one inevitable outcome may well be shallower conceptual understandings, the justification for such a compromise is that any subject-level deficiencies are, in the end, more than offset by the transferrable skills obtained from learning to code in such a popular language.


A curriculum's instructional design is therefore increasingly being optimized not only for learning outcomes specific to the given domain, but also for the transferrable programming skills that are simultaneously instilled. And, given python's modern penetration throughout industry, such reasoning carries a certain, compelling force. It also invites some uncomfortable questions for WL educators about the integration of the Wolfram Language into their own curricula.


Can one get a job programming in the Wolfram Language? Can one build a computational system in the Wolfram Language? The reflexive response might be "Yes" to both questions given the existence of Wolfram Research Inc where WL-programming jobs are advertised daily. But the immediacy of this answer obscures a more pertinent truth that needs to also take into account: WRI's 1K-strong workforce is a drop in the modern computational ocean; WRI remains the default destination for the cream of the world's WL developers; WRI possesses the maturity of a 35+ year old enterprise, and finally, WRI does not have to navigate pivotal licencing agreements nor negotiate access to inhouse, black-box implementations.


A more relevant question might therefore be: How many start-ups are choosing the WL as their core system-building language? Currently the answer would be a precious few, but this may be about to phenomenally change.


Combining WL's linguistic essence with some key technological additions transforms it into a bone-fide system-building language. The tantalizing prospect is that once WL's unique capabilities in exploration are parlayed into this longer-form development, an entirely novel versatility springs into existence, even beyond that which python can, or will ever offer. And as the sociological arc bends towards the meritorious, many many opportunities may be about to present.


Choosing a programming language is a complex balancing act and the conclusion here is that justifying a choice of the WL over other languages (Python/C/Java/R/Rust etx.) in any educational, research or commercial setting, ultimately reduces to WL's capabilities in computational construction.


One view maintains that WL's exploratory scientific niche is assured but fixed because of fundamental inability to approach, python's non-proprietary, system-building capability. An alternative view holds that the linguistic advantage of WL expression can bring more harmony to computational construction. The pretext of this course and these tools is a conviction about the latter as some stepping stones are put in place for the pioneers. Poets can become novelists.