www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Beeflang - open source performance-oriented compiled programming

reply JN <666total wp.pl> writes:
There's some new programming language around, seems to be 
targeting similar areas as D does, although it doesn't use GC and 
seems to be targeted mostly towards game developers.

https://www.beeflang.org/

Announcement and discussion: 
https://news.ycombinator.com/item?id=21991382
Jan 08
next sibling parent Rumbu <rumbu rumbu.ro> writes:
On Thursday, 9 January 2020 at 07:54:22 UTC, JN wrote:
 There's some new programming language around, seems to be 
 targeting similar areas as D does, although it doesn't use GC 
 and seems to be targeted mostly towards game developers.

 https://www.beeflang.org/

 Announcement and discussion: 
 https://news.ycombinator.com/item?id=21991382
Jan 09
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 9 January 2020 at 07:54:22 UTC, JN wrote:
 There's some new programming language around, seems to be 
 targeting similar areas as D does, although it doesn't use GC 
 and seems to be targeted mostly towards game developers.

 https://www.beeflang.org/

 Announcement and discussion: 
 https://news.ycombinator.com/item?id=21991382
It's look like a very competent language and it is just being released to the public. Things that I like is that it has manual memory management, no GC or stupid life times. However, leaking or double free can be detected. Good direction I think for memory management for what the language is intended for. It has mixins just like D. ... then the weird, it has a PREPROCESSOR that is even less capable than C. That's a very weird design decision.
Jan 09
next sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 9 January 2020 at 11:59:42 UTC, IGotD- wrote:
 ... then the weird, it has a PREPROCESSOR that is even less 
 capable than C. That's a very weird design decision.
There's quite a bit of weirdness in Beef that has been copied conditional compilation. One other feature that seems to be inspired a bit by D is how the scope keyword forces objects to be allocated on stacks. It can also limit their lifetime to named blocks instead of the entire function.
Jan 09
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 9 January 2020 at 12:14:53 UTC, Gregor Mückl wrote:
 On Thursday, 9 January 2020 at 11:59:42 UTC, IGotD- wrote:
 ... then the weird, it has a PREPROCESSOR that is even less 
 capable than C. That's a very weird design decision.
There's quite a bit of weirdness in Beef that has been copied enable conditional compilation. One other feature that seems to be inspired a bit by D is how the scope keyword forces objects to be allocated on stacks. It can also limit their lifetime to named blocks instead of the entire function.
Also `defer { }` is like `scope (exit) { }`. But I doubt the author is inspired by D **at all**. 1. the pre-processor. no trace of any affiliation to D there (`version()`, `static if` etc.) 2. attributes. no trace of any affiliation to D there either ( + introspection using __traits) 3. syntax for template declaration. It does not even propose to fix the big C++ error. D fixes it at least 4. `public` `public` `public` `public` `public` like in JAVA. Any influence of D here would have be to follow the principle of least astonishment. Now there are things I didn't like, i.e 'personally'. 1. sparse documentation. no global EBNF, no doc section for the declaration. 2. the project source tree. hard to find the compiler. it's hidden in IDEHelper ? 3. no linux binaries provided. Because the doc doesn't specify very well the things so I wanted to quick test if out of order declarations are supported, mutually dependent namespaces, aliases, etc. because this is something that tells much if a language is powerful or not. 4. A conservative (CastTo)exp. I think that casts are important enough to make them well distinctguishable like D `cast`. 5. `repeat {} while ()` and `do {}` lacks of orthogonality. `do {} while (false);` could have been used instead, saving `repeat`. This new statement a very few value added but I understand that it's tempting to invent small things like that when creating a language. A few good points however 1. `??` and `?.` operators. D failed to get those. 2. sane `switch` with implicit `break` and explicit `fallthrough`.
Jan 09
next sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 9 January 2020 at 16:58:16 UTC, Basile B. wrote:
   5. `repeat {} while ()` and `do {}` lacks of orthogonality. 
 `do {} while (false);` could
      have been used instead, saving `repeat`. This new 
 statement a very few value added
      but I understand that it's tempting to invent small things 
 like that when creating a
      language.
do {} has a separate meaning in beef. These blocks are not looping, but using break; is valid in them to skip to their end. While this is certainly creative, I don't know if it all that useful. But it burns the "do" keyword in the grammar and something else is required to start a do/while block.
Jan 09
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
 On Thursday, 9 January 2020 at 16:58:16 UTC, Basile B. wrote:
   5. `repeat {} while ()` and `do {}` lacks of orthogonality. 
 `do {} while (false);` could
      have been used instead, saving `repeat`. This new 
 statement a very few value added
      but I understand that it's tempting to invent small 
 things like that when creating a
      language.
