awful programming -> here's a pointer: use a better language!!!

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > YOSPOS > awful programming -> here's a pointer: use a better language!!!

«‹›1321 »

VikingofRock: Aug 24, 2008

Can we talk about the elephant in the room here? What possessed everyone to use

C++ code:


/* these comments */

instead of

C++ code:


// these comments

? C99 turns twenty next year...

# ? Jul 18, 2018 19:01

Adbot: ADBOT LOVES YOU

# ? Jan 15, 2026 04:39

Progressive JPEG: Feb 19, 2003

VikingofRock posted:

Can we talk about the elephant in the room here? What possessed everyone to use
C++ code:
/* these comments */
instead of
C++ code:
// these comments
? C99 turns twenty next year...

i'll sometimes use /* comments */ for inline stuff, e.g. annotating parameters when they aren't obvious

C++ code:

somefunc(false /* butt */, true /* fart */);

outside of that, i prefer // comments because then its easier for someone to comment out a chunk of code temporarily with their own /* */'s

# ? Jul 18, 2018 19:42

Chopstick Dystopia: Jun 16, 2010; lowest high and highest low loser of: WEED WEE
k

VikingofRock posted:

Can we talk about the elephant in the room here? What possessed everyone to use
C++ code:
/* these comments */
instead of
C++ code:
// these comments
? C99 turns twenty next year...

I preferred the way they emphasised /* the text */
I mostly use // in the wild but it depends.

Sure adapt to your team, but what if you're coming in as the architect or tech lead?

Probably should spend the first day using IDE/lint/an extremely unsafe regex to rewrite all existing code in your bracket and spacing style then recommit the entire code base to establish dominance.

# ? Jul 18, 2018 20:16

Lutha Mahtin: Oct 10, 2010

is there a way to auto format comments in jetbrains ides? in java files they support autoformatting when it's a javadoc comment, but not when it's a standard block or line comment. I've looked around and not found anything for it, which is super frustrating because the code to do it is obviously there

the main thing that drives me nuts is that i have to hand-janitor mutli-line comments if i ever edit them and change the comment to need more or fewer lines of text. the javadoc formatter does nice line re-wrapping

# ? Jul 18, 2018 20:20

Toady: Jan 12, 2009

i always use //, but i guess some people prefer the other style because you can easily comment out whole sections by moving the terminator. i just use my IDE's hotkey which //'s out the current selection

# ? Jul 18, 2018 20:23

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

Lutha Mahtin posted:

is there a way to auto format comments in jetbrains ides? in java files they support autoformatting when it's a javadoc comment, but not when it's a standard block or line comment. I've looked around and not found anything for it, which is super frustrating because the code to do it is obviously there

the main thing that drives me nuts is that i have to hand-janitor mutli-line comments if i ever edit them and change the comment to need more or fewer lines of text. the javadoc formatter does nice line re-wrapping

select all, code -> reformat code

# ? Jul 18, 2018 21:16

redleader: Aug 18, 2005; Engage according to operational parameters

shut the gently caress up about code formatting. this was never an interesting topic the last 500 times it was discussed, and it is still not an interesting topic

# ? Jul 18, 2018 21:50

redleader: Aug 18, 2005; Engage according to operational parameters

although on further consideration, it's petty enough to be appropriate for the terrible programmer thread. namaste

# ? Jul 18, 2018 21:51

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 8 years!)

redleader posted:

shut the gently caress up about code formatting. this was never an interesting topic the last 500 times it was discussed, and it is still not an interesting topic

you sound like the kind of person who changes formatting in the middle of a line

# ? Jul 18, 2018 21:52

Mao Zedong Thot: Oct 16, 2008

redleader posted:

shut the gently caress up about code formatting. this was never an interesting topic the last 500 times it was discussed, and it is still not an interesting topic

# ? Jul 18, 2018 22:08

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

cjs: i have a job now

# ? Jul 18, 2018 23:04

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

programming is still bad

# ? Jul 18, 2018 23:06

Ellie Crabcakes: Jan 31, 2008; Stop emailing my boyfriend Gay Crungus

redleader posted:

code:

shut the gently caress up
         about code formatting.
