terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

MALE SHOEGAZE posted:

that sucks. all of my computer jobs have owned. my last one had lovely development practices and the codebase was a nightmare but people were friendly and no one was getting super mad and it was a great place to work.

redhat is even better

do you work for redhat now?

I thought you were just contracting there

# ? Sep 5, 2015 22:09

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 07:54

tef: May 30, 2004; -> some l-system crap ->

Bloody posted:

actually, concurrency is easy and you should be able to handle it

concurrency is easy when you don't share aything. parallelism is easy. threads are easy. locks are clumsy. shared state is terrible. there's a reason we pass the buck to a RDBMS to implement transactions. most of the data structures we use are awful.

how to write threaded code:

don't share state, communicate. use a queue and dump stuff in, in one thread, and pull stuff out at another. avoid multiple readers/writers if you can. then when it's slow you can break out the mutexes and semaphors and atomics.

# ? Sep 5, 2015 22:11

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

NihilCredo posted:

i have a company hat and two company polo shirts, all are still shrinkwrapped and will stay so until I lose a bet or something

used to be that all things bearing our company logo had to be approved by the CEO before they could go out, even a T-shirt. I think that's still the case, too, but our head of design is who approves them.

we get way less swag that way but the quality is way higher.

# ? Sep 5, 2015 22:11

tef: May 30, 2004; -> some l-system crap ->

let alone the bunch of :rice:

lock free algorithms hacker news gets a boner over

tef fucked around with this message at 22:21 on Sep 5, 2015

# ? Sep 5, 2015 22:15

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

fritz posted:

their hearts are in the right place at least: http://arxiv.org/abs/1508.07231

lol:

the paper posted:

Aspect is a large code: At the time of writing this chapter, it has 297 source files with 69,704 lines of code.

yeah that is a large code alright

# ? Sep 5, 2015 22:15

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

fleshweasel posted:

if you don't know how to do concurrency you should learn. read a loving book if you have to. have your coworker who does know review your code or work with you. it's not this exceptionally hard thing especially if your language offers constructs for doing it nicely. if you're writing a scheduler for an OS, sure, not everyone can specialize that much. but concurrency is too fundamental a thing to skip out on and is necessary for even relatively simple programs to work nicely.

it's also not hard to follow a few simple rules that will lead to always writing correct code

1. know if the platform you're working on imposes any major concurrency constraints, eg on OS X and iOS and many other platforms you must interact with the UI on the main thread

2. know the threading constraints for basic data structures on your platform, eg on OS X and iOS the basic immutable value classes and collections can be used on multiple threads safely and the basic mutable value classes must be protected from access by multiple threads

3. know the basic high-level concurrency constructs offered by your platform, eg threads, operations, queues, locks, semaphores, so you know how to do work in the background and actually protect shared resources from access by multiple threads

4. you probably don't need to use any low-level constructs yourself, leave that for the implementors of the high-level constructs. really. this includes atomic operations, barriers, volatile, etc.

5. look up everything else. always. never assume anything, ever, you will get it wrong.

these rules should apply on pretty much any platform you see

# ? Sep 5, 2015 22:27

The Management: Jan 2, 2010; sup, bitch?

eschaton posted:

4. you probably don't need to use any low-level constructs yourself, leave that for the implementors of the high-level constructs. really. this includes atomic operations, barriers, volatile, etc.

I'm going to upgrade this to don't ever do this, because you don't actually understand the platform as well as you think you do.

# ? Sep 5, 2015 22:40

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

eschaton posted:

it's also not hard to follow a few simple rules that will lead to always writing correct code

1. know if the platform you're working on imposes any major constraints

2. know the constraints for basic data structures on your platform

3. know the basic high-level constructs offered by your platform

4. you probably don't need to use any low-level constructs yourself, leave that for the implementors of the high-level constructs. really.

5. look up everything else. always. never assume anything, ever, you will get it wrong.

