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

The Bosque Programming Language

microsoft.com

Post reply on HN
Print view View original

61–70 of 172 posts

Re: The Bosque Programming Language

#61

Post by dkersten »

mikekchar wrote: post #13
externalreality wrote: post #2

Yet another programming language. I wish I was that rich that I could just throw money at people to develop yet another programming language. I think at this point programming languages do more harm than good. Why, because some poor fellow is going to spend time that he could be using to cure cancer but instead he reinventing the wheel in some language that he is going to be sick of by time he if 35 - 40 years of age…

The thing is that people curing cancer (or doing any other kind of research) famously don't spend their time learning niche languages. Quite frequently they can't program at all. If they can, they usually write some really horrible code in whatever language they learned at school -- mainly because they are too busy doing their research to care about programming. Programmers, on the other hand, do spend their time lea…

> I stupidly put C++ on my CV the last time I was looking for a job and someone started asking me about Boost.

I used C++ as my main language for a few years and have used C++ more recently (although the last time I used it professionally was about 5 years ago now) and last year did a personal project to catch up on all the latest features (basically a project to upgrade my knowledge from C++11 to C++14 and C++17), although I've since given up on C++ since the latest additions are far too complex for me and I'm no longer confident that my code actually works how I want (I'm slowly trying to pick up Rust as a replacement).

My point, though, is that I consider my C++ skills to be above average, or at least, above passable, and yet I have never used Boost, have no intentions of ever using boost if I do use C++ (between C++17's standard library features and plenty of easy to use header only libraries, I just don't see the need for Boost for any projects I've ever used C++ on), so I wouldn't be able to answer any questions on Boost either.

Re: The Bosque Programming Language

#62

Post by hacker_9 »

UK-AL wrote: post #29
hacker_9 wrote: post #22

Only thing that caught my eye is the require syntax, which is nice, but then I thought what happens if this contract fails? Its possible you'd want to return false, or raise exception, or log error, or even correct value and continue. So whilst a nice feature, not practical IMO if it would always result in an exception.

I don't think they are runtime checks

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.

Re: The Bosque Programming Language

#63

Post by aramishn »

Stratoscope wrote: post #46
jjtheblunt wrote: post #19

Earlier quoted context omitted.

There's an English error on the very first sentence of the description on the Microsoft site.

> 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

Re: The Bosque Programming Language

#64

Post by hibbelig »

coldtea wrote: post #54
fjfaase wrote: post #20

Earlier quoted context omitted.

I hope you do not mind, if I make some comments. The first is that you should try to include realistic examples in your documentation and promote good coding styles. For example, I do not see the benefit of a 'sign' function with an optional argument. Or have a 'sign' function that uses a local variable, while this could also be done with an if-statement or the ?-operator. I do not understand the concept op typed str…

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

Re: The Bosque Programming Language

#65

Post by trombonechamp »

mrkmarron wrote: post #9

Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…

Thanks for your work, this looks exciting!

I am curious about the following:

> Since the semantics and design of the language ensure fully determinized execution of any code there is actually no real need to perform logging within a block of code. So, logging is not available in the compute language.

While this may be true for execution, this is not true of data on which the program operates. For example, when processing large amounts of data, how should one keep track of statistics, performance information, data irregularities (which don't cause errors but may be useful to look into further), and other such events which might otherwise be logged?

Similarly, suppose the program performs some operation which depends on the system time which fails at runtime for certain system times. If run in deployed mode, it would restart and run the same thing in debug mode, but the environment would be different. How would such an operation be able to be traced back to the particular conditions which caused the error?

Re: The Bosque Programming Language

#66

Post by thechao »

mrkmarron wrote: post #26
reikonomusha wrote: post #16

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 would say accidental complexity comes from mostly historical reasons. Two sources discussed in the report are reference equality and looping. These make a ton of sense if you are implementing a language with a compiler that targets an x86 processor. They map naturally to the features of the hardware but make other tasks impractical, e.g. compilation to a FPGA or verifying a SemVer dependency update doesn’t break yo…

This is the exact goal of the removal of “incidental algorithms”, as described in a number of papers/talks by Sean Parent, Mat Marcus, Jaakko Järvi, et al. They mostly explore this in the setting of GUI behavior implementation.

Re: The Bosque Programming Language

#67

Post by asimpletune »

fjfaase wrote: post #20
mrkmarron wrote: post #9

Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…

I hope you do not mind, if I make some comments. The first is that you should try to include realistic examples in your documentation and promote good coding styles. For example, I do not see the benefit of a 'sign' function with an optional argument. Or have a 'sign' function that uses a local variable, while this could also be done with an if-statement or the ?-operator. I do not understand the concept op typed str…

I think the typed string is to sort of the same as typed lists. The string can be thought of as a container for the type it holds.

Re: The Bosque Programming Language

#68

Post by azhenley »

reikonomusha wrote: post #16
mrkmarron wrote: post #9

Hi project owner (Mark) here. It is a bit late in the evening for me but I will try to answer any questions when I can. The Bosque language is currently in a very early state with lots of work to do and not ready for practical use. However, I am very excited by the potential in the concepts and wanted to make the project a collaborative endeavor, including both other academics and developer community, from the start.…

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!

Re: The Bosque Programming Language

#69

Post by asimpletune »

hacker_9 wrote: post #62
UK-AL wrote: post #29

Earlier quoted context omitted.

I don't think they are runtime checks

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?

Re: The Bosque Programming Language

#70

Post by mpartel »

Reading the publication, I don't see that big a difference to existing purely functional languages. It almost reads like a rediscovery and refinement of the main value propositions of e.g. Haskell.

That said, some of the refinements, especially the (TypeScript-inspired?) record typing and manipulation facilities, look quite pleasant.

Post reply on HN