Live data from Hacker News

The Bosque Programming Language

github.com

51–60 of 178 posts

Re: The Bosque Programming Language

#52
post #44

> is a breakthrough research project [citation needed] In all seriousness, each time when I see a project self-describing itself as a breakthrough, it is a red flag. No matter if it is programming, mathematics, arts, or anything. (Of course, unless used ironically.) Either, it is a huge ego and a total lack of self-skepticism (vide Stephen Wolfram's recent Theory of Everything) or fiddling of the marketing department…

I just read this as "within the context of MS research projects — maybe even specifically in the category of programming languages — Bosque has a relatively high breakthrough value".

But I might be wrong here.

Re: The Bosque Programming Language

#53

Hi, project owner here, great to see this on HN and always happy to hear from folks here and on the GitHub repo. We also have a webinar with Q&A scheduled for Thursday morning ( https://note.microsoft.com/MSR-Webinar-Programming-Languages... ) which may be of interest as well.

>From this perspective the natural choice for the Bosque language is to adopt a pure functional model with immutable data only.

>The Bosque language fuses functional programming with block scopes and {...} braces by allowing multiple assignments to updatable variables var

This seems like a contradiction. There should only be an if-expression if 0.1 is correct. Not a branch

Re: The Bosque Programming Language

#54

Hi, project owner here, great to see this on HN and always happy to hear from folks here and on the GitHub repo. We also have a webinar with Q&A scheduled for Thursday morning ( https://note.microsoft.com/MSR-Webinar-Programming-Languages... ) which may be of interest as well.

Judging from the code snippets, the language supports generic types (`List`). Are there plans to support Higher kinded types? Smth like `typedef Ev=F`.

Re: The Bosque Programming Language

#56
post #44

> is a breakthrough research project [citation needed] In all seriousness, each time when I see a project self-describing itself as a breakthrough, it is a red flag. No matter if it is programming, mathematics, arts, or anything. (Of course, unless used ironically.) Either, it is a huge ego and a total lack of self-skepticism (vide Stephen Wolfram's recent Theory of Everything) or fiddling of the marketing department…

Cool. Could you maybe just read ahead and evaluate the claim for yourself and then post a comment about that if you end up agreeing/disagreeing with it?

Re: The Bosque Programming Language

#57

Yeah, but what is it? > The Bosque programming language is a breakthrough research project from Microsoft Research. Tells me nothing useful about it. > Bosque simultaneously supports a high productivity development experience expected by modern cloud developers, coming from say a TypeScript/Node stack, It's a web language then? > while also providing a resource efficient and predictable runtime with a performance pro…

Does a language really have to aim for a specific use case?

Re: The Bosque Programming Language

#59
post #3

I gotta say you lost me at args->allof It’s 2020, if you’re really serious about building a new language, shouldn’t you at least pick a reasonable naming case convention? (allOf, AllOf, all_of, all-of would all work) (Not talking about the fact that allOf doesn’t seem very consistent with other languages...)

My question is why -> instead of . for method/field access. I see almost all of the examples using -> but a few use . but unless there’s a difference (like how in C++ -> is a pointer dereference access), I think -> just adds noise to the syntax needlessly . The documentation doesn’t appear to explain when to use one over the other, or perhaps . is a typo.

Agree, the arrow is syntactically redundant in C and C++ and does indeed make code look noisier that it could be. (The same can be said about the “four-dot” double colon.)

Re: The Bosque Programming Language

#60
post #36

Earlier quoted context omitted.

Sure, but they are not simply saying that they do not allow unbounded loops, that is what some languages do already, like Coq. They are saying that the compiled program "uses constant stack space, eliminating any possible out-of-stack issues". This seems impossible unless recursion cannot depend in any way on inputs from the outside world. Mind you, even if you have constant stack space that does not mean that you wo…

There is a difference between "running out of stack memory" and "running out of memory used to store stack-structured data". Any recursive algorithm can be mechanically transformed into an equivalent iterative algorithm that uses only a single activation record on the system call stack. If you perform that transformation on an entire program, then the total depth of the call stack is a static property of the call gra…

To me it just seems that you're arguing semantics...

I mean, what is the difference between "stack memory" and "heap memory allocated to store the stack", other than the fact that the OS preallocates the first one for you by default?

To me, "the stack" and "a stack-like data structure stored in the heap that is used as a stack to replace what would otherwise be the stack" is functionally the same thing...

You know that (given appropriate conditions) you can just allocate stack frames wherever you want and point your stack pointer to whatever you want, whenever you want, right?

This is what the Go compiler does to prevent Go programs from running out of the stack space provided by the OS by default. But AFAIK they don't advertise that Go programs use constant stack space and you don't have to worry about out-of-stack issues...

So as far as I understand, there is no transformation that would make any recursive program use "constant stack space", unless of course, you just use some other memory to store what you'd store on your stack (but then again, that doesn't mean your stack has constant space, it just means that you're not using the default OS-provided stack space as a stack, and you're using other memory as a stack instead).

Apart from that, as I said before, even if you had "constant stack space" it does not mean that you won't have out-of-stack issues.

Post reply on HN