Why Sony Is Using LLVM/Clang On The PlayStation 4

[DanLamb]

Haskell, Scala and Rust don't have e.g. Java-like syntax.

Scala syntax is a safe pareto improvement over Java syntax. Is there anything you don't like about Scala syntax?

Putting types on the right seems generally a much better idea and more consistent with type inference.

`val a = new MyClass()` makes more sense than `MyClass a = new MyClass()`

Having all code blocks auto-return the last statement enables much conciseness and eliminates the need for things like a special case ternary operator. Scala's match/case is much nicer than C/Java/C# switch/case. It also uses the same syntax as Scala's native partial functions, like a mathematical partial function, which is elegant.

[C] has some defects e.g. header files which are necessary because of backward compatibility with C libraries.

That's an understatement... The macro/proprocessor system is a mess... C arrays are totally disjoint from C++ templates for no reason other than legacy... you can't override a variable in a subclass... With more time, I could remember tons of other flaws of C.

The whole point of the Rust project is people who want the elegance of the Scala/Haskell syntax, but the deployment characteristics of C (no VM, easy integration with other C libs).

[DrYak]

I have a maybe stupid question. How is the ABI compatibility guaranteed when using LLVM on a system that is 99% built with another compiler like GCC? I mean library linking, calling conventions, symbol name mangling and all that kind of stuff.

It depends on what the calling conventions are and thus more or less what the official compiler is.

In the case of GCC vs. LLVM, they more or less interchangeable.

C code uses a very well known and supported ABI on almost all modern OSes. Both GCC and LLVM follow it.

the question is regarding C++.

Under Linux, the C++ ABI is also well defined, it uses GCC's C++ ABI, (which in turn uses the Itanium C++ ABI, according to the link posted earlier).
That means that C++ code usually follows the same conventions and thus you can compile a program with LLVM and link it against GCC-compiled C++ libraries.

So on the grand order of things, Sony moving to LLVM will make it easier to create source ports of the same games on Linux: at least you won't have to adapt the source from some weird propretary compiler, you could re-compile them simply by using a linux version of LLVM. The only edits that you'll need are regarding graphics/audio/etc. platform API. But the C/C++ language itself should be recompilable.
Also LLVM itself is very standard compliant. Chance are, it could also be possible to compile the same source-port under Linux using GCC.