these rules should apply on pretty much any platform you see

# ? Sep 5, 2015 23:25

Catalyst-proof: May 11, 2011; better waste some time with you

eschaton posted:

it's also not hard to follow a few simple rules that will lead to always writing correct code

1. know if the platform you're working on imposes any major concurrency constraints, eg on OS X and iOS and many other platforms you must interact with the UI on the main thread

2. know the threading constraints for basic data structures on your platform, eg on OS X and iOS the basic immutable value classes and collections can be used on multiple threads safely and the basic mutable value classes must be protected from access by multiple threads

3. know the basic high-level concurrency constructs offered by your platform, eg threads, operations, queues, locks, semaphores, so you know how to do work in the background and actually protect shared resources from access by multiple threads

4. you probably don't need to use any low-level constructs yourself, leave that for the implementors of the high-level constructs. really. this includes atomic operations, barriers, volatile, etc.

5. look up everything else. always. never assume anything, ever, you will get it wrong.

these rules should apply on pretty much any platform you see

yeah man, concurrency isn't hard to learn, just avoid anything having to do with the hard parts of concurrency, and you'll be good at concurrency!

# ? Sep 6, 2015 00:09

Vanadium: Jan 8, 2005

it's like half "dont reinvent the wheel" and half "dont try to be cleverer than necessary" i guess

i wonder how far you get just using stuff provided by your lang's standard library that promises to work on all supported platforms

# ? Sep 6, 2015 00:33

Corla Plankun: May 8, 2007; improve the lives of everyone

probably the actual hardest part of concurrency is choosing your battles

# ? Sep 6, 2015 00:38

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

eschaton posted:

do you work for redhat now?

I thought you were just contracting there

i'm still contracting but it feels exactly like working there. also i'm pretty sure i'll be full time soon.

# ? Sep 6, 2015 01:43

Jerry Bindle: May 16, 2003

horse mans posted:

yeah man, concurrency isn't hard to learn, just avoid anything having to do with the hard parts of concurrency, and you'll be good at concurrency!

yeah agreed. similar to crypto, concurrency is really easy to get working 'alright', but it is very difficult to do a top-quality job of. i can go out there and read the executor service javadoc and run a bunch of threads just like i read the bouncy castle api and make a crypto product -- any one can. doesn't mean its a good idea!

# ? Sep 6, 2015 02:05

sarehu: Apr 20, 2007; (call/cc call/cc)

It's way different -- you can easily write concurrent code and prove it correct, even as some scrub, but you can't do that with crypto.

# ? Sep 6, 2015 02:22

Kilroy: Oct 1, 2000

coffeetable posted:

The Sushi Bar Problem posted:

Imagine a sushi bar with 5 seats. If you arrive while there is an empty seat, you can take a seat immediately. But if you arrive when all 5 seats are full, that means that all of them are dining together, and you will have to wait for the entire party to leave before you sit down.

Puzzle: write code for threads entering and leaving the sushi bar that enforces these requirements.

I did another @home quiz about a year ago that was almost exactly this, except instead of a single bar with five seats it was multiple tables. Also spent a long time testing it, and seemed fine. Also didn't get the job (although, in that case, I did have one more interview after the coding quiz at least).

Kilroy fucked around with this message at 04:19 on Sep 6, 2015

# ? Sep 6, 2015 04:11

triple sulk: Sep 17, 2014

that sushi problem is in the 7 weeks of concurrecy book or w/e it's called. i own it and read that part and there's something about locking and poo poo but i don't remember it all that well

# ? Sep 6, 2015 04:17

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

writing concurrent code is easy, just do the python method and have a single lock around all the code that shares anything with each other. it's not even that big of a performance issue if the amount of time spent doing that is small compared to the other work a thread does. an example of correct & safe (though not optimal) concurrent code:

code:

