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.
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.
> 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."
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.
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.
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.
> 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)
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.
> 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.
People have problem with the question "Imagine you're trying to find the (maximum distance) of all the stars in the sky" because the maximum distance of all stars is ill defined and nonsensical. Maximum distance to what? To the center of universe? To the edge of the universe? To my house? Or the furthest distance between two stars of all the stars? Half of the solution is stating the correct question.
21 comments
[ 3.2 ms ] story [ 64.3 ms ] threadKill it with fire!!!
previous discussion (2 days ago): https://news.ycombinator.com/item?id=19671795
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.
"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/regular...
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.
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_...
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.
> 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)
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