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

171–178 of 178 posts

Re: The Bosque Programming Language

#171

Post by arc776 »

littlestymaar wrote: post #167
arc776 wrote: post #148

Earlier quoted context omitted.

You're right no dependent types, though to be fair that wasn't the only thing mentioned, and none of the other replies have yet suggested a language with dependent types either. I was responding to: > ...great tooling and moderate performance. There are many aspects to programming languages beyond raw speed. The world has enough cookie cutter procedural and OOP languages. I'd love to see a new language from a differe…

> In terms of languages with existing dependent type implementations, it looks like the main options would be ATS, Agda, F , or Idris. Some of these are pretty far away from the OOP paradigm too. This* is an OK response to the original question. > Seems a bit sudden to jump from my posting a reply to this as the same vein as "rewrite it in Rust". The thing is: 90% of comments talking about Nim comes from people like…

My comment history is 90% talking about Nim because this is the account I talk about Nim on :) Probably it's the same for other people. My last comment was 7 months ago on the 1.0 release.

It seems like when talking about a smaller language you have to walk that fine line between putting an experience of using them out there, and being a PR ambassador. I'm really not into that, but I guess that's the reality.

Re: The Bosque Programming Language

#172

Post by pron »

littlestymaar wrote: post #170
pron wrote: post #169

Earlier quoted context omitted.

Rust has a real existence that's somewhere in the vicinity of that of Elixir, Haskell, Ada, and Delphi. It's definitely alive, but it's not "the one to beat" or a major factor, even in the systems programming space, which is what I was responding to.

Then you misunderstood the comment you were responding, because it claimed Rust was the one to beat in terms of design , never in terms of market share. I someone wanted to release a new functional programming language, it would be totally legitimate to ask how it compare with Haskell, and complain that it's a poor reinvention of standard ML, even if Haskell only has a tiny market share.

Then you misunderstood my comment because what I said was that because of its market share and age, it isn't the one to beat in terms of design, because we have no sensible way to judge how good its design is, even in comparison to other languages. The sample size is just too small, and the experiment too young.

Re: The Bosque Programming Language

#173

Post by traes »

TomMarius wrote: post #165
traes wrote: post #124

Earlier quoted context omitted.

x+y = 0 (with that specific syntax) will error in pretty much every language.

So we will refuse to allow symbols in identifiers after all?

The only programming languages where arithmetic symbols are allowed identifiers have an identifier sigil (ala Perl, PHP), require whitespace around arithmetic (some teaching languages), or don't have conventional arithmetic syntax (e.g. Forth, Lisp).

Re: The Bosque Programming Language

#174

Post by TomMarius »

traes wrote: post #173
TomMarius wrote: post #165

Earlier quoted context omitted.

So we will refuse to allow symbols in identifiers after all?

The only programming languages where arithmetic symbols are allowed identifiers have an identifier sigil (ala Perl, PHP), require whitespace around arithmetic (some teaching languages), or don't have conventional arithmetic syntax (e.g. Forth, Lisp).

Please read the comment I originally answered to.

Re: The Bosque Programming Language

#175

Post by littlestymaar »

pron wrote: post #172
littlestymaar wrote: post #170

Earlier quoted context omitted.

Then you misunderstood the comment you were responding, because it claimed Rust was the one to beat in terms of design , never in terms of market share. I someone wanted to release a new functional programming language, it would be totally legitimate to ask how it compare with Haskell, and complain that it's a poor reinvention of standard ML, even if Haskell only has a tiny market share.

Then you misunderstood my comment because what I said was that because of its market share and age , it isn't the one to beat in terms of design, because we have no sensible way to judge how good its design is, even in comparison to other languages. The sample size is just too small, and the experiment too young.

Yes, that's what you said, and to make your point, you compared Rust to two super new languages that are still mostly developed by a single person and not being used anyware.

Then you rectified yourself, and more accurately compared Rust with Haskell and other languages. At this point you already gave up on your initial argument, because no-one would consider Haskell too small to be a proper benchmark of a new functional programming language.

Of course, as this is an internet argument, you're not going to recognize it. Now, since we are now circling back to the initial claims, I don't think this conversation is worth pursuing. Have a nice (and safe) day.

Re: The Bosque Programming Language

#176

Post by klibertp »

