Announcement

Collapse
No announcement yet.

Leaf: A New "Soon To Be Great" Programming Language

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by TheBuzzSaw View Post
    I would kill for a language that is native (compiled) but as expressive and modern as C# or Lua. Is Leaf that language? It uses LLVM, so that's a big first step. Sadly, the syntax is awful, and I don't feel any amount freedom granted from all the highly expressive new features.

    In my opinion, there is a strong demand for a language between C++ and Java. C++ has too many technical aspects that make it unproductive, and Java requires a VM (and has awful memory management). This mythological third language could drop all the legacy baggage of both languages, keep C++'s native/compiled benefits, and incorporate expressive syntax improvements from Java, Python, C#, etc.

    On a side note, if someone could please write a non-Ruby language to blow PHP out of the water, that'd be fantastic.
    On what planet is C# modern? C# is basically the same as Java and is loaded with legacy hacks. Scala, Haskell, and Microsoft's F# are far better. You haven't used any of those. Ruby is even better than C#.

    The JVM is fine for server work or Win/Mac/Linux desktop apps. It's not ok for iOS or many other domains. Rust looks promising for a good non-VM language.

    Comment


    • #42
      Originally posted by DanLamb View Post
      On what planet is C# modern? C# is basically the same as Java and is loaded with legacy hacks. Scala, Haskell, and Microsoft's F# are far better. You haven't used any of those. Ruby is even better than C#.
      Those all look like a whole lot of the same thing... Same ideas, new syntax. Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?

      The JVM is fine for server work or Win/Mac/Linux desktop apps. It's not ok for iOS or many other domains. Rust looks promising for a good non-VM language.
      It works fine on crappy Android hardware, so why not iOS? If memory serves me correctly, Java was originally developed for embedded devices.

      Comment


      • #43
        Originally posted by nslay View Post
        Those all look like a whole lot of the same thing... Same ideas, new syntax. Can you provide examples of legacy hacks and how Scala, Haskell and F# are actually better than languages like C# or Java?
        Java has this horrific convention of writing getters/setters everywhere because you can't change a variable to a function without breaking source + binary compatability.

        C# automates this with properties, but in some ways it's even worse. There is no reason C# should have both mostly redundant language constructs of variables/fields and properties. You can have a local variable, but not a local property. You can have an instance variable, but generally you can always replace it with an instance property. "readonly" works on instance/class fields, but not properties and not local variables, and it's different from const. If you want a read only property, that uses a completely separate syntax. Props can be overridden, variables can not. The "var" type inference mechanism works with local variables, but not instance variables or class variables or properties or function return values. What a complete chaotic mess!!

        Scala has var (read/write) and val (read only) and that's it. Whether you use them as local var/vals, instance var/vals, or singleton var/vals, they work the same and use the same syntax and don't need a myriad of weird rules and legacy syntaxes and keywords. Type inference works in all cases and also works similarly with function return types.

        null. Scala/F# support null for Java/C# interop, but native Scala/F# otherwise doesn't use null at all. Option is a much better solution than null. C#'s nullable types are a much weaker partial solution, which is why Microsoft's newer F# uses Option.

        Arrays. C#/Java both started with arrays and added generics as a separate system later. Arrays should use the generics syntax. And they should use the same casting rules. Scala does, Java/C# do not. Java/C# have arrays that can downcast (covariance) which is a mistake that they can't fix for legacy reasons as you can write code that compiles but fails at runtime.

        I mentioned LINQ. Scala does all the in-memory stuff that LINQ does in the core language where C# has this separate disjoint syntax bolted on.

        Ternary operator. C/Java/C#/JavaScript use the ternary operator, because they don't have "if" expressions that return a value like Ruby, Scala, or most other modern languages. The ternary operator also doesn't extend cleanly to multiple else if conditions or multi-line expressions like an "if" expression.

        Partial functions. C had switch/case statements which was carried over into JavaScript/C#/Java. This is similar to a mathematical partial function (a function defined for only some range of inputs like a logarithm function). Scala basically replaces the C-era switch/case with native partial function support.

        Native support for tuples is extremely useful.

        Native support for pattern matching is huge. This dove tails with Option btw.

        Native support for currying. You can approximate it with C#/Java, but it's nice to have native support.

        Look at Scala's parser combinator library for an example of some useful, practical code that really showcases the conciseness and elegance of Scala in a way that would be far more bulky in Java/C#.

        Comment


        • #44
          Originally posted by XorEaxEax View Post
          I'm not spending much time on IRC these days but I have popped into the channel on a couple of occasions, I was kind of surprised as the first time I entered the channel there were like 9 people there including araq, next time I went there which was like 3 weeks later or so there were 49 people in the channel, so it seems like it's attracting attention as you said.
          Our current IRC-users record is still only 59 though (last i heard). You're always welcome to stop by again and help us hit 60!


          I took a quick glance at your game engine proposal and it looks interesting, are you basing it after an existing engine api or are are you coming up with the implementation from scratch?
          I'm glad you're interested. I grew up coding, and OpenGL/DirectX code in particular. As did my brother, the author of this C# gaming toolkit (which we used to create this iOS/Android game.. which unfortunately never made it off the ground, but not due to any technical reason). At the moment, I use Unity3D professionally (and co-made this game with it in the past, independently).

          The code for my engine, Hymn, is being written from scratch. However my brother's code-base and my experience with Unity3D will way in heavily on some design elements. There are many great things about Unity, but also a few gotchas there I like to think I have better designs for :-)


          From what (little) I've seen of 'general purpose' game engines the big design problem seems to be how much work you leave to the game programmer and how much is 'automated' by the engine, basically flexibility versus ease of use.
          It's great you bring this up. You're right, sometimes things like 2D games are difficult to do well in existing 3D oriented game-engines, but i would argue that's it's easily fixed with proper modularity and templates. It's not illustrated in the diagram, but my design is to use 'part's to construct the entire scene graph, including the core event sequence. The the game's whole runtime will be customizable and subject to editor defined modes (see diagram). So you could construct your scene to use both a 3D canvas part and a 2D one, and you simply control the ordering in which they update themselves & their subjective "children". Beyond that, the editor will provide meaningful templates as starting points for scenes, projects, and prefabs.

          One key benefits of using Nimrod here, is it gives me the ability to construct and filter the part's code in a sane way (no mixins or parsers required). In the diagram you'll notice I illustrate injecting editor defined behavior into specific ares of the code, and code for the same procedure in different modes. When talking about doing that, there are two things too consider. a) editors need dynamic things, and b) release builds need to be fast. Because 'part' (in the code) is just my macro, I can control exactly what sort of code gets created under different build conditions. So i can build for things to be very dynamic for editing, and then turn around and make them very efficient for release (and getting really crazy I can even write my own tune-up macros which optimize out common script-kiddy mistakes). I've tried to design this in both C# and D before, but I never found a solution as elegant as what I've discovered Nimrod can do (not mention Nimrod does very well in benchmarks).


          Judging by your rough draft I assume the engine will automatically handle things like collision by using the data in the 'Space' structure, I found it odd that you directly handled the space.position updating rather than adding a velocity variable to the Space struct and have the game engine handle the actual updating of the position based upon that value (while taking delta time into consideration I guess), that said game programming is not my field of expertize at all so I'm probably talking nonsense. Feel free to disregard me.
          I see you know a bit about games logic The code in the diagram is only reference (especially in the early mockup) and designed more to illustrate core concepts than to actually function (though real code could look very similar to that in the first slide). The code in the early mockup is mostly me going a bit overboard after discovering what macros could do, lol. It was also made in roughly and hour, and I forgot to spellcheck...

          Also, 'Space' is somewhat equivalent to Unity's 'Transform'. I'm just calling it 'Space' experimentally. Physics objects (which may be derived of Space) will be separately available as replacements or counterparts to Space. I have a lot of ideas here, but also a lot of unanswered questions left to investigate. For now, i'm focusing on building the core code-base.

          Comment


          • #45
            Originally posted by DanLamb View Post
            Native support for tuples is extremely useful.
            C# 4.0 added a tuple class to the standard library, but it's much more verbose and clunky to use than languages with native tuples like Scala. Also, C# has "out" parameters which are mostly a substitute for having real tuples. It's nice to not need superfluous langauge features like "out" variables and just have native tuple support.

            Comment


            • #46
              Originally posted by TheBuzzSaw View Post
              Java requires a VM
              Firstly, as a personal note, I must say I don't share the opinion on C++. However, it's a matter of taste, I guess.
              Secondly, I always assumed GJC compiled to native binaries (I'm not a Java programmer, so I didn't check, it just sounded right to me), isn't it that way?

              Comment


              • #47
                Originally posted by mrugiero View Post
                Secondly, I always assumed GJC compiled to native binaries (I'm not a Java programmer, so I didn't check, it just sounded right to me), isn't it that way?
                GCJ can compile Java directly to native binaries, but after the official JDK became completely GNU open source, there was no point, and the project became obsolete.

                IMO, there is no practical difference between native binaries vs some intermediary format with an embeddable VM.

                On Windows/Mac/Linux, embedding the JVM on a medium to large app is fine, but for iOS or embedded, the JVM isn't conveniently embeddable. People have done it but it's usually more headache than it's worth. Oracle has plans to fix this but who knows when that will happen.

                A second problem is that Java is purposefully designed to restrict interop with non-JVM code. There is JNI which people use to access OpenGL for example, but it's not ideal. The benefit is it insulates devs from some of the low level complexity assocaited with low level code, but it can be limiting if you really want to use a non-Java library.

                A third issue is some desirable features like array bounds checking have a small performance cost. Overall, Java's runtime performance is pretty good and the tradeoff vs C is quite reasonable.

                A final issue is the Java VM has memory overhead. For medium to large apps or server apps, the VM overhead is insignificant, but if you write a tiny process and want a micro foot print, Java isn't a good choice.

                Comment


                • #48
                  Originally posted by DanLamb View Post
                  (...) IMO, there is no practical difference between native binaries vs some intermediary format with an embeddable VM.

                  On Windows/Mac/Linux, embedding the JVM on a medium to large app is fine, but for iOS or embedded, the JVM isn't conveniently embeddable. People have done it but it's usually more headache than it's worth. Oracle has plans to fix this but who knows when that will happen.

                  A second problem is that Java is purposefully designed to restrict interop with non-JVM code. There is JNI which people use to access OpenGL for example, but it's not ideal. The benefit is it insulates devs from some of the low level complexity assocaited with low level code, but it can be limiting if you really want to use a non-Java library.

                  A third issue is some desirable features like array bounds checking have a small performance cost. Overall, Java's runtime performance is pretty good and the tradeoff vs C is quite reasonable.

                  A final issue is the Java VM has memory overhead. For medium to large apps or server apps, the VM overhead is insignificant, but if you write a tiny process and want a micro foot print, Java isn't a good choice.
                  There are practical differences, but I can say you made two statements which I can say are not necessarily true:
                  - bounds checking is very small overhead (because CPUs have branch prediction and the "uncommon trap" does not happen as common case). This is slower (like 1%) but Java in the same time have some live optimizations like Class Hierarchy Analysis so it only has some different runtime profile. Bounds checking can and are removed by the JVM, so this is even less of an issue
                  - the issue of VM is that: there is no practical difference between native binaries vs some intermediary format with an embeddable VM. In practice there is a practical difference: an offline compiler can do many more optimizations and it can spend a lot of time looking for a code pattern that can optimize for. An online compiler does have tradeoff optimizations, making use of the most effective/common. This is even more visible on the low end devices and phones. Compilation analyses take memory and CPU time in themselves. Combined with the fourth point (that GC programs tend to use more memory) make your last statement true: a VM based application will use more memory which this is why "Java isn't a good choice" for a "tiny process and want a micro foot print".

                  Did you try JNA? Is decently easy to work with and you can run (not as fast but is it fast enough) external libraries.

                  Comment


                  • #49
                    Originally posted by sarmad View Post
                    Lots of mockery; lots of discouragement; are there any ethics left on the internet? Wow
                    So skepticism and criticism are unethical these days, seriously? If you can't take some criticism (whether well deserved or not) you'll never get very far.

                    Sure, some stuff on here could be worded better, or less harshly. But seriously, you've got a developer we've never even heard about, who claims to be the future creator of the go-to language and also claims to have (or build on) more than 50 years of experience? I think some skepticism is warranted.

                    The website has a few nice words on how they're not afraid to change stuff, how they're challenging everything, while being better than anyone else. The typical marketing spiel of anyone trying to sell their wares. But aside from this, there's very little hard proof that demonstrates just how this language solves typical real-world problems better than existing languages.

                    In fact, I'd say syntax is usually the lowest barrier in most scenarios. Yes, writing "var a= [1, 2, 3]" is a bit faster then writing, say "var a = new List<int>(){ 1, 2, 3 };".

                    But if you really want to impress me, give me a language that allows me to write trivial (non blocking) networking and I/O calls, with native support for multi-threading and easy-as-pie IPC. While still being easy to read and maintain.

                    The reason why languages like Java and C# became successful very quickly (aside from having a corporate sponsor) is all of the tooling available. Good compilers, good IDEs and even more important, a huge library of ready-to-use code.

                    Comment


                    • #50
                      Originally posted by Wildfire View Post
                      So skepticism and criticism are unethical these days, seriously? If you can't take some criticism (whether well deserved or not) you'll never get very far.

                      Sure, some stuff on here could be worded better, or less harshly. But seriously, you've got a developer we've never even heard about, who claims to be the future creator of the go-to language and also claims to have (or build on) more than 50 years of experience? I think some skepticism is warranted.

                      The website has a few nice words on how they're not afraid to change stuff, how they're challenging everything, while being better than anyone else. The typical marketing spiel of anyone trying to sell their wares. But aside from this, there's very little hard proof that demonstrates just how this language solves typical real-world problems better than existing languages.

                      In fact, I'd say syntax is usually the lowest barrier in most scenarios. Yes, writing "var a= [1, 2, 3]" is a bit faster then writing, say "var a = new List<int>(){ 1, 2, 3 };".

                      But if you really want to impress me, give me a language that allows me to write trivial (non blocking) networking and I/O calls, with native support for multi-threading and easy-as-pie IPC. While still being easy to read and maintain.

                      The reason why languages like Java and C# became successful very quickly (aside from having a corporate sponsor) is all of the tooling available. Good compilers, good IDEs and even more important, a huge library of ready-to-use code.
                      There is a difference between mockery and criticism. Here is a comparison to help you understand the difference:

                      criticism:
                      Looking at the given info, I don't yet see any feature that makes this language the go-to language. The developer needs to give more info on why this is better than existing languages, or give more info about the future plans for the project so we at least know where it's heading.

                      mockery:
                      You've got a developer we've never even heard about, who claims to be the future creator of the go-to language and also claims to have (or build on) more than 50 years of experience.

                      Mentioning the shortcomings of some work is a different thing from claiming the developer is not eligible or capable of meeting his claims. Also, giving an opinion about what should be done is a totally different thing from asking him to stop and give up.

                      Comment

                      Working...
                      X