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

101–110 of 178 posts

Re: The Bosque Programming Language

#101

Post by devinj »

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 from me, but more often angry users who demanded things of me, and rarely anyone saying thanks.

Re: The Bosque Programming Language

#102

Post by wolfspider »

sfvisser wrote: post #52
stared wrote: 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.

If you have worked with F* or Low* then you probably have some exposure to using Z3 and getting this kind lexical analysis from it is a breakthrough. I just wish Z3 was available on more platforms by default.

Re: The Bosque Programming Language

#103

Post by francasso »

This is another PL I won't try (not that the authors should care).

I'm still waiting for a good "system programming language" that

- has compile time execution that can call a compiler API to allow compile time code generation

- full compile time reflection, optional runtime reflection

- doesn't have any kind shape or form of automatic memory management

- has decent discriminated unions

- is not much more opinionated than C on how I should live my life

- operator overloading: define at least common operators (+, *, -, etc...) for user types. Sometimes I like the idea to be able to define infix/postfix functions in general while also assigning a priority and an associativity (totally possible with a hand made parser), but I think that could easily lead to a mess if miss-used by the community.

Zig is spot on for some of those. JB's Jai on others. For the rest it looks like there aren't many people that are bothered by the things I'm bothered with.

Re: The Bosque Programming Language

#104

Post by gnulinux »

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.

I don't understand what people are trying to categorize when they say C/C++. They're incredibly different languages. It's hard to find similarities between C and modern C++ (C++2x flavor). If we put C and C++ under the same umbrella, why not put Java there too? I just think when you say C/C++ you need to clarify what exactly do you mean by that.

Re: The Bosque Programming Language

#105

Post by pjmlp »

pron wrote: post #79
pjmlp wrote: post #78

Earlier quoted context omitted.

Indeed, at the end of the day there are certain domains where they are unavoidable, and regardless of countless rants from our side, those are the tools that get picked when one of said domains needs to be addressed. Given your line of work, why not Java itself, on an hypothetical future where Valhalla is done, and AOT is a standard feature in equal footing with JIT capabilities/performance?

Maybe, but I'm allowed to like more than one language, no? :) But seriously, I don't think AOT can ever match a JIT on peak performance without reducing the abstraction level and significantly increasing programmer burden, and much of Java's design is around "we automatically turn RAM into speed." It's a great value proposition for huge swathes of the software industry, but I don't think it's necessarily the best str…

Sure, just curious. :)

Currently I am on a mix of .NET (C# F#) alongside C++.

I agree with the performance part, that is why the best is to be able to have both around, AOT + JIT.

Re: The Bosque Programming Language

#106

Post by pjmlp »

jfkebwjsbx wrote: post #73
pjmlp wrote: post #33

Earlier quoted context omitted.

Actually that was already a thing in Mesa/Cedar, Modula-3, Oberon language family and Eiffel. Sadly Java has not taken this into account, nor AOT support out of the box, and now it is catching up with it.

Eiffel does not enforce preconditions at compile time. What are you referring to?

I was only referring to:

" 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++ (and C# and Go) have over languages like Java is ability to avoid heap-allocated objects (i.e. stack-allocated structs)."

Re: The Bosque Programming Language

#107

Post by zenexer »

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. It looks like it borrows a lot from TypeScript and C#, then attempts to make the resulting syntax a bit stricter with various forms of contracts. I think the goal is to make stronger guarantees at compile-time and promote better design practices. That, in turn, can result in faster applications because the compiler can make more assumptions.

If that is the goal, it needs to be explained more clearly in the readme before receiving widespread publicity, and there needs to be text explaining how each feature achieves that goal. A big part of developing a new programming languages is selling it: you have to convince a lot of opinionated people that it's worth their time and energy to invest in learning your technology.

Ideally, these arguments would be written during the design process before implementation even begins, so I don't think it's unreasonable to expect that they be available in the readme.

This might be a better link for the HN post: https://www.microsoft.com/en-us/research/project/bosque-prog...

Re: The Bosque Programming Language

#108

Post by hhas01 »

cmrdporcupine wrote: post #92
hhas01 wrote: post #84

Earlier quoted context omitted.

“I think they've done an incredible job with their ObjC interop, given said mismatch.” Which is to say, the Swift devs have done an incredible job of solving the wrong problem . Apple needed a modern language for faster, easier Cocoa development. What they got was one that actually devalues Apple’s 30-year Cocoa investment by treating it as a second-class citizen. Gobsmacking hubris! Swift was a pet project of Lattne…

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 mindless makework and brittleness. Busyness vs productivity; minutiae vs expressivity. Casual complexity vs rigorous parsimony.

Call me awkward, but I firmly believe good language design means good UI/UX design. Languages exist for humans, not hardware, after all. Yet the UX of mainstream languages today is less than stellar.

(Me, I came into programming through automation so unreasonably expect the machines to do crapwork for me.)

Re. JIT, I’m absolutely fine with baking down to machine code when you already know what hardware you’re targeting. (x86 is just another level of interpretation.) So I don’t think that was it; it was just that Lattner &co were C++ fans and users, so shaped the language to please themselves. Add right time, right place, and riding high on (deserved) reputation for LLVM work. Had they been Smalltalk or Lisp fans we might’ve gotten something more like Dylan instead. While I can use Swift just fine (and certainly prefer it over C++), that I would have enjoyed. Ah well.

Re: The Bosque Programming Language

#109

Post by [deleted] »

gliese1337 wrote: post #40
wizeman wrote: 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…

[deleted]

Re: The Bosque Programming Language

#110

Post by dkersten »

wizeman wrote: post #36
dkersten wrote: post #28

Earlier quoted context omitted.

> Again, no interaction with the outside world? Or are all inputs recorded during the entire execution? Inputs would need to be cached (eek, if there’s a lot of state loaded from external services or databases, or if that state is sensitive and you want to control where it may get persisted), but more importantly, output needs to be not output on the rerun (eg database writes and api calls). > So recursion cannot dep…

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…

Absolutely, there is a big difference between compile time statically known stack size and bounded loops. Hell, loops can be bounded but dynamically sized. If they, indeed, mean that the stack is known ahead of execution, then you are absolutely right, as long as you can have recursion that depends on user input, the stack cannot be known statically.
Post reply on HN