beefytech / Beef

Beef Programming Language
http://www.beeflang.org
Other
2.47k stars 127 forks source link

Quick Review #188

Closed MahmoudFayed closed 4 years ago

MahmoudFayed commented 4 years ago

I tested the Beef programming language during the last 2 days

(1) Domain : System programming language (Support low-level programming and writing high performance code) + focus on (Game Development) (2) Syntax : Similar to C# (3) Typing : Static-Typing (4) Memory Management : No Garbage Collector (5) Tools : Includes (Compiler + Standard Library + IDE + LibSDL extension + SpaceGame) (6) Developer : Brian Fiete (One of the PopCap founders!) (7) Development Time : Many Years (I see some source code files from 2013)

I tried to find innovative features or new programming paradigm, but these things doesn't exist, so it's not a research project that attracts computer scientists, but looking at the (Quality of the software and the obvious hard work and the developer experience) - it's a pragmatic programming language designed based on experience - a language like this (could get success quickly because it's familiar and solve a practical need, but in most cases it doesn't continue, or at least doesn't influence other programming languages)

The features let me remember two things The first thing { Crystal programming language = Ruby syntax + C/C++ performance (as a goal) Nim programming language = Python syntax + C/C++ performance (as a goal) Beef programming language = C# syntax + C/C++ performance (as a goal) }

The second thing { Other programming languages that are trying to fill the same gap i.e. (Replacing C/C++ with modern language) or (Providing a new language for Game Engine development). The list is very long : D, Rust, Nim, Zig, Odin, Jai, V, etc }

The problem with most of these new languages are (1) Little innovation (Except Rust) (2) C/C++ are not one language, they are two languages, if we want something small and simple, we can use C, and if we want something with many features and very powerful, we can use C++, designing a new programming language that are not very innovative, will not encourage large adoption! - the D programming language is an example - so why many programming languages are trying to repeat the D story! in another way.

Back to the Beef programming language

(1) GREAT WORK - I respect the quality of the product (2) I know that you developed an IDE for productivity - but here you have some problems

(3) Think more about the innovation in the language, Maybe Beef looks better than Zig, Odin, V, Jai, etc but this is not enough to attract mainstream programmers from C/C++ world (4) Provide code generator and more easy way for writing extensions for C/C++ libraries (5) A package manager to quickly install & update the programming language itself and the libraries is more important than the IDE - because the Package Manager solve a clear problem in C/C++ world. (6) Focus on attracting contributors not users, You need a team to help you, not users who consumes your time, sure you will need them in Testing, but valuable contributors are important at this stage.

My final words

(1) I like the Beef programming language as a start towards a GREAT programming language in the future (2) It's not a critics, it's just how I see Beef today, and I think it can be much better in the next future

Keep up the GREAT WORK

bfiete commented 4 years ago

Thanks for this thoughtful review, Mahmoud.

MahmoudFayed commented 4 years ago

You are welcome

HydrogenC commented 4 years ago

I think an IDE is necessary. Lack of a easy-to-use ide is the main reason why Pony, Odin, V and Zig haven't become popular. They only provide VSCode extensions but they requires downloading and configuring after installed and they doesn't have a perfect support of debugging.

HydrogenC commented 4 years ago

Actually, I've used D before I got to know Beef and I feel that the main reason why it failed is as followed:

  1. Introducing a gabage collector (although I can disable the gc by marking a function as @nogc, but the whole stdlib is build on the gc, so I cannot access the stdlib within a @nogc func)
  2. Breaking changes from D1 to D2 in both the language and the standard library (Tango is the stdlib for D1, and Phobos is the stdlib for D2. Now that D1 has been discontinued for 10 years, and D2 is recommend to use, still some people use Tango as the stdlib since it doesn't depend on gc)
  3. Introducing some strange syntaxes that a programmer of C++ or C# are hard to adapt to (such as concating strings with ~, providing template types with !)
  4. Lack of a good ide and debugger. (After 10 years of development, Visual D is still immature and not as easy-to-use and powerful as the Beef IDE, while other IDEs of Dlang are even worse)
Aidiakapi commented 4 years ago

Lack of a easy-to-use ide is the main reason why ...

I wouldn't say so, an extension for existing editors/IDEs ((VSCode, IntelliJ, and the likes) is much more useful in my opinion, since that way people don't have to relearn a new and less feature rich/customizable IDE. While the examples you mentioned are very bare bones, that has more to do with how much work has been put into those. If the same amount of effort that went into Beef's IDE was put into an extension for another editor, it'd have syntax highlighting, completion, building, and debugging.

HydrogenC commented 4 years ago

I wouldn't say so, an extension for existing editors/IDEs ((VSCode, IntelliJ, and the likes) is much more useful in my opinion, since that way people don't have to relearn a new and less feature rich/customizable IDE. While the examples you mentioned are very bare bones, that has more to do with how much work has been put into those. If the same amount of effort that went into Beef's IDE was put into an extension for another editor, it'd have syntax highlighting, completion, building, and debugging.

I agree with you to some extent. But what is undeniable, a text editor would never be more powerful than the Visual Studio IDE, especially in project management, though VS is often critisized for its large size. The beef ide is an attempt to a VS-like full featured ide suitable for large projects (as it aims at game development, which are often large projects). On the other hand, the ide is built on the Beefy2D library and can be the snowcase of the library itself as well as a good example of it.

sukhchain99 commented 4 years ago

@MahmoudFayed I don't know what is wrong with you, but you sound like a 10 year old.

1st) You said stuff like "Think more about the innovation in the language, Maybe Beef looks better than Zig, Odin, V, Jai, etc but this is not enough to attract mainstream programmers from C/C++ world", like don't you know why this project has so much activity now? It's because GameFromScratch featured BeefLang in his video and that's why we all came here to try it out, many of those Users even started contributing, so you are wrong kiddo.

2nd) You said "Provide code generator and more easy way for writing extensions for C/C++ libraries", it's called wrapper generator and it should only be made after a language has hit version 1.0, which Beef hasn't yet.

