6 ms·

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 v

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. At this point the goal is to explore interesting options in the language design space – whether the Bosque language becomes mainstream or just provides useful ideas for other languages to adopt. So, please take a look, expect plenty of rough edges, and we would love comments, suggestions, and PR’s on the GitHub repo.

cmroanirgo 7y ago
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.
logicallee 7y ago
Could you comment on how you came up with the name, or its meaning?
- mrkmarron 7y ago
  It is a Spanish word used in the SouthWest US for forest along a river. No particular reason behind the name, just a unique and easily searchable choice.
  - logicallee 7y ago
    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 subconscious influence, if you've ever heard any reference to Basque.)
    - logicallee 7y ago
      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.
      - Udik 7y ago
        Not really: Bosque, Bosco, Bois, Bos, all mean "wood", "forest" in, respectively, Spanish and Portuguese, Italian, French, Dutch. So it's a pretty familiar word to most Europeans.
        logicallee 7y ago
        OK, thanks.
      - mimixco 7y ago
        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.
- dordoka 7y ago
  Bosque is spanish for "forest" (not necesarily along a river).
reikonomusha 7y ago
Hello! Disclaimer: I haven’t read the full publication yet and I’ve only skimmed it. A lot of programming languages that are coming out these days talk about simplicity, lowering “cognitive load”, increasing expressiveness, being nimble/lightweight/easy/whatever, and—this one stated by you—reducing “accidental complexity”. When I looked at your grammar and some examples, I saw atomic building blocks that don’t lead to any less complexity than what I’d get if I strung together similar building blocks in Lisp or Python or ML. To me, “accidental complexity” doesn’t seem like a very well defined concept. I might say such a term in a meeting room arguing to upper management that we need to pay off tech debt. Or I might blog using such a term to talk vaguely philosophically about software engineering. But I don’t think I’d find myself using it in a formal context to argue the merits (or lack thereof) of a technology. I admit that this may be due to my ignorance of a term of art. The introduction to your publication is even more bold: “Regularized programming” (and hence Bosque) will (supposedly) unleash a revolution on programming the same way structured programming did the paradigms before it, ushering a “golden age” of programming and the like. Focusing on the term “accidental complexity”, can you elaborate what that means? What is an example of accidental complexity and how does it naturally come about with the current crop of languages. And how—in the large—does this programming language avoid it (or help the programmer avoid it)? Edit: I see in your publication, upon the mention of “accidental”, you cite “Frederick P. Brooks, Jr. 1987. No Silver Bullet Essence and Accidents of Software Engineering. Computer 20 (1987), 10–19.” But in reading this [0], Brooks says: > The complexity of software is an essential property, not an accidental one. He only speaks of certain difficulties as being “accidental”, and past ways in which we’ve improved the impedance of such difficulties. [0] http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/NoSilverBullet.html http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/NoSilverBu...
- mrkmarron 7y ago
  I would say accidental complexity comes from mostly historical reasons. Two sources discussed in the report are reference equality and looping. These make a ton of sense if you are implementing a language with a compiler that targets an x86 processor. They map naturally to the features of the hardware but make other tasks impractical, e.g. compilation to a FPGA or verifying a SemVer dependency update doesn’t break your application. Section 5 of the paper explores some scenarios that, once this “accidental complexity” has been removed, become much more feasible. These types of experiences are currently aspirational, and much work remains, but the hope is to demonstrate the practicality and value of these concepts.
arrow7000 7y ago
Hi Mark! What's this language's purpose and how will it be better at that than existing languages?
- mrkmarron 7y ago
  The current purpose is explore language design choices and their impact on their general utility for programmers and enabling automated developer tools (like verifiers and compilers). The hope is to use Bosque as a proof of concept for various ideas. Some examples of better than existing languages are included as case studies in section 5 of the technical report: -Automatically finding (ideally) any runtime error and producing a test case for it. -Verifying that a SemVer update is safe or flagging where it will change the behavior of your code. -Supporting compilation to high speed SIMD code or other accelerator architectures. This is all still an aspirational goal and a lot of work remains though.
  - thomasfortes 7y ago
    > -Verifying that a SemVer update is safe or flagging where it will change the behavior of your code. Isn't that similar to what Elm does?
    - mrkmarron 7y ago
      My understanding it Elm checks for signature changes such as adding a parameter to a function. We would like to do more and actually compare the actual behavior of the code before/after the change as well.
    - schwartzworld 7y ago
      Sounds like it, but Elm is only for front-end web dev.
