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