7 ms·

The Bosque Programming Language

36 points by omaranto 7y ago

ccnafr 7y ago
"a combination of TypeScript inspired syntax and types plus ML and Node/JavaScript inspired semantics" Kill it with fire!!!
unforswearing 7y ago
microsoft project page: https://www.microsoft.com/en-us/research/project/bosque-programming-language/ https://www.microsoft.com/en-us/research/project/bosque-prog... previous discussion (2 days ago): https://news.ycombinator.com/item?id=19671795 https://news.ycombinator.com/item?id=19671795
anuragsoni 7y ago
Nice discussion on an earlier post about this project: https://news.ycombinator.com/item?id=19671795 https://news.ycombinator.com/item?id=19671795
- deleted 9mo ago
  [deleted]
mikece 7y ago
Is this coming out of MS Research as one of these "look, we came up with a way to do this" but it's not something that has a concrete use case? It reminds me of their MSR's project where they made a bootable operating system kernel in C# which, if I recall correctly, influenced the Midori project, elements of which have percolated into refactorings that have shipped with Windows 10. It also makes me think of F# which is a very useful language on its own but serves as more of a test-bed for future features for C#. I suppose if the learnings of Bosque find their way into TypeScript that might be useful but I don't see a practical use for Bosque as it is. Either that or I've completely missed the point.
- dman 7y ago
  Not all research is useful today/tomorrow.
- arx1422 7y ago
  C# along with lots of more recent programming paradigms have been moving in a more functional dimension for a while. I guess its not surprising the F# user base/culture is probably more excited to be beta-testers"new functional goodies" before things get ironed out enough for C#ers who (to broadly generalize) are more interested in getting something built than the theory of how it gets done.
- igouy 7y ago
  > Either that or I've completely missed the point. "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." https://www.microsoft.com/en-us/research/publication/regularized-programming-with-the-bosque-language/ https://www.microsoft.com/en-us/research/publication/regular...
pictur 7y ago
yetanother#
azhenley 7y ago
Are there plans to actually measure "simple, obvious, and easy to reason about" with people? As I mentioned in the discussion two days ago, PL researchers throw around these terms but never actually measure them. You can learn a lot from a small user study.
- msvan 7y ago
  I am very tired of the phrase "easy/hard to reason about." It sounds so hand-wavy every time.
  - azhenley 7y ago
    I would be fine with "easier to reason about" if they did a comparison study to some other language. For example, have participants do a few comprehension tasks with Bosque code snippets and also with C++ code snippets. Measure task completion time, task success, and self-reported cognitive load [1]. Then do a semi-structured interview to get some insights into the participants' opinions. [1] Cognitive Load Measurement as a Means to Advance Cognitive Load Theory https://www.tandfonline.com/doi/abs/10.1207/S15326985EP3801_8 https://www.tandfonline.com/doi/abs/10.1207/S15326985EP3801_...
  - bb88 7y ago
    A concrete example of "hard to reason about" is: High level languages exist to remove the complexity of opcodes of the bare metal running underneath. And that's because assembly code (unless you're well versed in it) is hard to reason about.
