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
JawnV6
Jul 4, 2004

So hot ...
the compiler's blind to the re-ordering that the proc is going to do as well, there's no way it can know what execution units will be available at runtime, what's so special about that arbitrary point on the chain?

Adbot
ADBOT LOVES YOU

Max Facetime
Apr 18, 2009

JawnV6 posted:

the compiler's blind to the re-ordering that the proc is going to do as well, there's no way it can know what execution units will be available at runtime, what's so special about that arbitrary point on the chain?

right, the same thing applies for the processor and the assembler code it reorders before executing it, too. except there the programmer's intention is obscured by one or more layers of encodings already:
  • an informal requirement about the order in which things can happen -> written text file of high-level source code
  • high-level source code -> result of transformation by AOT compiler
  • (bytecode from AOT compilation -> result of transformation by JIT compiler)
  • assembler -> microcode transformation by CPU before things do happen

none of which is a problem if there's only a single thread of execution at any one time

when there is many, then having high-level source code (and bytecode) and assembler each force one order even if it's an arbitrary order results in this kind of code:
code:
100 REM by programmer 1
110 A = D+3
120 B = E+2
130 C = F*4

200 REM by programmer 2
210 E = B+2
220 F = C*4
225 PRINT B,C
230 D = A+3
237 PRINT A
when the intentions of the programmers were more like this:
code:
100 REM by programmer 1
110 A = D + 3
110 B = E + 2
110 C = F * 4

200 REM by programmer 2
210 E = E$ = B+2
210 F = F$ = C*4
225 PRINT E$-2,F$/4
210 D = D$ = A+3
237 PRINT D$-3
then at runtime the CPU chooses some execution order. with this much information lost in the translation it's quite unlikely that the chosen order turns out consistent with what everyone intended originally

so really it's the whole chain that has a problem

duTrieux.
Oct 9, 2003

i've been dicking around with a new wordpress install which means a return to php and oh my god this is horsehit

duTrieux.
Oct 9, 2003

i'm not even a Real Coder and, like, gently caress. drat, mang.

Bloody
Mar 3, 2013

Max Facetime posted:

right, the same thing applies for the processor and the assembler code it reorders before executing it, too. except there the programmer's intention is obscured by one or more layers of encodings already:
  • an informal requirement about the order in which things can happen -> written text file of high-level source code
  • high-level source code -> result of transformation by AOT compiler
  • (bytecode from AOT compilation -> result of transformation by JIT compiler)
  • assembler -> microcode transformation by CPU before things do happen

none of which is a problem if there's only a single thread of execution at any one time

when there is many, then having high-level source code (and bytecode) and assembler each force one order even if it's an arbitrary order results in this kind of code:
code:
100 REM by programmer 1
110 A = D+3
120 B = E+2
130 C = F*4

200 REM by programmer 2
210 E = B+2
220 F = C*4
225 PRINT B,C
230 D = A+3
237 PRINT A
when the intentions of the programmers were more like this:
code:
100 REM by programmer 1
110 A = D + 3
110 B = E + 2
110 C = F * 4

200 REM by programmer 2
210 E = E$ = B+2
210 F = F$ = C*4
225 PRINT E$-2,F$/4
210 D = D$ = A+3
237 PRINT D$-3
then at runtime the CPU chooses some execution order. with this much information lost in the translation it's quite unlikely that the chosen order turns out consistent with what everyone intended originally

so really it's the whole chain that has a problem

so the problem is we haven't parallelized words on a page?

Blinkz0rz
May 27, 2001

MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

duTrieux. posted:

i've been dicking around with a new wordpress install which means a return to php and oh my god this is horsehit

wordpress is piss trash for suckhole idiots

i include myself in the list of suckhole idiots because job still uses wp for a bunch of stupid stuff

JawnV6
Jul 4, 2004

So hot ...

Max Facetime posted:

so really it's the whole chain that has a problem

im not really following the example but at this point EAX doesn't have some box it's sitting in, it's recognized as a contrivance. capturing E$ or w/e before modification is happening natively

ahmeni
May 1, 2005

It's one continuous form where hardware and software function in perfect unison, creating a new generation of iPhone that's better by any measure.
Grimey Drawer

duTrieux. posted:

i've been dicking around with a new wordpress install which means a return to php and oh my god this is horsehit

if you're using Wordpress and it's not at least a first party hosted solution then I think we need to hold an intervention for you or something

ahmeni
May 1, 2005