this was never
         an interesting topic the
         last 500 times it was 
         discussed, and it is still
         not an interesting topic

# ? Jul 18, 2018 23:07

Shaman Linavi: Apr 3, 2012

newjob uses resharper and it forces everyone to use the 100% correct indentation style
allman style

# ? Jul 18, 2018 23:12

flakeloaf: Feb 26, 2003; Still better than android clock

oh hey assert() is dead, that's good news

try
{wait i already validated this, gently caress off}

throw (my hands in the air like i do not care)

# ? Jul 18, 2018 23:46

fritz: Jul 26, 2003

tef posted:

programming is still bad

mlmp

# ? Jul 19, 2018 00:09

Doom Mathematic: Sep 1, 2008

A good programmer is a child who is learning to make silly games and having a blast.

# ? Jul 19, 2018 00:39

SardonicTyrant: Feb 26, 2016; BTICH IM A NEWT
熱くなれ夢みた明日を
必ずいつかつかまえる
走り出せ振り向くことなく
&

I am a good programmer because I admit I am a terrible programmer.

# ? Jul 19, 2018 01:08

FlapYoJacks: Feb 12, 2009; DOES NOT OWN EXOTIC FISH

SardonicTyrant posted:

I am a good programmer because I admit I am a terrible programmer.

re: terrible programmers: I am a good programmer because I admit I am a terrible programmer.

# ? Jul 19, 2018 01:09

floatman: Mar 17, 2009

I am a programmer who's just good enough to know he's terrible and not good enough to ever improve, life is suffering and despair namaste.

# ? Jul 19, 2018 01:23

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

fantastic news everyone!! you'll all be excited to know that my HKT embedding in rust is working without the terrible overhead of packing every possible kind into a single enum. the trick was to model computations over kinds as what is basically lazy iterator with a special evaluator built in.

code:

    #[test]
    fn test_vec_functor() {
        let e = Vec::<i32>::eval()
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| format!{"{:?}", i});

        // operation is constructed on the stack, so, typeof e is:
        // `functor<'_, VecKind, String,
        //         functor<'_, VecKind, i32, [closure@src/sandbox/lazy8.rs:377:18: 377:27],
        //                functor<'_, VecKind, i32, [closure@src/sandbox/lazy8.rs:376:18: 376:27],
        //                       Head<'_, VecKind, i32>>>>`
        assert_eq!(e.run(vec![1,2,3]), vec!["4".to_owned(), "8".to_owned(), "12".to_owned()]);
        assert_eq!(e.run(vec![3,2,1]),  vec!["12".to_owned(), "8".to_owned(), "4".to_owned()])
    }

performance is not too bad!

code:

// i know nothing about benchmarking so this probably sucks!
    #[bench]
    fn bench_vec_map_native(b: &mut Bencher) {
        b.iter(|| {
            let result = vec![1, 2, 3]
                .into_iter()
                .map(|i| i * 2)
                .map(|i| i * 2)
                .map(|i| format!("{:?}", i))
                .collect::<Vec<String>>();

            let result2 = vec![1, 2, 3]
                .into_iter()
                .map(|i| i * 2)
                .map(|i| i * 2)
                .map(|i| format!("{:?}", i))
                .collect::<Vec<String>>();

            assert_eq!(result, result2)
        });
    }

    #[bench]
    fn bench_vec_map_from_functor(b: &mut Bencher) {
        let h = Vec::<i32>::eval()
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| format!{"{:?}", i});

        b.iter(|| {
            let result = h.run(vec![1, 2, 3]);
            let result2 = h.run(vec![1, 2, 3]);
            assert_eq!(result, result2)
        })
    }

test sandbox::lazy8::tests::bench_vec_map_from_functor    ... bench:         857 ns/iter (+/- 80)
test sandbox::lazy8::tests::bench_vec_map_native          ... bench:         666 ns/iter (+/- 103)

the difference is constant, (i think: no matter how many operations you chain, the functor version is about 150ns behind native). there's a traversal step that I think i could eliminate by "compiling" the operation, as well as a few other spots for optimization. it's pretty close to zero cost. there's a single heap allocation for a generator that yields the inner type (the A in F<A>) into the operation. the allocation is being made so that i can return a generator from a function, so i might be able to fix this by creating or consuming the generator elsewhere. but i'm not sure about that.