uryga 7y ago
this is interesting (emphasis mine): > Bosque is designed to encourage limited uses of recursion [and using map/filter etc instead]. This is done by introducing the rec keyword which is used at both declaration sites to indicate a function/method is recursive and again at the call site so as to affirm that the caller is aware of the recursive nature of the call i don't think i've seen a way marking functions that might not terminate at the call site. (though termination doesn't seem to be a specific focus here)
- coldtea 7y ago
  Isn't this similar to e.g. recur in Clojure?
  - uryga 7y ago
    you might be right, though i understood it as "every call to a recursive function must be prefixed with `rec`", which would mean that, say, ,`last xs` [assuming that `last` is implemented recursively and xs is a linked list] would have to look like `rec last xs` instead, de facto making the recursiveness of `last` a part of its public API.
geogra4 7y ago
I was hoping this was a programming language written in Basque
- aivisol 7y ago
  Or something to do with forestry
ben509 7y ago
> The categorization and coverage results of these semantic loop idioms shows that almost every loop a developer would want to write falls into a small number of idiomatic patterns which correspond to higher level concepts developers are using in the code, e.g., filter, find, group, map, etc. The fact that there are idioms that they could use doesn't mean those idioms are natural to the way people think, in particular, to the way they think when trying to solve problems. I avoided a fully functional style in my language[1] (even it has a functional kernel) because I've watched people write code while working with them or as interview candidates, and observed them (and myself, tbh) having trouble solving problems with "big" elements. Thinking about the whole array makes it "big" mentally. I'm not a psychologist or a linguist, so I can't tell you what that means, just that I've observed a pattern. When I was doing interviews, we had the infamous stars question, which goes like this: "Imagine you're trying to find the (maximum distance) of all the stars in the sky. How do you compute this?" Candidates reliably get hung up on "all the stars in the sky" and don't realize they can break the problem into the current maximum star plus all the rest of them. (That some people get it and some just don't is why I don't use the question.) With the humble for loop, you're naturally dealing with a single thing at a time. That's why I think it's unwise to throw it out and only use functional constructs. And that said, often we do want to address the whole structure. When you look at problem solving, it's about reexpressing a question in such a way that the answer falls from it naturally. To do that, we need a multitude of idioms that can expose different aspects of a problem and be composed reliably. > We believe that further work, such as identifying recursive idioms or other fundamental algorithmic patterns, can further reduce the need for unstructured recursion – eventually limiting it to an infrequently used part of the language. I do agree with this. If you're going to have find, map, filter, etc. then it makes sense to have a generalized tree-walking algorithm. That's how I'd probably like to express it. But, again, when I'm solving the problem initially, I need to be able to deal with small things to keep it all in my brain at once. That's how we teach it and often how we will want to express it to ourselves when we're in the fog of solving an unknown. I absolutely would love something that could describe boundaries, enforce invariants and make guarantees that a traversal won't hang, but I wouldn't want that to be the only way to express such traversals. Development is an evolutionary process; we often start with something that might suck but is viable, and then iterate and improve it. [1]: https://tenet-lang.org/basics.html#control-statements https://tenet-lang.org/basics.html#control-statements

36 points by omaranto 7y ago

"a combination of TypeScript inspired syntax and types plus ML and Node/JavaScript inspired semantics" Kill it with fire!!!

unforswearing 7y ago

microsoft project page: https://www.microsoft.com/en-us/research/project/bosque-programming-language/ https://www.microsoft.com/en-us/research/project/bosque-prog... previous discussion (2 days ago): https://news.ycombinator.com/item?id=19671795 https://news.ycombinator.com/item?id=19671795

anuragsoni 7y ago

Nice discussion on an earlier post about this project: https://news.ycombinator.com/item?id=19671795 https://news.ycombinator.com/item?id=19671795

deleted 9mo ago
[deleted]

mikece 7y ago

Is this coming out of MS Research as one of these "look, we came up with a way to do this" but it's not something that has a concrete use case? It reminds me of their MSR's project where they made a bootable operating system kernel in C# which, if I recall correctly, influenced the Midori project, elements of which have percolated into refactorings that have shipped with Windows 10. It also makes me think of F# which is a very useful language on its own but serves as more of a test-bed for future features for C#. I suppose if the learnings of Bosque find their way into TypeScript that might be useful but I don't see a practical use for Bosque as it is. Either that or I've completely missed the point.

dman 7y ago
Not all research is useful today/tomorrow.
arx1422 7y ago
C# along with lots of more recent programming paradigms have been moving in a more functional dimension for a while. I guess its not surprising the F# user base/culture is probably more excited to be beta-testers"new functional goodies" before things get ironed out enough for C#ers who (to broadly generalize) are more interested in getting something built than the theory of how it gets done.
igouy 7y ago
> Either that or I've completely missed the point. "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." https://www.microsoft.com/en-us/research/publication/regularized-programming-with-the-bosque-language/ https://www.microsoft.com/en-us/research/publication/regular...

pictur 7y ago

yetanother#

azhenley 7y ago

Are there plans to actually measure "simple, obvious, and easy to reason about" with people? As I mentioned in the discussion two days ago, PL researchers throw around these terms but never actually measure them. You can learn a lot from a small user study.

msvan 7y ago
I am very tired of the phrase "easy/hard to reason about." It sounds so hand-wavy every time.
- azhenley 7y ago
  I would be fine with "easier to reason about" if they did a comparison study to some other language. For example, have participants do a few comprehension tasks with Bosque code snippets and also with C++ code snippets. Measure task completion time, task success, and self-reported cognitive load [1]. Then do a semi-structured interview to get some insights into the participants' opinions. [1] Cognitive Load Measurement as a Means to Advance Cognitive Load Theory https://www.tandfonline.com/doi/abs/10.1207/S15326985EP3801_8 https://www.tandfonline.com/doi/abs/10.1207/S15326985EP3801_...
- bb88 7y ago
  A concrete example of "hard to reason about" is: High level languages exist to remove the complexity of opcodes of the bare metal running underneath. And that's because assembly code (unless you're well versed in it) is hard to reason about.

