Live data from Hacker News

Graal and Truffle could accelerate programming language design

medium.com

191–200 of 204 posts

Re: Graal and Truffle could accelerate programming language design

#191

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…

As a specific example, Graal is built on the JVM. I'd be interested to see if they have support for languages that require tail call optimization (haskell, scheme) as the JVM cannot work with TCO languages.

Re: Graal and Truffle could accelerate programming language design

#192

Earlier quoted context omitted.

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

Most programmers are average though, so it helps to have languages that make it harder for you to introduce bugs.

Re: Graal and Truffle could accelerate programming language design

#193

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…

> Given a good foundation, which could be Lisp or something even better, you can whip up the "simpler" languages in no time.

In practise, that foundation (for many programs) is Java byte code.

Re: Graal and Truffle could accelerate programming language design

#194

Earlier quoted context omitted.

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.

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

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.

Re: Graal and Truffle could accelerate programming language design

#195

Earlier quoted context omitted.

Who gets to determine which facts? Why would that group not use that to their advantage, instead of to the benefit of everyone? > 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. The question is not whether the market picks t…

> The question is not whether the market picks the optimal outcome, but whether a committee of experts would do better. The experience of central planning within the Warsaw Pact should hint at the answer... The experience of the entire Internet seems to suggest a different answer, so it's not that central planning is always bad. Note that the best, most reliable, most stable parts of the Internet were invented and co…

> Today we can rarely if ever agree on any kind of protocol or standard, and if we do, it's usually a huge bloated mess.

So the question becomes, how do you know whether you're going to get a huge bloated mess or the Internet, and how do you influence the outcome?

As the number of potential 'experts' increases and the number of people involved in choosing them increases, you get something that looks more and more like a market, but without price transparency...

Re: Graal and Truffle could accelerate programming language design

#196

Earlier quoted context omitted.

I agree with your entire comment. However, I also agree the point the op authors make about tooling being reimplemented time and time again, taking years to get anywhere near the point represented by the 1st 9-point wishlist. What the programming field could do, which would be awesome, would be to implement language category backends that follow your "mostly like" categorization. These backends would be engineered to…

We already that in the form of Lisp and Smalltalk. Sadly that's not what the majority of programmers want to use.

We need something with the capabilities of Lisp and Smalltalk but with syntax more like Ruby or Python.

Re: Graal and Truffle could accelerate programming language design

#197

Earlier quoted context omitted.

This is quite outdated. here is an overview of Graal/Truffle papers and tutorials: https://wiki.openjdk.java.net/display/Graal/Publications+and...

Is this one less outdated? https://www.youtube.com/watch?v=FJY96_6Y3a4

Yes this brand new. Have fun!

Re: Graal and Truffle could accelerate programming language design

#198

Earlier quoted context omitted.

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

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.

These people and their gamified minds... ;)

Re: Graal and Truffle could accelerate programming language design

#199

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…

As a specific example, Graal is built on the JVM. I'd be interested to see if they have support for languages that require tail call optimization (haskell, scheme) as the JVM cannot work with TCO languages.

You apparently can, cf http://cesquivias.github.io/blog/2015/01/15/writing-a-langua...

Re: Graal and Truffle could accelerate programming language design

#200

Earlier quoted context omitted.

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.

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

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.

Post reply on HN