Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bosque Programming Language

github.com

Post reply on HN
Print view View original

121–130 of 178 posts

Re: The Bosque Programming Language

#121

Post by cmrdporcupine »

hhas01 wrote: post #108
cmrdporcupine wrote: post #92

Earlier quoted context omitted.

I don't have enough experience with Swift to agree or disagree with you about it, but it strikes me that there were already Smalltalk-like languages out there that fit this niche somewhat -- such as F-Script -- and Apple could have gone down that road instead of shoehorning Swift into the role. Objective C already had Smalltalk-style message dispatch syntax, and something fairly close to Smalltalk blocks/lambdas. So…

Agreed. Swift is a language designed by and for compiler engineers; and it shows. Contrast Smalltalk which was designed by and for users and usability. Chalk and cheese at every level—especially user level. Alas, I think decades of C has trained programmers to expect and accept lots and lots of manual drudgework and unhelpful flakiness; worse, it’s selected for the type of programmer who actively enjoys that sort of…

I mean, I work in C++ all day (chromecast code base @ Google), and I like the language. But I also know where it does and doesn't belong. For application development, particularly _third party_ app dev, it makes no sense. And neither did Objective C, which is the worst of both worlds. I had to work in it for a while and it's awful.

I agree Dylan (or something like it) would have been a good choice, except that it wouldn't mate well with the Smalltalk style keyword/selector arguments in Cocoa, also it has the taint of being associated with the non-Jobs years and so maybe there would have been ... political... arguments against it.

They just needed a Smalltalk dialect with Algolish/Cish syntactic sugar to calm people down, and optional or mandatory static typing to making tooling work better.

Re: The Bosque Programming Language

#123

Post by garyclarke27 »

sachinjoseph wrote: post #19
mrkmarron wrote: post #14

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.

The use use of '=' here scares me: function add2(x: Int, y: Int): Int { return x + y; } add2(2, 3) //5 add2(x=2, y=3) //5 add2(y=2, 5) //7 The language already supports '=' operator for assignment of variables in the current scope, so should you use the same operator for denoting value assignment formal parameters in a function call? This can lead to a lot of confusion between variables in the scope and formal parame…

I love this feature - calling named parameters is (for me) a glaring omission from Javascript (and surprisingly Typescript), I know you can define an object argument, but not many do and that’s not very elegant.

Re: The Bosque Programming Language

#124

Post by traes »

TomMarius wrote: post #94
shakna wrote: post #15

Earlier quoted context omitted.

Refusing to allow symbols in identifiers might make some things easier to read, but is annoying as hell if you're touching anything scientific. If you have something clear you break tokens on, like whitespace (except within quotes), then you should have no problems allowing arbitrary symbols inside an identifier.

x = 0 y = 1 x+y = 0 z = x+y What is z?

x+y = 0 (with that specific syntax) will error in pretty much every language.

Re: The Bosque Programming Language

#125

Post by alexhutcheson »

whb07 wrote: post #69
pron wrote: post #68

Earlier quoted context omitted.

> has to prove itself not just superior to C++, but superior to Rust ... and Zig and Nim and D, I guess? None of them are seeing enough usage to even score them meaningfully against C++. The incumbents are C/C++, and there's no one else within two orders of magnitude. Just experiments at various stages; some are still in the lab, others have started some field trials, but that's about it.

As I'm writing this, I spent X hours trying to find where my C project was leaking memory. Turns out one of the openssl pointers needed to be freed explicitly, which was my fault from having just seen their docs and them not explicitly showing so. Point is, with Rust this wouldn't be a thing. I wouldn't have to compile my program with a number of clang flags and then run the sanitizers and try to fish out where this…

If the library were written in modern C++, then it also wouldn't be a problem. It would have given you a std::unique_ptr, ownership would have been clear, and deletion would have been handled automatically.

Re: The Bosque Programming Language

#126

Post by steveklabnik »

throwaway_pdp09 wrote: post #97
TomMarius wrote: post #86

Earlier quoted context omitted.

It's a language research project. > In the Bosque project we ask the question of what happens if the IR is designed explicitly to support the rich needs of automated code reasoning, IDE tooling, etc. With this novel IR first perspective we are exploring a new way to think about and build a language intermediate representation and tools that utilize it. Our initial experiments show that this empowers a range of next-g…