uryga 7y ago

this is interesting (emphasis mine): > Bosque is designed to encourage limited uses of recursion [and using map/filter etc instead]. This is done by introducing the rec keyword which is used at both declaration sites to indicate a function/method is recursive and again at the call site so as to affirm that the caller is aware of the recursive nature of the call i don't think i've seen a way marking functions that might not terminate at the call site. (though termination doesn't seem to be a specific focus here)

coldtea 7y ago
Isn't this similar to e.g. recur in Clojure?
- uryga 7y ago
  you might be right, though i understood it as "every call to a recursive function must be prefixed with `rec`", which would mean that, say, ,`last xs` [assuming that `last` is implemented recursively and xs is a linked list] would have to look like `rec last xs` instead, de facto making the recursiveness of `last` a part of its public API.

geogra4 7y ago

I was hoping this was a programming language written in Basque

aivisol 7y ago
Or something to do with forestry

ben509 7y ago

> The categorization and coverage results of these semantic loop idioms shows that almost every loop a developer would want to write falls into a small number of idiomatic patterns which correspond to higher level concepts developers are using in the code, e.g., filter, find, group, map, etc. The fact that there are idioms that they could use doesn't mean those idioms are natural to the way people think, in particular, to the way they think when trying to solve problems. I avoided a fully functional style in my language[1] (even it has a functional kernel) because I've watched people write code while working with them or as interview candidates, and observed them (and myself, tbh) having trouble solving problems with "big" elements. Thinking about the whole array makes it "big" mentally. I'm not a psychologist or a linguist, so I can't tell you what that means, just that I've observed a pattern. When I was doing interviews, we had the infamous stars question, which goes like this: "Imagine you're trying to find the (maximum distance) of all the stars in the sky. How do you compute this?" Candidates reliably get hung up on "all the stars in the sky" and don't realize they can break the problem into the current maximum star plus all the rest of them. (That some people get it and some just don't is why I don't use the question.) With the humble for loop, you're naturally dealing with a single thing at a time. That's why I think it's unwise to throw it out and only use functional constructs. And that said, often we do want to address the whole structure. When you look at problem solving, it's about reexpressing a question in such a way that the answer falls from it naturally. To do that, we need a multitude of idioms that can expose different aspects of a problem and be composed reliably. > We believe that further work, such as identifying recursive idioms or other fundamental algorithmic patterns, can further reduce the need for unstructured recursion – eventually limiting it to an infrequently used part of the language. I do agree with this. If you're going to have find, map, filter, etc. then it makes sense to have a generalized tree-walking algorithm. That's how I'd probably like to express it. But, again, when I'm solving the problem initially, I need to be able to deal with small things to keep it all in my brain at once. That's how we teach it and often how we will want to express it to ourselves when we're in the fog of solving an unknown. I absolutely would love something that could describe boundaries, enforce invariants and make guarantees that a traversal won't hang, but I wouldn't want that to be the only way to express such traversals. Development is an evolutionary process; we often start with something that might suck but is viable, and then iterate and improve it. [1]: https://tenet-lang.org/basics.html#control-statements https://tenet-lang.org/basics.html#control-statements