the interface suffers quite a bit but it still accomplishes my goals. the enum interface is considerably better but i'm pretty sure you're not going to do better without modifying the compiler:

code:

impl<'d> Functor<'d, VecKind> for VecKind {
    /// If you use your imagination, you can pretend that this translates to:
    /// (F<A>, Fn(A) -> B) -> F<B>
    /// While it's pretty ugly, the type equation above is enforced.
    /// There's also some room for improvement here.
    ///
    /// In this encoding, "FA" represents our concrete HKT, Vec<A>.
    ///
    /// The return type is the ugliest bit: basically, the only way to build a deferred chain
    /// of polymorphic operations on the stack is by building a nested structure like so:
    /// Map {
    ///   op: closure@src...,
    ///   inner: Map {
    ///       op: closure@src...,
    ///       inner: Value(Some(1))
    ///
    /// The outermost map executes it's closure with the value of the output of it's inner Map, which
    /// executes it's closure with the output of _it's_ inner Map, and so forth. This is how futures and interators work.
    ///
    /// So anyhow, we basically have to pass our function and our FA into the output of our functor,
    /// so I'm basically just pretending this is boilerplate that you can ignore. However it's still
    /// an important and complicated part of the public api so it's really not ideal. OH well.
    fn map<F, A, B, FA>(fa: FA, f: F) -> functor<'d, VecKind, B, F, FA>
    where
        F: Fn(FA::Item) -> B,
        FA: Lifted<'d, Kind = VecKind, Item= A>,
    {
        functor {
            inner: fa,
            f: f,
            __marker_k: VecKind,
            __marker_b: PhantomData,
        }
    }
}

but uh, there's a problem:

code:

        let h = Vec::<i32>::eval()
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| format!{"{:?}", i});
> time cargo test

I gave up after 10 minutes, so it appears that compile time increases exponentially with the number of operations chained. naive guess is that it's related to generators, since they're unstable, otherwise i have no idea.

why am i doing this?

DONT THREAD ON ME fucked around with this message at 03:35 on Jul 19, 2018

# ? Jul 19, 2018 03:02

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

oh yeah coroutines motherfuckers!!

code:

    fn request_yield<D2>(
        &'d self,
        input: <Self as Lifted<'d>>::HeadInput,
        outer: D2,
    ) -> Box<Generator<Yield = <D2 as Yield<'d>>::ChainOutput, Return = ()> + 'd>
    where D2: 'd + Yield<'d, Input = Self::Item>
    {
        Box::new(move || {
            for i in input.into_iter() {
                yield outer.run(i)
            }
            return ();
        })
    }

# ? Jul 19, 2018 03:21

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I�ve graduated from embedded C and now I�m just writing a Jaguar game in 68000 assembly

also when I tweet about writing the OS for my 68k computer I keep getting followed by kernel engineers who live in San Francisco

I may be a good programmer...

nah I still suck at my day job of janitoring AWS

# ? Jul 19, 2018 03:42

JawnV6: Jul 4, 2004; So hot ...

MALE SHOEGAZE posted:

performance is not too bad!
code:
// i know nothing about benchmarking so this probably sucks!
    #[bench]
    fn bench_vec_map_native(b: &mut Bencher) {
        b.iter(|| {
            let result = vec![1, 2, 3]
                .into_iter()
                .map(|i| i * 2)
                .map(|i| i * 2)
                .map(|i| format!("{:?}", i))
                .collect::<Vec<String>>();

            let result2 = vec![1, 2, 3]
                .into_iter()
                .map(|i| i * 2)
                .map(|i| i * 2)
                .map(|i| format!("{:?}", i))
                .collect::<Vec<String>>();

            assert_eq!(result, result2)
        });
    }

    #[bench]
    fn bench_vec_map_from_functor(b: &mut Bencher) {
        let h = Vec::<i32>::eval()
            .map(|i| i * 2)
            .map(|i| i * 2)
            .map(|i| format!{"{:?}", i});

        b.iter(|| {
            let result = h.run(vec![1, 2, 3]);
            let result2 = h.run(vec![1, 2, 3]);
            assert_eq!(result, result2)
        })
    }

