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

91–100 of 178 posts

Re: The Bosque Programming Language

#91

Post by throwaway894345 »

cmrdporcupine wrote: post #87
terhechte wrote: post #50

Earlier quoted context omitted.

> I personally would welcome a new language that gives me full-spectrum dependent types with great tooling and moderate performance. I'd propose to have a look at Swift. It is very similar to Rust in many aspects (particularly the type system), with slower performance (due to some of the abstractions). The tooling on macOS is already really good, on Linux it is getting there, and on Windows the next release will add…

I don't see how Swift is similar to Rust -- it's a garbage collected, OO language, not really appropriate for low level / systems level programming. It's a nice looking language for what it is, with some nicer modern features in its type system etc, but its niche is not the same as Rust.

> it's a garbage collected, OO language, not really appropriate for low level / systems level programming

I'm of the impression that Swift is reference counted, which, while technically a kind of GC, is also appropriate for low level / systems programming (which isn't to say that Swift is a good language for low level / systems programming; only that its memory management isn't the disqualifying factor).

Re: The Bosque Programming Language

#92

Post by cmrdporcupine »

hhas01 wrote: post #84
h-cobordism wrote: post #71

Earlier quoted context omitted.

> embarrassingly knotty around its ObjC bridging (there’s a basic impedance mismatch between those two worlds) I think they've done an incredible job with their ObjC interop, given said mismatch. But you're right — the person above who said that > The world has enough cookie cutter procedural and OOP languages. definitely isn't looking for Swift.

“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 it's not like existing Cocoa programmers would have been frustrated or confused.

Clearly the original NeXT engineers were inspired by Smalltalk and wanted something like it, but had performance concerns etc, perhaps there would have been performance concerns with moving to a VM based environment for mobile devices, but I think with a modern JIT these problems could be alleviated. As we've seen with V8, etc..

So I think it was actually a missed opportunity for Smalltalk to finally have its day in the sun :-)

Re: The Bosque Programming Language

#93

Post by throwaway894345 »

jleahy wrote: post #37
curryhoward wrote: post #32

Earlier quoted context omitted.

> It’s already suspicious by virtue of having a hand-wavy "Int" type (what size/signedness is that?) and it appears to be object-oriented (so we have to rely on compiler optimisations to remove dynamic dispatch) and garbage-collected (so by default any non-trivial type is heap-allocated). These are just ways in which it is worse than Rust as far as performance goes, since "ergonomics"/"productivity" is so subjective.…

