41–50 of 78 posts
I can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
I really liked the turkey, and I thought the solution looked elegant, so I had a go at it in CoffeeScript and node-canvas: https://gist.github.com/1475034 All requests in less than 66 ms, mean less than 19 ms.
Earlier quoted context omitted.
Well I'm the guy who runs that particular blog, and I can tell you I'm no marketing guru. While Reinaldo and I edited the post together, I'm pretty sure that the line was in his original text. (Just checked: it was.) Maybe people keep saying Go feels like an interpreted language because it feels like an interpreted language? :-)
I've done a fair bit of Go programming ( https://github.com/jbarham ), but have programmed professionally mostly in Python for the past 10 years, and for me Go does feel an interpreted language because it requires so few type declarations compared to mainstream statically typed languages like C++ or Java. Checking the app source code for the article at http://code.google.com/p/go-thanksgiving/source/browse/app/a... ,…
I can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
// Pseudo Go:
maybe_paths := filepath.Glob(dir + "/*.png")
case maybe_paths of {
Some paths: {
// Do things with paths
}
None: {
// Handle error case
}
}
Furthermore, not having sum types forces us to include a distinguish value `null` for reference (pointer) types, as a way to communicate "no value". This is bad as now we cannot distinguish references that should never be `null` from those than can be `null`.
I can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
[1] http://www.gigamonkeys.com/book/beyond-exception-handling-co...
This is quite offtopic, but if even programmers are using jpeg when they should use png, what hope is there for anyone else? The images this generates have mostly flat areas of all one color - it should have been a png.
Earlier quoted context omitted.
AppEngine instances, unless they're running in a special backend instance, exist in a special containerized machine. These machines are very slow and don't have much RAM - 600 MHz and 128 MB. Based on the source that was posted on the blog, this app was running on a normal instance, as the source did not contain a backends.yaml file. So it makes sense that a Core 2 Duo running at 2.13 GHz and slow CoffeeScript would…
This isn't true any more. They recently announced faster frontend instances with more memory ( http://googleappengine.blogspot.com/2011/12/app-engine-161-r... ), and I'm willing to bet this has been available internally since long before Thanksgiving. I'd bet money that this app used the beefiest class of frontend instances.
I can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
Bruce Eckel on exceptions and Go: http://www.artima.com/weblogs/viewpost.jsp?thread=331407
I can't help but cringe whenever I read Go code because the following: paths, err := filepath.Glob(dir + "/*.png") if err != nil { panic(err) } is repeated over and over again. Didn't we learn in the 90's that exceptions are far, far superior to return codes?
Not really, no. I've always found them more trouble than they're worth. Explicit, in-line error handling works much better for me. I'm not sure what you mean by "over and over again," in this context, though. There are only three error checks of that kind in this program. It's an unusual program anyway, in that _any_ error condition jumps to the same path: displaying the default image. In most programs you want finer…
In my view, all attempts at making a distinction between recoverable and non recoverable errors inevitably fail simply because it is a non local distinction that cannot be made for any particular piece of code in isolation.