nwienert wrote: post #168
klibertp wrote: post #145

Earlier quoted context omitted.

I actually went through the language doc, which describes the language in more detail (there are still some WIPs and TODOs). I was able to name at least one language which would be considered "prior art" for every one of the features detailed there. A good deal of languages also come close to supporting all of them in one package, and languages that offer most of the features are a dime a dozen. There are a few menti…

This can almost be said for many languages, even the popular ones like Rust which didn’t event most of the things it does. Who cares? It’s all about how they put it all together. Plus some of the IR stuff is interesting. Basque strikes me as a better attempt at a new Typescript than Reason. I really like that they are adding things like check, assert, validate into the language itself. I mean it just looks far better…

> I really like that they are adding things like check, assert, validate into the language itself.

I'm not sure. Contracts are supported in some other languages as a library feature; recent examples I encountered were Elixir, Scala, Clojure, and Haxe; there's also, of course, Racket, but there it's hard to say where the library ends, and language begins... Eiffel, Cobra, Pyret have contracts as a language feature - it may be easier to support it that way instead of first making the language expressive enough and then writing that library.

> What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.

No, out of these only the last one matters: there is no "good" pace (you're either moving too fast or too slow), and there is no "right" way to design a language. The only thing that matters for a language is to gain traction - otherwise, it dies - and that seems to be almost entirely unrelated to the technical features of the language. Luck (e.g., C, Python, PHP) and money (e.g., Java, C#, Go) seem to play a much greater role in making a language successful, along with vendor lock-in (e.g., Objective C, Java, C#).

The lag between an innovative feature conception and its implementation (in the mainstream language(s)) seems to be 10-20 years on average, but it can sometimes take 50+ years while a feature is repeatedly discovered and forgotten in 10-20 years cycle. For example, there are optional static type systems (for otherwise dynamic languages) in languages from the '80s (ie. Common Lisp) and '90s (ie. Dylan), and the more formal gradual typing is IIRC from 2001 (by J. Siek). TypeScript, Flow, Python's mypy, and similar solutions are a mainstream-ish emanation of these ideas - it them took some 15 years to materialize and a few more to appear on the "working programmer" radar. This is a very common pattern: basically, if you want to know how programming will look like in a decade, you can simply look at the experimental features and ideas from 10+ years ago.

Re: The Bosque Programming Language

#177

Post by pron »

littlestymaar wrote: post #175
pron wrote: post #172

Earlier quoted context omitted.

Then you misunderstood my comment because what I said was that because of its market share and age , it isn't the one to beat in terms of design, because we have no sensible way to judge how good its design is, even in comparison to other languages. The sample size is just too small, and the experiment too young.

Yes, that's what you said, and to make your point, you compared Rust to two super new languages that are still mostly developed by a single person and not being used anyware. Then you rectified yourself, and more accurately compared Rust with Haskell and other languages. At this point you already gave up on your initial argument, because no-one would consider Haskell too small to be a proper benchmark of a new functi…

I think most people would think Haskell is too small and that we have enough experience with it to judge the merits of its design.

Re: The Bosque Programming Language

#178

Post by nwienert »

klibertp wrote: post #176
nwienert wrote: post #168

Earlier quoted context omitted.

This can almost be said for many languages, even the popular ones like Rust which didn’t event most of the things it does. Who cares? It’s all about how they put it all together. Plus some of the IR stuff is interesting. Basque strikes me as a better attempt at a new Typescript than Reason. I really like that they are adding things like check, assert, validate into the language itself. I mean it just looks far better…

> I really like that they are adding things like check, assert, validate into the language itself. I'm not sure. Contracts are supported in some other languages as a library feature; recent examples I encountered were Elixir, Scala, Clojure, and Haxe; there's also, of course, Racket, but there it's hard to say where the library ends, and language begins... Eiffel, Cobra, Pyret have contracts as a language feature - i…

So basically I pointed out a novel feature that is great and you refuted it with.. that it exists a library? Well, yea. That’s not really a point.

Having it built into the language is the feature - it means compile time optimization and much better vertical integration for errors, analysis.

Also there is absolutely a good pace, you admitted it! I didn’t say “fast” note, hah.

Finally, yes. I know all the trends, etc. Not sure what your point is, it doesn’t refute anything I said.

Post reply on HN