For ‘moderate performance’ surely JVM based languages are what you’re looking for? There’s great tooling and a very low barrier to creating new languages. Creating a new systems programming language like C++, Rust or Zig is by contrast a lot more effort and means having significantly worse support for debugging and IDEs unless you put a lot of effort in (generating good DWARF debug data for a new language is hugely c…

Presumably LLVM closes the gap significantly?

Re: The Bosque Programming Language

#94

Post by TomMarius »

shakna wrote: post #15
TylerE wrote: post #8

Earlier quoted context omitted.

all-of should not work unless your syntax for basic arithmetic is something heinous.

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?

Re: The Bosque Programming Language

#95

Post by hhas01 »

exdsq wrote: post #81
h-cobordism wrote: post #71

Earlier quoted context omitted.

> embarrassingly knotty around its ObjC bridging (there’s a basic impedance mismatch between those two worlds) I think they've done an incredible job with their ObjC interop, given said mismatch. But you're right — the person above who said that > The world has enough cookie cutter procedural and OOP languages. definitely isn't looking for Swift.

But it doesn’t have dependent types does it?

Nope. I think it periodically gets floated on Swift-Evolution, but someone would have to design and implement it… and I suspect the Swift codebase (which is C++; it isn’t even self-hosting) is already fearsomely complex as it is.

Or, to borrow another Tony Hoare quote:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

..

Alas, big complex codebases facilitate fiddling with the details over substantive changes; and that’s even before considering if the Swift language’s already-set syntax and semantics are amenable to expressing concepts they weren’t originally designed for. Stuff like Swift evo’s current thrash over trailing block[s] syntax reminds me of Python’s growth problems (e.g. its famously frustrating statement vs expression distinction that’s given rise to all its `lambda…`, `…if…else…`, etc nonsense).

It’s hard to scale after you’ve painted yourself into a corner; alas, the temptation is to start digging instead. I really wish Alan Kay had pursued his Nile/Gezira work further. That looked like a really promising approach to scalability. We really need better languages to write our languages in.

Re: The Bosque Programming Language

#96

Post by cmrdporcupine »

throwaway894345 wrote: post #91
cmrdporcupine wrote: post #87

Earlier quoted context omitted.

I don't see how Swift is similar to Rust -- it's a garbage collected, OO language, not really appropriate for low level / systems level programming. It's a nice looking language for what it is, with some nicer modern features in its type system etc, but its niche is not the same as Rust.

> it's a garbage collected, OO language, not really appropriate for low level / systems level programming I'm of the impression that Swift is reference counted, which, while technically a kind of GC, is also appropriate for low level / systems programming (which isn't to say that Swift is a good language for low level / systems programming; only that its memory management isn't the disqualifying factor).

I wouldn't consider reference counted GC systems level appropriate. It _can_ be more deterministic, but not when it's tracing and collecting cycles (which a decent modern RC implementation must do) and it usually plays havoc on L1 cache (by touching counts).

You can make RC quite nice (I've written cycle collecting implementations before) but there's reasons why C++ programmers are encouraged generally to avoid shared_ptr and use unique_ptr whenever possible: harder to reason about or trace object lifetimes, and performance implications.

Now if the garbage collection was optional, and one could still freely heap or stack allocate and free, then, yes, I could see it. But I don't think that's the case w/ Swift, at least not last time I looked at it. It's also why Go is imho not a 'systems' programming language.

Re: The Bosque Programming Language

#97

Post by throwaway_pdp09 »

TomMarius wrote: post #86
thrower123 wrote: post #62

Earlier quoted context omitted.

It would be good for its own sake to provide some motivation for why you'd bother using it over the dozen established alternatives with mature ecosystems and tooling.

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

Re: The Bosque Programming Language

#98

Post by ken »

norswap wrote: post #56
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…

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?

I read through the whole readme. I can’t figure out which part of this they think is the “breakthrough”.

Re: The Bosque Programming Language

#99

Post by ken »

cmrdporcupine wrote: post #96
throwaway894345 wrote: post #91

Earlier quoted context omitted.

> it's a garbage collected, OO language, not really appropriate for low level / systems level programming I'm of the impression that Swift is reference counted, which, while technically a kind of GC, is also appropriate for low level / systems programming (which isn't to say that Swift is a good language for low level / systems programming; only that its memory management isn't the disqualifying factor).

I wouldn't consider reference counted GC systems level appropriate. It _can_ be more deterministic, but not when it's tracing and collecting cycles (which a decent modern RC implementation must do) and it usually plays havoc on L1 cache (by touching counts). You can make RC quite nice (I've written cycle collecting implementations before) but there's reasons why C++ programmers are encouraged generally to avoid share…

> I wouldn't consider reference counted GC systems level appropriate. It _can_ be more deterministic, but not when it's tracing and collecting cycles (which a decent modern RC implementation must do)

Swift has what you would call an ‘indecent’ RC design, then, because it doesn’t.

> and it usually plays havoc on L1 cache (by touching counts).

Swift (like Objective-C) can store the refcounts either inline or in supplementary structures, for performance.

> Now if the garbage collection was optional

In the common case, it practically is, as (most) value types will only ever live on the stack, or inline in another data structure.

Re: The Bosque Programming Language

#100

Post by cmrdporcupine »

ken wrote: post #99
cmrdporcupine wrote: post #96

Earlier quoted context omitted.

I wouldn't consider reference counted GC systems level appropriate. It _can_ be more deterministic, but not when it's tracing and collecting cycles (which a decent modern RC implementation must do) and it usually plays havoc on L1 cache (by touching counts). You can make RC quite nice (I've written cycle collecting implementations before) but there's reasons why C++ programmers are encouraged generally to avoid share…

> I wouldn't consider reference counted GC systems level appropriate. It _can_ be more deterministic, but not when it's tracing and collecting cycles (which a decent modern RC implementation must do) Swift has what you would call an ‘indecent’ RC design, then, because it doesn’t. > and it usually plays havoc on L1 cache (by touching counts). Swift (like Objective-C) can store the refcounts either inline or in supplem…

imho inline will still mess with cache somewhat as adding a reference count still often requires bringing something into cache or evicting something from cache that wouldn't happen with a pure pointer reference.

Glad to hear that value types are optimized well.

Post reply on HN