Interesting. But I feel like Racket is a better framework for quickly prototyping new languages.
Graal and Truffle could accelerate programming language design
51–60 of 204 posts
Re: Graal and Truffle could accelerate programming language design
#52Earlier quoted context omitted.
> The TruffleC engine is roughly competitive with GCC It is not surprising in sense Java is competitive to C/C++ as per many Java developers.
I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.
> In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time.
If the program runs on the user's machine, I'm pretty certain the users WILL notice the difference, memory wise.
Re: Graal and Truffle could accelerate programming language design
#53There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your la…
To add to the examples, Truffle currently has interpreters for unmanaged languages such as C/Fortran (with Sulong), dynamic languages such as Ruby and JS, statistics/math like R and functional like Clojure.
The interopability is done in a way that does not need a common representation or object layout.
> I wouldn't use Rust for the syntax; I'd use it because I want properties like complete memory safety, manual control over memory allocation, easy (and fast!) access to C libraries, and short startup time. These are all things that Truffle explicitly does not deliver.
Truffle itself does not do it, but it is possible to have a Truffle interpreter with these requirements. Memory safety can be enforced at the frontend compiler level like Rust does I believe. Memory can be allocated directly with Unsafe or calling libc functions. GNFI [1] allows for fast calls to native libraries. Startup can be improved radically with SubstrateVM, but it is currently closed-source. There are many ways to improve the JVM startup, but not necessarily convenient (but then you don't need to wait to compile your program either to start running it).
Re: Graal and Truffle could accelerate programming language design
#54> A way to create a new language in just a few weeks As a Lisp programmer, I regularly create new languages in a matter of hours.
Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.
Yes, you could. You'd implement a program to take C code and emit an equivalent Lisp program (i.e., parse C and emit the tree into Lisp), then compile the Lisp program. The annotations and care the parser/semantic analysis code uses will provide the semantics of C.
This will, however, not "play" like C without a great deal of work. You will be dragging an entire Lisp VM around and have to shake all of that out to actually produce something as lean as a C program at the end. You're probably best suited to take the Lisp compiler and build a "independant code" generator to generate binaries that don't rely on Lisp. But I'm waving my hands, you'd need to talk to the SBCL or CCL development teams there.
Re: Graal and Truffle could accelerate programming language design
#55> A way to create a new language in just a few weeks As a Lisp programmer, I regularly create new languages in a matter of hours.
I was thinking that myself. If they had started with a modern Lisp implementation, they would be worlds ahead. :-/
Re: Graal and Truffle could accelerate programming language design
#56> Since the dawn of computing our industry has been engaged on a never ending quest to build the perfect language. Except it really hasn't. The industry is going to use whatever language has the bare minimum feature set they value at the moment and no more. Call me cynical but my point of view is: if the industry were really striving for perfection, there would be no COBOL or BASIC, for instance. Lisp had already bee…
if the industry were really striving for perfection, there would be no COBOL or BASIC, for instance. COBOL was a huge improvement at the time, an innovation in readability. BASIC is a good demonstration of why the platonic ideal language is wrong: it was designed for beginners (that's what the acronym stands for), and it did a reasonably good job at that. Beginners might be overwhelmed by OOP, multiple dispatch and a…
> BASIC is a good demonstration of why the platonic ideal language is wrong
That's often my point when people bring up arguments against a language that seems a bit more complex (Perl), or for language simplicity (Python). Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage. The siple example of an extreme end of this is APL. If you can internalize and understand the extremely concise and powerful syntax and semantics of the language (I haven't), you can do amazing things very quickly[1].
Now, doing amazing things very quickly isn't the only metric by which we judge a language, but it is a useful metric, and it's probably worth having a language on that end of the spectrum in your tool set.
Re: Graal and Truffle could accelerate programming language design
#57Earlier quoted context omitted.
UIs though... I haven't worked with a single Java based GUI application that did feel smooth, fast and efficient. I wonder why that is.
Because most developers don't care and code everything on the UI thread. Additionally Swing has bad defaults, so it requires effort to make the required set of calls to make them look better. Back in the Sun glory days, there were Sun blogs like Filthy Rich Clients, which lead eventually to a book http://filthyrichclients.org/ . It was a consequence of Sun not getting what it means developing GUIs for the consumer sy…
Android does a bunch of things to keep you off the UI thread(IO throws an exception, handlers, Async Tasks, etc).
You still have to GC at some point and when that happens chances are you're going to drop frames. Unless you're very aware of the garbage you're creating you'll take more than ~5ms which is usually enough to push you over 16ms with the other work that goes on during a frame.
Re: Graal and Truffle could accelerate programming language design
#58Earlier quoted context omitted.
Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.
Yes, you could. You'd implement a program to take C code and emit an equivalent Lisp program (i.e., parse C and emit the tree into Lisp), then compile the Lisp program. The annotations and care the parser/semantic analysis code uses will provide the semantics of C. This will, however, not "play" like C without a great deal of work. You will be dragging an entire Lisp VM around and have to shake all of that out to act…
That doesn't sound significantly easier than what we've done to implement C using Truffle. I'm not sure I buy this argument that what we've done could have been done trivially using Lisp macros.
Re: Graal and Truffle could accelerate programming language design
#59Before anyone gets too excited, make sure you look at what a compiler using Truffle actually looks like, and remember that Java is far from an ideal language for writing a compiler. I'll use their SimpleLanguage (their primary tutorial lang) as an example.
Parser [1] shows how lack of sum types makes code messy. Lots of "factory.createStringLiteral" kind of calls. At least Java has a mature parser generator.
Implementing interpreter nodes [2] requires a pretty large amount of boilerplate, each individual node is relegated to its own file, some classes are littered with probably autogenerated getters/setters. While functional languages can be too terse, Java shows its exceptional verbosity here.
[1] https://github.com/graalvm/truffle/blob/master/truffle/com.o...
[2] https://github.com/graalvm/truffle/tree/master/truffle/com.o...
Re: Graal and Truffle could accelerate programming language design
#60Earlier quoted context omitted.
Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.
You cannot. Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. Lisp is so easy to metaprogram because everything is parentheses and the burden is on the user, not the parser, to determine the program's abstract syntactic structure. So, Lisp can only metaprogram its own syntax, you can't introduce a C-like syntax.
> You cannot.
You can. Reader macros let you put whatever syntax you want on top of Sexprs. For example:
Welcome to Clozure Common Lisp Version 1.10-r16479M (DarwinX8664)!
? (spark-init)
#P"/Users/ron/devel/spark/ergolib/init.lisp"
? (require :parcil)
...
? (in-readtable infix)
|NIL|
? infix(x=1.23+4.56)
5.79
? sin(x*x+1)
0.03341171
?