Microsoft has recently introduced the Bosque programming language, an investigative language design research project "for writing code that is simple, obvious, and easy-to-reason-about for both humans and machines." According to Microsoft, "the goal is improved developer productivity, increased software quality, and enabling a range of new compiler and tooling experiences." The language derives from a combination of TypeScript inspired syntax and types, plus ML and Node/JavaScript inspired semantics. It is the latest addition to the list of programming languages developed by Microsoft, which includes popular languages like TypeScript, C#, and F#.
Bosque is an illustration of a programming paradigm called "regularized programming", which is introduced by Mark Marron, principal research software development engineer at Microsoft. Regularized programming is an effort to build on the success of the structured programming model which rose to prominence in the 1970s. The structured programming model aims at improving the clarity and quality of computer programs, while also reducing the development time through the use of selection, repetition, block constructs, and subroutines.
In his paper introducing regularized programming, Marron states that the rise of structured programming and abstract data types "represented a move away from a programming model that reflected incidental features of the underlying hardware architecture and toward a model that emphasized programmer intent more directly. This shift simultaneously made it easier and less error-prone for a developer to convert their mental model of a system into code, and led to a golden age of compiler and IDE tooling development." According to him, "these programming methodologies simplified the reasoning of a program by eliminating substantial sources of accidental complexity." In his paper, he lists a few additional sources of complexity not dealt with by the structured programming model and describes how regularized programming, demonstrated via Bosque, seeks to eliminate these with the goal of advances in software quality, programmer productivity, and compilers/tooling.
The paper lists five major sources of complexity, based on developer interviews, personal experience with analysis/runtime/compiler development, and empirical studies. These sources are mutable state and frames, loops, recursion, and invariants, indeterminate behaviour (sort stability, map/dictionary enumeration order, etc.), data invariant violations, and equality and aliasing. According to Marron, these are the causes behind various bug families, they increase the effort required to implement functionality in a program, and greatly complicate automatic reasoning about a program. Bosque handles these problems via multiple language features such as the use of immutable data, eliminating loops and restricting recursion, fully determinizing the language semantics, introducing algebraic bulk data operators, etc.
The language has caught the attention of the community, with people discussing the language features, syntax, and its purpose on forums like Reddit, HackerNews, and Twitter. A user arrow7000 questioned Marron on HackerNews about the purpose of the language and how it was intended to be better in comparison with existing languages. According to Marron, Bosque is planned to be used as a proof of concept to explore language design choices, with the aspirational goals of enabling automated developer tools like compilers and verifiers.
Bosque's GitHub page mentions that the project is in an early state and invites academic collaboration and community participation. It states that the functionality is limited, acknowledges the presence of bugs, and hence the recommendation is to use it for experimentation in side projects and not for any production work. Also, since the main focus of the project is core language design. there is limited support for compilation/development and no support for packaging, deployment, lifecycle management, etc.
For more information, you can check out Bosque's GitHub page.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/php8-arrays-variables-operators/en/smallimage/logo-1676024749475.jpg){kind=logo}
/articles/concurrency-design-hilbert-problem-golang/en/smallimage/logo-1675270232021.jpg){kind=logo}
/articles/article-series-php-8-x/en/smallimage/article-series-php-8-x-small-1674555818786.jpg)
/articles/php-8-type-system-improvements/en/smallimage/PHP-8-type-system-extensions-small-1673963813329.jpg)
/articles/php8-functions-methods/en/smallimage/logo-1671609279794.jpg){kind=logo}
/articles/php8-classes-enums/en/smallimage/LOGO-1669397860437.jpg){kind=logo}
/articles/php8-attributes-match-new-operator/en/smallimage/logo-1665745535891.jpg){kind=logo}
/articles/secure-software-development-gitops/en/smallimage/accelerating-secure-software-delivery-lifecycle-with-GitOps-small-1679658720410.jpg)
/presentations/refactoring-rust/en/smallimage/qcon-plus-s-1679694299933.jpeg)
/presentations/aws-apache-airflow/en/smallimage/qcon-plus-s-1679694143127.jpeg)
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
Community comments
So far more pluses and only few minuses for Bosque!
by Bas Groot,
So far more pluses and only few minuses for Bosque!
by Bas Groot,
Your message is awaiting moderation. Thank you for participating in the discussion.
(In the past I wrote a set of frameworks and programming languages that was meant to never crash, I had to solve many of these problems too.)
I applaud the idea of asking developers what hits them over the head, before designing a new language at all. This language touches pretty much all hang and crash causes and prevents a lot of hand-coding that's only there to prevent mundane errors.
Extra points for doing away with nasty, subtly ambiguous (apple === orange) compares; I know this pain too well. Also extra points for doing away with all this unnecessary constructor inheritance bloat code, as in most cases you just want everything zero anyway. Also extra points for atomic multi-value assignments, it prevents a lot of mutexing.
Typed (parseable?) strings are promising but the examples (zipcodes, regex) are weak: zip codes are different in each country and many languages have their proprietary regex extensions and modifiers. I think you end up needing subtypes, modifiers or forcing everyone into a common denominator, but all that makes the added ease melt away like snow in summer. Not sure about that one.
Minus points for all these new |??+>:@...[]@_<~=?+ tokens, I understand why, but in practice it makes code very confusing and hard to read. Having made this mistake myself, I'd prefer human readable keyword operators where possible.
I'm not sure what exactly will happen if I get an error or assert. I'd hope for local scopes to catch errors that would otherwise crash my entire program, but not with the bloating and murky side effects of try {} catch {}.
The idea of replaying an error in debug mode I have my doubts: it is cute, but it's not clear from what point on it will (or even can) replay. Many things (clock time, race conditions, random, async wait, user input) make a reliable rerun impossible, even in a 100% deterministic language. Maybe they mean reverse-engineering the error information from analyzing the stack trace as if it was in debug mode.
And I'm curious how they will do threads. The language primitives, such as native iterators instead of loops, suggest heavy parallel execution could become possible, which would be nice since hardware is becoming more parallel but not much faster. The design does not state it yet, but suggests it will run on a .Net or Java like runtime with green threads (multi-value-assign being atomic), and hopefully this gets a more value added and more usable way of dealing with threads than Go.