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

[movieman]

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.

[XorEaxEax]

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

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.

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.

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).

(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.

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

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!'

[TheBuzzSaw]

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.

[DanLamb]

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.

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.

[ciplogic]

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.

[Wildfire]

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.

[peppercats]

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

[TheBuzzSaw]

Go?
5 characters

Actually, I believe Go makes blocking network calls. It just abstracts the whole process away from you.

[TheBuzzSaw]

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.

[sarmad]

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.