The Bosque Programming Language • Hacker News Board

Re: The Bosque Programming Language

#121

Post by velcrovan » Wed, Apr 17, 2019, 9:14 PM UTC

teddyh wrote: post #97

velcrovan wrote: post #93

Earlier quoted context omitted.

Horrible in the sense of being an obvious mismatch for how development happens on GitHub, which pretty much exists to make contributions easy across institutional boundaries. No one benefits from the choice of MIT as a GitHub default. It's a quagmire of legal confusion borne out of pure ignorance.

> GitHub, which pretty much exists to make contributions easy across institutional boundaries No, GitHub exists to somehow benefit the current owners, Microsoft, however they decide is the best way. > No one benefits from the choice of MIT as a GitHub default. Actually, there is a good argument to be made that Microsoft actually benefits from MIT being the default, as nickpsecurity pointed out in a sibling comment.

OK I see what you're getting at. Sure, maybe MS is pushing MIT out of sneaky bastardliness. But, it kinda sounds like what you're saying is that as long as it's good for the owner it can't also be horrible.

I mean, my auto shop exists to benefit me however I decide is best, and there is a good argument to be made that I benefit from sabotaging my customers' cars. So what!

Re: The Bosque Programming Language

#122

Post by quickthrower2 » Wed, Apr 17, 2019, 10:03 PM UTC

mhd wrote: post #36

Am I the only one who really can't stand the expression "easy to reason about"? Everywhere you look everything that isn't exactly CORBA, ASN1., EJBs or XMLs is E2RA...

I thought "easy to reason about" was reserved for pure functional programming languages :-)

Re: The Bosque Programming Language

#123

Post by a1369209993 » Wed, Apr 17, 2019, 10:19 PM UTC

emmanueloga_ wrote: post #33

mshockwave wrote: post #24

> Thus, Bosque does not have any undefined behavior I think this is the one that should be highlighted most. Otherwise, from an engineering perspective, many of the other language features have already been implemented and widely used in other languages

I think I remember someone talk about undefined behavior in specifications and how it is actually a good thing, in the sense that offers increased liberty for implementations and some other advantages. Anybody else has heard this? Don't quite remember where I read it. My humble opinion aligns with yours, it seems intuitively "better" to have no undefined behavior. https://en.wikipedia.org/wiki/Undefined_behavior#Risk…

That was the original rationale for introducing (formally) undefined behavior in the original C standard. Malicious optimization is a after-the-fact perversion of it.

Re: The Bosque Programming Language

#124

Post by SlowRobotAhead » Wed, Apr 17, 2019, 10:22 PM UTC

hardtoreason wrote: post #115

SlowRobotAhead wrote: post #110

>Bosque programming language is designed for writing code that simple, obvious, and easy to reason about for both humans and machines. var v: List[Int ?] = List@{1, 2, none, 4}; OK! I think it needs some work. AM I supposed to intuitively know what ? and @ mean?

"Easy to reason about" doesn't mean "Doesn't require you to read any documentation."

Ok, and simple, obvious,?

Re: The Bosque Programming Language

#125

Post by foldr » Wed, Apr 17, 2019, 10:52 PM UTC

velcrovan wrote: post #118

foldr wrote: post #96

Earlier quoted context omitted.

I don't know what is meant by "space" here. It's a text file. There's nothing to stop someone listing multiple copyright holders in an MIT license. In general, having a long list of copyright holders is bad, because it makes it almost impossible in practice to verify that all of the copyright holders actually consent to release their code under the relevant license.

He’s not implying that the space in the file is somehow limited. He’s pointing towards the same problem you are guesturing at in your second paragraph: that “listing” copyright holders really only makes sense when there is only one of them. Any more than that and you raise the legal question: who exactly has copyright on which parts? When there is more than one copyright holder, you absolutely need language to addres…

"Each contributor" is meaningless unless you have a list of contributors. If you have a list of contributors, you may as well put it in the license.

Re: The Bosque Programming Language

#126

Post by auggierose » Thu, Apr 18, 2019, 1:26 AM UTC

ken wrote: post #88

auggierose wrote: post #40

