What is Bosque?
From Bosque GitHub repo:
The Bosque programming language is a Microsoft Research project that is investigating language designs for writing code that is simple, obvious, and easy to reason about for both humans and machines
Lemme add a couple of points
- Bosque is typed and functional.
- Heavily affected by JavaScript, TypeScript, and ML.
- More of a research product than a profitable product.
- An open source project licensed under MIT (very non-Microsoft'ish 😁).
When was it invented?
The GitHub repo was created on 3rd of Mar, 2019, and published on Microsoft.com on 15th of April, 2019.
What's the implementation of the language?
Currently, the language is implemented on TypeScript which runs on Node.js.
So, what does it bring new into the table?
Maybe a new era of programming
The author of Bosque, Mark Marron, introduces a new programming model called Regularized Programming.
In his research paper, he mentions how structured programming (that we knew since 1970) might cause "accidental complexity"!
We believe that, just as structured programming did years ago, this regularized programming model will lead to massively improved developer productivity, increased software quality, and enable a second golden age of developments in compilers and developer tooling.
How Regularized Programming Differs from Structured Programming
You can simply say that: "Regularized Programming = Structured Programming v2.0".
That's how Marron tells us in his white paper, that regularized programming is built on structured programming... but, it aims to eliminate sources of complexity.
In other words, fewer bugs in your code!
The sources of complexity he mentions are:
- Loops, Recursion, and Invariants: I assume you already know those 😆
- Mutable State and Frames: mutable vs immutable objects are always confusing.
- Indeterminate Behaviors, like: uninitialized variables.
- Data Invariant Violations: accessing/modifying data using index in arrays and such.
- Equality and Aliasing: by value, by reference variable passing.
Code sample
Instead of doing the usual iterative loop in C, e.g:
Multiply all array elements by 2.
int a[5] = {1, 2, 3, 4, 5};
int b[5];
for(int i=0; i<5; i++)
b[i] = a[i]*2;
Bosque avoids the whole idea about looping and accessing array directly from the memory by doing:
var a = List[Int]@{1, 2, 3, 4, 5};
var b = a.map[Int](fn(x) => x*2);
It's all academic for now
Now, don't jump to use this in your company or workplace 😆
Cuz, the whole thing is academic and meant for R&D for the next programming languages generation.
Quoting from the project repo:
we do not recommend the use of the Bosque language for any production work and instead encourage experimentation only with small/experimental side projects at this point in time.
Fun fact
People are already questioning the async model for this programming language 😂
Bonus fun fact
OP: There will likely be job offers in the next few weeks asking for a couple years of experience with this new programming language.
Re: And there will be people applying with 5 years experience already too :P
What do you think
Do we really need a new programming language with a whole new paradigm?
Would it be really useful to have Bosque?
Top comments (23)
It's not a new paradigm. It's strongly-typed purely functional programming. It's been around for a while. In fact I don't really see any value as a research / academic language here. I've gone through the list of features and it seems everything has already been done, even better, by some existing languages. Just not C, JS, or Python, but that's not the competition in R&D. There it's Haskell, Clean, ATS, Idris, Mercury...
It just looks like a shitty grab for power. A tactic Microsoft is well-known for.link
The regularized programming paradigm is not meant to bring new features, as it says clearly "it eliminates sources of complexity"... so basically, it's a paradigm that takes out what the author thinks as "complex".
Look at it like this, we had the procedural programming paradigm, in which we are using pointers in C.
Just by switch those local variables from stack into the heap... whoops, we have objects.
And, we do point to the object father... whoops, we have inheritance.
Lastly, we override the function pointer with another function pointer... we have polymorphism!
Voila, we derived OOP paradigm!
Sounds similar to the regularized programming paradigm, right?
That being said, you can start using regularized programming on languages that supports functional programming, like Python or JS.
The sources of complexity are not in the programming languages, they come from the nature of problem domains.
That's why domain specific languages shine, they offer few sentences but those are the one needed in the context of that problem domain.
That's also the reason why some languages are better than other for specific tasks and worst for others. For example: perl is very good for text matching and processing, but it might not be so good to build the abstractions needed for a given domain.
Even ASM language is preferred for coding some operations that are near to low level control of external devices (programming drivers for external hardware, controlling microchips) or bit-wise memory operations. And that's because it was designed to that problem domain.
Every programming paradigm has its own set of languages that fit better for the task.
Nevertheless it is true that in the history of programming a lot of unnecessary constructs have been built because the needed programming theory was not available or was not considered. Some examples are the goto sentences, and some people says that abstract clases (some computer scientists argue that abstract clases are not needed if the language has a good support of types, interfaces). Other experts are against of sentences that break the loop, because they say no sentence should contradict a previous one.
If the goal is to find the canonical set of sentences that allows to drive the complexity needed by a general purpose language then I am agree, it is an interesting work.
Nevertheless, if the goal if to go back to old programming paradigms just because the new ones are lacking some features then I am not so happy.
I have programmed the last 30 years, using a lot of this paradigms. There procedural programming paradigm lacked the capacity to easy handle a lot of complexity of the problem domain. I was already programming with structs when the object oriented paradigm came. A lot of people tough at first glance that objects where structs + methods. It took a time to see the additional benefits that OOP has for re-usability and driving the complexity of the problem domain. And that was only possible by mean of reading of the theory.
Per see, javascript is not a danger to the industry. The danger is that newcomers start to learn by javascript, and the past of the programming theory is forgotten.
There is a quotation that says "Those who cannot learn from history are doomed to repeat it".
I would say: If somebody wants to go back to procedural programming paradigm because his tech stack uses it, perfect. But he should be aware that is not the better way to handle the complexity of some problem domains. The complexity would crystallize in form of additional code and new concepts and abstractions. It would eventually precipitate over the solutions whose nature is from that problem domain.
I totally agree with you.
Domain has been always the main the source of complexity, and a new paradigm won't be able to swipe off complexity just because it's more bullet-proof.
Coming from the reverse code engineering field, I would say that the keyword
gotohas still its use-cases, such as creating code obfuscator / protector (by using JMP in ASM).But, as you said there are just "off" parts of some paradigms like the keyword
gotothat causes more harm than good in most scenarios.I just hope that in the future we won't see developers promoting this paradigm for all kind of scenarios as we saw with TDD and micro-services!
You know what I love about JS and Python?
They give us all the power (allow all different kind of syntax/paradigm in a simple way), then they tell us: "do what you want... however you want" :D
A reduction of complexity is still a feature. It doesn't do anything new in that department either; it just copied purely functional programming and put a new label on it.
One might say "that was the old microsoft".
Seeing all the investments they are making into oss, they might be onto something
A skeptic would say this is part of they "embrace, extend, extinguish" strategy. The link I posted details how their current OSS investments contribute to just that.
Thanks for sharing the video, everything makes more sense
Thanks Yaser for the explanation. It wasn't as clear just by reading the README.
I guess we'll see in the future. Languages usually stick around because they are solving at least one issue programmers are having, in combination with some marketing and the right early adopters.
Could this be also a playground for new TypeScript features?
(lol for the person asking after 5 minutes the project has been released if they can use async/await :P)
Regarding the topic of solving "accidental complexity" I'm waiting for the release of Dark (though I never understand why programmers would use generic words to name their language :D). The aim of Dark is bigger I guess, they aim to decrease all complexity, not just in the language but in the tooling as well. I believe it's built in OCaml.
You can read a DEV post on it as well:
Dark (lang) - removing accidental complexity of programming
Niels Bom
Let me know your thoughts about both things!
You know what I love about your comments, rhymes... I always learn something new from them!
This is the first time I hear about Dark, I've gone through their website and so... all are marketing information, nothing really technical.
What interested me, is the team behind it... one is the founder of CircleCI and another was a product manager at KickStarter. Surely, they will get tons of funding!
Can't wait to see the actual product in the future...
This says it all 😆
To be honest, I don't see any potential feature... I just see a whole different perspective of programming (that says it's less error-prone), and many programmers are gonna promote that (if proven successful).
A new language always sounds exciting. The example looks like a regular
mapover a list, though. Is there something else in the example?Please check this comment: dev.to/0xrumple/comment/a970
It may sound interesting to explore q new language and if it does improve upon shortcomings of popular concepts then why not. But as you pointed out it is strictly for exploring better programming concepts and research.
To be honest I already have my hands full learning popular languages and their frameworks which are good for a particular niche of work and not so good for other, i wouldn't mind ignoring it all together.
Lastly what are your thoughts on Julia the general purpose language also good enough for computation, tasked with starting a new era of programming by bringing all the goodies from previous languages.
Yeah, a new approach every since in a while in programming has been always the norm. This industry, software, always love new stuff!
I've gone through Julia docs, and I think it's really great; not sure though if what they are promoting: "Julia is fast" is just an implementation detail (to how they implement it in each platform).
It really has an appealing syntax, especially for the parallel computing part:
docs.julialang.org/en/v1/base/para...
I hope it won't be like R (focused just on data science stuff).
Hmm, is there another example. The mapping is something you can do now in JS, Python, C++, Haskell, etc.
I'm not sure that we will see a new feature (though the author says there are unusual features), as I mentioned in the previous comments... it's all for the regularized programming paradigm (which the author says it's less error-prone).
More on this in this comment: dev.to/0xrumple/comment/a970
Does seem intresting but doesn't tell me how its better than any other language.
IMHO, the programming language itself does not provide any super duper features, it's just a more of proof of concept (PoC) for the regularized programming paradigm.
More on this in this comment: dev.to/0xrumple/comment/a970
Hi Yaser. Thanks for this article!. I think we need more programming language. Totally agree with you with the term you used "very non-Microsoft'ish" xD
Not exactly the first one though
github.com/Microsoft/vscode
You're welcome :)
it has not very intresting features for migration. in my opinion it is a library on node.js . not a programming language
Use the browser dev tools to get rid of them 😁