Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Tad Naff
Jul 8, 2004

I told you you'd be sorry buying an emoticon, but no, you were hung over. Well look at you now. It's not catching on at all!
:backtowork:
Was wondering when that would show up here.

Adbot
ADBOT LOVES YOU

hobbesmaster
Jan 28, 2008

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?

Volte
Oct 4, 2004

woosh woosh

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.
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.

beuges
Jul 4, 2005
fluffy bunny butterfly broomstick

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 :smug:

qntm
Jun 17, 2009
Perl code:
print         "10. Ordinary code runs at runtime.\n";
END { print   "16.   So this is the end of the tale.\n" }
INIT { print  " 7. INIT blocks run FIFO just before runtime.\n" }
UNITCHECK {
  print " 4.   And therefore before any CHECK blocks.\n"
}
CHECK { print " 6.   So this is the sixth line.\n" }
print         "11.   It runs in order, of course.\n";
BEGIN { print " 1. BEGIN blocks run FIFO during compilation.\n" }
END { print   "15.   Read perlmod for the rest of the story.\n" }
CHECK { print " 5. CHECK blocks run LIFO after all compilation.\n" }
INIT { print  " 8.   Run this again, using Perl's -c switch.\n" }
print         "12.   This is anti-obfuscated code.\n";
END { print   "14. END blocks run LIFO at quitting time.\n" }
BEGIN { print " 2.   So this line comes out second.\n" }
UNITCHECK {
 print " 3. UNITCHECK blocks run LIFO after each file is compiled.\n"
}
INIT { print  " 9.   You'll see the difference right away.\n" }
print         "13.   It only _looks_ like it should be confusing.\n";

Linear Zoetrope
Nov 28, 2011

A hero must cook

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").

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
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.

Athas
Aug 6, 2007

fuck that joker

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).

Hammerite
Mar 9, 2007

And you don't remember what I said here, either, but it was pompous and stupid.
Jade Ear Joe

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:

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").

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?

LOOK I AM A TURTLE
May 22, 2003

"I'm actually a tortoise."
Grimey Drawer

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.

Athas
Aug 6, 2007

fuck that joker

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.

TheresaJayne
Jul 1, 2011

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

Series DD Funding
Nov 25, 2014

by exmarx

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:

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").

Don't forget generics :twisted:

Evil_Greven
Feb 20, 2007

Whadda I got to,
whadda I got to do
to wake ya up?

To shake ya up,
to break the structure up!?

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.

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

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.

Simulated
Sep 28, 2001
Lowtax giveth, and Lowtax taketh away.
College Slice

Series DD Funding posted:

Don't forget generics :twisted:

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.

brap
Aug 23, 2004

Grimey Drawer
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.

pokeyman
Nov 26, 2006

That elephant ate my entire platoon.
Debugging symbols are for chumps without printf.

ExcessBLarg!
Sep 1, 2001

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 think part of the argument is that if you ever give people an out like this, they'll end up abusing it, somehow. In practice this would mean regularly running across commits that don't compile because they generate warnings which are now errors.

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.

Volte
Oct 4, 2004

woosh woosh

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.
Isn't that the same argument fascists use to justify limiting personal freedoms :colbert:

kitten emergency
Jan 13, 2008

get meow this wack-ass crystal prison
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

brap
Aug 23, 2004

Grimey Drawer

uncurable mlady posted:

go has really great tooling

:pwn:

was it downloading your dependencies straight from the HEAD of some github repository that sold you?

kitten emergency
Jan 13, 2008

get meow this wack-ass crystal prison

fleshweasel posted:

:pwn:

was it downloading your dependencies straight from the HEAD of some github repository that sold you?

dependency management is a dumpster fire but other than that, stuff like gofmt is great

Athas
Aug 6, 2007

fuck that joker

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.

SupSuper
Apr 8, 2009

At the Heart of the city is an Alien horror, so vile and so powerful that not even death can claim it.
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.

Suspicious Dish
Sep 24, 2011

2020 is the year of linux on the desktop, bro
Fun Shoe
but but but semver!!!

Internet Janitor
May 17, 2008

"That isn't the appropriate trash receptacle."

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.

brap
Aug 23, 2004

Grimey Drawer

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.

xtal
Jan 9, 2011

by Fluffdaddy

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.

Series DD Funding
Nov 25, 2014

by exmarx

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 :laugh:

qntm
Jun 17, 2009

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?

Soricidus
Oct 21, 2010
freedom-hating statist shill

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

raminasi
Jan 25, 2005

a last drink with no ice

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.

fishmech
Jul 16, 2006

by VideoGames
Salad Prong

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.

dwazegek
Feb 11, 2005

WE CAN USE THIS :byodood:

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? :confused:

sarehu
Apr 20, 2007

(call/cc call/cc)

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.

Rob Pike ought to be experienced enough to have learned this stuff, but perhaps his ego renders him physically incapable of learning new ideas.

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.

FamDav
Mar 29, 2008

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".

FamDav
Mar 29, 2008

dwazegek posted:

Between this and a bunch of recent npm stupidity, do people not add their dependencies to source control? :confused:

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

TooMuchAbstraction
Oct 14, 2012

I spent four years making
Waves of Steel
Hell yes I'm going to turn my avatar into an ad for it.
Fun Shoe

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.

Adbot
ADBOT LOVES YOU

Xarn
Jun 26, 2015

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. :v: 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 :suicide:, so I am not saying that debugger is the most important, just that it is definitely a required knowledge.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply