Earlier quoted context omitted.
When doing this in your own libraries, be sure to document how to generate the struct tag name from the typedef name. (MS don't do this - but they're not consistent about it anyway.) Then when people see a typedef'd struct used somewhere in a header, they'll know how to forward declare it in their own headers.
What's forward declaring mean?
First chapter of Kernighan and Donovan's new Go book [pdf]
211–220 of 233 posts
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#212Earlier quoted context omitted.
A fantastic idea, even slower to compile (since you need to parse extra source files), more complex workflow, and extra files which developers have to remember to ignore.
I'm not even aware of go compiling most of the time (it's typically under 1 second). go's build system handles these sort of things without a more complex workflow.
> I'm not even aware of go compiling most of the time (it's typically under 1 second).
That's besides the point, codegen from extra on-disk files can only be slower than codegen without extra on-disk files, so "generics are slow to compile" and "go has generate" don't make sense together, yet they are used together to assert that generics are bad and anyway go has a replacement.
> go's build system handles these sort of things without a more complex workflow.
No they don't. If you're using go generate you have to run go generate. That's a strictly more complex workflow than not having to run it.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#213Earlier quoted context omitted.
Java. Static types (less sophisticated than state of the art, more sophisticated than Go), fairly easy deployment (you can easily make a package with everything except the JVM, so it's your one binary + /usr/bin/java + libjli + lib{c,dl,pthread,z}), concurrency is state of the art (whether old-school threads-and-locks with java.util.concurrent, actors with Akka, fibres with Quasar, whatever you like), is a quite smal…
If going down this route, I'd probably look into using Kotlin with dropwizard, rather than Java. Maybe it's just me, but the amount of code you have to write in Java that really should be auto-generated (and often is, by an IDE) is absurd. I've not toyed extensively with Kotlin yet, but so far it does look like a "modern Java done right". Most of the code you don't actually need to write, or read -- like getters and…
Yes! Kotlin and Ceylon are both really interesting, as attempts to judiciously add and remove features to/from Java, to produce something recognisable, and easy for the unwashed masses (ie me) to pick up, but still much better.
My only concern is that they don't have much depth of community or history yet. That can be a very interesting and rewarding time to pick up a language, but it can also be a drag on actually getting things done.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#214Earlier quoted context omitted.
I would choose Go. It comes with an excellent built-in package net/http ( https://godoc.org/net/http ) that quickly allows you to setup a web service. An Go's mechanic (?) of implicit satisfaction of interfaces allows you to do some really cool things. One of the gripes about Go seems to be error handling, and your code ends up with a whole bunch of 'if err != nil { stuff }'. Matt Silverlock ( http://elithrar.github.…
Yes, just using built-in packages, and not depending on too many third-party packages is definitely attractive to me. The code full of "if err != nil" is an issue that I've also noticed. However, I'm hopeful that this may actually remind me to be more exhaustive in error handling. Why did you mention the container? How kind of benefits would you be getting from a container for Go?
A container is just useful. But given Go's static binaries, you could also just ship the binary over to a server and be up and running. But it's nice to just have a container with all the bits/config inside that you can just copy over. The benefits of a container are the same for any language.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#215Earlier quoted context omitted.
I'm not even aware of go compiling most of the time (it's typically under 1 second). go's build system handles these sort of things without a more complex workflow.
> I'm not even aware of go compiling most of the time (it's typically under 1 second). That's besides the point, codegen from extra on-disk files can only be slower than codegen without extra on-disk files, so "generics are slow to compile" and "go has generate" don't make sense together, yet they are used together to assert that generics are bad and anyway go has a replacement. > go's build system handles these sort…
I didn't say generics were bad. I said compilation is so fast that I didn't notice it.
While I agree that "strictly" your assessment is corect it's more complex, I think you're being a bit literal; it's just another command. most of my builds have hundreds of commands.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#216Earlier quoted context omitted.
If going down this route, I'd probably look into using Kotlin with dropwizard, rather than Java. Maybe it's just me, but the amount of code you have to write in Java that really should be auto-generated (and often is, by an IDE) is absurd. I've not toyed extensively with Kotlin yet, but so far it does look like a "modern Java done right". Most of the code you don't actually need to write, or read -- like getters and…
Yes! Kotlin and Ceylon are both really interesting, as attempts to judiciously add and remove features to/from Java, to produce something recognisable, and easy for the unwashed masses (ie me) to pick up, but still much better. My only concern is that they don't have much depth of community or history yet. That can be a very interesting and rewarding time to pick up a language, but it can also be a drag on actually g…
True. Then again, that code that your IDE generated for 10 year old Java doesn't really have a community that refreshes it either, and it sits there in your VCS, and takes up space in code reviews etc.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#217Earlier quoted context omitted.
I should explicitly state I seem to be in the minority in the Go community here, but: You don't get a compiler error if you initialize by name. You do get a compiler error when you initialize by position. In my minority opinion, you can and should use that to your advantage whenever possible. Some structs are clearly "configuration-like", for instance, and you don't want an error if a new option shows up, which will…
That's a pretty risky thing to do.
I just don't get this attitude. I'm asking for the compiler to break my code if something I depended on changes. The alternative is the risky one! This is the safe alternative.
Compiler errors aren't evil. They're a tool. They work best when there is a one-to-one correspondence between problems and errors. That's not possible in the general case, but the closer we get, the better. And the worst case is not when I get a spurious error. That's easy to deal with. The worst case is when I don't get an error I should have. If you're going to worry about "riskiness", that's the risk that should keep you up at night. Not compiler errors for things that turn out to be no big deal, and can quite likely be fixed with one quick go fmt -s.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#218Earlier quoted context omitted.
That's a pretty risky thing to do.
I just don't get this attitude. I'm asking for the compiler to break my code if something I depended on changes. The alternative is the risky one! This is the safe alternative. Compiler errors aren't evil. They're a tool. They work best when there is a one-to-one correspondence between problems and errors. That's not possible in the general case, but the closer we get, the better. And the worst case is not when I get…
I agree. But the industry is hurtling down a tunnel of weak typing and runtime checking. So compiler features are diminishing in relevance at a geometric rate.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#219Earlier quoted context omitted.
I should explicitly state I seem to be in the minority in the Go community here, but: You don't get a compiler error if you initialize by name. You do get a compiler error when you initialize by position. In my minority opinion, you can and should use that to your advantage whenever possible. Some structs are clearly "configuration-like", for instance, and you don't want an error if a new option shows up, which will…
So I get to go back and look at the struct to see the order every time I initialize an instance? Or watch everything break when the noob on the team alphabetizes the struct fields? Yeah, that's a great solution.
If you're doing this, it is, by definition, on structs you choose to do it on. If you lack the judgment ability to decide when you want that, fine, never do it.
And the noob that is so noobish that they change code and don't even compile it to check to see whether it works is a menace well beyond this issue. That's an overpowerful argument; the real problem is the noob that isn't even running the compiler. The noob doesn't "break struct initializations" specially, they break everything.
Re: First chapter of Kernighan and Donovan's new Go book [pdf]
#220Earlier quoted context omitted.
I just don't get this attitude. I'm asking for the compiler to break my code if something I depended on changes. The alternative is the risky one! This is the safe alternative. Compiler errors aren't evil. They're a tool. They work best when there is a one-to-one correspondence between problems and errors. That's not possible in the general case, but the closer we get, the better. And the worst case is not when I get…
I agree. But the industry is hurtling down a tunnel of weak typing and runtime checking. So compiler features are diminishing in relevance at a geometric rate.
I see the exact opposite trend happening. Weak typing is plateauing. It's the last moment of apparent strength before long, slow, but inevitable collapse. Most interesting work is being done on the static side right now, partially because there's no more work to be done on the dynamic side. (A great deal of being dynamic is precisely throwing away all the structure you might build further features on.)
You can also see this in how all the dynamic languages are working on adding "optional" or "incremental" dynamic typing. Static languages, by contrast, generally create one dynamic type, stick it in a library somewhere, and let the small handful of people who really need it use it. Few, if any, of them are adding any dynamic features. The motion trends are clear.