Butt getButt() {
  synchronized(this) {
    if (this.butt == null) {
      this.butt = makeButt();
    }
    return this.butt;
  }
}

it's once you start trying to be "clever" with concurrency that you gently caress things up.

# ? Sep 6, 2015 04:17

MeruFM: Jul 27, 2010

didn't you all do the dining philosopher problem in school? concurrency is a bitch sometimes but logicking through them is still possible.

# ? Sep 6, 2015 07:06

The Management: Jan 2, 2010; sup, bitch?

Jabor posted:

writing concurrent code is easy, just do the python method and have a single lock around all the code that shares anything with each other. it's not even that big of a performance issue if the amount of time spent doing that is small compared to the other work a thread does. an example of correct & safe (though not optimal) concurrent code:
code:
Butt getButt() {
  synchronized(this) {
    if (this.butt == null) {
      this.butt = makeButt();
    }
    return this.butt;
  }
}
it's once you start trying to be "clever" with concurrency that you gently caress things up.

Python is literal poop at concurrency. it gets slower and accomplishes less work with each thread you add. it is really very bad.

# ? Sep 6, 2015 14:31

gonadic io: Feb 16, 2011; >>=

terrible programmer question: in my game, I want to implement a tycoon like job queue.

what i want to happen:
- you say: i'd like these blocks to be put here.
- phantom blocks appear at the location
- a worker gets assigned the job to place those blocks
- the worker trundles over, and the phantom blocks get replaced with real ones
- the worker looks for his next jobs, and there should be some default 'idle' job.

also i want to be able to get a list of workers which includes which job they're currently doing (if any)
and a list of jobs which includes which worker is doing that job (if any).

this is sounding an awful lot like a database to me, is it worth integrating sql or something, or just doing it in code?
anybody got a particular way they'd recommend i implement this?

# ? Sep 6, 2015 15:01

Brain Candy: May 18, 2006

Jabor posted:

writing concurrent code is easy, just do the python method and have a single lock around all the code that shares anything with each other. it's not even that big of a performance issue if the amount of time spent doing that is small compared to the other work a thread does. an example of correct & safe (though not optimal) concurrent code:
code:
Butt getButt() {
  synchronized(this) {
    if (this.butt == null) {
      this.butt = makeButt();
    }
    return this.butt;
  }
}
it's once you start trying to be "clever" with concurrency that you gently caress things up.

lol, no, this is exactly the problem with Java's java.util.Vector where they synchronized all the methods

Java code:


Vector<V> things = ...

public void threadingIsEasy() {
    for (int i = 0; i < things.size(); ++i ) {
       V v = things.get(i); //Sometimes this throws an exception
       ...
    }
   ...
}

# ? Sep 6, 2015 15:12

Brain Candy: May 18, 2006

Kilroy posted:

Also spent a long time testing it, and seemed fine.

this is a dumb, you tested ~0% of cases. ofc you test, but spending a long time doesn't mean poo poo because of the magic of combinatorics

you gotta do a proof even if it's just in your head

# ? Sep 6, 2015 15:17

Kilroy: Oct 1, 2000

Brain Candy posted:

this is a dumb, you tested ~0% of cases. ofc you test, but spending a long time doesn't mean poo poo because of the magic of combinatorics

you gotta do a proof even if it's just in your head

How do you mean? I did reason about the code to convince myself of its correctness, for what that's even worth, and thought of different ways I could try to break it, and then wrote code to do that. That's what I mean by "spent a long time testing it". What should I be doing to prove out concurrent code?

# ? Sep 6, 2015 15:35

MononcQc: May 29, 2007

gonadic io posted:

terrible programmer question: in my game, I want to implement a tycoon like job queue.

what i want to happen:
- you say: i'd like these blocks to be put here.
- phantom blocks appear at the location
- a worker gets assigned the job to place those blocks
- the worker trundles over, and the phantom blocks get replaced with real ones
- the worker looks for his next jobs, and there should be some default 'idle' job.