It's one continuous form where hardware and software function in perfect unison, creating a new generation of iPhone that's better by any measure.
Grimey Drawer
ive now got two minor contributions to open source software under my belt and I know it's like the least important thing ever but it's a nice feeling to give back to things I like (iPython and paramiko)

VikingofRock
Aug 24, 2008




ahmeni posted:

ive now got two minor contributions to open source software under my belt and I know it's like the least important thing ever but it's a nice feeling to give back to things I like (iPython and paramiko)

hell yeah; that's awesome

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder

ahmeni posted:

ive now got two minor contributions to open source software under my belt and I know it's like the least important thing ever but it's a nice feeling to give back to things I like (iPython and paramiko)

remember to list them on your resume as 'important contributions'

Symbolic Butt
Mar 22, 2009

(_!_)
Buglord
recently I sent some PRs to ansible and let me say if you want to contribute to some python project oh boy ansible has a lot of work to do

also the dudes are pretty nice and open, which is not exactly a thing in every open source project

suffix
Jul 27, 2013

Wheeee!

ahmeni posted:

ive now got two minor contributions to open source software under my belt and I know it's like the least important thing ever but it's a nice feeling to give back to things I like (iPython and paramiko)

not to go full stallman but i think it's a really nice experience for people to realize that they can add their own features to programs they use and contribute them to help other people

like when i was a baby writing toy programs i still thought "real" programs were wizardry you needed to be an initiated programmer to understand
but actually looking into a project and submitting a small patch made me realize that it's easy and teaches you a lot, and you don't have to be a genius to add a command line option or fix a missing null check or add an example to the documentation

Dessert Rose
May 17, 2004

awoken in control of a lucid deep dream...
i feel that way about most "released" code

like i've seen tons of magical thinking about memory managers around my team recently. how do they work?? well actually memory managers are really simple, you see you just keep a list of the blocks you've handed out, ... the reason you don't write a new one is not that they are exceptionally difficult to get right, but that it's just reinventing the wheel.

but then like, i run an open source app and it breaks for whatever reason and my brain goes "welp there's no fixing that, nothing in that stack trace has a name that makes sense to me"

if i can get past that and actually read the stack trace and find the file responsible, though, submitting a patch is actually super easy

and maintenance programming is a v useful skill. most of your time in industry is going to be spent making some software that someone else wrote years ago do something new, or fixing it when it breaks, and dude is nowhere to be found. OSS contributions are the simplest way to get that experience and you even get some proof that you have it! it's better than certifications

cowboy beepboop
Feb 24, 2001

Symbolic Butt posted:

recently I sent some PRs to ansible and let me say if you want to contribute to some python project oh boy ansible has a lot of work to do

also the dudes are pretty nice and open, which is not exactly a thing in every open source project

i once saw a PR for ansible that added python 3 support and it was rejected by the founder because he didn't think python 3 was going to gain any traction

Symbolic Butt
Mar 22, 2009

(_!_)
Buglord
lol I noticed the original author doesn't commit to ansible anymore, I guess he left development to a company and they're managing ansible in a more sensible way now?

anyway, I saw some PRs dealing with six so it's definitely an ongoing thing

but it really sucks that they're keeping ansible compatible with python 2.6, you have to remember to not use set literals and stuff

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder

Symbolic Butt posted:

lol I noticed the original author doesn't commit to ansible anymore, I guess he left development to a company and they're managing ansible in a more sensible way now?

anyway, I saw some PRs dealing with six so it's definitely an ongoing thing

but it really sucks that they're keeping ansible compatible with python 2.6, you have to remember to not use set literals and stuff

it's not a problem as long as you don't contribute

JewKiller 3000
Nov 28, 2006

by Lowtax

Symbolic Butt posted:

but it really sucks that python 2.6

ahmeni
May 1, 2005

It's one continuous form where hardware and software function in perfect unison, creating a new generation of iPhone that's better by any measure.
Grimey Drawer
there's a lot of us poor devops still wrangling rhel5/6 installs with ansible so 2.6 compat is crucial

Wheany
Mar 17, 2006

Spinyahahahahahahahahahahahaha!

Doctor Rope
i have been doing some test driven development for the past week, almost by accident.

well, i'm actually most excited that the code is actually unit testable in the first place. feels pretty good that the code is just bad and not poo poo from satan's rear end in a top hat anymore.

MononcQc
May 29, 2007

tdd's main advantages come from helping you write testable code, and making test writing a shitton less tedious to write by attaching it to newcode; the contrapositive of that is that writing code is now more boring and tedious by comparison.

