Graal and Truffle could accelerate programming language design • Hacker News Board

Re: Graal and Truffle could accelerate programming language design

#31

Post by pjmlp » Tue, Jul 19, 2016, 5:47 PM UTC

the_duke wrote: post #23

geodel wrote: post #12

Earlier quoted context omitted.

I agree mostly. Any Java application which does not need GUI other than web is just fine in most use cases.

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 systems, think that their Solaris UIs (SunView, OpenWindows, CDE) weren't that great in that area.

So most Java developers stick with the defaults and as such the majority of Java based applications send the wrong message.

Re: Graal and Truffle could accelerate programming language design

#32

Post by ktRolster » Tue, Jul 19, 2016, 5:50 PM UTC

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

Re: Graal and Truffle could accelerate programming language design

#33

Post by ricardobeat » Tue, Jul 19, 2016, 5:53 PM UTC

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

Re: Graal and Truffle could accelerate programming language design

#34

Post by ktRolster » Tue, Jul 19, 2016, 5:53 PM UTC

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

Re: Graal and Truffle could accelerate programming language design

#35

Post by ktRolster » Tue, Jul 19, 2016, 5:54 PM UTC

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'

Re: Graal and Truffle could accelerate programming language design

#36

Post by hobs » Tue, Jul 19, 2016, 5:54 PM UTC

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…

Do a little googling and you wont get a downvote: https://news.ycombinator.com/item?id=7494732

dang's profile https://news.ycombinator.com/user?id=dang with contact information.

Re: Graal and Truffle could accelerate programming language design

#37

Post by pjmlp » Tue, Jul 19, 2016, 5:55 PM UTC

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…

Well you have the mainframes model that used kernel JITs for all their official languages, like the OS/400 nowadays IBM i.

On IBM i the language surface is RPG, Cobol, C, C++ and Java.

On other ones you could eventually consider the micro-coded CPUs as a kind of cross language VMs.

Re: Graal and Truffle could accelerate programming language design

#38

Post by shoyer » Tue, Jul 19, 2016, 5:56 PM UTC

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…

At the very bottom of every Hacker News page, there is a contact link: hn@ycombinator.com

Re: Graal and Truffle could accelerate programming language design

#39

Post by stcredzero » Tue, Jul 19, 2016, 5:56 PM UTC

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…

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 satisfy the wish lists, but be tailored to certain specific domains. (System programming, hard real-time, soft-real-time, high level dynamic programming...) From what I can see, we're a good part of the way there already. (Graal and Truffle, LLVM, GUILE)

"Little languages" can have significant advantages over APIs in terms of flexibility, optimization, and conceptual fit with specific domains. Why not create infrastructure to not only de-duplicate work creating tooling for languages while ensuring everyone always had 1st-class tooling and making "little languages" as easy to create as APIs?

Re: Graal and Truffle could accelerate programming language design

#40

Post by ktRolster » Tue, Jul 19, 2016, 5:57 PM UTC

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.

Could you re-implement a language such as C as a macro?

You can do that pretty quickly in IO language (admittedly, that's not Java)