
Graal and Truffle could accelerate programming language design - cosbas
https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.qchn61j4c
======
nostrademons
There'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 language is mostly like C# (C#, F#,
Boo, IronPython). The JVM works if your language is mostly like Java (Java,
Clojure, Scala, Kotlin). Even PyPy has frontends for Ruby, PHP, Smalltalk, and
Prolog.

"Mostly" in this case means semantically, not syntactically. It's things like
concurrency model; floating point behavior; memory layout; FFI; semantics of
basic libraries; performance characteristics; and level of dynamism. You can
write a Python frontend for both the JVM and CLR, and it will _look_ like
Python but _act_ like Java and .NET, respectively, with no guarantee that
native CPython libraries will work on it.

The problem is that this is where basically all the interesting language-
design research is. 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.

It's a great tool if you work in the JVM ecosystem and want to play around as
a language designer. But most of the interesting languages lately have created
their own ecosystems, and they succeed by solving problems so fundamental that
people will put up with having to learn a new ecosystem to gain the benefits
they offer.

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

[1]
[http://dl.acm.org/citation.cfm?id=2500832](http://dl.acm.org/citation.cfm?id=2500832)

~~~
nostrademons
The big question is "Would you want to use this in a mission-critical
project?" Emscripten lets you write webapps in C, for example, but outside of
sharing common libraries across server/Android/iOS/web clients, few people use
it.

Pretty much every professional job I've had used polyglot programming of some
sort - when I was in financial software it was mixed Java/C/Fortran numerics,
when I founded my first startup it was polyglot Javascript/ActionScript, and
at Google it was a large server that was first Python/C++ and then Java/C++.
The boundary between languages is _always_ problematic. And the reason for
that is because you choose memory layout to make certain trade-offs around the
access patterns for that data. Do you inline data structures in a vector, or
chase pointers? Do objects carry their type information with them so you can
manipulate them dynamically, or do they throw it away at compile-time for
greater efficiency? Do you get O(1) string indexing or native UTF-8? Do you
allocate on the stack or the heap? Do you copy, borrow, move, or COW?

And then when you go to switch representations to call into another language,
you pay a cost to convert all the data structures you might be touching. In
many cases, that cost could be more than you saved by using optimized
representations in the first place.

~~~
thomaswue
The idea of Truffle language interoperability is to avoid switching the
representation at the language boundary. Objects carry their type information
with them that includes the semantics on how to access their properties. This
also allows Truffle to fake up the existence of an object without actually
performing allocations (e.g., a table in raw buffer format can be interpreted
as an array of objects). This clear separation of logical and physical layout
enables efficient data representation in the context of higher level languages
that typically suffer from pointer chasing and object header overheads.

~~~
nostrademons
Right, and my point is that this won't work unless you dictate a common memory
layout for all Truffle objects. And if you do _that_ , then you lose the
ability to make trade-offs about object representation that depend upon access
patterns that only the programmer can know. The whole reason we have different
programming languages is because not all domains of computation face the same
trade-offs.

~~~
thomaswue
It works without common memory layout between Truffle languages. It even
simplifies the ability to use diverse physical memory layouts within the same
language. The programmer specifies the logical layout based on the semantics
of a language. The runtime decides how to map this logical layout onto the
physical hardware. It can take into account the trade-offs the programmer
decided to choose.

~~~
nostrademons
Right, and my point is that the reason people continue to use C++ or Rust over
JVM languages is because there are some use-cases where the JVM's decision
about how to map the logical layout onto physical memory causes unacceptably
high memory usage and/or cache misses, or prevents them from taking advantage
of clever serialization formats (Cap'n Proto, for example, loses much of its
performance benefits on the JVM without the use of sun.misc.unsafe). Will
Truffle allow the programmer to override Graal's decisions on this and
manually specify memory layout? And if so, how are conversions between
different language formats specified?

If you already buy the JVM's premise of "just let the compiler do it, we'll
figure out the most efficient representation", then this is a non-issue. But
there are still programmers out there who believe that Rust or C++ or Go or
CPython or whatever presents a better memory layout for the tasks that they
wish to accomplish, or language designers who think they can do better than
all of the above, and these are the users that Graal+Truffle is trying to win
over. What's the story for them?

~~~
thomaswue
The default when running static languages like C++ or Rust or Go via Sulong is
to stick to the memory layout chosen by the programmer. There is no conversion
to typical JVM memory layouts. Nor does running on the JVM has major
restrictions for the framework (we are working on a version that does not run
on the JVM in the SubstrateVM project). What Graal+Truffle allows is for
library writers and language designers to invent new representations without
any restrictions on the layout and have them interact with the rest of the
system. We want programmers to use the best language for the task. And even
combine multiple languages within one program. Foreign objects can be passed
around freely as parameters and local variables, but there are restrictions
when building combined data structures - e.g., if you have a highly optimized
native data structure, it is not possible to install a pointer to a JavaScript
object in it without performance loss.

~~~
nostrademons
Interesting. So, if I'm understanding this correctly - Truffle allows a
language designer to specify a certain logical layout for data structures,
along with hints for how this will get converted to a physical memory layout.
Language implementors also get the full power of Graal for lowering their AST
to machine code and other compiler tasks. On cross-language boundaries, it
generates automatic accessors for _other_ languages to access that data, using
the logical layout to identify how particular fields need to be pulled out and
manipulated, but _not_ requiring that the full data structure be converted
across the foreign-call boundary. One consequence of this is that nesting &
embedding of data structures may require an explicit conversion, since if an
object is a hashtable in Javascript but a packed series of fields in C, it's
obviously not going to fit.

Sorta like SWIG++? If you could do SWIG but never require that an end-user
write a typemap or debug a crash themself, there'd probably be a big market
for that.

~~~
thomaswue
Yes, this is an excellent description.

------
wahern
Judging by LuaTruffle, the Lua example, then this framework is useless.

LuaTruffle appears to implement the syntax of Lua but none of the semantics.
For example, no metatables and no coroutines. Lua is unparalleled in its
support of coroutines, and metatables are what make optimizing Lua
_difficult_. Without implementing either of those things you've neither
demonstrated the ability of the framework to implement novel control-flow
semantics (asymmetric coroutines that can yield across multiple, unadorned
function invocation) nor performance capabilities (JIT-optimizing Lua tables
is non-trivial).

I'm not even sure LuaTruffle implements Lua's lexical closures or tail call
optimization, both critical to Lua's ability to support functional programming
patterns.

Of course, it definitely doesn't implement the Lua C API, which is part-and-
parcel of what makes Lua preferable as an extension and glue language. But I
was willing to overlook that if it could easily implement the former.

The beauty of a good DSL isn't the syntax (I know, hard to believe!), but in
novel approaches to code flow execution and other deep semantics. Golang's
goroutines are beautiful. Rust's ownership analyzer and prover are what
_defines_ the language. Haskell's lazy evaluation open up whole new dimensions
for problem solving (and headaches). If your language framework doesn't at
least preserve the ability to implement those things cleanly and performantly,
it's not adding much value and is basically a toy. It's not like writing a
lexer for a DSL is a serious impediment. (Using Lua's LPeg, for example, you
can write parsers and build an AST for most major languages in a few hundred
lines of code.)

~~~
chrisseaton
LuaTruffle has a few hours work by an casual non-expert external person.

If you want to know about how well we can implement the semantics of an
existing language then look at JRuby+Truffle - it passes more Ruby language
tests than any other alternative Ruby implementation. The only stumbling block
is co-routines as the JVM doesn't have these and they're hard to implement
efficiently with other constructs.

~~~
vvanders
Does that kinda throw off the whole concept about pushing language design if
you can't do coroutines?

That's a pretty critical feature of Lua that somewhat defines it(along with
it's low overhead + embeddability, both of with you won't get with the JVM).

