I could be wrong, but I don't believe the existence of Go was much of a problem. Go and Dart are very different languages aimed for very different use cases. If anything, I think Go helped us because we could point to it as a successful language that Google hasn't cancelled.
> not that far from Java
This is something that hurt us, I think. You can write Dart code that looks a lot like Java, and many of our early public examples did. To make matters worse, for no good reason, Dart 1.0 didn't do any type inference, so even though you could use "var" for local variables, doing so would give you a worse user experience.
But you don't have to write Java in Dart. You can write really elegant, clean code in Dart in a way that Java doesn't enable. You don't have to stuff everything inside classes. We've always had nice terse lambdas, higher-order functions, collection literals, etc.
Here's a random little program of mine:
import 'package:hauberk/src/engine.dart';
import 'package:hauberk/src/content.dart';
main() {
var content = createContent();
var save = content.createHero("blah");
while (true) {
var watch = Stopwatch();
watch.start();
// Generate a dungeon at each level.
var count = 0;
for (var i = 1; i <= Option.maxDepth; i++) {
var game = Game(content, save, 1);
for (var _ in game.generate());
// Read some bit of game data so the JIT doesn't optimize the whole
// program away as dead code.
if (game.hero.pos.x >= -1) count++;
}
watch.stop();
print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms");
}
}
It's not the most beautiful code in the world, but I do think it's a good bit simpler and cleaner than it would be in Java.
The thing is, this is almost identical to well written JavaScript. In fact you could do almost all of this in JS even before ES5. So the non-Java-like features you're using here were already present, which again suggests that Dart isn't really getting past the "Good Enough" problem.
It's also something you could do in Java, with the exception of having to wrap main with the obligatory EntryPoint class.
I think this just goes to show that good code can be written in almost any language (except Perl of course) because writing good code almost always just means writing obvious code, which necessitates avoiding cleverness and obscure features (literally all of Scala), twisting control flow (I'm looking at you State monads and call/cc), or adding too many indirections due to limitations of the language (Java).
Why was "except Perl of course" needed here? Do you have any data to back up that you can not write well written code in Perl? Or are you just simply venting your prejudices?
> I could be wrong, but I don't believe the existence of Go was much of a problem.
It wasn't so much Go per se, but the fact that Google was pushing two new languages at the same time. It created the perception, for me at least, that Google was pushing out new languages to see which ones stuck and kill those that didn't. Google had/has the reputation for killing off projects that it lost interest in. And I wasn't willing to learn new a new language and its ecosystem only to be marooned there a few years later.
So, while I was definitely interested in alternatives to JS, there was no way I'd pick up on Dart.
Totally agree. Also, Go was refreshing. Intentionally limited, yes, but simple-yet-powerful. Then they show off Dart and it looked like yet another 90's-style curly-brace language, and I'm sure I'm not the only one who asked "why bother?".
That is nice. It's also almost indistuishable from Java 10. The string interpolation at the end is the last big syntactic nicety Java is missing - at least relative to this example.
Yes it is a little nicer than Java 11, but not so much to really make a difference, while throwing away all the Maven central goodies.
import engine.*;
import static content;
import static java.lang.System.out;
public class Demo {
public void main(String args[]) {
var content = createContent();
var save = content.createHero("blah");
while (true) {
var start = System.currentTimeMillis();
// Generate a dungeon at each level.
var count = 0;
for (var i = 1; i <= Option.MAX_DEPTH; i++) {
var game = new Game(content, save, 1);
for (var ignored : game.generate());
// Read some bit of game data so the JIT doesn't optimize the whole
// program away as dead code.
if (game.hero.pos.x >= -1) count++;
}
var stop = System.currentTimeMillis();
var elapsedMilliseconds = start - stop;
out.printf("Generated %d dungeons in %dms\n", count, elapsedMilliseconds);
}
}
}
> I do think it's a good bit simpler and cleaner than it would be in Java.
Is it really? My Java is rusty, but now that Java has type inference it looks nearly exactly like what you'd type in Java (minus `public static void`, `new`, etc.)
I removed everything that seems redundant. Less syntax means less to break, and less for new programmers (who are 10x the volume of existing programmers) to learn:
import 'package:hauberk/src/engine.dart'
import 'package:hauberk/src/content.dart'
content = createContent()
save = content.createHero("blah")
while (true)
watch = Stopwatch()
watch.start()
# Generate a dungeon at each level.
count = 0
for (i = 1; i <= Option.maxDepth; i++)
game = Game(content, save, 1)
for (_ in game.generate())
# Read some bit of game data so the JIT doesn't optimize the whole program away as dead code.
if (game.hero.pos.x >= -1) count++
watch.stop()
print("Generated $count dungeons in ${watch.elapsedMilliseconds}ms")
Separating variable declaration and reassignment at a glance makes code more clear. Indenting loop bodys makes code more clear, and the curly braces won't suddenly break. Keeping lines short makes it nicer to work with in various editor setups.
> Separating variable declaration and reassignment at a glance makes code more clear.
Hrm, maybe. Python does well not using them - if you reassign something, it's being reassigned. Maybe, since declaration is more common, make declaration the default and reassignment explicit?
> Indenting loop bodys makes code more clear
Glad you agree.
> curly braces won't suddenly break
They do all the time, everytime indentation (how people read coe) gets out of sync with braces. Hence avoiding redundancy.
> Keeping lines short makes it nicer to work with in various editor setups.
Displaying code to match the screen is the editors job. Sometimes your screen is 30 characters, sometimes it's a lot more.
> not that far from Java
This is something that hurt us, I think. You can write Dart code that looks a lot like Java, and many of our early public examples did. To make matters worse, for no good reason, Dart 1.0 didn't do any type inference, so even though you could use "var" for local variables, doing so would give you a worse user experience.
But you don't have to write Java in Dart. You can write really elegant, clean code in Dart in a way that Java doesn't enable. You don't have to stuff everything inside classes. We've always had nice terse lambdas, higher-order functions, collection literals, etc.
Here's a random little program of mine:
It's not the most beautiful code in the world, but I do think it's a good bit simpler and cleaner than it would be in Java.