But if you use a REPL to program, once your REPL example works, move it to a file and it's now a test case :toot:

tef
May 30, 2004

-> some l-system crap ->
write your test first in prolog and you have written your program

tef
May 30, 2004

-> some l-system crap ->
i kinda hate test driven design. i'm sure people will chime in to tell me that this isn't true test driven design, but, like agile, the name is the popular bit, and knowing the name is the average level of understanding of the practice. let's call it tdd as found in the last 2 years of ruby code bases.

1. people put their assertions invariants in their tests and not in their program

it isn't so much defensive code, but code that fails fast when the invariant fails. to understand how a piece of code works you now have to look through the litany of test files for the constraints. and before anyone tells me "lol performance" i will tell them pre-emptively to go gently caress themselves: when you decide to do something for performance reasons you are implicitly agreeing that it is a bad idea to do and you're doing a bad thing to get speed.

it's little things like where you handle each edge case explicitly rather than rolling up your code and cleverly doing things. if i have to read the tests to work out what a program should be doing, odds are the code's a poo poo show.

2. people use a hell of a lot of mocks and stubs and fakes

which in my experience, don't provide a lot of value or insight for their maintenance costs, even though i am sure there are three purists who will tell me that i'm conflating the names (sure!) but i mean this: if you're testing against a mock you're not testing against your code.

i have been told "well mocks help me write tests for untestable code" except now you have two problems: mocks, and bad code.

3. tests slow down refactoring

this one is weird because i know a lot of you will say "not with my tests", and i guess that's true, but i've encountered a lot of tests which assert that underlying methods on different objects get called. you're not testing behaviour you're testing implementation, and when you want to change implementation you must re-write the tests. throw in that a lot of tests use fake objects and you have to rewrite numerous lines of code to re-implement the behaviour.

4. testing isn't free

tests are code and have maintenance, documentation burdens just like any other code, and just like any other code we shirk them. we even pretend that tests are documentation some times.

and for some particular ruby specialities

5. gently caress testing dsls

put them in the bin along with people who think "a dsl" is something built atop of a general purpose language where some semantics are capriciously changed and, gently caress the 'stack traces' they produce on errors.

6. gently caress cucumber

this is a bonus but i've only encountered this flagellation under tdd rubyism. let's write our tests like a click through license, and then write a series of regular expressions to convert them into ruby assertions and then gently caress anyone who ever has to debug it. no-one will ever loving read your cucumber specs. what makes good tests good and good docs good are not compatible goals. you are writing bad tests and bad docs.

i like tests just as much as i like coding in general, it's a chore but it pays off. i just don't think the tdd "test first" mentality leads to better code or better tests, just more tests which lock in your mistakes from the earliest point.

tbh after ~two years~ of ruby i'm slowly convinced that testing is so valued in ruby because almost every feature is a footgun of nils.

i know some people who love thinking about apis by writing tests (and some who scratch it out on paper, in the repl, etc), and it's pretty good that it works for them. it's the weird "works on my machine" school of programming methodology: you have to do what works for me because what else works?

this goes out to all the weird static typing cranks too, who look at you and say "how can you begin to write fifth order functions?" because the idea that your lovely little script of automation and business logic doesn't need the same sort of structure that a theorem prover or compiler does. who will tell you about the magic of type inference until you ask them about monomorphism restrictions and row polymorphism and they look sad


testing is great it's just we're as good as it as we are about code and the only thing driving your design should be constraints

brap
Aug 23, 2004

Grimey Drawer
TDD is nice when you know what the outputs should be for various inputs but not what should actually be done to achieve those outputs.

it's not always that useful and it's not a substitute for reasoning about the implementation.

people also forget that they usually have no idea what those edge cases that gently caress up their solution even are until they come up.

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder
my feeling on TDD is that everyone probably does some sort of TDD, even if those "tests" are just thought experiments, or clicking around in the UI. if there's some sort of way to quickly automate those tests, you should do it.

but yes, most of the problems are with how do you deal with the boundaries between components. when you do all TDD all the time, you end up inventing lots of weird ways to deal with those boundaries, and if you're not really careful you end up mocking until your tests are pointless. or not mocking enough. or whatever. it sucks and no one has solved the problem yet.

DONT THREAD ON ME fucked around with this message at 23:27 on Sep 27, 2015

Sinestro
Oct 31, 2010

