Live data from Hacker News

The Bosque Programming Language

microsoft.com

71–80 of 172 posts

Re: The Bosque Programming Language

#71
post #54

Earlier quoted context omitted.

> I do not see the benefit of a 'sign' function with an optional argument Perhaps you don't see the benefit of an identity function either ("why not just use the variable")? Encapsulating things in a function instead of a statement is key to certain patterns (and functional style).

I agree with GP. The 'sign' function with a mandatory argument I understand. Making the argument optional I don't understand.

I think its less about a sign function than about showing how optional (i.e. nullable) values work. Most languages have them, and making that possibility explicit is recent best practice.

Re: The Bosque Programming Language

#72

Earlier quoted context omitted.

Hello! Disclaimer: I haven’t read the full publication yet and I’ve only skimmed it. A lot of programming languages that are coming out these days talk about simplicity, lowering “cognitive load”, increasing expressiveness, being nimble/lightweight/easy/whatever, and—this one stated by you—reducing “accidental complexity”. When I looked at your grammar and some examples, I saw atomic building blocks that don’t lead t…

I wish PL researchers would actually run studies to measure cognitive load and usability metrics while using their language compared to some other language. I would do it if the right PhD student came along!

I have never investigated this, but I feel that PL pragamtics and PL-feel is relatively under researched.

I talked about this with colleagues a few years back, but we had very distinctly different feelings about what we were doing when writing C vs C#: C often feels more like writing text that will be translated to code while C# already feels like you are manipulating code. It makes no sense when I write this out but that's phemenology for ya.

Re: The Bosque Programming Language

#73

Earlier quoted context omitted.

Hello! Disclaimer: I haven’t read the full publication yet and I’ve only skimmed it. A lot of programming languages that are coming out these days talk about simplicity, lowering “cognitive load”, increasing expressiveness, being nimble/lightweight/easy/whatever, and—this one stated by you—reducing “accidental complexity”. When I looked at your grammar and some examples, I saw atomic building blocks that don’t lead t…

I wish PL researchers would actually run studies to measure cognitive load and usability metrics while using their language compared to some other language. I would do it if the right PhD student came along!

> I would do it if the right PhD student came along!

Quit trying to lure unsuspecting CS grads into your van!

Re: The Bosque Programming Language

#74
Some comments on the code, based on Tictactoe example (https://github.com/Microsoft/BosqueLanguage/blob/master/docs...):

1. overall quite nice looking and easy to understand

2. too verbose in places, e.g. this constant structure:

    const winPositionOptions: List[List[[Int, Int]]] = List[List[[Int, Int]]]@{
        List[[Int, Int]]@{ @[ 0, 0 ], @[ 0, 1 ], @[ 0, 2 ] },
        List[[Int, Int]]@{ @[ 0, 1 ], @[ 1, 1 ], @[ 2, 1 ] },
        List[[Int, Int]]@{ @[ 0, 2 ], @[ 1, 2 ], @[ 2, 2 ] },

        List[[Int, Int]]@{ @[ 0, 0 ], @[ 1, 0 ], @[ 2, 0 ] },
        List[[Int, Int]]@{ @[ 1, 0 ], @[ 1, 1 ], @[ 1, 2 ] },
        List[[Int, Int]]@{ @[ 2, 0 ], @[ 2, 1 ], @[ 2, 2 ] },

        List[[Int, Int]]@{ @[ 0, 0 ], @[ 1, 1 ], @[ 2, 2 ] },
        List[[Int, Int]]@{ @[ 0, 2 ], @[ 1, 1 ], @[ 2, 0 ] }
    };
Has types defined in 10 places, 9 of which are redundant.

Also you are using @{...} for lists and @[...] for tuples; a more usual convention (in e.g. Python or Haskell) would be [...] and (...) respectively.

3. String types aren't intuitive (at least to me). E.g. in this code:

    const playerX: String[PlayerMark] = 'x'#PlayerMark;
It appears that a String[PlayerMark] is a subset of String that can have the values 'x' or 'o'.

I would have preferred something like:

    type PlayerMark = 'x' | 'o';
    type PlayerMarkOrBlank = 'x' | 'o' | ' ';

Re: The Bosque Programming Language

#75

Earlier quoted context omitted.

> There's an English error on the very first sentence of the description on the Microsoft site. [emphasis added] The correct usage would be to talk about an error "in" a sentence, not "on" a sentence. Muphry's law get you every time! https://en.wikipedia.org/wiki/Muphry%27s_law

> Muphry Sems like it got you too! (Yes that was intentional

In this case the misspelling is actually the correct one. HN has shortened the link in GPs post but if you follow it you'll see it spelled "Muphry's law", and it is a separate one from the general one that everyone knows about.

That said it wouldn't surprise me at all if I've misspelled something here : )

Re: The Bosque Programming Language

#77

Earlier quoted context omitted.

How not? method makeAutoMove(mark: String[PlayerMark], rnd: Int): Game requires !this->hasWinner(); method makeExplicitMove(x: Int, y: Int, mark: String[PlayerMark]): Game requires !this.board->isCellOccupied(x, y); If I'm reading it right though, it looks more like it simple doesn't execute the function at all instead of throwing etc. So yet another possible route to deal with an invalid contract.

It could be checked at compile time no?

How would you check them at compile time without using dependent types (at least it doesn't look to me like these are dependent types)?

Re: The Bosque Programming Language

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

Re: The Bosque Programming Language

#79
Please consider using a license other than MIT. MIT assumes all contributors work for a single institution, and doesn't protect licensees from later patent infringement claims.

https://writing.kemitchell.com/2019/03/09/Deprecation-Notice...

Either Apache 2.0 or Blue Oak Model would be better choices.

Re: The Bosque Programming Language

#80

Please consider using a license other than MIT. MIT assumes all contributors work for a single institution, and doesn't protect licensees from later patent infringement claims. https://writing.kemitchell.com/2019/03/09/Deprecation-Notice... Either Apache 2.0 or Blue Oak Model would be better choices.

I don’t know much about licenses but last week I added a license to one of my GitHub repositories for the first time. GitHub seemed to be heavily pushing MIT as the default.

If the MIT license assumes everyone works at the same place then that seems horrible for GitHub repositories, right?

Post reply on HN