51–60 of 78 posts
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.
Would the size of the png's be smaller?
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?
Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions): // Pseudo Go: maybe_paths := filepath.Glob(dir + "/*.png") case maybe_paths of { Some paths: { // Do things with paths } None: { // Handle error ca…
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?
Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions): // Pseudo Go: maybe_paths := filepath.Glob(dir + "/*.png") case maybe_paths of { Some paths: { // Do things with paths } None: { // Handle error ca…
The entire reason Go has multiple return values for functions (such as paths and err in this case) is to avoid having to encode errors in the "real" function result.
Now I agree, that this is less nice as say pattern matching and real sum types, but if you know how to appreciate those just switch to a functional language!
Maybe its just me but all blogpost about go read like they where checked by a marketing guru after the have been written. The always enforce the same basic points, it always sound the same. If I somebody says "go" my mind alwasys jumps to "feels like a interpreted language".
Its stuck me several times how defensive and no-I'm-right the go crowd gets when anyone dislikes it. Try jumping on the google group sometime.
Anyone remember that academic paper about relative speeds of c, go and something or another? As I recall Andrew went out of his way to reimplement the whole thing in go, and make a few snarky comments about "I wonder where they got those bench marks from, because that's not what I saw".
This was interesting because I've never seen Go used in production yet. However, the solution is not optimal for performance (as his benchmarking suggests is one of the goals). If there is a finite number of possible images and each image takes CPU time to generate, then why not lazy cache the images in a CDN after generating them once?
Earlier quoted context omitted.
Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions): // Pseudo Go: maybe_paths := filepath.Glob(dir + "/*.png") case maybe_paths of { Some paths: { // Do things with paths } None: { // Handle error ca…
You can distinguish between nulls which are errors and nulls that are just the actual return value. That is what err is for . The entire reason Go has multiple return values for functions (such as paths and err in this case) is to avoid having to encode errors in the "real" function result. Now I agree, that this is less nice as say pattern matching and real sum types, but if you know how to appreciate those just swi…
That's nonsense, MRVs are tuples (conceptually, Go implemented them with special syntax because... well, it's Go so it could not go with the general principle now could it?), so Go very specifically encodes errors in the function result.
And using a sum type would encode the error in the type, not in the result itself.
Earlier quoted context omitted.
Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions): // Pseudo Go: maybe_paths := filepath.Glob(dir + "/*.png") case maybe_paths of { Some paths: { // Do things with paths } None: { // Handle error ca…
This kind of fussy type system is at odds with Go's design goals. It would make the language more abstracted from the underlying machine for little gain. I can't think of an instance of the issue you describe causing problems in real Go code.
There is nothing fussy about it, and the only way in which it's at odds with Go's design goals is that Go's design goals include things like "fuck you, only core types get to be generic", "that these mistakes were resolved 20 years ago does not mean we're not going to re-introduce them" and "if we give it a different name it's not the same thing, nah nah nah".
Earlier quoted context omitted.
I see that claim everywhere as well, and I don't understand it. Does it just mean "it has a type system that you won't hate"? There are still plenty of type declarations in that code, whereas if you ported it to OCaml they'd all be inferred.
Yes, basically. As far as I can tell Go is entirely about getting rid of unnecessary cruft and boilerplate and making a practical language you won't hate working in. Inasmuch as most interpreted languages are intended to be practical languages you won't hate working in, they are similar to Go. As far as the actual type system, the reason they feel similar is probably because interpreted languages tend to be duck-type…
The person you respond to talked about OCaml. From this I infer he at least has some basic knowledge of OCaml. You don't seem to have any.
Here's a hint: OCaml's object types are structurally typed (and OCaml can actually infer types).
Your whole second paragraph is unnecessary (and unwarrantedly condescending), and the first one is basically a lie (Go is chock-full of special syntax and cases, and Go code is full of cruft).
Earlier quoted context omitted.
Reading the same code I also cringed, but for a different reason: the validity of `paths` is tied to the validity of `err`; you should never look at at `paths` without first checking `err`. We can solve this much better using sum types (also known as discriminate unions): // Pseudo Go: maybe_paths := filepath.Glob(dir + "/*.png") case maybe_paths of { Some paths: { // Do things with paths } None: { // Handle error ca…
This kind of fussy type system is at odds with Go's design goals. It would make the language more abstracted from the underlying machine for little gain. I can't think of an instance of the issue you describe causing problems in real Go code.