test sandbox::lazy8::tests::bench_vec_map_from_functor    ... bench:         857 ns/iter (+/- 80)
test sandbox::lazy8::tests::bench_vec_map_native          ... bench:         666 ns/iter (+/- 103)
the difference is constant, (i think: no matter how many operations you chain, the functor version is about 150ns behind native). there's a traversal step that I think i could eliminate by "compiling" the operation, as well as a few other spots for optimization. it's pretty close to zero cost. there's a single heap allocation for a generator that yields the inner type (the A in F<A>) into the operation. the allocation is being made so that i can return a generator from a function, so i might be able to fix this by creating or consuming the generator elsewhere. but i'm not sure about that.

hi, i still know absolutely nothing about "kinds" despite several generous attempts, but i DO know benchmarking

are you doing any source inspection? i'll admit i reach for that super early, but you'd want to make sure that the 'native' version isn't getting artificially boosted by the compiler (like that rjmccall post about the swift perf 'regression') . make sure it's actually doing the work, with such a short list it'd be tempted to just solve it at compilation time, you want to see it 'actually' loading values from a list-lookin' thingy and processing them

is 'eval' up there a language feature kicking into an interpreter or a hook of your implementation?

MALE SHOEGAZE posted:

I gave up after 10 minutes, so it appears that compile time increases exponentially with the number of operations chained.

hm, sounds like the compiler's fault

Luigi Thirty posted:

kernel engineers who live in San Francisco

those jerks??

# ? Jul 19, 2018 03:55

redleader: Aug 18, 2005; Engage according to operational parameters

tef posted:

cjs: i have a job now

# ? Jul 19, 2018 04:09

tinaun: Jun 9, 2011; tell me...

male shoegaze you should write a blog chronicling your HKT rust adventures, there's fp nerds on the lang team who would probably love to read about it

# ? Jul 19, 2018 04:24

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

JawnV6 posted:

hi, i still know absolutely nothing about "kinds" despite several generous attempts, but i DO know benchmarking

are you doing any source inspection? i'll admit i reach for that super early, but you'd want to make sure that the 'native' version isn't getting artificially boosted by the compiler (like that rjmccall post about the swift perf 'regression') . make sure it's actually doing the work, with such a short list it'd be tempted to just solve it at compilation time, you want to see it 'actually' loading values from a list-lookin' thingy and processing them

by source inspection I assume you mean inspecting the outputted assembly? yeah I would very much like to and I've tried but I need a little bit more time with assembly before I can make sense of it. working on that!

anyhow as you say: vec for sure has at least unsafe optimizations that i could probably implement. but i wouldn't be surprised if there's compiler boosting. so i'm optimistic about where i'll be able to get performance.

but yeah, uh, testing a bigger list, that makes sense. same benchmark as before but with 10,000 entries in the list:

code:

test sandbox::lazy8::tests::bench_vec_map_from_functor    ... bench:   2,231,253 ns/iter (+/- 40,062)
test sandbox::lazy8::tests::bench_vec_map_native          ... bench:   2,138,998 ns/iter (+/- 39,938)

quote:

is 'eval' up there a language feature kicking into an interpreter or a hook of your implementation?

eval is part of my implementation, it's just creating the head of the evaluation chain, which is later interpreted. I've been thinking of it as an interpreter anyhow.

quote:

hm, sounds like the compiler's fault

yeah, i think so.

tinaun posted:

male shoegaze you should write a blog chronicling your HKT rust adventures, there's fp nerds on the lang team who would probably love to read about it

i decided that i was going to blog about it early on so i've actually been taking notes and stuff. thanks for the prodding, the hard part now is not giving up when i decide that it's all stupid.

e: my benchmark currently maps the `Vec<i32>` to a `Vec<String>`, if i skip the string formatting step and just multiply the int a couple of times, the native implementation does much, much, much better.

code:

