Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

Post reply on HN
Print view View original

41–50 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#41

Post by kbenson »

nostrademons wrote: post #17

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 la…

> It's a great tool if you work in the JVM ecosystem and want to play around as a language designer.

Except that it's not really exposing much of the JVM from what the article mentions, it just uses the JVM as a base. That is, Truffle languages can talk to other truffle languages, but I'm not sure how easy it is for a truffle language to talk to a JVM language.

From everything I read, it seems like people thought Parrot was a good idea so decided to rewrite/reimagine it using the JVM instead of C as a base.

Re: Graal and Truffle could accelerate programming language design

#42

Post by stormbrew »

ricardobeat wrote: post #33

> 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?

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

Re: Graal and Truffle could accelerate programming language design

#43

Post by jackmott »

nostrademons wrote: post #17

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 la…

F# isn't much like C#, and in fact it does suffer a bit for it, as some of the back end causes compromises in the F# language. Mutable fields in records have secret baggage, functions with arithmetic operators can't be automatically genericized unless you mark them inline, etc

Re: Graal and Truffle could accelerate programming language design

#44

Post by wcrichton »

chrisseaton wrote: post #28
lisper wrote: post #22

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

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.

Re: Graal and Truffle could accelerate programming language design

#45

Post by stcredzero »

wellpast wrote: post #4

> 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 goi…

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.

Re: Graal and Truffle could accelerate programming language design

#46

Post by stcredzero »

bostonpete wrote: post #26
lisper wrote: post #22

> 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'm vaguely familiar with Lisp, but I'm not a Lisp programmer. Can you explain this comment?

It's much the same in Smalltalk. Often, one could create a domain-specific superset of Smalltalk, complete with its own control structures.

Re: Graal and Truffle could accelerate programming language design

#47

Post by IanCal »

speeder wrote: post #29

Ask HN via comment hijacking due to the Ask HN post also failing with various errors: I want to submit a story about WhatsApp being blocked in Brazil, again. My first attempts told me I was submitting too fast (but I didn't submitted anything in a LOOOONG time... I am slow-banned or something?) Then I thought it was a bug due to me having a invalid character in the title, when I attempted to submit it again with the…

There is a contact link at the bottom of the page : hn@ycombinator.com

Re: Graal and Truffle could accelerate programming language design

#48

Post by dkarapetyan »

Doesn't RPython do all the same things? Also there are language workbenches (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).

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.

Re: Graal and Truffle could accelerate programming language design

#49

Post by Cacti »

nostrademons wrote: post #17

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 la…

We should be clear here by what we mean by language.

It's perfectly possible and manageable to create cross-language VMs and to translate pretty accurately between languages. However, what breaks down, as you alluded to, is that people expect the standard libraries, and the libraries of others, to work interchangeably, and that is orders of magnitudes more complex (mostly because you are, by definition, working closer to the metal).

So, I need to ask, how much research is being done in giving the standard library as much consideration as the language? Do we have a grasp on what it would take to treat the stdlib as a "first class" citizen?

Re: Graal and Truffle could accelerate programming language design

#50

Post by JohnStrange »

outworlder wrote: post #27

> 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…

The majority never picks the best and markets do not optimize as much as some people think. Whether it's movies, arts, books, music, politicians, keyboards or programming languages, the most popular choices are practically never the best ones.

Which is probably why a technocracy in which every voter must pass a fact-based proficiency test before being allowed to vote might trump democracy. Not sure, just wanted to chime in with being cynical. :/

Post reply on HN