Then tell us this. In fact stick it somewhere obvious. Also please talk straight, please don't mention "next-generation experiences", that's just marketing nothingspeak to HN techies. "enhanced fuzzing" - as opposed to what? "soft-realtime compilation" - meaning...? "stable GC support" - oh thank god for that, finally GC is reliable and can be used in production. thankyou thankyou thankyou for banishing GC instabilit…

> Then tell us this. In fact stick it somewhere obvious.

The first sentence of this page:

> The Bosque programming language is a breakthrough research project from Microsoft Research.

"Microsoft Research" is in italics, even.

Re: The Bosque Programming Language

#127

Post by mrkmarron »

tomp wrote: post #23
mrkmarron wrote: post #14

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.

Can you explain some further things about this languages? 1. How does the GC work? It says "novel reference counting" does that mean it leaks cycles or handles them (either by also tracing or preventing them statically)? 2. Is that the only thing it does to provide a C++-like "resource efficient and predictable runtime"? After all, that's basically Swift (or Python+static types). I think the main improvement that C++…

Hi and thanks for the questions:

1. By design the language provides some novel memory invariants including, no cycles in the object graph, no old-to-new pointers, and no pointer updates. Thus, we don't need to worry about cycle collection, can greatly reduce the number of Ref-Count operations, and can (later) employ pool allocation more consistently.

2. Bosque also supports by-value types (including the future ability to do by-value unions) and, since the language is referentially transparent, the compiler can aggressively use stack allocation and copy semantics. Also, the collections are all fully determinized and use low-variance implementations to avoid "bad luck" performance anomalies.

3. The compiler does not enforce the checks. They can either be checked at runtime or checked by converting the program into a logical form that Z3 or another theorem prover can check. Values in the language are immutable and there is no concurrency (yet) but since the language is immutable concurrency is by definition data-race free.

Re: The Bosque Programming Language

#128

Post by throwaway_pdp09 »

steveklabnik wrote: post #126
throwaway_pdp09 wrote: post #97

Earlier quoted context omitted.

Then tell us this. In fact stick it somewhere obvious. Also please talk straight, please don't mention "next-generation experiences", that's just marketing nothingspeak to HN techies. "enhanced fuzzing" - as opposed to what? "soft-realtime compilation" - meaning...? "stable GC support" - oh thank god for that, finally GC is reliable and can be used in production. thankyou thankyou thankyou for banishing GC instabilit…

> Then tell us this. In fact stick it somewhere obvious. The first sentence of this page: > The Bosque programming language is a breakthrough research project from Microsoft Research. "Microsoft Research" is in italics, even.

And I quoted exactly that line. In my first post.

Re: The Bosque Programming Language

#129

Post by tasogare »

zenexer wrote: post #107
devinj wrote: post #101

The snark and meanness in this HN thread is totally uncalled for and why people don't publish code. I can't believe this thread is on the front page together with https://news.ycombinator.com/item?id=23157783 . Go read that, especially the ending comments on open source. > I made this thing that I thought was cool and I gave it away, and what I got back were occasionally friendly people who nicely requested things fr…

The issue here is the link; it doesn't do a great job of explaining _why_ Bosque is breakthrough. A bold claim like that needs evidence. What's special here? From glancing at the code snippets--which is really all we have in the way of evidence on that page--I see an interesting language concept, but it's not entirely here how that relates to the initial claim. There are definitely some interesting elements, though.…

Thanks for the link, it is interesting. I’ve wished for the "Typed Strings" feature in C# a number of times, including today, so I hope it will be ported there one day.

Re: The Bosque Programming Language

#130

Post by AnimalMuppet »

benibela wrote: post #77
pron wrote: post #68

Earlier quoted context omitted.

> has to prove itself not just superior to C++, but superior to Rust ... and Zig and Nim and D, I guess? None of them are seeing enough usage to even score them meaningfully against C++. The incumbents are C/C++, and there's no one else within two orders of magnitude. Just experiments at various stages; some are still in the lab, others have started some field trials, but that's about it.

... and Pascal ! Many languages are superior to C/C++ C/C++ just wins from the amount of available libraries and high-quality implementations.

Maybe I'm too much of a pragmatist, but to me, the amount of available libraries and the quality of the implementations is part of what "superior" means.

You may think that Pascal is superior on paper (that is, just the language specification). If we were programming on paper, that might matter. But we aren't.

Post reply on HN