Under Windows things get a little bit uglier. The C ABI is standarized, as is the ABI of some other system libraries which follow pascal conventions. *BUT* There's no official "Windows C++ ABI".
Microsoft's Visual C++ has an ABI, which is more or less documented. But this ABI *isn't the same* as GCC's (as the Itanium C++ ABI).
And lots of other compiler define their own ABI (borland's compiler use their own incompatible ABI. I suspect that other big proprietary player like Wacom, ICC have differing ABIs too).
Thus if you mix code compiled in Borland and in MSVC you can call each other's C functions, but you can't mix C++ classes. (that's why, for example, GTK+ use the C-based GObject and Vala is translated into plain C : to avoid problems on OSes that don't define a C++ ABI).
Sadly I have limited C++ experience under Windows (I've either done some small self-contained project under MSVC, or I've compiled stuff with MINGW's GCC calling only C library, and using C++ classes that were shipped with MinGW already. The rare cross platform stuff was done calling OLE/COM objects using helper code like DispatchHelper), so I know that you can mix C code from various compiler, but I don't know if you can mix MSVC classes from a GCC or LLVM main program (except when using said helper code for OLE/COM objects).

After reading what happened to the developers of Game Dev Tycoon I think it?s a good choice to avoid using GCC in proprietary software development. {...} It seems it wasn?t a lot of work to comply, but using clang keeps the devs and publishers away from troubles like this.

Game Dev Tycoon's problem have absolutely nothing to do with the GCC compiler, and entirely to do with the libraries against which the game is linked.
The game is linked against libc (which is licensed under LGPL). The problem was complying with the license (LGPL requires that users have GPL-like copyleft rights-to-hack on the sub-part that is LPGL licensed. That easy to do in practice as libc is dynamically linked {= just freely hack the .so library to exercise your LPGL rights}, but the developpers had failed to inform the users in any way)

Moving from a proprietary compiler to LLVM doesn't change a thing compared to moving the compiler to GCC: at the end of the day, you're still linking your game against whatever is the proprietary system library inside a PS4 (for which Sony already has the rights as its shipped on PS4). As pointed by others PS4's system is BSD-based, its system library is BSD licensed which allows pretty much anyone doing whatever they want with, including integrating modified verison into commercial products and not sharing the modification.


And regarding Scale/Haskell etc.:

The main difficulty is that functional programming, as done in Scala and Haskell is a completely different paradigm than the paradigm in C/C++ etc.
It's an even bigger jump than going from assembler all the way up to object and template programming.
It's comparable to the jump to hardware description language like VHDL and Verilog when doing FPGA.

`val a = new MyClass()` makes more sense than `MyClass a = new MyClass()`
Having all code blocks auto-return the last statement enables much conciseness

Note that C++11 also let go with the redundant typing:
`auto a = new MyClass;` (type needs to be specified for 'a' only when type can't be automatically inferred, like with overloaded functions)

And returning the last statement has always been an implicit result of C ABI (the last result is always in the accumulator). Thus the " ({ ... }) " extension with some compilers, and the possibility to omit the return statement with GCC.

[JS987]

Scala syntax is a safe pareto improvement over Java syntax. Is there anything you don't like about Scala syntax?

I don't think e.g. Pascal syntax is improvement over Java syntax. Java is stuck in past and doesn't evolve fast enough. Scala should be Java extended with new features as C++ was extended in C++11 and future C++14.
Scala isn't alternative to C++ because it depends on JVM and can't be compiled as native executables and libraries.

[mrugiero]

Scala isn't alternative to C++ because it depends on JVM and can't be compiled as native executables and libraries.

AFAIK, a language is usually not intrinsically VM dependent, but it's a matter of implementation.

[DanLamb]

I don't think e.g. Pascal syntax is improvement over Java syntax.

Scala is _way_ more than merely the Pascal style variable syntax: Native partial functions, pattern matching, overridable class variables, etc. Once you understand the differences, you won't want to go back.

Java is stuck in past and doesn't evolve fast enough.

True. I'd argue that C,C++,Java,C#,JavaScript all have too much legacy baggage.

Scala should be Java extended with new features as C++ was extended in C++11 and future C++14.

Backward compatibility comes at a cost. It really limits what you can clean up.

Groovy is a mostly Java backward compatible language with extra features.

Scala isn't alternative to C++ because it depends on JVM and can't be compiled as native executables and libraries.

The major limitation of JVM is that it is extremely hard to interface with other C-based libraries and APIs.

Depending on a VM isn't a problem -- everything has some type of VM/runtime dependency: Lua/C#/JavaScript have their VMs, C++ has runtime library requirements.

[mrugiero]

Depending on a VM isn't a problem -- everything has some type of VM/runtime dependency: Lua/C#/JavaScript have their VMs, C++ has runtime library requirements.

Maybe I've got the concept backwards (this subject is not the one I find the most interesting), but aren't VMs actually kind of bytecode interpreters? If that's so, there is a difference between calling some functions, which you could avoid if so desired in C++, and running on top of an interpreter.

[JS987]

Depending on a VM isn't a problem -- everything has some type of VM/runtime dependency: Lua/C#/JavaScript have their VMs, C++ has runtime library requirements.

VM has too high CPU and memory usage. VM-based languages are option when performance and memory usage don't matter or native executables can't be used.

[smitty3268]

You guys just took a glance and decided it wasn't worth the effort and don't really understand what these tools are about.

I'll admit i haven't looked particularly closely at all the languages listed here. However, I have tried programming in functional programming languages before. And i hated it.

I find it highly unlikely i would ever like a functional programming language, simply because of the entire paradigm they enforce. And i think that is a very typical developer experience. The people who enjoy programming in that style are the exception, not the rule.

That said, i can certainly see the elegance they provide. It's simply difficult for me to think in that way, so i can achieve a lot more with less effort using other languages.

And, further, i do enjoy certain functional language inspired additions to more typical languages. Things such as array.Where(x=>x.test).Select(x=>new Y(x)); in c# are very convenient. I just don't like being constrained to that type of programming 100% of the time.

[DanLamb]

And, further, i do enjoy certain functional language inspired additions to more typical languages. Things such as array.Where(x=>x.test).Select(x=>new Y(x)); in c# are very convenient. I just don't like being constrained to that type of programming 100% of the time.

The more common names for those are "map" and "filter". C# chose SQL-derived names where SQL where=filter and SQL select=map, which is fine.

Almost every language except C, has "map" and "filter" or something nearly identical: JavaScript, Ruby, Python, Scala, C#, Java 8, R, etc.

C++ has "map" and "filter" but it's really terrible for several reasons.

If you like map/filter, the next step would be to use flatMap (C# calls it SelectMany) and use Option rather than null.

However, I have tried programming in functional programming languages before. And i hated it.

Even if you stick with strictly imperative programming, Scala just cleans up so many of the obvious mistakes with Java/C# and C++:

In C++/Java/C#, every type with a type parameter uses syntax like List<int>, Map<int,SomeClass>, AnotherClass<int>, but then for absolutely no logical reason (beyond legacy) arrays are this special case and use int[] instead of Array<int>.

Or just consider basic properties/variables: C++/C# have this limited disjoint form of type inference, because it was bolted on late in the lifetimes of the languages. Java expects you to manually write and maintain getter/setters for overridable class properties. C# has completely redundant properties vs variables and a zillion illogical special cases: you can have type inference on a local var, but not a class/instance var and not a property. You declare read only props one way, read only statics and globals another way, and you can't do read only local variables. What a hodgepodge!

[mrugiero]

In C++/Java/C#, every type with a type parameter uses syntax like List<int>, Map<int,SomeClass>, AnotherClass<int>, but then for absolutely no logical reason (beyond legacy) arrays are this special case and use int[] instead of Array<int>.

Actually http://en.cppreference.com/w/cpp/container/array