also i want to be able to get a list of workers which includes which job they're currently doing (if any)
and a list of jobs which includes which worker is doing that job (if any).

this is sounding an awful lot like a database to me, is it worth integrating sql or something, or just doing it in code?
anybody got a particular way they'd recommend i implement this?

finite state machines sound like the thing.

- a task is planned with a given location, where a block is placed.

- at that location you place a 'block' in a state 'pending'
- a worker assigned to a block switches it to the 'scheduled' state
- when a block is handled by a worker, it switches into the 'done' state where it stays at.

- a worker has an `idle` state where it hangs around/does nothing.
- a block in the 'pending' state triggers an event to be sent to one of the workers
- a worker picks the block and goes into a 'scheduled' state where it tries to reach there -- the worker notifies the block of this
- a worker switches into the 'working' state once reaching the block
- when done, the worker goes back into idle.

block: pending --> scheduled --> done
worker: idle --> scheduled --> working --> idle

The workers can be put in any sort of data structure, but something location-related may sound good if most of the work will be to find workers closest to tasks and so on. The advantage of a FSM-based approach is that you can drive interrupts, nest the FSMs, etc. and get a lot of flexibility: do you want max parallelism? Assign all blocks to different workers. Do you want more efficient worker-usage? Assign a limit distance between worker and blocks and let workers queue up tasks.

The hard part is moving your things to be somewhat event-based, which can yield confusing interactions and organization, and can bring you to very surprising feedback loops.

Stuff feels like a database because you have a lot of data to sift through, but that's because we associate 'database' with 'state'. There is no need in this thing (that I can see or know of) to depend on a DB if you don't need persistency and to have all of your data copied to an external system.

# ? Sep 6, 2015 15:41

Brain Candy: May 18, 2006

Kilroy posted:

How do you mean? I did reason about the code to convince myself of its correctness, for what that's even worth, and thought of different ways I could try to break it, and then wrote code to do that. That's what I mean by "spent a long time testing it". What should I be doing to prove out concurrent code?

here's how i do it YMMV

- figure out exactly what i need to do
- do it
- test to make sure i didn't gently caress up the implementation

typically you get to do this in a loop in non-concurrent code so if you don't get it right the first time you can still red-green-refactor to something nice. also, you don't need to do it exactly, just being in the right general direction is enough. it looks v. similar:

- figure out what to do
- do it
- test to see if the implementation or the design was bad
- repeat until happy

the difference is that you can test your ideas while you are testing your implementation. in concurrent code, you only get to test your implementation because your tests can't validate a good design, only fail an awful one. because of the ridiculous permutations of how things can go down, you could test for the rest of your life and it still wouldn't allow you to be confident about your design.

# ? Sep 6, 2015 16:33

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Brain Candy posted:

lol, no, this is exactly the problem with Java's java.util.Vector where they synchronized all the methods
Java code:
Vector<V> things = ...

public void threadingIsEasy() {
    for (int i = 0; i < things.size(); ++i ) {
       V v = things.get(i); //Sometimes this throws an exception
       ...
    }
   ...
}

The "easy and correct" mechanism there is ofc:

code:

synchronized(things) {  
    for (int i = 0; i < things.size(); ++i ) {
       V v = things.get(i); //It's safe now
       ...
    }
}

the important thing is you have a single lock you take at the start and release at the end. if you don't try and be "clever" (like, for example, thinking "I don't need to take the lock because the individual methods are synchronized"), you will come up with a correct solution.

# ? Sep 6, 2015 17:14

Brain Candy: May 18, 2006

Jabor posted:

The "easy and correct" mechanism there is ofc:
code:
synchronized(things) {  
    for (int i = 0; i < things.size(); ++i ) {
       V v = things.get(i); //It's safe now
       ...
    }
}
the important thing is you have a single lock you take at the start and release at the end. if you don't try and be "clever" (like, for example, thinking "I don't need to take the lock because the individual methods are synchronized"), you will come up with a correct solution.