3rd) You said "A package manager to quickly install & update the programming language itself and the libraries is more important than the IDE - because the Package Manager solve a clear problem in C/C++ world.", And that's delusional! Nobody is dying here for a package manager, it would be a nice to have but what's the point of it if the language itself isn't stable yet? A package manager is something I can make in a week using already available template code, not a big deal. As for the libraries, it can automated after the implementation of wrapper generator.

4th) Why did you say "Focus on attracting contributors not users, You need a team to help you, not users who consumes your time, sure you will need them in Testing, but valuable contributors are important at this stage.", What is wrong with you?

Edit: Sorry man. I saw that you are an experienced developer after looking at your profile and I also noticed that you have made a language and you are speaking from experience, but your programming language experience is different from BeefLang's objective. It's a game oriented language and your language is general purpose. There are already many general purpose programming languages out there who have gained success already, there's no point in competing in that domain, whereas Game Engine developers are still trying out stuff to find the one which is specifically made for game development. Like Unity has it's own version of C# and Godot made GDScript because no other language fulfilled their needs. BeefLang has potential and opportunity both and it will succeed when more game developers will start using it in their projects.

HydrogenC commented 4 years ago

(1) Little innovation (Except Rust)

In my opinion, your ring-lang is quite good in syntax, at least better than lua. But since lua is very well-known, it is difficult for any language to take its place. From your words I can know that you like innovations, just like how you designed ring-lang. But I think that having too much innovation may make the language hard to learn (especially for a small language without a strong background). On the contrary, being similar with another popular language in syntax is a good choice. Just like beef, I don't even have to learn it before writing it since I know C# well. People won't spend too much time learning and experimenting a small language, so being similar in syntax is more attractive. Also, the primary reason why Rust could become popular is its background (Mozilla) not its innovations.

Skrylar commented 4 years ago

Re: innovation. I don't really buy in to the innovation meme personally. No practical language "innovates." They just codify things people are doing more painfully by hand. The ones paid to do so do it much faster (Delphi, C#) and the amoprhous committees make everyone wait decades for things everyone else has been doing for years (C++.) Accusing a language of not innovating enough is practically always actually "it doesn't have a big enough name behind it to get over my sunk cost / social proof hurdle."

Re: extensions. Really all you need is an autocomplete server. Now that LSP exists it might be worth things standardizing on that. Nim and Haxe have autocomplete servers, and there are a lot of user made extensions to bolt those in to people's favorite editors.

Re: D. I was an early D1 user. Tango was not the stdlib, phobos was. Tango was part of the community death; it was developed in semi-secret and only made available to a special "inside crowd." Between that and D2's train wreck decision making (they literally screwed with GC-less mode because Phobos was coded poorly, and instead of fixing the bad code they just decided turning the GC off was bad.) In short, they shined brightly until they decided to shit the bed.

