Announcement

Collapse
No announcement yet.

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

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

  • #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


            • #51
              Originally posted by Wildfire View Post
              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.
              OCCAM?

              Years (actually a decade or two) since I wrote any, but it was designed from the ground up for multithreading and message passing.

              Comment


              • #52
                Sorry for late reply, sometimes I actually have to work at work, I hate it when that happens

                Originally posted by F i L View Post
                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!
                Heh, ok I guess I should dust of xchat and pop in again.

                Originally posted by F i L View Post
                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 :-)
                Yes from what I understand a lot of game engines today draw inspiration from Unity, so it would seem that they got the abstraction/flexibility balance down well.

                Originally posted by F i L View Post
                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
                I've done very little experimentation with Nimrod as of yet (spending time playing around with Go and Rust mainly) so I'd love to see some of your code once it's in a presentable state to see if I can follow it and see how you solve things and thus get a better grasp of the language (always been someone who learns much faster from actual practical code rather than example snippets and abstract explanations), also since it's such a fast developing language (due to being so young) I'm sure it has changed a lot / added many more features since I last played around in it (which was several months ago).

                Originally posted by F i L View Post
                (not mention Nimrod does very well in benchmarks).
                Yes I saw that and also the rogue level generator benchmark where Nimrod did great aswell. It was smart of Araq in my opinion to compile Nimrod to C / C++ and thus directly be able to leverage a mature and very strong optimizing compiler like GCC to generate very fast code. And the results I've seen so far are impressive.

                Originally posted by F i L View Post
                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...
                Well as I'm interested in all aspects of programming I've certainly played around a little bit with game programming aswell, also a friend of mine has been bugging me about writing a game with him for HTML5.

                While I think it would be fun to write a game I'm really no fan of Javascript so I'm a bit reluctant, anyway he recently badgered me again and wanted me to take a look at a HTML5 game engine called Phaser, I don't know how that engine compares to unity (as I've never really looked at unity's api), but it (Phaser) seems to automate very much and basically you are mainly setting parameters for the ingame objects rather than actually doing much manual game logic, at least that's my impression from my quick glance at the documentation. It seems robust enough and certainly removes a lot of the burden from the programmer, but it also seems as though you'd quickly hit flexibility issues, also I'd much rather do more coding but in a language I like working in, then less coding but in a language I don't enjoy. Ahwell, we'll see if he gives up or if I'm forced to join his venture due to the 'unwritten buddy contract', I'm starting to run out of excuses

                Originally posted by F i L View Post
                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.
                Sounds like a good plan, the core stuff will likely follow a quite straightforward pattern while the user-level abstraction is something one can probably spend way too much time trying to 'get it just right!'

                Comment


                • #53
                  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#.

                  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.
                  Both Java and C# are modern in that they do away with #include and #define in favor of superior build systems and namespaces. C# is way better than Java as a language overall. Java is just plain stupid. No (custom) value types? No unsigned integer types? Type erasure for its generic system? Absolute garbage. However, I am a cross-platform developer, so that rules out C# as well. (No, Mono does not count.)

                  And I don't understand this mentality that a language/technology can be too heavy/bloated for one platform but light/acceptable on another. Sure, it's great that my PC is far more powerful than my game consoles and mobile devices, but why squander that power with VMs? No thanks. I'll stick with the natively compiled tech to get the MOST out of my PC.

                  Comment


                  • #54
                    Originally posted by TheBuzzSaw View Post
                    Both Java and C# are modern in that they do away with #include and #define in favor of superior build systems and namespaces. C# is way better than Java as a language overall. Java is just plain stupid. No (custom) value types? No unsigned integer types? Type erasure for its generic system? Absolute garbage. However, I am a cross-platform developer, so that rules out C# as well. (No, Mono does not count.)
                    I agree with those C# advantages and would add non-checked exceptions to the list.

                    The items on the Scala list I just posted are much more significant. Did you read that at all? You can workaround most of the Java deficiencies you suggest pretty easily: True unsigned ints are nice, but it's really easy to workaround. Java 8 even has system library functions for unsigned int access so you don't lose performance for niche use cases where unsigned ints are critical. Reified generics is nice, but how often do you really need generic type info at runtime? The Scala advantages I mentioned are generally much larger.

                    Originally posted by TheBuzzSaw View Post
                    And I don't understand this mentality that a language/technology can be too heavy/bloated for one platform but light/acceptable on another. Sure, it's great that my PC is far more powerful than my game consoles and mobile devices, but why squander that power with VMs? No thanks. I'll stick with the natively compiled tech to get the MOST out of my PC.
                    Well Dalvik vs Oracle JVM have completely different runtime characteristics. The VM you use is probably more relevant to performance than the language. If you switch between JVM languages like Java, Groovy, Scala, Clojure, the performance differences are probably generally minor.

                    With tiny apps, 100K of RAM/disk overhead can be a deal breaker. For a larger app, it doesn't matter. I would disagree that a VM is necessarily slower than native code. Java with a VM runs faster than many native code languages. Last I checked it regularly outperformed Google Go for example.

                    You can do native compilation with Java, but it's less polished and there usually isn't justification to do that.

                    Comment


                    • #55
                      Originally posted by DanLamb View Post
                      I agree with those C# advantages and would add non-checked exceptions to the list.

                      The items on the Scala list I just posted are much more significant. Did you read that at all? You can workaround most of the Java deficiencies you suggest pretty easily: True unsigned ints are nice, but it's really easy to workaround. Java 8 even has system library functions for unsigned int access so you don't lose performance for niche use cases where unsigned ints are critical. Reified generics is nice, but how often do you really need generic type info at runtime? The Scala advantages I mentioned are generally much larger.
                      (...)
                      Well Dalvik vs Oracle JVM have completely different runtime characteristics. The VM you use is probably more relevant to performance than the language. If you switch between JVM languages like Java, Groovy, Scala, Clojure, the performance differences are probably generally minor.

                      With tiny apps, 100K of RAM/disk overhead can be a deal breaker. For a larger app, it doesn't matter. I would disagree that a VM is necessarily slower than native code. Java with a VM runs faster than many native code languages. Last I checked it regularly outperformed Google Go for example.

                      You can do native compilation with Java, but it's less polished and there usually isn't justification to do that.
                      I like Scala and I *love* Kotlin, but and there is always a but, Java sometimes as a VM doesn't cut it.
                      For example: "how often do you really need generic type info at runtime?", I would say a lot, especially when you use collections of value types. A class storing an boxed 1 byte is at least 16 bytes long, and storing it in a generic List<T> in Java simply means you will use at least 16x more memory for it. Even more, you use it when is combined with Generic frameworks that do for example code validation (like Code Contracts). As Java runtime (I talk about HotSpot) depends often on more information to give more aggressive optimizations (as any compiler will do), it means that in certain cases the optimizer will not cut it, or it will put an "uncommon trap" to reduce casting. Even Hotspot does it, when you talk about cross-platform Java, running on Android's "advanced" tracing JIT, you will have also a performance hit.
                      "I would disagree that a VM is necessarily slower than native code" - this is somewhat true (and somewhat false) because:
                      - fast is relative. Java as with a VM (it can be compiled statically even by GCJ or using tools like Excelsior JET) always starts slower big applications than their native equivalents. Even optimization wise the Hotspot does recompilations and use a heuristic/speculative optimization path (based on the classes it see), so in case a new class appear in system, up to "rewarmup" phase it can run it certainly slower than their "native" counterpart. Java has a GC and sometimes the pauses can run slower some operations than a classic C++ allocator
                      - "Java is faster than Go" - Java should be faster than Go as Go tries to not make deep compiler optimizations on the code. But Go is again: faster than Java on startup, is very quick at compilation, maybe faster than Java's , which made the creator R. Pike to say: "it has a scripting feeling". Java needs a multi-pass compiler when Go doesn't meaning that Go may generate really faster the native code that starts up faster than Java, compare to compile Java code, then Java has to extract Jars and interpret and finally compile hot spots of them.

                      Comment


                      • #56
                        Originally posted by sarmad View Post
                        There is a difference between mockery and criticism. Here is a comparison to help you understand the difference:

                        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.
                        Actually, that's what I'd call "skepticism", although expressed in a provocative way (think satire). I've found nothing that warrant's the claim of 50 years of experience. I've found no other languages designed be the developer. They do claim it will be "the language we've all been waiting for".

                        It's another way of saying that all I see are tall claims and little data to back it up. It's only natural to receive some ridicule for that. It's the same I would get if I claimed that I was going to build the best car ever, while also claiming that I was drawing on a combined experience of 150 years. And all I had to show for it were a few small pieces of tech and no overal concepts or anything. ("Sorry, you're not 150 years old, you have no previous experience or at least nothing to show for it, and reading about other people's experiences does not make them your own.")

                        Also, I never told them to give up on it, just to provide some more substantial proof to back up their claims.

                        Comment


                        • #57
                          Originally posted by Wildfire View Post
                          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.
                          Go?
                          5 characters

                          Comment


                          • #58
                            Originally posted by peppercats View Post
                            Go?
                            5 characters
                            Actually, I believe Go makes blocking network calls. It just abstracts the whole process away from you.

                            Comment


                            • #59
                              Originally posted by TheBuzzSaw View Post
                              Actually, I believe Go makes blocking network calls. It just abstracts the whole process away from you.
                              How the heck do I edit my posts? Anyway, I misspoke. It has locks that are hidden away but not necessarily blocking calls.

                              Comment


                              • #60
                                Originally posted by Wildfire View Post
                                Actually, that's what I'd call "skepticism", although expressed in a provocative way (think satire). I've found nothing that warrant's the claim of 50 years of experience. I've found no other languages designed be the developer. They do claim it will be "the language we've all been waiting for".

                                It's another way of saying that all I see are tall claims and little data to back it up. It's only natural to receive some ridicule for that. It's the same I would get if I claimed that I was going to build the best car ever, while also claiming that I was drawing on a combined experience of 150 years. And all I had to show for it were a few small pieces of tech and no overal concepts or anything. ("Sorry, you're not 150 years old, you have no previous experience or at least nothing to show for it, and reading about other people's experiences does not make them your own.")

                                Also, I never told them to give up on it, just to provide some more substantial proof to back up their claims.
                                He never claimed he has 50 years of experience, he only claims he is going through the past 50 years of progress in programming languages and trying to summarize it all in one language. Like most people, I personally don't see any proof of his claim, but I also don't yet see any proof of the opposite. Time will tell whether he'll be able to do it, until then I'll assume he actually means it.

                                Comment

                                Working...
                                X