|
Was wondering when that would show up here.
|
# ? Sep 5, 2016 07:25 |
|
|
# ? May 30, 2024 01:42 |
|
fleshweasel posted:Unused variables is the poster child for things that should be allowed in a debug build but disallowed in a release build or in CI. Unused parameters too?
|
# ? Sep 5, 2016 07:29 |
|
fleshweasel posted:Unused variables is the poster child for things that should be allowed in a debug build but disallowed in a release build or in CI.
|
# ? Sep 5, 2016 07:34 |
|
Volte posted:Obviously this will lead to people shipping debug builds and we cannot allow it. Millenial programmers must be protected from themselves by the wise greybeards. So just restrict debug builds to only run under the debugger. Problem solved
|
# ? Sep 5, 2016 07:45 |
|
Perl code:
|
# ? Sep 5, 2016 09:30 |
|
fleshweasel posted:Unused variables is the poster child for things that should be allowed in a debug build but disallowed in a release build or in CI. I haven't been in the "Go community" (meaning, following their Google Group) for a long time now, but at least back around 1.0-1.5 the core developers had two very strong opinions: 1. If it's worth warning about, it's worth erroring over 2. "Compiler flags" shouldn't be a thing, building is building. The userbase can get very sarcastic and nasty if you express doubts about either of these things (or any of the other "Go philosophies").
|
# ? Sep 5, 2016 09:36 |
|
It's actually quite insidious because both those concepts are pretty easily defensible in isolation, it's only when you put the two together that it gets a bit silly.
|
# ? Sep 5, 2016 10:03 |
|
Jsor posted:2. "Compiler flags" shouldn't be a thing, building is building. I strongly believe in this one. If you want the compiler to do something, put the details in the source text. Although, I think that I might make an exception for warnings, and that is mostly to support automatically generated code (which might have lots of unused variables and functions).
|
# ? Sep 5, 2016 10:17 |
|
Jsor posted:I haven't been in the "Go community" (meaning, following their Google Group) for a long time now, but at least back around 1.0-1.5 the core developers had two very strong opinions: I am sympathetic to both of those viewpoints but in the case of local messing-around it should totally be possible to run code that is "sloppier" than you would check in. There should be a declaration you can make/some other facility to indicate to the language "I know various things might be wrong with this code, ignore them" and developers should be prevented from checking in code that has that declaration in it. Athas posted:I strongly believe in this one. If you want the compiler to do something, put the details in the source text. What about configuration files relating to a project as a whole? How remote from the code itself is too remote?
|
# ? Sep 5, 2016 10:50 |
|
hobbesmaster posted:Unused parameters too? Unused parameters in public methods might be required for the class to conform to some interface, or to preserve backwards compatibility. In private methods they can be treated like unused locals.
|
# ? Sep 5, 2016 11:50 |
|
Hammerite posted:What about configuration files relating to a project as a whole? How remote from the code itself is too remote? Things like include paths and library configuration are fine. I'm not even opposed to metadata in general. That might be because I have yet to work in a language that makes all that part of the code itself (except for Lisp, but that's cheating). Also, if you must have configuration, I strongly prefer actual configuration files over complicated command line parameters. If everything is designed properly, configuration files should feel like they're just another source code file.
|
# ? Sep 5, 2016 12:02 |
|
Athas posted:Things like include paths and library configuration are fine. I'm not even opposed to metadata in general. That might be because I have yet to work in a language that makes all that part of the code itself (except for Lisp, but that's cheating). Also, if you must have configuration, I strongly prefer actual configuration files over complicated command line parameters. If everything is designed properly, configuration files should feel like they're just another source code file. Thats what they have done with Java Spring, you used to have xml config files now using Spring-boot you have a @Configuration annotation to use and do all the config in class files. - so much so that you no longer need web.xml files
|
# ? Sep 5, 2016 12:12 |
|
Jsor posted:I haven't been in the "Go community" (meaning, following their Google Group) for a long time now, but at least back around 1.0-1.5 the core developers had two very strong opinions: Don't forget generics
|
# ? Sep 5, 2016 15:12 |
|
TheresaJayne posted:Thats what they have done with Java Spring, you used to have xml config files now using Spring-boot you have a @Configuration annotation to use and do all the config in class files. - so much so that you no longer need web.xml files Interesting idea. XML is a horror in and of itself, really.
|
# ? Sep 5, 2016 15:46 |
|
hobbesmaster posted:Unused parameters too? And unreachable code. Sometimes I just want to slap a "return;" at the top of a function, and it pisses me off when Java will then refuse to compile.
|
# ? Sep 5, 2016 15:54 |
|
Series DD Funding posted:Don't forget generics They're just wrong about generics. That's the problem with opinionated language creators... sometimes they cling to a lovely opinion and everyone else suffers for it.
|
# ? Sep 5, 2016 16:41 |
|
I don't think I see how "no compiler flags" is defensible. At the very least you will tend to come up with debug and release flavors where one has no optimizations and debug symbols and the other has all optimizations and maybe no symbols. Then again Go retards don't think debuggers are useful.
|
# ? Sep 5, 2016 16:58 |
|
Debugging symbols are for chumps without printf.
|
# ? Sep 5, 2016 17:02 |
|
Hammerite posted:I am sympathetic to both of those viewpoints but in the case of local messing-around it should totally be possible to run code that is "sloppier" than you would check in. I don't necessarily agree with it, but I kind of want to be sympathetic to that opinion as sloppy code is a major pet peeve.
|
# ? Sep 5, 2016 17:07 |
|
ExcessBLarg! posted:I think part of the argument is that if you ever give people an out like this, they'll end up abusing it, somehow.
|
# ? Sep 5, 2016 17:34 |
|
IMO go has really great tooling and is designed to be really straightforward so I don't get why people want it to be something it isn't
|
# ? Sep 5, 2016 17:39 |
|
uncurable mlady posted:go has really great tooling was it downloading your dependencies straight from the HEAD of some github repository that sold you?
|
# ? Sep 5, 2016 17:42 |
|
fleshweasel posted:
dependency management is a dumpster fire but other than that, stuff like gofmt is great
|
# ? Sep 5, 2016 17:52 |
|
fleshweasel posted:I don't think I see how "no compiler flags" is defensible. At the very least you will tend to come up with debug and release flavors where one has no optimizations and debug symbols and the other has all optimizations and maybe no symbols. Sure, you will eventually need some compiler flags, but it's so easy to go overboard (ever seen the gcc manpage?), that I think it is a good principle to take a strong stand against them, and only include the ones that really are unavoidable. A highly configurable compiler is likely also a really buggy compiler, as it becomes increasingly unlikely that all possible code paths have been tested. Buggy compilers tend to imply a bad time.
|
# ? Sep 5, 2016 17:58 |
|
My favorite Go horror story is a Kickstarter game which failed once their programmer left, because nobody else could get the code to even compile anymore. The dependency versions Go pulled had changed from the cached versions the original programmer had, so the codebase was an unusable broken mess.
|
# ? Sep 5, 2016 18:02 |
|
but but but semver!!!
|
# ? Sep 5, 2016 18:12 |
|
pokeyman posted:Debugging symbols are for chumps without printf. It's very easy to believe that printfs are a sufficient tool and debuggers are overcomplicating things until you work with a codebase that doesn't fit in your head at once, was written by someone other than you, or both. CS programs are notoriously terrible at giving students exposure to "coding in the large" in any sense. It's kinda like how when the biggest program you've ever written fits on two sheets of paper the idea of version control or automated build systems seem like ludicrous overkill. Rob Pike ought to be experienced enough to have learned this stuff, but perhaps his ego renders him physically incapable of learning new ideas.
|
# ? Sep 5, 2016 18:17 |
|
uncurable mlady posted:dependency management is a dumpster fire but other than that, stuff like gofmt is great If I'm properly understanding what gofmt does, what it's doing is basically unremarkable.
|
# ? Sep 5, 2016 18:26 |
|
ExcessBLarg! posted:I think part of the argument is that if you ever give people an out like this, they'll end up abusing it, somehow. JSON doesn't have comments because people used them for parser directives. Now people just put the parser directives in the source, so you need to parse it, check a special key and then parse it again. You can't prevent people from abusing your APIs so you should really just give them the least-worst option to abuse.
|
# ? Sep 5, 2016 18:33 |
|
fleshweasel posted:I don't think I see how "no compiler flags" is defensible. At the very least you will tend to come up with debug and release flavors where one has no optimizations and debug symbols and the other has all optimizations and maybe no symbols. Idk about other operating systems but "release" binaries I make for Linux start with debugging symbols and then have binutils strip them out into a separate file, so the symbols are still accessible if the release binary breaks in a way debug doesn't. And optimization flags are moot since the go compiler barely optimizes at all
|
# ? Sep 5, 2016 18:36 |
|
SupSuper posted:My favorite Go horror story is a Kickstarter game which failed once their programmer left, because nobody else could get the code to even compile anymore. The dependency versions Go pulled had changed from the cached versions the original programmer had, so the codebase was an unusable broken mess. The dependency had the same version number but contained different code?
|
# ? Sep 5, 2016 18:37 |
|
TooMuchAbstraction posted:And unreachable code. Sometimes I just want to slap a "return;" at the top of a function, and it pisses me off when Java will then refuse to compile. fortunately if (true) return; does compile
|
# ? Sep 5, 2016 18:39 |
|
qntm posted:The dependency had the same version number but contained different code? That sounds totally plausible if the "dependency" is some 0.0.1 alpha unreleased side project thing.
|
# ? Sep 5, 2016 18:39 |
|
SupSuper posted:My favorite Go horror story is a Kickstarter game which failed once their programmer left, because nobody else could get the code to even compile anymore. The dependency versions Go pulled had changed from the cached versions the original programmer had, so the codebase was an unusable broken mess. Maybe it was a different kickstarter but the one I'd heard of was just that the programmer left, none of the rest knew Go, and they didn't even understand it enough to compile the last source code release the guy'd sent in because they were an ideas guy and some dudes who could draw. And they also couldn't convince anyone who knew Go to join the project.
|
# ? Sep 5, 2016 18:39 |
|
SupSuper posted:My favorite Go horror story is a Kickstarter game which failed once their programmer left, because nobody else could get the code to even compile anymore. The dependency versions Go pulled had changed from the cached versions the original programmer had, so the codebase was an unusable broken mess. Between this and a bunch of recent npm stupidity, do people not add their dependencies to source control?
|
# ? Sep 5, 2016 18:49 |
|
Internet Janitor posted:It's very easy to believe that printfs are a sufficient tool and debuggers are overcomplicating things until you work with a codebase that doesn't fit in your head at once, was written by someone other than you, or both. CS programs are notoriously terrible at giving students exposure to "coding in the large" in any sense. It's kinda like how when the biggest program you've ever written fits on two sheets of paper the idea of version control or automated build systems seem like ludicrous overkill. If you have a multi threaded application then a debugger is going to be, uh, not great, and print statements are more useful. Most work entails spending a vanishingly small proportion of time debugging code -- not fixing bugs, but actually going in with print statements or use of a debugger. So ignoring debuggers and using print statements is fine.
|
# ? Sep 5, 2016 18:58 |
|
qntm posted:The dependency had the same version number but contained different code? If you want a new mv in go, you create a new repo. There's no package versioning at all, or really packages. It's really a distributed monorepo with zero tooling around dependency management and build consistency. Vendoring tools exist, but they don't solve issues like "these packages vendor different versions of A and don't compile" or even "these packages vendor the same exact versions of A and don't compile".
|
# ? Sep 5, 2016 18:58 |
|
dwazegek posted:Between this and a bunch of recent npm stupidity, do people not add their dependencies to source control? There's a difference between using a dependency management tool (maven, cargo, even npm) and vendoring your dependencies. If vendoring is the only option for your language, then you end up with potentially exponential duplication of library code (which could make it all the way to your binary) and build and runtime issues if your language can't deal effectively with multiple declarations of the same thing. EDIT: though dependency management tools are hard to scale wrt to version selection. See https://github.com/rust-lang/cargo/issues/2064 for why cargo is broken. Even worse they keep talking about public vs private dependencies when people have clearly mentioned that some libraries break in duplication no matter what. I don't even know what to think about the SAT solver solution they're talking about. FamDav fucked around with this message at 19:28 on Sep 5, 2016 |
# ? Sep 5, 2016 19:07 |
|
Internet Janitor posted:It's very easy to believe that printfs are a sufficient tool and debuggers are overcomplicating things until you work with a codebase that doesn't fit in your head at once, was written by someone other than you, or both. CS programs are notoriously terrible at giving students exposure to "coding in the large" in any sense. It's kinda like how when the biggest program you've ever written fits on two sheets of paper the idea of version control or automated build systems seem like ludicrous overkill. As sarehu notes, I've not experienced a debugger that was useful for debugging multithreading issues. Sometimes you just need the entire program to do its thing, only with copious logging, and then go back and analyze what happened. Debuggers are fantastic for singlethreaded issues though.
|
# ? Sep 5, 2016 19:13 |
|
|
# ? May 30, 2024 01:42 |
|
sarehu posted:So ignoring debuggers and using print statements is fine. No its not. While there are a lot of bugs that are easy to debug by both and some that are better to debug with logs, there are also bugs that are hard to debug with logging, but p. easy with competent use of debugger. Like, last time I had to deal with intermittent deadlock on service shutdown bug, some "using print statements is good enough" guy spent couple of hours littering the shutdown sequence of prints to narrow down where the deadlock happens to "somewhere during shutdown of this service". I found the exact spot in ~5 minutes, by getting the shutdown to deadlock, attaching debugger and looking at the main thread callstack. I also took a look through other thread stacks and found out that some dumb rear end made threads that were circularly dependent (A waited for B, which waited for C, which waited for A), but usually happened not to deadlock because of reasons. Needless to say, I have also witnessed people who tried debugging a multiple-message session-negotiation bug by single stepping through the code first , so I am not saying that debugger is the most important, just that it is definitely a required knowledge.
|
# ? Sep 5, 2016 19:19 |