jjtheblunt 7y ago
There's an English error on the very first sentence of the description on the Microsoft site.
- Stratoscope 7y ago
  > There's an English error on the very first sentence of the description on the Microsoft site. [emphasis added] The correct usage would be to talk about an error "in" a sentence, not "on" a sentence. Muphry's law get you every time! https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law
  - aramishn 7y ago
    > Muphry Sems like it got you too! (Yes that was intentional
    - eitland 7y ago
      In this case the misspelling is actually the correct one. HN has shortened the link in GPs post but if you follow it you'll see it spelled "Muphry's law", and it is a separate one from the general one that everyone knows about. That said it wouldn't surprise me at all if I've misspelled something here : )
  - jasonincanada 7y ago
    Surely you didn't mean too but the correct tense of "get" on you're sentence would be "gets"
    - Stratoscope 7y ago
      That was to make sure I didnt violate Muphry's law!
    - svrtknst 7y ago
      > on you're sentence would be "gets" this just gets better and better
fjfaase 7y ago
I hope you do not mind, if I make some comments. The first is that you should try to include realistic examples in your documentation and promote good coding styles. For example, I do not see the benefit of a 'sign' function with an optional argument. Or have a 'sign' function that uses a local variable, while this could also be done with an if-statement or the ?-operator. I do not understand the concept op typed strings. Would that not be simple a subtype of strings (implementing additional restrictions on the values of the strings, a true substype)? Also, when I see something like: 'args.all(fn(x) => x % 2 == 1)' I do experience it as 'simple, obvious, and easy to reason about for both humans and machines' because it only makes sense if you already have a lot of knowledge about languages like TypeScript. I think that something like: 'All x in args: x % 2 == 1' is easier to read. BTW, why does 'fn(x)' not have a type? Are types optional in your langauge? I would not give examples of mechanisms that have not been implemented and seem to go against your principle ideas, such as references. What happens, I pass a part of a value to a 'ref' argument of a function? There are some other language out there that are only based on immutable values. If you are fond of immutable values, why not implement them in an existing language and see how far you get. This has the benefit that people do not have to learn a new language and keeps you from reimplementing a lot of stuff that others already have implemented.
- coldtea 7y ago
  >I do not see the benefit of a 'sign' function with an optional argument Perhaps you don't see the benefit of an identity function either ("why not just use the variable")? Encapsulating things in a function instead of a statement is key to certain patterns (and functional style).
  - hibbelig 7y ago
    I agree with GP. The 'sign' function with a mandatory argument I understand. Making the argument optional I don't understand.
    - CREwert 7y ago
      I think its less about a sign function than about showing how optional (i.e. nullable) values work. Most languages have them, and making that possibility explicit is recent best practice.
fxfan 7y ago
Hello, no offense but the community here is bikeshedding. I'd suggest you to discuss this at /r/programming
- ahaferburg 7y ago
  They're bikeshedding there as well. Just filter out any post that contains the word syntax.
  - fxfan 7y ago
    Technical discussion is usually still leagues better on reddit than here
- coldtea 7y ago
  Sounds offensive to me. First of all, the community here discusses the post, and whatever they like about the language and announcement -- and whatever they think of tied (loosely or not, to that). We're not here as some committee with some explicit purpose to give relevant PL criticism.
  - fxfan 7y ago
    I don't mind you being offended, I was talking to the creator.
ahaferburg 7y ago
You seem to have some goals in common with Floyd. Maybe you want to get in touch. https://github.com/marcusz/floyd https://github.com/marcusz/floyd https://www.reddit.com/r/ProgrammingLanguages/comments/arwjlo/floyd_language_wants_to_become_faster_than_c/ https://www.reddit.com/r/ProgrammingLanguages/comments/arwjl...
trombonechamp 7y ago
Thanks for your work, this looks exciting! I am curious about the following: > Since the semantics and design of the language ensure fully determinized execution of any code there is actually no real need to perform logging within a block of code. So, logging is not available in the compute language. While this may be true for execution, this is not true of data on which the program operates. For example, when processing large amounts of data, how should one keep track of statistics, performance information, data irregularities (which don't cause errors but may be useful to look into further), and other such events which might otherwise be logged? Similarly, suppose the program performs some operation which depends on the system time which fails at runtime for certain system times. If run in deployed mode, it would restart and run the same thing in debug mode, but the environment would be different. How would such an operation be able to be traced back to the particular conditions which caused the error?
- mrkmarron 7y ago
  Great question. We take a very maximalist stance here and do not provide any environmental API’s in the Bosque language. Instead all IO, data-time, IP address operations must be part of a host platform – similar to how JavaScript does not provide IO or an event loop in the spec but relies on the browser or Node.js to provide it. With this model the host can just log/record the environment interactions. The details of this host and integration are an open issue, both research and engineering, but I am very excited by the AMBROSIA architecture (https://github.com/Microsoft/AMBROSIA https://github.com/Microsoft/AMBROSIA) by one of my colleagues as a possible design.

cmroanirgo 7y ago

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.

logicallee 7y ago

Could you comment on how you came up with the name, or its meaning?

mrkmarron 7y ago
It is a Spanish word used in the SouthWest US for forest along a river. No particular reason behind the name, just a unique and easily searchable choice.
- logicallee 7y ago
  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 subconscious influence, if you've ever heard any reference to Basque.)
  - logicallee 7y ago
    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.
    - Udik 7y ago
      Not really: Bosque, Bosco, Bois, Bos, all mean "wood", "forest" in, respectively, Spanish and Portuguese, Italian, French, Dutch. So it's a pretty familiar word to most Europeans.
      - logicallee 7y ago
        OK, thanks.
    - mimixco 7y ago
      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.
dordoka 7y ago
Bosque is spanish for "forest" (not necesarily along a river).

reikonomusha 7y ago

Hello! Disclaimer: I haven’t read the full publication yet and I’ve only skimmed it. A lot of programming languages that are coming out these days talk about simplicity, lowering “cognitive load”, increasing expressiveness, being nimble/lightweight/easy/whatever, and—this one stated by you—reducing “accidental complexity”. When I looked at your grammar and some examples, I saw atomic building blocks that don’t lead to any less complexity than what I’d get if I strung together similar building blocks in Lisp or Python or ML. To me, “accidental complexity” doesn’t seem like a very well defined concept. I might say such a term in a meeting room arguing to upper management that we need to pay off tech debt. Or I might blog using such a term to talk vaguely philosophically about software engineering. But I don’t think I’d find myself using it in a formal context to argue the merits (or lack thereof) of a technology. I admit that this may be due to my ignorance of a term of art. The introduction to your publication is even more bold: “Regularized programming” (and hence Bosque) will (supposedly) unleash a revolution on programming the same way structured programming did the paradigms before it, ushering a “golden age” of programming and the like. Focusing on the term “accidental complexity”, can you elaborate what that means? What is an example of accidental complexity and how does it naturally come about with the current crop of languages. And how—in the large—does this programming language avoid it (or help the programmer avoid it)? Edit: I see in your publication, upon the mention of “accidental”, you cite “Frederick P. Brooks, Jr. 1987. No Silver Bullet Essence and Accidents of Software Engineering. Computer 20 (1987), 10–19.” But in reading this [0], Brooks says: > The complexity of software is an essential property, not an accidental one. He only speaks of certain difficulties as being “accidental”, and past ways in which we’ve improved the impedance of such difficulties. [0] http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/NoSilverBullet.html http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/NoSilverBu...

mrkmarron 7y ago
I would say accidental complexity comes from mostly historical reasons. Two sources discussed in the report are reference equality and looping. These make a ton of sense if you are implementing a language with a compiler that targets an x86 processor. They map naturally to the features of the hardware but make other tasks impractical, e.g. compilation to a FPGA or verifying a SemVer dependency update doesn’t break your application. Section 5 of the paper explores some scenarios that, once this “accidental complexity” has been removed, become much more feasible. These types of experiences are currently aspirational, and much work remains, but the hope is to demonstrate the practicality and value of these concepts.

arrow7000 7y ago

Hi Mark! What's this language's purpose and how will it be better at that than existing languages?

mrkmarron 7y ago
The current purpose is explore language design choices and their impact on their general utility for programmers and enabling automated developer tools (like verifiers and compilers). The hope is to use Bosque as a proof of concept for various ideas. Some examples of better than existing languages are included as case studies in section 5 of the technical report: -Automatically finding (ideally) any runtime error and producing a test case for it. -Verifying that a SemVer update is safe or flagging where it will change the behavior of your code. -Supporting compilation to high speed SIMD code or other accelerator architectures. This is all still an aspirational goal and a lot of work remains though.
- thomasfortes 7y ago
  > -Verifying that a SemVer update is safe or flagging where it will change the behavior of your code. Isn't that similar to what Elm does?
  - mrkmarron 7y ago
    My understanding it Elm checks for signature changes such as adding a parameter to a function. We would like to do more and actually compare the actual behavior of the code before/after the change as well.
  - schwartzworld 7y ago
    Sounds like it, but Elm is only for front-end web dev.

jjtheblunt 7y ago

There's an English error on the very first sentence of the description on the Microsoft site.

Stratoscope 7y ago
> There's an English error on the very first sentence of the description on the Microsoft site. [emphasis added] The correct usage would be to talk about an error "in" a sentence, not "on" a sentence. Muphry's law get you every time! https://en.wikipedia.org/wiki/Muphry%27s_law https://en.wikipedia.org/wiki/Muphry%27s_law
- aramishn 7y ago
  > Muphry Sems like it got you too! (Yes that was intentional
  - eitland 7y ago
    In this case the misspelling is actually the correct one. HN has shortened the link in GPs post but if you follow it you'll see it spelled "Muphry's law", and it is a separate one from the general one that everyone knows about. That said it wouldn't surprise me at all if I've misspelled something here : )
- jasonincanada 7y ago
  Surely you didn't mean too but the correct tense of "get" on you're sentence would be "gets"
  - Stratoscope 7y ago
    That was to make sure I didnt violate Muphry's law!
  - svrtknst 7y ago
    > on you're sentence would be "gets" this just gets better and better

fjfaase 7y ago

I hope you do not mind, if I make some comments. The first is that you should try to include realistic examples in your documentation and promote good coding styles. For example, I do not see the benefit of a 'sign' function with an optional argument. Or have a 'sign' function that uses a local variable, while this could also be done with an if-statement or the ?-operator. I do not understand the concept op typed strings. Would that not be simple a subtype of strings (implementing additional restrictions on the values of the strings, a true substype)? Also, when I see something like: 'args.all(fn(x) => x % 2 == 1)' I do experience it as 'simple, obvious, and easy to reason about for both humans and machines' because it only makes sense if you already have a lot of knowledge about languages like TypeScript. I think that something like: 'All x in args: x % 2 == 1' is easier to read. BTW, why does 'fn(x)' not have a type? Are types optional in your langauge? I would not give examples of mechanisms that have not been implemented and seem to go against your principle ideas, such as references. What happens, I pass a part of a value to a 'ref' argument of a function? There are some other language out there that are only based on immutable values. If you are fond of immutable values, why not implement them in an existing language and see how far you get. This has the benefit that people do not have to learn a new language and keeps you from reimplementing a lot of stuff that others already have implemented.

coldtea 7y ago
>I do not see the benefit of a 'sign' function with an optional argument Perhaps you don't see the benefit of an identity function either ("why not just use the variable")? Encapsulating things in a function instead of a statement is key to certain patterns (and functional style).
- hibbelig 7y ago
  I agree with GP. The 'sign' function with a mandatory argument I understand. Making the argument optional I don't understand.
  - CREwert 7y ago
    I think its less about a sign function than about showing how optional (i.e. nullable) values work. Most languages have them, and making that possibility explicit is recent best practice.

fxfan 7y ago

Hello, no offense but the community here is bikeshedding. I'd suggest you to discuss this at /r/programming

ahaferburg 7y ago
They're bikeshedding there as well. Just filter out any post that contains the word syntax.
- fxfan 7y ago
  Technical discussion is usually still leagues better on reddit than here
coldtea 7y ago
Sounds offensive to me. First of all, the community here discusses the post, and whatever they like about the language and announcement -- and whatever they think of tied (loosely or not, to that). We're not here as some committee with some explicit purpose to give relevant PL criticism.
- fxfan 7y ago
  I don't mind you being offended, I was talking to the creator.

ahaferburg 7y ago

You seem to have some goals in common with Floyd. Maybe you want to get in touch. https://github.com/marcusz/floyd https://github.com/marcusz/floyd https://www.reddit.com/r/ProgrammingLanguages/comments/arwjlo/floyd_language_wants_to_become_faster_than_c/ https://www.reddit.com/r/ProgrammingLanguages/comments/arwjl...

trombonechamp 7y ago

Thanks for your work, this looks exciting! I am curious about the following: > Since the semantics and design of the language ensure fully determinized execution of any code there is actually no real need to perform logging within a block of code. So, logging is not available in the compute language. While this may be true for execution, this is not true of data on which the program operates. For example, when processing large amounts of data, how should one keep track of statistics, performance information, data irregularities (which don't cause errors but may be useful to look into further), and other such events which might otherwise be logged? Similarly, suppose the program performs some operation which depends on the system time which fails at runtime for certain system times. If run in deployed mode, it would restart and run the same thing in debug mode, but the environment would be different. How would such an operation be able to be traced back to the particular conditions which caused the error?

mrkmarron 7y ago
Great question. We take a very maximalist stance here and do not provide any environmental API’s in the Bosque language. Instead all IO, data-time, IP address operations must be part of a host platform – similar to how JavaScript does not provide IO or an event loop in the spec but relies on the browser or Node.js to provide it. With this model the host can just log/record the environment interactions. The details of this host and integration are an open issue, both research and engineering, but I am very excited by the AMBROSIA architecture (https://github.com/Microsoft/AMBROSIA https://github.com/Microsoft/AMBROSIA) by one of my colleagues as a possible design.