No idea if Beef's HCR works. V's doesn't on Windows. Nim's does. Most of those other languages don't have it at all.

Re: Jai. "Jai compiler - not released yet." Vapor for a decade. Why is it even in a comparison?

My takeaway is that Beef the language succeeds at being the C# clone it was evidently meant to be. Were I still a C#'er i would be excited to jump ship. Might even give people who were considering Haxe some pause in the future (Haxe's native code route is... circuitous at best. HaxeCPP is awfully slow to build. Hashlink is much faster and JIT tax is only for debugging. Hot reloads only work via a Javascript target and some machinery with Kha+an MS javascript runtime though.)

I don't think the toolchain was ready for the spotlight. It was sandwiched between Corona SDK and the Shiro stack which were both quite production ready. I don't think Beef is just yet. Could be close?

Skrylar commented 4 years ago

In my opinion, your ring-lang is quite good in syntax, at least better than lua. But since lua is very well-known, it is difficult for any language to take its place. Lua ticks many boxes that almost nobody else does. It's tiny, liberally licensed, easy to bind, is well documented, modular, and very importantly easy to sandbox memory usage and via debug interfaces prevent infinite loops.

AngelScript and MRuby are the closest I can think of that tick those boxes too. Experimenting with Janet right now and its close but still has some edges. I'm not sure they have the same level of safeties though. Most of the non-Luas aren't quite so simple as "set debug handler, count ticks" or "set custom malloc, reject anything too big."

I've seen and read Ring get rejections because in order to build it you have to install a completely unrelated Windows-only program he wrote for block-based programming, in order to emit C files, and then ultimately you use the C files, but people get easily confused about all this.

Also, the primary reason why Rust could become popular is its background (Mozilla) not its innovations.

Agreed. People care too much about names. You don't hear people screech Go isn't "innovative" because they see "Google" and immediately their social proof hamster wheels stop in their tracks.

Rust is actually miserable to use IMHO. It has macros but they are semi-crippled. Anything to do with floating point numbers is extremely verbose and full of boxing/unboxing/having to add special generic markers and figure out which flags have to be set. And upstream says floats being obnoxious is "not a bug." Compile times are dog slow. When I installed gtk-rs and found out a simple window with a label on it took 15-30 seconds to build even incrementally I slammed the hard nope.

HydrogenC commented 4 years ago

Rust is actually miserable to use IMHO. It has macros but they are semi-crippled. Anything to do with floating point numbers is extremely verbose and full of boxing/unboxing/having to add special generic markers and figure out which flags have to be set. And upstream says floats being obnoxious is "not a bug." Compile times are dog slow. When I installed gtk-rs and found out a simple window with a label on it took 15-30 seconds to build even incrementally I slammed the hard nope.

Yep, I've tried Rust for a while, but found that they are not considering to add the thing I really want. I have been following rfcs#349 for long but there aren't any progress on it. Its type-system is quite broken with inheriting struct members and upcasting impossible. It is more like C rather than C++. C++ will never die out as long as large companies like Microsoft, Apple, IBM, Google and EA supports it, and Rust would have little chance to become popular without Mozilla. For a language without a strong background, having too much "innovations" is actually risky. By the way, I am personally confident of Beef.

kevspa commented 2 years ago

Actually, I've used D before I got to know Beef and I feel that the main reason why it failed is as followed:

  1. Introducing a gabage collector (although I can disable the gc by marking a function as @nogc, but the whole stdlib is build on the gc, so I cannot access the stdlib within a @nogc func)
  2. Breaking changes from D1 to D2 in both the language and the standard library (Tango is the stdlib for D1, and Phobos is the stdlib for D2. Now that D1 has been discontinued for 10 years, and D2 is recommend to use, still some people use Tango as the stdlib since it doesn't depend on gc)
  3. Introducing some strange syntaxes that a programmer of C++ or C# are hard to adapt to (such as concating strings with ~, providing template types with !)
  4. Lack of a good ide and debugger. (After 10 years of development, Visual D is still immature and not as easy-to-use and powerful as the Beef IDE, while other IDEs of Dlang are even worse)

You can use the betterC compiler switch to completely disable the gc, and while I agree with 2. (somewhat) and 3., D has good support for some popular text editors/IDEs such as Visual Studio Code and Atom. Also I don't know about at the time of your comment, but Visual D is extremely stable now. D is overrall a good language that provides all of the good of c++(and more) along with pretty much none of the bad.