I'm so impressed watching Notch program in realtime. "Last Minute Christmas Chopping" was an eye opener for me. (http://www.ludumdare.com/compo/ludum-dare-28/?action=preview...). I was totally baffled when he started to draw the ascii character map pixel by pixel in an 48h competition, but the result was usable and actually quite simple.
My takeaway is this: Doing something quick and dirty for a first draft and improve it later on often leads to better results in the long run than planing and over-engineering a solution beforehand, because you can start refining details much earlier or throw away bad approaches without investing too much time.
What I don't get is, why he seems to like Dart so much. Don't get me wrong: I love Dart as an language. The syntax looks very familiar to someone coming from c#, adds syntactic sugar and the editor, with line step debugger, is great. But in the end it's still javascript which makes it hard to create native and mobile builds. Wouldn't Haxe be more suitable?
Your takeaway reminds me of this quote from John Carmack:
"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better."
> But in the end it's still javascript which makes it hard to create native and mobile builds.
It's not "still JavaScript." Dart has its own VM and own libraries. Yes, you end up deploying to JavaScript in most scenarios, but Dart is its own platform which can live on its own in the server context and when the Dart VM is integrated with Chrome, on the client side too. I know what you meant, but the way you worded it does a disservice to Dart, making it sound like another CoffeeScript.
> What I don't get is, why he seems to like Dart so much.
Dart has a good mix of fast live-reload dev workflow, great IDE editing and debugging experience as well as productive optional typing analysis and feedback. Which seems to suit @notch's GTD/experimental coding style.
Idunno, I think there's room for admitting you have eclectic tastes and throwing in some compromises and making a game that isn't exactly your perfect fantasy but is something that includes elements you love in a way that's accessible to everybody else.
> My takeaway is this: Doing something quick and dirty for a first draft and improve it later on often leads to better results in the long run than planing and over-engineering a solution beforehand, because you can start refining details much earlier or throw away bad approaches without investing too much time.
I like Dart because it supports what you've described really really well. Optional type annotations enable you to don't worry about types when you do rapid prototyping.
Once your understanding of a good solution solidifies you can sprinkle type annotations over function signatures and wherever it makes sense to get great tooling support and to fortify core parts of your code base :)
In a nutshell it enables project lifecycles many companies go through many times (something written in Ruby eventually might have to be rewritten in Java for performance and tooling/collaboration support) yet being able to stick to one language which removes a ton of complexity.
I agree, Dart offers alot regarding prototyping. Maybe I'm thinking too much, but I believe native os and mobile targets are simply too important in the gaming industry and therefore it's difficult to leverage the device capabilities if your primary target is the web & webgl.
I guess, what I miss most is cross compilation, which would be totally awesome. But Dart moves slowly and I'm very hesitant to invest in a platform where its fate relies on the adoption in browsers. (how long until the Dart VM runs in chrome, ff, ...?)
The dart people seem to be focussed on getting it to generate code that is at fast as handwritten JavaScript. If they get there then you won't have to worry about a dart VM in a browser (won't happen in a non Google browser anyway). You still have really rapid development and rich debugging with the dartium browser (like notch) and you can use a dart VM on the server for faster than js performance.
>Doing something quick and dirty for a first draft and improve it later on often leads to better results in the long run than planing and over-engineering a solution beforehand, because you can start refining details much earlier or throw away bad approaches without investing too much time.
If it's something not too big, sure. Won't work so well if you don't know what to even do because you don't have any idea what the structure of the program's going to be like. I've found planning much more beneficial for myself.
>My takeaway is this: Doing something quick and dirty for a first draft and improve it later on often leads to better results in the long run than planing and over-engineering a solution beforehand, because you can start refining details much earlier or throw away bad approaches without investing too much time.
I think it depends on what you're doing, I doubt it works for every project out there.
My takeaway is this: Doing something quick and dirty for a first draft and improve it later on often leads to better results in the long run than planing and over-engineering a solution beforehand, because you can start refining details much earlier or throw away bad approaches without investing too much time.
What I don't get is, why he seems to like Dart so much. Don't get me wrong: I love Dart as an language. The syntax looks very familiar to someone coming from c#, adds syntactic sugar and the editor, with line step debugger, is great. But in the end it's still javascript which makes it hard to create native and mobile builds. Wouldn't Haxe be more suitable?