Live data from Hacker News

The Bosque Programming Language

microsoft.com

161–170 of 172 posts

Re: The Bosque Programming Language

#161
post #151

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…

> 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...

Re: The Bosque Programming Language

#163
post #155

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 mig…

Isn't this similar to e.g. recur in Clojure?

Re: The Bosque Programming Language

#164
post #156

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 am very tired of the phrase "easy/hard to reason about." It sounds so hand-wavy every time.

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.

Re: The Bosque Programming Language

#165
post #160

> 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 particula…

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.

Re: The Bosque Programming Language

#166

Earlier quoted context omitted.

Oh okay. I thought it might have something to do with Basque: "Basque is a language spoken in the Basque Country, a region that straddles the westernmost Pyrenees in adjacent parts of northern Spain and southwestern France. Linguistically, Basque is unrelated to the other languages of Europe and is a language isolate to any other known living language." I didn't know about the forest meaning at all. (Maybe a subconsc…

I'll spell it out (for the downvoter): "is a language isolate to any other known living language" as well as being "a language". It has a very special status between France and Spain. I think anyone who knows about Basque would think of Basque when reading about a computer language named Bosque.

Not if you speak Spanish. "Un bosque," a forest, isn't related to Euskera, as the Basque language in known in Spanish. That part of Spain is called Euskadi or País Vasco, neither of which looks like bosque in Spanish nor Basque in English.

Re: The Bosque Programming Language

#167

Some comments on the code, based on Tictactoe example ( https://github.com/Microsoft/BosqueLanguage/blob/master/docs... ): 1. overall quite nice looking and easy to understand 2. too verbose in places, e.g. this constant structure: const winPositionOptions: List[List[[Int, Int]]] = List[List[[Int, Int]]]@{ List[[Int, Int]]@{ @[ 0, 0 ], @[ 0, 1 ], @[ 0, 2 ] }, List[[Int, Int]]@{ @[ 0, 1 ], @[ 1, 1 ], @[ 2, 1 ] }, List…

Got to say, after reading the description in the linked URL, I was really surprised with just how complex the syntax is in the code samples. I don't want to be overly negative, but it doesn't look like it's going to reduce complexity to me - if anything it looks like one of the most incomprehensible languages I've come across in decades of experience.

I agree! Human-readability may have been a goal, but it wasn't a top priority.

Re: The Bosque Programming Language

#168
post #27

A random thought about the code samples. What do we gain from having to write point instead of other languages' point.y = value ? I believe that syntax should be designed to make things simple for developers, not for the designers of languages or for compilers.

"Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on u…

Lisp, the second oldest language after Fortran, didn't make this mistake. In Lisp, "=" isn't an operator at all. Assignment is (setf x y) and comparison is (eq x y) [and several variants of eq].

Re: The Bosque Programming Language

#169
post #155

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 mig…

Isn't this similar to e.g. recur in Clojure?

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.

Re: The Bosque Programming Language

#170

Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…

I was keen to read about this lang bc it came from m$, but this looks like it needs some work: I'd highly suggest changing "var" and "var!" definitions.

From your doc:

>var z = 5;

z = y; //error z is not updatable

"var" is shorthand for 'variable' as you're no doubt aware, so use "const", or use something else altogether to indicate a var.

I stopped reading after coming across your unintuitive "var!" syntax. Let an apple be an apple and an orange an orange.

Post reply on HN