Why did you name your language on "woods"?
The Bosque Programming Language
51–60 of 178 posts
Re: The Bosque Programming Language
#52> 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…
But I might be wrong here.
Re: The Bosque Programming Language
#53Hi, 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.
>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
#54Hi, 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.
Re: The Bosque Programming Language
#55Re: The Bosque Programming Language
#56> 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…
Re: The Bosque Programming Language
#57Yeah, 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…
Re: The Bosque Programming Language
#58Re: The Bosque Programming Language
#59I 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.
Re: The Bosque Programming Language
#60Earlier 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…
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.