The Bosque Programming Language • Hacker News Board

Re: The Bosque Programming Language

#101

Post by Someone » Wed, Apr 17, 2019, 4:21 PM UTC

CREwert wrote: post #71

hibbelig wrote: post #64

Earlier quoted context omitted.

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.

As fjfaase said “The first is that you should try to include realistic examples in your documentation and promote good coding styles.”

That ‘sign’ example could be somewhat improved by having it return an optional int instead (returning null on null inputs), or by having it take a double and return an optional int (returning null for not-a-numbers), but I think it isn’t that hard to come up with a more realistic short example.

Re: The Bosque Programming Language

#102

Post by willtim » Wed, Apr 17, 2019, 4:40 PM UTC

reikonomusha wrote: post #87

coldtea wrote: post #56

Earlier quoted context omitted.

> To me, “accidental complexity” doesn’t seem like a very well defined concept. I might say such a term in a meeting room arguing to upper management that we need to pay off tech debt. Or I might blog using such a term to talk vaguely philosophically about software engineering. But I don’t think I’d find myself using it in a formal context to argue the merits (or lack thereof) of a technology. That sounds bizarro. Ac…

Can you show me some examples? I understand complexity, I also understand incidental complexity, but I’m not sure about it being accidental.

Google the "Out of the Tar Pit" paper by Moseley and Marks. After incidental complexity, Accidental complexity is the all remaining stuff. It's the complexity you wouldn't have to deal with in an ideal perfect world. For example: manual memory management, performance optimisations, JavaScript equality semantics, aspect-oriented programming, dependency injection frameworks or any other ad-hoc technology to work around issues further down in the stack.

Re: The Bosque Programming Language

#103

Post by fxfan » Wed, Apr 17, 2019, 4:44 PM UTC

ahaferburg wrote: post #44

fxfan wrote: post #37

Earlier quoted context omitted.

Hello, no offense but the community here is bikeshedding. I'd suggest you to discuss this at /r/programming

They're bikeshedding there as well. Just filter out any post that contains the word syntax.

Technical discussion is usually still leagues better on reddit than here

Re: The Bosque Programming Language

#104

Post by vnorilo » Wed, Apr 17, 2019, 4:50 PM UTC

awild wrote: post #72

azhenley wrote: post #68

Earlier quoted context omitted.

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…

This is interesting. I "feel" this in Visual Studio, as the DE is more tightly I(ntegrated). Do you still feel like this in the context of a plugin-less plain editor?

Re: The Bosque Programming Language

#105

Post by jsjolen » Wed, Apr 17, 2019, 4:55 PM UTC

>For typed strings, String[T] the compare operator ignores the generic type and is based on the order of the underlying raw string e.g. both arguments are coerced to String.

Why? What even was the point in making them 'typed' then?

Also, what exactly are the relevant language-level details which BOSQUE contributes? It seems more like a large library than anything else.

Re: The Bosque Programming Language

#106

Post by augustk » Wed, Apr 17, 2019, 5:14 PM UTC

pmontra wrote: post #27

A random thought about the code samples. What do we gain from having to write point instead of other languages' point.y = value ? I believe that syntax should be designed to make things simple for developers, not for the designers of languages or for compilers.

"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 unequal footing: The left operand, a variable, is to be made equal to the right operand, an expression. Thus, x = y does not mean the same thing as y = x. Algol corrected this mistake with a simple solution: Let assignment be denoted by :=."

--Niklaus Wirth (Good Ideas,Through the Looking Glass)

Re: The Bosque Programming Language

#107

Post by richardfontana » Wed, Apr 17, 2019, 5:15 PM UTC

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

More accurately, Skitt's Law (which is mentioned in that Wikipedia article).

Re: The Bosque Programming Language

#108

Post by GordonS » Wed, Apr 17, 2019, 5:15 PM UTC

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

Got to say, after reading the description in the linked URL, I was really surprised with just how complex the syntax is in the code samples. I don't want to be overly negative, but it doesn't look like it's going to reduce complexity to me - if anything it looks like one of the most incomprehensible languages I've come across in decades of experience.

Re: The Bosque Programming Language

#109

Post by bfrydl » Wed, Apr 17, 2019, 5:39 PM UTC

The description suggests the syntax and type system are based on TypeScript. After looking through the docs I have to say I wish this were much more true. It seems like Microsoft Research has thrown out half the good ideas TypeScript has in favor of overly noisy, complex syntax.

Re: The Bosque Programming Language

#110

Post by SlowRobotAhead » Wed, Apr 17, 2019, 6:15 PM UTC

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