which is why getButt used an intrinsic lock so that i have the same number of locks as i have instances i touch

# ? Sep 6, 2015 17:44

Brain Candy: May 18, 2006

please continue this retarded regression, i want to get you to champion python's GIL

# ? Sep 6, 2015 17:45

suffix: Jul 27, 2013; Wheeee!

gonadic io posted:

terrible programmer question: in my game, I want to implement a tycoon like job queue.

what i want to happen:
- you say: i'd like these blocks to be put here.
- phantom blocks appear at the location
- a worker gets assigned the job to place those blocks
- the worker trundles over, and the phantom blocks get replaced with real ones
- the worker looks for his next jobs, and there should be some default 'idle' job.

also i want to be able to get a list of workers which includes which job they're currently doing (if any)
and a list of jobs which includes which worker is doing that job (if any).

this is sounding an awful lot like a database to me, is it worth integrating sql or something, or just doing it in code?
anybody got a particular way they'd recommend i implement this?

i don't think any real-time games keep their state in a database like that. it's just too slow

the done thing is to maintain a bunch of linked lists so you can quickly find all workers, or all idle workers, or all build orders, etc

that's a lot faster to update than a database
and a lot more bug-prone, e.g.: http://www.codeofhonor.com/blog/tough-times-on-the-road-to-starcraft

quote:

Given all the issues working against the team, you might think it was hard to identify a single large source of bugs, but based on my experiences the biggest problems in StarCraft related to the use of doubly-linked linked lists.

so you'd keep a bunch of lists, but make sure you update them from one place, e.g. automatically update the lists when you change a workers status, and have debug assertions, so if you iterate over busy workers and find an idle one you know you hosed up

# ? Sep 6, 2015 17:58

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Brain Candy posted:

please continue this retarded regression, i want to get you to champion python's GIL

it's straightforward to implement correctly, and the downside is relatively poo poo performance

not sure why you think this is complicated

# ? Sep 6, 2015 18:52

gonadic io: Feb 16, 2011; >>=

MononcQc posted:

finite state machines sound like the thing.

something like this as a rough framework? if this state machine is to maintain the state across the entire program then it needs access to the object that it's attached to which sets off a red flag

# ? Sep 6, 2015 19:43

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

gonadic io posted:

something like this as a rough framework? if this state machine is to maintain the state across the entire program then it needs access to the object that it's attached to which sets off a red flag

i feel like if i ever went down the scala rabbit hole i would never come out

sealed classes? case classes? so many ways to control my code that no one will ever use

# ? Sep 6, 2015 19:48

Valeyard: Mar 30, 2012; Grimey Drawer

Arrived in London and want to off myself, I got stuck in a lovely room that is smaller than all the other small rooms, and its boiling

# ? Sep 6, 2015 19:54

gonadic io: Feb 16, 2011; >>=

sealed = the only subclasses are defined in this file
case = automatic setter and getter properties for the constructors

sealed case classes are basically to give scala ADT-like sytax like haskell's data

# ? Sep 6, 2015 19:54

coffeetable: Feb 5, 2006; TELL ME AGAIN HOW GREAT BRITAIN WOULD BE IF IT WAS RULED BY THE MERCILESS JACKBOOT OF PRINCE CHARLES

YES I DO TALK TO PLANTS ACTUALLY

coffeetable posted:

gotta learn matlab. anyone know of a matlab book written for people who already know what a for loop is?

Matlab: Programming Fundamentals is what i wanted it turns out. discoveries so far

one externally-visible function per file. lollll. thankfully modules are possible, though im betting noone uses them
you can put matlab code inside a regular expression.
non-negligible function call overhead wtf

coffeetable fucked around with this message at 20:38 on Sep 6, 2015

# ? Sep 6, 2015 20:04