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

61–70 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#61

Post by outworlder »

ktRolster wrote: post #34
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…

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…

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

Re: Graal and Truffle could accelerate programming language design

#62

Post by [deleted] »

azakai wrote: post #25
the8472 wrote: post #16

Earlier quoted context omitted.

Startup times are mostly important for scripting or running things in the browser. If you start applications once on the server or desktop and keep them running then steady-state performance is more important. There also are projects underway to bring AOT compilation / caching of compiled code to the JVM. Right now they're only available to commercial customers due to their experimental nature and the needed support…

True about AOT coming to the JVM, however, dynamic languages can't be AOT'd well in general, so that won't help Graal+Truffle languages much. Instead, dynamic languages tend to do tiering, which in principle is something Graal+Truffle could do, but it might be a lot of work.

[deleted]

Re: Graal and Truffle could accelerate programming language design

#63

Post by kodablah »

frankpf wrote: post #24
kodablah wrote: post #11

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

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 [1]: http://c9x.me/compile/

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

Re: Graal and Truffle could accelerate programming language design

#64

Post by rogerbinns »

ktRolster wrote: post #35
rogerbinns wrote: post #6

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.

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'

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.

Re: Graal and Truffle could accelerate programming language design

#65

Post by pnathan »

chrisseaton wrote: post #58
pnathan wrote: post #54

Earlier quoted context omitted.

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.

Honestly, the front end would be about as hard, unquestionably! But the Lisp ecosystem is already in play, whereas you seem to have had to build that ecosystem. That is to say, it's not a major effort to scrape through the Lisp systems to understand what is going on, whereas your ecosystem with Graal etc required a great deal of work, it seems to be. Would that be correct? Or was it pretty plug and play after you had JVM bytecode?

Re: Graal and Truffle could accelerate programming language design

#66

Post by nostrademons »

eregon wrote: post #53
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…

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

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.

Re: Graal and Truffle could accelerate programming language design

#67

Post by ktRolster »

outworlder wrote: post #61
ktRolster wrote: post #34

Earlier quoted context omitted.

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…

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

The reality is: programming languages are fun, but the programming language is not the biggest barrier to writing good code, or even getting it done quickly.

Good programmers can write good code in any language, lousy programmers will write lousy code in every language. Malbolge might be excluded from that, but with a decent macro pre-processor, even brainfuck can be workable.

Re: Graal and Truffle could accelerate programming language design

#68

Post by dragonwriter »

wcrichton wrote: post #44
chrisseaton wrote: post #28

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

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

Re: Graal and Truffle could accelerate programming language design

#69

Post by wcrichton »

lisper wrote: post #60
wcrichton wrote: post #44

Earlier quoted context omitted.

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 ? The code for this is here: https://github.com/rongarret/ergolib

For sure, I was just considering normal macros.

Re: Graal and Truffle could accelerate programming language design

#70

Post by ktRolster »

rogerbinns wrote: post #64
ktRolster wrote: post #35

Earlier quoted context omitted.

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'

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.

  >Swift is also open source,
True, though practically speaking, it's not very usable without the (closed-source) Cocoa libraries (much like objective-C).
Post reply on HN