Live data from Hacker News

Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

github.com

41–50 of 82 posts

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#41
post #32
post #28

Earlier quoted context omitted.

This may be a problem if your truck breaks down in the desert, your 3g is out of range and you never thought to install an ide beforehand but apart from that when would you find yourself writing java without an ide?

When you're using somebody else's computer.

When was the last time any professional software developer was forced to do any real development on someone elses computer? In that case it is likely that one will miss his keyboard, desktop shortcuts, shell aliases, browser bookmarks much more than tour ide.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#42
"Rootbeer was created using Test Driven Development and testing is essentially important in Rootbeer"

I'm not sure what the "essentially" means here, but this is the first "big" program I'm aware of that name-checks TDD, and a counter-example to my theory that programs where much of the programmer effort goes into algorithms and data structures are not suited to TDD.

Was the TDD approach "pure"? (Only one feature implemented at a time, with absolutely no design thought given to what language features might need to be implemented in the future.)

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#43

Earlier quoted context omitted.

It's a problem with a language if it requires heavyweight environments to make aspects of writing code in it acceptable.

This Writing Java is unbearable without Eclipse/Netbeans. .NET a little bit less unbearable If your IDE "works harder" than your compiler, something seems wrong to me (of course we all expect things like syntax highlighting today)

It's not unbearable, I've done a huge amount of Java coding on the command-line. Yes, it's harder, but I strongly believe it's better to move onto Eclipse only after learning how the tools actually work underneath. It makes it far easier to debug weird issues with the IDE, and means you're not SOL if the IDE breaks, or you're on another person's computer - you're just a bit slower, and I'd argue that applies to all tools (custom aliases, bash scripts, vim config) and not just IDEs.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#45
post #42

"Rootbeer was created using Test Driven Development and testing is essentially important in Rootbeer" I'm not sure what the "essentially" means here, but this is the first "big" program I'm aware of that name-checks TDD, and a counter-example to my theory that programs where much of the programmer effort goes into algorithms and data structures are not suited to TDD. Was the TDD approach "pure"? (Only one feature imp…

I'd think a project like this is ideally suited to TDD: you know what the results should be for most operations, and they are easily testable. It's the same reason the Perl 6 test suite has been so valuable to the various Perl 6 compiler projects. (Not that any of them claim to use TDD.)

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#46
> The license is currently GPL, but I am planning on changing to a more permissive license. My overall goal is to get as many people using Rootbeer as possible.

It would be bad to compromise the freedoms of the users in order to be able to limit the freedoms of more of them.

Any reason why the GPLv3 would be considered unsuitable? How about the LGPLv3?

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#47

I had forgotten just how much I hate java namespaces. import edu.syr.pcpratts.rootbeer.testcases.rootbeertest.serialization.MMult; This seems like a pretty amazing project if the claims are true, though - I wasn't aware that CUDA was able to express so many of the concepts used to implement Java applications. The performance data in the slides is certainly compelling!

That is an unusually long namespace. It says more about the coding style of the programmer that wrote it than it does about Java.

After a while, most Java developers start thinking it's ok to build deep hierarchies of modules.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#48
post #15

Earlier quoted context omitted.

import edu.syr.pcpratts. ; The only reason you see the fully qualified class names is because the IDE does this automatically for you. If there were no IDEs everyone would be using the *s;

Wildcard imports are a bad idea regardless of whether you're using an IDE or not due to the risk of future name conflicts.

This sentiment is dogma from long ago when there was a slight performance improvement for individual imports. Today, there is no such performance advantage. Their risk of a namespace collision, but in practice, it is very rare and very easy to identify when it does. The main reason it remains is mainly due to default IDE configuration.

On the flip side, wildcard imports make coding much more fluid and concise. How many times have you had to hit ctrl+space two or more times in the same declaration to add import statements for interfaces and classes from the same package? IMHO, explicit imports greatly decrease the usefulness of the static import feature.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#49
post #24

Earlier quoted context omitted.

My point was more than Java namespaces can be easy to use. Pretty much everyone uses an IDE anyway so it's not like namespaces are ever an issue unless you do come across that rare name clash.

> Pretty much everyone uses X anyway so it's not like Y are ever an issue This 'its good enough, and everyone does it anyway' attitude leads us to incredibly damaging status quos.

Often though, "good enough" really is good enough. You can spend untold man hours trying to get that last little bit of perfection and never really achieve it anyways.

Re: Rootbeer GPU Compiler Lets Almost Any Java Code Run On the GPU

#50

Earlier quoted context omitted.

This Writing Java is unbearable without Eclipse/Netbeans. .NET a little bit less unbearable If your IDE "works harder" than your compiler, something seems wrong to me (of course we all expect things like syntax highlighting today)

Meh. It's about trade-offs. Some languages are designed to be lightweight and require minimal assistance from the IDE. Some languages are optimised for very large codebases and expect a lot of "ceremony and plumbing" around them. And then there are, of course, millions of shades between the two extremes. Java and C# are in the second group. These are all very useful tools when used for the right purposes. (Also I hav…

Java pretty much created the concept of a modern IDE where the editor knows about the libraries and does boilerplate expansion for you. This wasn't generally needed before the age of Java.
Post reply on HN