It seems like engineers always want to build One Tool to Solve Them All(tm)
and yet there are always tradeoffs to be made. The reason 90% of this industry
is still employed is because we don't have these one size fits all problems
that we'd so love to solve.

~~~
grashalm
There was a patch for coroutines on the JVM some time ago. Unfortunatly it did
not make it into the platform. No reason why it could not be added to the JVM.

SubstrateVM solves the embeddability part.

~~~
vvanders
Info out there on SubstrateVM looks a little sparse.

For context we use to run VM + tuneable data + game logic code in a 400kb
block allocated to Lua on the PSP. I'd love to hear how SubstrateVM compares.
Lua has a really rich history of being embedding in some pretty small targets.

~~~
nirvdrum
400 KB is a very aggressive target. I don't think anything in SubstrateVM
would absolutely prohibit that, but currently our images are larger.

Some of this is just simply a design trade-off. E.g., in JRuby+Truffle, we've
implemented much of the core library in Ruby. This has allowed us to achieve a
high level of language compatibility in a fairly short period of time --
implementing 3,000 core library methods in Java would be quite the
undertaking. As a consequence, the static binary must include those full Ruby
sources (compressed, but they're not in an optimized bytecode format).

Having said that, if we wanted to optimize for size over a restricted subset
of the language (think mruby), that would be straightforward to do.

------
outworlder
> 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 been invented. Garbage collection was a thing already. We had macros.
A REPL. A little later, OOP and multiple dispatch. The list goes on.

They had to ditch the (almost) perfect wheel for a cheaper square one. Fast
forward a few years, and the square wheel is now polished but just as square,
the insanely great wheel now just is as cheap as it is, but we won't use it,
as the axles expect the square wheel.

And then we invent Java and XML...

~~~
ktRolster
_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 list of design patterns. Sometimes experts are too.

Garbage collection is a nice feature, but it doesn't fit everywhere. Sometimes
you want to manage your own memory. That's why we have more than one language.

~~~
outworlder
> 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.

Sure. But these systems were created from the ground up, every single time.
Given a good foundation, which could be Lisp or something even better, you can
whip up the "simpler" languages in no time. Even ditch the parentheses if you
so desire. While getting all the benefits of the underlying system.

> Garbage collection is a nice feature, but it doesn't fit everywhere.
> Sometimes you want to manage your own memory. That's why we have more than
> one language.

Sure. But I disagree with that's the reason why we have multiple languages.
There's no single reason, it is probably a mixture of preferences, previous
knowledge, budget, time to market (JS!) among others.

We can manage our own memory from higher level languages. We can compile them.
We can even make them spit out assembly custom-made for a given, niche
application (see the Galileo magnetometer patch).

Sorry if I sound like a smug lisp weenie. But even that description is not
accurate: had we focused our collective resources towards "perfection", as
that sentence implies, we would have something way better than Lisp itself. Or
anything else that we currently use.

It is as if we had invented jet engines before planes. But then placed steam
engines on them because they were cheaper. Or that more people understood
them.

~~~
euyyn
Lisp didn't miss the train because it was too good or because people were
idiots. For a good foundation to be good it has to meet the pre-requisite to
work for most use cases. Lisp didn't when C did, in a time when hardware was
small and expensive.

Times have changed now? Sure, but history didn't wait.

~~~
nickpsecurity
That's a significant part of it. Check out PreScheme, though, for how that
might have worked:

[https://en.wikipedia.org/wiki/PreScheme](https://en.wikipedia.org/wiki/PreScheme)

It's a Scheme created as a C alternative for low-level programming used in a
verified Scheme48, VLISP. It was quite efficient. LISP's doing more of that
kind of thing might have fueled more use of the language.

------
wcrichton
Before 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...](https://github.com/graalvm/truffle/blob/master/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/parser/SimpleLanguage.atg)

[2]
[https://github.com/graalvm/truffle/tree/master/truffle/com.o...](https://github.com/graalvm/truffle/tree/master/truffle/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes)

~~~
qwertyuiop924
Urrgh. This just reminds me of why I gave up on android app development, and
the JVM ecosystem as a whole: it tests my ability to put up with bullshit.

~~~
eggy
I agree. I wanted to really write native Android apps, not HTML5 or even use
the NDK with C/C++. It is just too much stuff. The downloads, the verbosity of
Java, the lack of a slick toolchain (Android Studio is getting close, I
guess), and a slew of other incoherencies.

I don't cut slack for Obj-C on iOS either.

I've had great fun with two products for Android/iOS and Mac/PC/Linux:

[1] Godot game engine. I followed the introduction and had an app on my
Android phone in 10 minutes. A little hack in the background, but hey, for
gaming it is great.

[2] 8th - a dialect of Forth - you write Forth-like 8th, and voilà it's
running on your Anroid, PC, Mac, iOS device!

[1] [https://godotengine.org/](https://godotengine.org/)

[2] [http://8th-dev.com/about8th.html#cross](http://8th-
dev.com/about8th.html#cross)

~~~
qwertyuiop924
I have not used godot up to now, as I am wary of engines that require me to
learn a scripting language used nowhere else. Is it any good?

Oh, and I've heard React Native's not so bad for mobile.

~~~
eggy
I have not tried more than about 8 game engines, so my opinion is limited.
Godot is very good:

* Very customizable interface * Lots of tutorials on YouTube and elsewhere * Good examples provided * Script is very similar to Python, so not too hard to pick up, and again, lots of examples. * Easy packaging for Android, Windows, and Linux on my end * MIT license, commercial or non-commercial * 2D/3D and live debug and scripting on the fly

Really worth trying out, since it is easy to install and dive in.

I'll have a look at React Native, but I am not a JS programmer, and all of
these 'hot' JS libs, modules, etc... seem more cluttered than plain old JS. I
think if I were to branch out, I'd try Purescript instead.

~~~
qwertyuiop924
If you're thinking along the lines of Angular, React is very different (less
clutter, nice design, emphatically not a framework), and has inspired many re-
implementations of its ideas.

It's probably more worth checking out that most of what's out there.

------
kodablah
The Oracle flavors of the JVM/JDK probably scare too many away with regards to
redistribution of their product. That coupled with the fact that things like
the AOT engine is closed source and the weight of the JVM for anything besides
daemons (both mentioned towards the end of the article) probably keep language
designers away these days.

I would love a lightweight toolkit that made for easy language development.
VMKit[0] is dead, MicroVM[1] is a nice idea but not full fledged. Many like
myself looking to implement a toy language would love to be fast out of the
gate and would rather not mess with the OS-specific constructs and specifics
of LLVM IR. So we end up cross-compiling to existing languages or marrying
ourselves to a certain runtime (e.g. the CLR). Any other lightweight VMs or
AOT compilers that are cross-platform that language designers can use these
days?

0 - [http://vmkit.llvm.org/](http://vmkit.llvm.org/) 1 -
[http://microvm.github.io/](http://microvm.github.io/)

~~~
frankpf
QBE[1] seems to be what you're looking for. It "aims to be a pure C embeddable
backend that provides 70% of the performance of advanced compilers in 10% of
the code".

Previous discussion on HN:
[https://news.ycombinator.com/item?id=11555527](https://news.ycombinator.com/item?id=11555527)

[1]: [http://c9x.me/compile/](http://c9x.me/compile/)

~~~
kodablah
Neat, I missed this when originally posted. Sadly, it falls apart on the
"cross-platform" requirement (does not appear to support Windows).

------
dkarapetyan
Doesn't RPython do all the same things? Also there are language workbenches
([http://www.languageworkbenches.net/](http://www.languageworkbenches.net/))
that allow one to get a bunch of things like IDE support and even basic
compilers by properly expressing the language syntax and semantics.

I agree there is a lot of interesting stuff going on here but lets not forget
the prior art. Even OMeta I think already did a lot of these things way back
when. Going further back there's META II
([https://en.wikipedia.org/wiki/META_II](https://en.wikipedia.org/wiki/META_II)).

I think building self-specializing interpreters is the main trick. If that
becomes easy then a whole bunch of other magic is also possible. But I'm just
an amateur so all of this is still very impressive.

~~~
jakub_h
Since you mention OMeta, let me remark here that for some reason, this whole
Graal+Truffle thing looks to me like an "enterprisey" version of OMeta+COLA.

------
qwertyuiop924
Okay, very cute, but what if you want your language to have significant
semantic differences from C and the like? What if you want to write a Scheme
interpreter, for instance? Can I have Continuations? Can I have Tail Call
Optimization? I very much doubt it.

If you want to write a language that is semantically like C for the most part,
than go ahead and use Truffle, but that's not where interesting language
design is happening. Show me that Truffle's Ruby implementation hasn't removed
callcc (yes, Ruby has callcc), and maybe I'll reconsider.

~~~
Veedrac
You can do TCO relatively simply. You throw a special exception class for
nonlocal control flow (eg. tail calls, breaks from loops, continues, etc.) and
Graal knows how to optimize the cost away to a normal jump.

[http://cesquivias.github.io/blog/2015/01/15/writing-a-
langua...](http://cesquivias.github.io/blog/2015/01/15/writing-a-language-in-
truffle-part-4-adding-features-the-truffle-way/#a-lisp-birthright-tail-call-
optimization)

ZipPy (an incomplete Python implementation) supports Python's coroutines,
which are faster than any other implementation. In theory these might be
directly generalizable to get continuations.

[http://thezhangwei.com/documents/oopsla113-zhang.pdf](http://thezhangwei.com/documents/oopsla113-zhang.pdf)

~~~
qwertyuiop924
The TCO sounds like an ugly hack to me, but I'll take it. How would this
interact with the magical AST merging? I would assume that languages with
different calling conventions can't just merge like that.

~~~
grashalm
If you do it in a language specific way, you would probably need to catch
those TC exceptions when calling into functions of your language. That is very
easy to do, as every Truffle language controls how its functions get called in
a foreign languages.

~~~
qwertyuiop924
Ah.

------
dangerlibrary
There are a lot of weasel words for the other languages, but the comment about
ruby is extremely interesting:

"For example, the TruffleJS engine which implements JavaScript is competitive
with V8 in benchmarks. The RubyTruffle engine is faster than all other Ruby
implementations by far. The TruffleC engine is roughly competitive with GCC."

~~~
matthewrudy
Chris Seaton gave this talk recently about JRuby+Truffle and some specifics
about how it optimises so well compared to other Ruby implementations.

[https://youtu.be/b1NTaVQPt1E](https://youtu.be/b1NTaVQPt1E)

Previous discussion

[https://news.ycombinator.com/item?id=12062454](https://news.ycombinator.com/item?id=12062454)

~~~
vidarh
Chris is also reasonably active here.

I've had the pleasure of discussing some of his jRuby work with him in the
past (I occasionally plod along with own Ruby compiler in Ruby - it's nowhere
near complete) and they've done a lot of impressive work to demonstrate how
compiling Ruby into fast code is largely about assuming people will behave
sanely (e.g. people _won 't_ usually give Fixnum#+ side-effects, or make it
return weird stuff), but add fallbacks for when they do.

This is the big challenge with Ruby: The subset of Ruby that people actually
tend to work in is largely very predictable and possible to compile
efficiently, but there's a lot of stuff around the fringes that people expect
to work on the very rare occasions that we use it.

------
wellpast
I think another key part of the dream is IDE support. So maybe the dream is
complete with: Graal + Truffle + Nitra[1].

[1] Nitra -
[https://github.com/JetBrains/Nitra](https://github.com/JetBrains/Nitra)

~~~
zokier
How does Nitra and MPS fit together? They both come from JetBrains and both
describe themselves as "language workbenches"

------
Animats
So why is Oracle doing this?

Also, anything from Oracle which is partly open and partly closed is scary.
They've done that with Java and MySQL, which drives people away from both.

~~~
nickpsecurity
That was one of my counterpoints. We've seen Oracle fight to say API's are
copywritten and try to take down Android. All that kind of crap makes me think
safest route is pushing ETH/Wirth languages and/or Racket if you want DSL's
and stuff.

------
azakai
Graal + Truffle are very, very cool. The main downside is that it only runs on
the JVM, which is a substantial limitation.

However, I assume one goal of the project is to make the JVM more competitive,
which it certainly does.

------
rogerbinns
Have there been any recent languages/environments that (have reasonably)
succeeded but aren't completely open source? I feel a general resistance to
building a dependency on something when you don't have complete access to it,
but maybe that is just me.

~~~
ktRolster
_Have there been any recent languages /environments that (have reasonably)
succeeded but aren't completely open source?_

Xamarin. iOS too, although that depends on what you mean by 'recent'

~~~
rogerbinns
My comment was because I found it interesting that they are trying the
partially open source model, when it seems like that hinders adoption. So
'recent' is the competition for adoption.

Didn't a lot of Xamarin get open sourced after the acquisition? Swift is also
open source, although Xcode isn't.

~~~
ktRolster

      >Swift is also open source,
    

True, though practically speaking, it's not very usable without the (closed-
source) Cocoa libraries (much like objective-C).

------
TheMagicHorsey
Interesting. But I feel like Racket is a better framework for quickly
prototyping new languages.

~~~
trishume
Totally, Truffle is not nearly as easy as a simpler interpreter in a terser
language, but unlike a Racket interpreter your code can actually run faster
than raw Racket, and have incredible tooling and integration support.

------
kristianp
When I first heard about this it was promoted as a faster ruby implementation.
How far away is it from running rails?

Interesting that they've gone as far as running C extensions "internally",
making it easier to run existing ruby apps without running up against the
barrier of a native gem and having to change the code.

------
makmanalp
Previously:
[https://news.ycombinator.com/item?id=6232240](https://news.ycombinator.com/item?id=6232240)

------
wellpast
> Since the dawn of computing our industry has been engaged on a never ending
> quest to build the perfect language.

...unfortunately. I see PLs as mere material - sure, you can improve on them
but at far more important is how we architect our systems (the PL-independent
ways we create and organize our systems into interfaces and components) is
where I see the software practitioners of today flailing - and no PL is going
to save us there.

We need to have a better way to analyze systems on these architectural
measures and a better way to train people to build better architectures, not
more PLs.

~~~
stcredzero
_unfortunately. I see PLs as mere material_

That's only part of their point. It's as if we were in the building industry,
and we needed new tooling for each specific material. When I'm at a hackspace,
the same chop saw will let me cut wood, delrin rod stock, steel linear rails,
and aluminum extrusion. The same drill press and bits will operate just fine
on most of the above as well. What we have in the programming world is a
situation where I'd need a different toolset for every material I'd listed
above.

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

~~~
chrisseaton
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.

~~~
wcrichton
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.

~~~
dragonwriter
> Because Lisp is homoiconic, you don't code in (what I personally believe to
> be) reasonable syntax, you code in abstract syntax trees.

There's no reason a regular macro couldn't implement a basically C-like syntax
(though it would have Lisp, not C, tokenization rules, to the extent that
those are different) on what is passed as its argument. The actual call to the
macro would have typical Lisp syntax, but what the macro consumes would be
interpreted with whatever syntax was implemented by the macro.

(And, a _reader_ macro could implement more deeply C-like syntax.)

~~~
qwertyuiop924
Well, for regular macros, only if your C syntax was in a string. Otherwise,
lisp would try to tokenize it, and choke. Heck, if your lisp of choice offers
an eqivalent of TCL's uplevel, you wouldn't even need a macro, just a
function.

~~~
dragonwriter
> Well, for regular macros, only if your C syntax was in a string. Otherwise,
> lisp would try to tokenize it, and choke.

Which is why I said normal (rather than reader) macros could do a "basically
C-like syntax" but with Lisp tokenization rules.

~~~
qwertyuiop924
What would that look like?

~~~
TJSomething

      ((:include "stdio.h")
      
      (const char * message = "Like this.\n")
      
      (int main ((int argc) (char * * argv))
        (printf message)
        (return 0)))

~~~
qwertyuiop924
Ah.

------
cpeterso
Here is a video of a Graal/Truffle talk given by a researcher at Oracle
(presented at Mozilla in 2013):

[https://air.mozilla.org/one-vm-to-rule-them-
all/](https://air.mozilla.org/one-vm-to-rule-them-all/)

~~~
grashalm
This is quite outdated. here is an overview of Graal/Truffle papers and
tutorials:
[https://wiki.openjdk.java.net/display/Graal/Publications+and...](https://wiki.openjdk.java.net/display/Graal/Publications+and+Presentations)

~~~
iso-8859-1
Is this one less outdated?
[https://www.youtube.com/watch?v=FJY96_6Y3a4](https://www.youtube.com/watch?v=FJY96_6Y3a4)

~~~
grashalm
Yes this brand new. Have fun!

------
ricardobeat
> Interpreted dynamic languages like Python, JavaScript, PHP and Ruby look the
> way they do because building such a language is the path of least resistance
> when you start from a simple parse tree.

This looks... backwards?

~~~
stormbrew
Especially if you want to talk about ruby as a language with a simple parse
tree.

------
zzzcpan
So, judging by the slides for that "one vm to rule them all" talk [1], it's
Java all the way. One has to generate AST in a form of Java code and deal with
Java ecosystem. And it feels all very very complicated for all the wrong
reasons.

I guess some people from the Java world could find something useful there, but
it's very unlikely to attract anyone else.

[1] [https://lafo.ssw.uni-
linz.ac.at/pub/papers/2016_PLDI_Truffle...](https://lafo.ssw.uni-
linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf)

------
carapace
Well now, I have _got_ to find time to implement Joy (lang by Manfred von
Thun) in this and see if it works. (I can't tell just by thinking about it, at
least not so far. It will either work and be great, or not-work and be really
_really_ interesting why not.)

------
polskibus
This article, while very interesting, completely ommitted .NET CLR. Does
anyone know how does the CLR compare to JVM, especially the new CoreCLR? How
maturę is it in terms of using the best of breed JIT optimizations?

------
ktRolster
fwiw IO language is a pretty good prototyping language too.....good for
experimenting with different syntaxes, etc

------
desireco42
One word: Oracle.

~~~
carterehsmith
To be fair, Oracle gives you things such as VirtualBox, MySql, Java, Netbeans
etc for free. That's not too bad for an 'evil' company.

~~~
wilonth
No it doesn't, they are made by Sun Microsystems, they are free because of
Sun, not Oracle.

~~~
carterehsmith
That's just not true.

Consider all the improvements to the above software that came after Oracle's
purchase of Sun. There was a boatload of them and they keep coming. Oracle is
paying for that.

They are all free, and that is because of Oracle, not because of Sun as Sun
does not exist anymore.

~~~
wilonth
Improvements? How much? They ruined OpenOffice, triggering the LibreOffice
fork. They ruined MySQL, triggering the MariaDB fork. The original Sun would
have done 10X better improving those things they made.

------
ilostmykeys
Funny, I posted this yesterday and got no up votes. Can you post a duplicate
of some post and get up voted? I didn't realize that was possible.

~~~
chrisseaton
Take a look at the Medium URLs and you'll see they have a fragment ID and so
count as different submissions.

~~~
trishume
I wondered why this didn't get merged with my submission. Makes a neat example
of how random getting on the HN front page is though. Although I'm sad that
randomness chose to give the second posting karma instead of mine.

~~~
grashalm
What was your title? Without a good one, your post might have been just
skipped by most.

~~~
trishume
Exactly the same except including the "radically" from the blog post. Wow I
missed out on 400+ karma at this point... Oh well, at least they are only
internet points.

~~~
grashalm
These people and their gamified minds... ;)