The perfect day needs the perfect set of wheels.
as a static typing purist, I

Notorious b.s.d.
Jan 25, 2003

by Reene

Symbolic Butt posted:

but it really sucks that they're keeping ansible compatible with python 2.6, you have to remember to not use set literals and stuff

ahmeni posted:

there's a lot of us poor devops still wrangling rhel5/6 installs with ansible so 2.6 compat is crucial

the ansible model is ill-conceived. agentless is dumb. using the system python is dumb.

puppet and chef ship their own complete runtimes so their authors are not restricted to whatever red hat or ibm shipped in 2005

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder

tef posted:

who will tell you about the magic of type inference until you ask them about monomorphism restrictions and row polymorphism and they look sad

can you or anyone please explain this to me because i dont understand it

fritz
Jul 26, 2003

MALE SHOEGAZE posted:

my feeling on TDD is that everyone probably does some sort of TDD, even if those "tests" are just thought experiments, or clicking around in the UI. if there's some sort of way to quickly automate those tests, you should do it.


i had to work on a codebase w a guy who got mad when i wrote unit tests b/c tdd is just a development fad and he didnt believe in it

Notorious b.s.d.
Jan 25, 2003

by Reene

tef posted:

1. people put their assertions invariants in their tests and not in their program

it isn't so much defensive code, but code that fails fast when the invariant fails. to understand how a piece of code works you now have to look through the litany of test files for the constraints. and before anyone tells me "lol performance" i will tell them pre-emptively to go gently caress themselves: when you decide to do something for performance reasons you are implicitly agreeing that it is a bad idea to do and you're doing a bad thing to get speed.

it's little things like where you handle each edge case explicitly rather than rolling up your code and cleverly doing things. if i have to read the tests to work out what a program should be doing, odds are the code's a poo poo show.

the alternative to having invariants delimited in the tests isn't having better, clearer ruby code. that has never happened

it's the same lovely ruby code, but with unknown invariants

tef posted:

5. gently caress testing dsls

put them in the bin along with people who think "a dsl" is something built atop of a general purpose language where some semantics are capriciously changed and, gently caress the 'stack traces' they produce on errors.
gently caress ruby dsls in general

ruby lets you pass blocks to every method at all times. "can" does not imply "should"

Notorious b.s.d.
Jan 25, 2003

by Reene

MALE SHOEGAZE posted:

my feeling on TDD is that everyone probably does some sort of TDD, even if those "tests" are just thought experiments, or clicking around in the UI. if there's some sort of way to quickly automate those tests, you should do it.

i write a lot of lovely tests that are just automated versions of the clicking around i was doing in the UI or stuff from my repl

these tests will not communicate intent or invariants to later readers, but they save me time and they'll throw up a red flag if something is really, terribly broken

lame tests are better than no tests

Edison was a dick
Apr 3, 2010

direct current :roboluv: only
I've heard BDD described as generalising TDD up to client level requirements, like it's not a fundamental invariant of the universe that the client doesn't understand what they want.

Notorious b.s.d. posted:

the ansible model is ill-conceived. agentless is dumb. using the system python is dumb.

puppet and chef ship their own complete runtimes so their authors are not restricted to whatever red hat or ibm shipped in 2005

The only way I can see agentless ever working is if it can work by using /bin/sh

fritz posted:

i had to work on a codebase w a guy who got mad when i wrote unit tests b/c tdd is just a development fad and he didnt believe in it

I work with someone who effectively mandates spaghetti code since he requires no tests because they lock down the implementation, and he got it into his head that the only metric that works is lines of code, therefore we should be gaming the metric to reduce lines of code at all costs, "Code is documentation" be damned!

qntm
Jun 17, 2009
what on earth is test-driven design

Edison was a dick
Apr 3, 2010

direct current :roboluv: only

Notorious b.s.d. posted:

gently caress ruby dsls in general

ruby lets you pass blocks to every method at all times. "can" does not imply "should"

gently caress dsls that aren't actually different languages, hence inherit all the semantics of the original language, but with a bunch of crap on top.

Notorious b.s.d. posted:

lame tests are better than no tests

I wish I could agree, but if your tests are lame enough that they always pass until you need to scrap them because circumstances changed such that they are no longer applicable, you get shouted at for wasting the time in writing them in the first place.

Notorious b.s.d.
Jan 25, 2003

by Reene

Edison was a dick posted:

The only way I can see agentless ever working is if it can work by using /bin/sh

this will still gently caress you if you want to port to legacy unix or mainframe or, worst of all, windows