test sandbox::lazy8::tests::bench_vec_map_from_functor_no_string_alloc    ... bench:      69,607 ns/iter (+/- 7,078)
test sandbox::lazy8::tests::bench_vec_map_native_no_string_alloc          ... bench:       7,118 ns/iter (+/- 546)

Feels like some compiler hjinks to me, but it's not really surprising that iterators would be optimized around the simple computation i'm giving it.

DONT THREAD ON ME fucked around with this message at 12:31 on Jul 19, 2018

# ? Jul 19, 2018 12:08

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

JawnV6 (or anyone else): recommendations on where to get started learning assembly? it's about time.

don't say reading luigi's posts

# ? Jul 19, 2018 12:24

gonadic io: Feb 16, 2011; >>=

MALE SHOEGAZE posted:

Feels like some compiler hjinks to me, but it's not really surprising that iterators would be optimized around the simple computation i'm giving it.

Probably gets vectorised if the compiler can prove its a flat array yeah

# ? Jul 19, 2018 12:35

Sapozhnik: Jan 2, 2005; Nap Ghost

MALE SHOEGAZE posted:

JawnV6 (or anyone else): recommendations on where to get started learning assembly? it's about time.

don't say reading luigi's posts

https://blogs.msdn.microsoft.com/oldnewthing/20040914-00/?p=37873

# ? Jul 19, 2018 13:24

Luigi Thirty: Apr 30, 2006; Emergency confection port.

my x86 assembly knowledge really only applies to DOS and the 486 era

# ? Jul 19, 2018 14:38

flakeloaf: Feb 26, 2003; Still better than android clock

Luigi Thirty posted:

my x86 assembly knowledge really only applies to DOS and the 486 era

hi mister gibson, thanks for warning us about those raw sockets

# ? Jul 19, 2018 14:45

jony neuemonic: Nov 13, 2009

Luigi Thirty posted:

my x86 assembly knowledge really only applies to DOS and the 486 era

a better time, really.

# ? Jul 19, 2018 14:46

Luigi Thirty: Apr 30, 2006; Emergency confection port.

flakeloaf posted:

hi mister gibson, thanks for warning us about those raw sockets

you�re welcome. buy my hard drive software

# ? Jul 19, 2018 14:50

Lutha Mahtin: Oct 10, 2010

MALE SHOEGAZE posted:

JawnV6 (or anyone else): recommendations on where to get started learning assembly? it's about time.

don't say reading luigi's posts

you could look into a textbook or one of those open online classes for an undergrad level "computer organization" course. this is the class where you learn assembly and how the processor, uh, processes it

after you learn assembly you can learn how to write a compiler :getin:

# ? Jul 19, 2018 15:30

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

Lutha Mahtin posted:

you could look into a textbook or one of those open online classes for an undergrad level "computer organization" course. this is the class where you learn assembly and how the processor, uh, processes it

after you learn assembly you can learn how to write a compiler

ya ive written a few interpreters, so ive been looking forward to writing a compiler for a while

# ? Jul 19, 2018 15:56

The MUMPSorceress: Jan 6, 2012; ^SHTPSTS; Gary’s Answer

i learmed mips assembly for my compilers class and it was a pretty easy way to get my toes what with an assembly language. i have no loving clue how well that translates to the x86 shibboleth because ive never tried to gently caress with that poo poo.

# ? Jul 19, 2018 16:04

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

goddamn i'm so excited to have a year to study this stuff in earnest rather than cramming at night or on weekends when i'm already tired.

# ? Jul 19, 2018 16:13

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 8 years!)

my computer organization course was in masm and it wasn't too bad imo, but we stuck to ia-32 so maybe amd64 is worse?

# ? Jul 19, 2018 16:15

Adbot: ADBOT LOVES YOU

# ? Jan 15, 2026 04:39

VikingofRock: Aug 24, 2008

Hey male shoegaze if you're getting exponential compilation times you should file an issue on the rust GitHub. They take solving that sort of thing pretty seriously so I'm sure they would be very interested in hearing about your case.

# ? Jul 19, 2018 16:29

The Something Awful Forums > Discussion > Serious Hardware / Software Crap > YOSPOS > awful programming -> here's a pointer: use a better language!!!

«‹›1321 »