do {} has a separate meaning in beef. These blocks are not looping, but using break; is valid in them to skip to their end. While this is certainly creative, I don't know if it all that useful. But it burns the "do" keyword in the grammar and something else is required to start a do/while block.
Yes I understand the difference but by using `while (false)` in D for the looping condition you get the **same semantic** as Beef's `do {}`. Than a small AST rewrite or more simply the backend optimizations get ride very extremely easily of the codegen for the useless looping condition example: https://godbolt.org/z/LgHL_V
Jan 09
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
 [snip]

 do {} has a separate meaning in beef. These blocks are not 
 looping, but using break; is valid in them to skip to their 
 end. While this is certainly creative, I don't know if it all 
 that useful. But it burns the "do" keyword in the grammar and 
 something else is required to start a do/while block.
I think his point is that do {} while(false) is basically a non-looping do statement. So you can use breaks within it like below (adapting the example from beeflang.org). The only difference I can see is that you can return from Beef's do statement. There's probably a way to do that in D, but I haven't thought a lot about it. void main() { int result; do { int c = 2; if (c == 0) break; string op = "+"; if (op != "+") break; int c2 = 3; if (c2 == 0) break; result = c + c2; } while (false); assert(result == 5); }
Jan 09
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
 [snip]
I think I left off some {}, but the point stands.
Jan 09
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
 On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
 [...]
I think his point is that do {} while(false) is basically a non-looping do statement. So you can use breaks within it like below (adapting the example from beeflang.org). The only difference I can see is that you can return from Beef's do statement. There's probably a way to do that in D, but I haven't thought a lot about it. void main() { int result; do { int c = 2; if (c == 0) break; string op = "+"; if (op != "+") break; int c2 = 3; if (c2 == 0) break; result = c + c2; } while (false); assert(result == 5); }
Yes that. Thanks for clarifying my point.
Jan 09
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
 On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
 [snip]

 do {} has a separate meaning in beef. These blocks are not 
 looping, but using break; is valid in them to skip to their 
 end. While this is certainly creative, I don't know if it all 
 that useful. But it burns the "do" keyword in the grammar and 
 something else is required to start a do/while block.