Soricidus
Oct 21, 2010
freedom-hating statist shill

tef posted:

i kinda hate test driven design. i'm sure people will chime in to tell me that this isn't true test driven design, but, like agile, the name is the popular bit, and knowing the name is the average level of understanding of the practice. let's call it tdd as found in the last 2 years of ruby code bases.

1. people put their assertions invariants in their tests and not in their program

it isn't so much defensive code, but code that fails fast when the invariant fails. to understand how a piece of code works you now have to look through the litany of test files for the constraints. and before anyone tells me "lol performance" i will tell them pre-emptively to go gently caress themselves: when you decide to do something for performance reasons you are implicitly agreeing that it is a bad idea to do and you're doing a bad thing to get speed.

it's little things like where you handle each edge case explicitly rather than rolling up your code and cleverly doing things. if i have to read the tests to work out what a program should be doing, odds are the code's a poo poo show.

2. people use a hell of a lot of mocks and stubs and fakes

which in my experience, don't provide a lot of value or insight for their maintenance costs, even though i am sure there are three purists who will tell me that i'm conflating the names (sure!) but i mean this: if you're testing against a mock you're not testing against your code.

i have been told "well mocks help me write tests for untestable code" except now you have two problems: mocks, and bad code.

3. tests slow down refactoring

this one is weird because i know a lot of you will say "not with my tests", and i guess that's true, but i've encountered a lot of tests which assert that underlying methods on different objects get called. you're not testing behaviour you're testing implementation, and when you want to change implementation you must re-write the tests. throw in that a lot of tests use fake objects and you have to rewrite numerous lines of code to re-implement the behaviour.

4. testing isn't free

tests are code and have maintenance, documentation burdens just like any other code, and just like any other code we shirk them. we even pretend that tests are documentation some times.

and for some particular ruby specialities

5. gently caress testing dsls

put them in the bin along with people who think "a dsl" is something built atop of a general purpose language where some semantics are capriciously changed and, gently caress the 'stack traces' they produce on errors.

6. gently caress cucumber

this is a bonus but i've only encountered this flagellation under tdd rubyism. let's write our tests like a click through license, and then write a series of regular expressions to convert them into ruby assertions and then gently caress anyone who ever has to debug it. no-one will ever loving read your cucumber specs. what makes good tests good and good docs good are not compatible goals. you are writing bad tests and bad docs.

i like tests just as much as i like coding in general, it's a chore but it pays off. i just don't think the tdd "test first" mentality leads to better code or better tests, just more tests which lock in your mistakes from the earliest point.

tbh after ~two years~ of ruby i'm slowly convinced that testing is so valued in ruby because almost every feature is a footgun of nils.

i know some people who love thinking about apis by writing tests (and some who scratch it out on paper, in the repl, etc), and it's pretty good that it works for them. it's the weird "works on my machine" school of programming methodology: you have to do what works for me because what else works?

this goes out to all the weird static typing cranks too, who look at you and say "how can you begin to write fifth order functions?" because the idea that your lovely little script of automation and business logic doesn't need the same sort of structure that a theorem prover or compiler does. who will tell you about the magic of type inference until you ask them about monomorphism restrictions and row polymorphism and they look sad


testing is great it's just we're as good as it as we are about code and the only thing driving your design should be constraints

tef please stop doing ruby it's bad for you

tef
May 30, 2004

-> some l-system crap ->

Notorious b.s.d. posted:

the ansible model is ill-conceived. agentless is dumb. using the system python is dumb.

yes and no, it's a tradeoff.

it depends on the scope and actions of the system and how many of them that you have, it lowers the boundaries for using quickly or in addition to other systems too

triple sulk
Sep 17, 2014



Soricidus posted:

tef please stop doing ruby it's bad for you

agree, ruby is really bad and only when you never write it again will you be free from its tyranny and inflicted pain

DONT THREAD ON ME
Oct 1, 2002

by Nyc_Tattoo
Floss Finder
the worst part of interviewing for a ruby position is when people are like 'oh yeah, i love ruby' and i'm like 'do you really though?'

Adbot
ADBOT LOVES YOU

fritz
Jul 26, 2003

Edison was a dick posted:


I work with someone who effectively mandates spaghetti code since he requires no tests because they lock down the implementation, and he got it into his head that the only metric that works is lines of code, therefore we should be gaming the metric to reduce lines of code at all costs, "Code is documentation" be damned!


:stonklol:

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