Earlier quoted context omitted.

I think this is nicely solved in Swift.

How? I don't know any way to do a bulk update of an immutable structure in Swift, apart from constructing an entirely new structure and passing all values (not just changed ones) to its initializer.

You can just declare all members of the structure as vars. The structure will still be immutable.

Re: The Bosque Programming Language

#127

Post by velcrovan » Thu, Apr 18, 2019, 2:09 AM UTC

foldr wrote: post #125

velcrovan wrote: post #118

Earlier quoted context omitted.

He’s not implying that the space in the file is somehow limited. He’s pointing towards the same problem you are guesturing at in your second paragraph: that “listing” copyright holders really only makes sense when there is only one of them. Any more than that and you raise the legal question: who exactly has copyright on which parts? When there is more than one copyright holder, you absolutely need language to addres…

"Each contributor" is meaningless unless you have a list of contributors. If you have a list of contributors, you may as well put it in the license.

No, it's not meaningless. It refers to everyone who has contributed. According to the Blue Oak license, everyone who has contributed licenses their contribution according to the terms of that license. There’s no need to identify them separately, not for licensing purposes anyway. If their code is in there, it’s covered by the license.

Re: The Bosque Programming Language

#128

Post by augustk » Thu, Apr 18, 2019, 8:19 AM UTC

SlowRobotAhead wrote: post #111

augustk wrote: post #106

Earlier quoted context omitted.

"Choosing the equal sign to denote assignment is one notoriously bad example that goes back to Fortran in 1957 and has been copied blindly by armies of language designers since. This bad idea overthrows a century-old tradition to let = denote a comparison for equality, a predicate that is either true or false. But Fortran made this symbol mean assignment, the enforcing of equality. In this case, the operands are on u…

Equals is a verb AND a adjective though. So I disagree it's notoriously bad to use it as assignment. This is a situation solved entirely with = (make these equals) and == (are these equals?). >Thus, x = y does not mean the same thing as y = x. Unless it does, or should. The specfic argument you're arguing here is on that is just a simple syntax. You don't like = for assignment, but I do. You like = for comparison, bu…

But why change the meaning of one of the most common mathematical symbols? Every new generation of programmers must then relearn what "=" means. If you see "=" in a comment you are never really sure what it means, is it assignment or is it the standard mathematical predicate?

Re: The Bosque Programming Language

#129

Post by mcintyre1994 » Thu, Apr 18, 2019, 8:54 AM UTC

mrkmarron wrote: post #120

mcintyre1994 wrote: post #78

Typed strings look really nice, something I tend to wish every language had eventually - though I'm not sure why you'd limit them to Strings and not allow them for all types? I really like the Logarithm example shown in the Dotty docs for instance: https://dotty.epfl.ch/docs/reference/other-new-features/opaq...

There were some discussions for a more general system -- e.g. Int[Seconds] would be a typed int indicating the contents represented seconds. We needed to think more about all of these usecases and how things worked so we decided to start with just strings as the most useful. It is great to see you had the same idea though and would definitely like to revisit this in the future.

To be fair Strings would solve a problem I have right now with Scala pre-Dotty, our object IDs are all strings and the compiler does nothing to stop you using a user ID in a method that expects a contact ID, etc.

For your Int[Seconds] example, I haven't used them at all but could it work something like the F# measures concept? That seems sort-of similar but more general from scanning the docs.

Re: The Bosque Programming Language

#130

Post by foldr » Thu, Apr 18, 2019, 9:02 AM UTC

velcrovan wrote: post #127

foldr wrote: post #125

Earlier quoted context omitted.

"Each contributor" is meaningless unless you have a list of contributors. If you have a list of contributors, you may as well put it in the license.

No, it's not meaningless. It refers to everyone who has contributed. According to the Blue Oak license, everyone who has contributed licenses their contribution according to the terms of that license. There’s no need to identify them separately, not for licensing purposes anyway. If their code is in there, it’s covered by the license.

No, not unless you have a record that they agreed to contribute their code under that license. There's no magic wording in a license file that can make it possible to get by without keeping a proper record of contributors.