Hacker News Reader

Comment by mrkmarron | Hacker News Reader

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.

View on HN

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

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.

This is the exact goal of the removal of “incidental algorithms”, as described in a number of papers/talks by Sean Parent, Mat Marcus, Jaakko Järvi, et al. They mostly explore this in the setting of GUI behavior implementation.

I wish PL researchers would actually run studies to measure cognitive load and usability metrics while using their language compared to some other language.

I would do it if the right PhD student came along!

I have never investigated this, but I feel that PL pragamtics and PL-feel is relatively under researched.

I talked about this with colleagues a few years back, but we had very distinctly different feelings about what we were doing when writing C vs C#: C often feels more like writing text that will be translated to code while C# already feels like you are manipulating code. It makes no sense when I write this out but that's phemenology for ya.

This is interesting. I "feel" this in Visual Studio, as the DE is more tightly I(ntegrated). Do you still feel like this in the context of a plugin-less plain editor?

Running any study with real humans is very expensive. We can measure simple things empirically (eg reaction time), but trying to measure something such has “cognitive load” is probably impossible, and what is a usability metric? Do those already exist for PL or so they need to be invented somehow?

We (PL researchers) think about this a lot, but so far no one has come up with any good answers on how to empirically measure PL usability for an entire PL (vs chipping off small features to evaluate). At best, we can run qualitative studies with little in the way of rigor.

> I would do it if the right PhD student came along!

Quit trying to lure unsuspecting CS grads into your van!

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

That sounds bizarro. Accidental complexity is pretty obvious to show in an example of a function or an application architecture or class.

It might be harder to define in abstract (except as e.g. "complexity not imposed inevitably by the functionality/problem domain"), but it's very easily observable in specific code examples.

Can you show me some examples? I understand complexity, I also understand incidental complexity, but I’m not sure about it being accidental.

Google the "Out of the Tar Pit" paper by Moseley and Marks. After incidental complexity, Accidental complexity is the all remaining stuff. It's the complexity you wouldn't have to deal with in an ideal perfect world. For example: manual memory management, performance optimisations, JavaScript equality semantics, aspect-oriented programming, dependency injection frameworks or any other ad-hoc technology to work around issues further down in the stack.

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.

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

I agree with GP. The 'sign' function with a mandatory argument I understand. Making the argument optional I don't understand.

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.

As fjfaase said “The first is that you should try to include realistic examples in your documentation and promote good coding styles.”

That ‘sign’ example could be somewhat improved by having it return an optional int instead (returning null on null inputs), or by having it take a double and return an optional int (returning null for not-a-numbers), but I think it isn’t that hard to come up with a more realistic short example.

I think the typed string is to sort of the same as typed lists. The string can be thought of as a container for the type it holds.

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?

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) by one of my colleagues as a possible design.

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.

You seem to have some goals in common with Floyd. Maybe you want to get in touch.

https://github.com/marcusz/floyd https://www.reddit.com/r/ProgrammingLanguages/comments/arwjl...

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

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.

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

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.

Sounds like it, but Elm is only for front-end web dev.

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

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.

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

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

OK, thanks.

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.

Bosque is spanish for "forest" (not necesarily along a river).

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

> 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

Surely you didn't mean too but the correct tense of "get" on you're sentence would be "gets"

> on you're sentence would be "gets"

this just gets better and better

That was to make sure I didnt violate Muphry's law!

More accurately, Skitt's Law (which is mentioned in that Wikipedia article).

> Muphry

Sems like it got you too!

(Yes that was intentional

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 : )

The error is a missing word if anyone is wondering.

"The Bosque programming language is designed for writing code that _is_ simple, obvious, and easy to reason about for both humans and machines."

So what?

Reply on news.ycombinator.com