I think his point is that do {} while(false) is basically a non-looping do statement. So you can use breaks within it like below (adapting the example from beeflang.org). The only difference I can see is that you can return from Beef's do statement. There's probably a way to do that in D, but I haven't thought a lot about it. void main() { int result; do { int c = 2; if (c == 0) break; string op = "+"; if (op != "+") break; int c2 = 3; if (c2 == 0) break; result = c + c2; } while (false); assert(result == 5); }
Use goto, then people will know that these breaks are gotos in disguise and the code is more readable (less indentation, no confusion with a loop, no catastrophic nesting where you don't know where the break go to) and is much simpler to modify. void main() { int result; int c = 2; if (c == 0) goto skip; string op = "+"; if (op != "+") goto skip; int c2 = 3; if (c2 == 0) goto skip; result = c + c2; skip: assert(result == 5); } Never use the do {} while(false) construct, it's stupid. Burn it with fire. PS: yes, I'm passionate about that construct; it poisoned our code base because of a colleague who used it all the time. It is a real pain to get rid of it (of course they were not used in a 10 line example, but in 300/400 lines nested behemoths).
Jan 10
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 10 January 2020 at 09:00:53 UTC, Patrick Schluter 
wrote:
 On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
 void main() {
     int result;
     do {
         int c = 2;
         if (c == 0)
             break;
         string op = "+";
         if (op != "+")
             break;
         int c2 = 3;
         if (c2 == 0)
             break;
         result = c + c2;
     } while (false);
     assert(result == 5);
 }
Use goto, then people will know that these breaks are gotos in disguise and the code is more readable (less indentation, no confusion with a loop, no catastrophic nesting where you don't know where the break go to) and is much simpler to modify. void main() { int result; int c = 2; if (c == 0) goto skip; string op = "+"; if (op != "+") goto skip; int c2 = 3; if (c2 == 0) goto skip; result = c + c2; skip: assert(result == 5); }
or don't do too many things at-once: void main() { auto result() { int c = 2; if (c == 0) return c; string op = "+"; if (op != "+") return c; int c2 = 3; if (c2 == 0) return c; return c + c2; } assert(result == 5); }
Jan 10
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 10 January 2020 at 09:33:01 UTC, Sebastiaan Koppe 
wrote:
 On Friday, 10 January 2020 at 09:00:53 UTC, Patrick Schluter 
 wrote:
 On Thursday, 9 January 2020 at 17:41:31 UTC, jmh530 wrote:
 void main() {
     int result;
     do {
         int c = 2;
         if (c == 0)
             break;
         string op = "+";
         if (op != "+")
             break;
         int c2 = 3;
         if (c2 == 0)
             break;
         result = c + c2;
     } while (false);
     assert(result == 5);
 }
Use goto, then people will know that these breaks are gotos in disguise and the code is more readable (less indentation, no confusion with a loop, no catastrophic nesting where you don't know where the break go to) and is much simpler to modify. void main() { int result; int c = 2; if (c == 0) goto skip; string op = "+"; if (op != "+") goto skip; int c2 = 3; if (c2 == 0) goto skip; result = c + c2; skip: assert(result == 5); }
or don't do too many things at-once: void main() { auto result() { int c = 2; if (c == 0) return c; string op = "+"; if (op != "+") return c; int c2 = 3; if (c2 == 0) return c; return c + c2; } assert(result == 5); }
Yes. You can also consolidate void main() { int result; int c = 2; string op = "+"; int c2 = 3; if (c != 0 && op == "+" && c2 != 0) result = c + c2; assert(result == 5); } etc. but that was not the point of my rant. It was strictly about the "non-looping loop goto obfuscation" construct.
Jan 10
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 9 January 2020 at 17:19:38 UTC, Gregor Mückl wrote:
 On Thursday, 9 January 2020 at 16:58:16 UTC, Basile B. wrote:
   5. `repeat {} while ()` and `do {}` lacks of orthogonality. 
 `do {} while (false);` could
      have been used instead, saving `repeat`. This new 
 statement a very few value added
      but I understand that it's tempting to invent small 
 things like that when creating a
      language.
do {} has a separate meaning in beef. These blocks are not looping, but using break; is valid in them to skip to their end. While this is certainly creative, I don't know if it all that useful. But it burns the "do" keyword in the grammar and something else is required to start a do/while block.
What? They put that asinine "do {break; } while(0)" non-looping loop C idiom in the language as a 1st order construct? That language is therefore officially deadbeef for me. I hate that construct with a passion (I had to work on too much code using that). It is an obfuscated goto for people who want to use gotos but are not man enough to actually use goto. It is worse that a real goto, as with a real goto you have a label at the destination.
Jan 10
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jan 09, 2020 at 04:58:16PM +0000, Basile B. via Digitalmars-d wrote:
[...]
 A few good points however
 
   1. `??` and `?.` operators. D failed to get those.
Wasn't there a proposal for the "Elvis operator" a while back? Did nobody follow up on it with an actual DIP? I would support this. It's a pretty useful thing to have to not have to continually check for null-ness in a long chain of dots. A library solution is *possible* but ugly and has corner cases that are not easily handled.
   2. sane `switch` with implicit `break` and explicit `fallthrough`.
Yeah, I agree `fallthrough` is a much better construct that implicit fallthrough with mandatory repetitive `break`s. I doubt this is possible to change in D at this point, though. Unless people get onboard with D3. But so far the official stance appears to be that D3 will never happen. Also, did you know D's switch statement has allow insane syntax, like Duff's device (and many -- far more horrible -- things)? I'd love to get rid of that, as it needlessly obfuscates code, and any optimizing compiler worth its salt ought to be able to emit that sort of code automatically without needing the programmer to explicitly write it that way. T -- Fact is stranger than fiction.
Jan 09
parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 9 January 2020 at 18:51:18 UTC, H. S. Teoh wrote:
 On Thu, Jan 09, 2020 at 04:58:16PM +0000, Basile B. via 
 Digitalmars-d wrote: [...]
 A few good points however
 
   1. `??` and `?.` operators. D failed to get those.
Wasn't there a proposal for the "Elvis operator" a while back? Did nobody follow up on it with an actual DIP? I would support this. It's a pretty useful thing to have to not have to continually check for null-ness in a long chain of dots. A library solution is *possible* but ugly and has corner cases that are not easily handled.
Yes there was an attempt by Razvan7 [1] and following a big discussion on the NG. The attempt did not succeed because the implementation was, according to Walter, naive in the sense that there were cases where I don't remember what was doubly evaluated, leading to possible side-effects. The attempt was for the Elvis so "?:" and not "??" (which makes less sense in D because of implicit bool eval of class instance, array, etc.). [1] https://github.com/dlang/dmd/pull/7242
Jan 09
prev sibling parent Rumbu <rumbu rumbu.ro> writes:
On Thursday, 9 January 2020 at 11:59:42 UTC, IGotD- wrote:
 On Thursday, 9 January 2020 at 07:54:22 UTC, JN wrote:
 There's some new programming language around, seems to be 
 targeting similar areas as D does, although it doesn't use GC 
 and seems to be targeted mostly towards game developers.

 https://www.beeflang.org/

 Announcement and discussion: 
 https://news.ycombinator.com/item?id=21991382
It's look like a very competent language and it is just being released to the public. Things that I like is that it has manual memory management, no GC or stupid life times. However, leaking or double free can be detected. Good direction I think for memory management for what the language is intended for. It has mixins just like D. ... then the weird, it has a PREPROCESSOR that is even less capable than C. That's a very weird design decision.
Well, this sums up everything, including the preprocessing which concurrent GC. This predated Unity's IL2CPP by about 6 months. Compile times were a big issue, and the little edges of the language and libraries were problematic since they were built around a JIT. Then it struck me that I don't really care about that was statically compiled and without a GC. I just followed along all the obvious next steps from there, and here we are 5 years later."
Jan 09
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 07:54:22 UTC, JN wrote:
 There's some new programming language around, seems to be 
 targeting similar areas as D does, although it doesn't use GC 
 and seems to be targeted mostly towards game developers.

 https://www.beeflang.org/

 Announcement and discussion: 
 https://news.ycombinator.com/item?id=21991382
Thanks for sharing. The language itself looks pretty standard, but it claims to provide two features that could be a selling point for interactive applications: good C++ interop and hot patching. If they deliver on that, then they could be in a good positition.
Jan 09
parent reply JN <666total wp.pl> writes:
On Thursday, 9 January 2020 at 13:39:21 UTC, Ola Fosheim Grøstad 
wrote:
 Thanks for sharing. The language itself looks pretty standard, 
 but it claims to provide two features that could be a selling 
 point for interactive applications:  good C++ interop and hot 
 patching. If they deliver on that, then they could be in a good 
 positition.
Personally the things that I like about it is how clean it looks and how IDE support is taken into account when designing it.
Jan 09
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 9 January 2020 at 18:01:10 UTC, JN wrote:
 Personally the things that I like about it is how clean it 
 looks and how IDE support is taken into account when designing 
 it.
Designing with IDE support in mind from the start is the right approach today, absolutely right. Could give them a faster pick up. The syntax does not win me over, e.g. using "[attribute]" for disabling bounds checking is going to be confusing: «int val = arr[[Unchecked]i];» But ultimately its success will depend on delivering solutions that other languages don't provide. If hot patching works out ok then they could create their own than Dart, and appeal to a wider audience (could work for both portable mobile Games and Apps, and that would be... significant).
Jan 09
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 9 January 2020 at 19:55:40 UTC, Ola Fosheim Grøstad 
wrote:
 On Thursday, 9 January 2020 at 18:01:10 UTC, JN wrote:
 Personally the things that I like about it is how clean it 
 looks and how IDE support is taken into account when designing 
 it.
Designing with IDE support in mind from the start is the right approach today, absolutely right. Could give them a faster pick up.
Not only today, since Turbo Pascal for MS-DOS, the languages that have been designed with IDE support in mind, are the ones that ended up getting a long term place on my toolbox. All others, I used to learn about new programming paradigms and approaches to solving problems, but at the end of the day IDE workflows and graphical tooling were too important to give away. I find quite interesting, that although James Gosling was responsible for XEmacs, he is also on the IDE camp.
Jan 10
parent Chris Katko <ckatko gmail.com> writes:
There is zero chance I'd use a language younger than 10 years old 
for a game.

  - No toolchain
  - No bugs discovered by an active community
  - No community, tutorials
  - No 3rd party libraries
  - No proof-by-fire that the language doesn't have a huge, 
project breaking "gotcha" that will only be noticed by a really 
smart programmer
  - NO PROOF that the language developer will even be around in a 
few years.

Dlang is at the cusp of the minimum I'd consider any viable game. 
Unless by "game" you mean like, a 1-3 month dev cycle that you 
don't support for years later and just throw on the Steam store 
and forget about.
Jan 11
prev sibling parent Rumbu <rumbu rumbu.ro> writes:
I find very interesting the approach used to implement struct 
interfaces without any boxing. Very clean and nice.

struct Circle : IDrawable
{ void Draw() {}  }

/* Calling the following method with an instance of Circle will 
first cause boxing to occur at the
  callsite, then Draw will be called via dyanmic dispatch (method 
table) */
public static void DrawDynamic(IDrawable val)
{
     val.Draw();
}

/* Calling the following method with an instance of Circle will 
create a specialized instance of
the DrawGeneric method which accepts a Circle argument and 
statically calls the Circle.Draw
  method, which is faster */
public static void DrawGeneric<T>(T val) where T : IDrawable
{
     val.Draw();
}
Jan 09