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

[fuzz]

They do claim it will be "the language we've all been waiting for".

And considering so many programmers have different tastes, this quote can't even be true. Hence my "javascript? Python" comment...

[log0]

Relax guys. It is just a dude working on his dream programming language and calling for some feedback. There is nothing wrong about that. I think pretty much every dev out there has some ideal language in his head. This one has decided to realize it using llvm, which is great on its own I think, can be used as another example of how to implement languages on top of llvm at the very least.

[DanLamb]

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.

Scala mostly solved this issue on the JVM. A Scala generics Array[Int] has zero boxing overhead. It has the same memory usage and performance profile as Java/C# int[].

Even in C#, List<int> uses int[] internally, but the latter generally provides better performance.

The Scala solution is much cleaner. There is no separate array syntax vs generics syntax because one was grafted on to the language after the fact. There's no real logic behind Java/C# on arrays, it's just sloppy design that can't be fixed for legacy. reasons.

Java/C# arrays have broken casting: The compiler correctly stops code from casting generics List<Circle> to List<Shape> but erroneously allows you with arrays. Java/C# safely allow code to cast List<Circle> to List<? extends Shape> (C# syntax is slightly different), but higher performance arrays don't support that elaborate type parameter constructs. In Java/C# you have to choose between performance of this older legacy array mechanism vs the newer syntax and better type parameter system of generics. Scala just has a cleaned up design so you get the best of both and don't have these competing redundant disjoint language constructs for legacy reasons.

I like Scala and I *love* Kotlin

Dare I ask why? I love JetBrains, I've used Kotlin, but there doesn't seem to be much of a point to it next to Scala.

[DanLamb]

Relax guys. It is just a dude working on his dream programming language and calling for some feedback. There is nothing wrong about that. I think pretty much every dev out there has some ideal language in his head. This one has decided to realize it using llvm, which is great on its own I think, can be used as another example of how to implement languages on top of llvm at the very least.

Ivy is a niche pet programming language. There are thousands of those. That's fine for what it is.

Then someone has to chime in with the most outrageous, ignorant, politcal, and arguably outrageously wrong and closed minded comment like: "as long as there is nothing that comes even remotely close to Visual Studio in combination with the MSDN, it's not worth it to discuss the language."

I've used Visual Studio and MSDN and C# for a full ten years. I know those tools pretty darn well. They are not that good. It's my opinion, but if you take the time to learn something like SBT and use your IDE as just an optional code navigation and automation tool, it makes a more logical elegant flexible workflow.

Similarly, language design is important. I articulated a clear list of reasons why something like Scala is an order of magnitude better than something like Java/C# and the C# folks just tune that out and cling to the crusty old features that C# has over Java like unsigned ints and List<int> which have mostly been solved a long time ago.

[TheBuzzSaw]

Similarly, language design is important. I articulated a clear list of reasons why something like Scala is an order of magnitude better than something like Java/C# and the C# folks just tune that out and cling to the crusty old features that C# has over Java like unsigned ints and List<int> which have mostly been solved a long time ago.

Why do you refer to unsigned ints as "crusty old features"? Unsigned integer values are incredibly important.

[DanLamb]

Why do you refer to unsigned ints as "crusty old features"? Unsigned integer values are incredibly important.

There's a simple workaround where you put an unsigned int value in a signed int variable. It's easy. I've done it a lot.

Usually, you only explicitly need unsigned ints when implementing low level algorithms or protocols, which is important, but it generally involves a low percentage of source code.

Compare that to class instance variables/properties. That's something most code bases use *everywhere*, so it's more important to have an elegant implementation for that like Scala does, and not an archaic overly complex solution mired in legacy like C#.

[DanLamb]

Why do you refer to unsigned ints as "crusty old features"? Unsigned integer values are incredibly important.

Upon rereading this: I meant that the debate point is "crusty" and "old" because the workaround is just too simple.

the language feature is still nice and relevant. It's a minor advantage but it counts.