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

«‹›3 »

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Pissflaps posted:

10 print "gas and ban install opera"
20 goto 10

this is real bad advice just b t w

for all the bad programmers itt who might not know better

# ¿ May 7, 2013 22:45

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 20:21

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Police Academy III posted:

I've a sneaking suspicion that there's only a very low number of people who are in any way decent at programming, but they've realized that there's no way for them to transmit that knowledge to the rest of us and so are content to let us keep running around like retards and making grand, overly generalized proclamations about programming on hacker news.

actually no one knows how to program decently

h t h

# ¿ May 8, 2013 03:49

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

chumpchous posted:

when people say a programming language is pass by reference, does that mean you can call a function using pointers as variables? wheras some languages don't allow you to use pointers? if that's the case what is the appeal of a non pass-by-reference language?

That's not what 'pass-by-reference' means.

When a function is 'pass-by-reference', the arguments are passed as pointers ('references') to the actual values, rather than the values proper. This means that you can modify the arguments (by dereferencing the pointer), which can be good or bad. It also means that you don't have to copy the values from one space in memory to another, which is important when dealing with large variables (arrays, big objects, etc).

In C and similar languages, you can actually work with pointers, so you can make the decision explicitly. (void foo(int a, int * b) - a is passed by value, b is passed as a pointer.) Java doesn't have user-defined pointers, so the language has to make the decision for you. The decision they made for primitives (ints, bools, etc) was 'pass-by-value'. In "int a = 1; foo(a); print(a)", the result printed will always be '1', no matter what happens in foo(). This is the primary appeal of pass-by-value: you can guarantee that variables passed as function arguments remain unchanged when you return to your own scope. It's a reasonable default.

Java objects, on the other hand, are passed by reference: if you pass in an object to a function & modify it therein, you can retrieve the modified value from the calling function. That means it's possible to 'simulate' pointers in Java by using objects. E.g. "class IntPointer { int containedInt; } IntPointer a = new IntPointer(); foo(a); print(a.containedInt) - the result could be anything! This is of course clunky & overly verbose, but if you like Java, that is probably right up your alley!

The (primary) reason that Java doesn't have pointers is that pointers let you freely tinker with memory. Unlike C, Java's memory is managed - instead of the programmer having to handle memory allocation & deallocation, it's abstracted into an operation of the JVM. That means, as another consequence, that the programmer can't be allowed to tinker with memory freely, because that would break the abstraction that lets Java's memory management works.

^^ This paragraph is the actual answer you were looking for, feel free to skip the rest.

*java objects are actually pointers with a very constrained set of operations that can be performed on them.

# ¿ May 8, 2013 04:16

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

that was a long and boring carepost in the pos.

things that are more fun than talking about java and pointers and pass-by-reference: function pointers, closures, lambdas, first-class functions generally. ask me about those!

also sorry if I got anything wrong in my last post, I'm tired and suffering from allergies and my grandpa died last night and I'm typing enormous amounts of dumb poo poo rather than think about anything right now.

:justpost:

e: haha, it looks like I was responding to tori there

sorry

# ¿ May 8, 2013 04:19

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Tori CMOS posted:

owned

# ¿ May 8, 2013 04:21

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

ShadowHawk posted:

Thanks for this, it made me realize I already understood pointers but didn't really have words for them cause I've been working in python and ruby and never got no CS degree

half the common problems people have with pointers are just dumb syntax poo poo

int * foo, bar, etc

pointers are really very simple once you understand the basics!

except when you start dealing with funny pass-by-reference stuff (void foo(int& bar){}), dumb tricks/idioms like *foo++, etc

(basically the only reason pre/post-increment operators exist in tyool 2013 are to enable people who want to write unreadable code and/or to accidentally stumble into undefined language behavior)

but the basics of pointers are basically just one conceptual leap, and if you know how objects work in java/python/ruby then you're pretty much already there.

congrats!

# ¿ May 8, 2013 05:20

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

tef posted:

java is call by value. objects are stored as reference.

in a pass by reference language you can write a swap function.

actual languages that are pass by ref: perl

yeah sorry I was real tired. I mentioned actual pass by reference in my second post in passing but basically I'm dumb.

also I've never used perl or other pass-by-reference languages so that's my excuse.

(fun fact: I originally described java as being universally pass-by-value, then I went back and edited it into the current state because if passing references by value isn't pass-by-reference, what is????)

((I'm dumb))

# ¿ May 8, 2013 16:12

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

# ¿ May 9, 2013 23:06

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

I was going to complain about OBL mixing brace styles but I mean

well

there's nothing to say now

code:

                                 catch(Exception x)
                                      {
                               logger . debug("!!! "+x.toString()+" "+key);
                               logger . error("!!! "+x.toString());
                                      }

# ¿ May 10, 2013 15:26

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Mr SuperAwesome posted:

if you're really stuck or retarded or more likely the original author was retarded

why not...

both !?

# ¿ May 12, 2013 15:26

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Mr SuperAwesome posted:

http://msdn.microsoft.com/en-us/library/vstudio/ff926074.aspx

this is what you are looking for hth

that document seems to recommend only sometimes using var, and using explicit variable typing in cases where the type might not be obvious from context

I guess that means the truth was

somewhere in the middle????

# ¿ May 12, 2013 17:40

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Hellsworn Barn posted:

are you fuckers serious about checked exceptions

do you even shaggar ????

# ¿ May 13, 2013 21:40

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

http://www.theonion.com/articles/find-the-thing-youre-most-passionate-about-then-do,31742/

# ¿ May 14, 2013 16:14

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Tiny Bug Child posted:

this is almost correct, but opening braces never go on their own line

agreeing with tbc

Hellsworn Barn posted:

there is literally no way to "properly deal with checked exceptions." the key to safe exception handling is centralization. every process/app domain/whatever should have a centralized handler responsible for managing control flow based on exception type/data/context. the good part about checked exceptions is that they provide information regarding what exceptions may be thrown, which helps get the logic in your centralized handler right the first time. the bad part about checked exceptions is that it encourages bad exception handling practices by forcing you to deal with exceptions throughout your code. the good is greatly outweighed by the bad since proper design all but eliminates the need for conditional logic based on exception type.

disagreeing with someone who's disagreeing with shaggar (which is practically the same as agreeing with shaggar)

this day is off to a terrible start!

# ¿ May 16, 2013 20:04

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

THC posted:

In the Stanford course on iTunes U, the guy says to enable a breakpoint for all exceptions and to just have that on all the time. Is there any situation where I would not want to do this? Most of the projects I've looked at don't have this turned on.

edit: talkin bout Xcode

code:

void foo() {
    ...
    throw new ButtException();
}

void main() {
    ...
    try {
        foo();
    } catch (ButtException e) {
        safelyHandleError(e);
    }
    ....
}

you probably aren't interested in having the debugger halt execution whenever an exception occurs.

setting breakpoints on exceptions can be useful when debugging specific problems, of course, but it's not a good general rule.

e: I might be misunderstanding what exactly the lecturer advises. if xcode has functionality that breaks whenever an exception bubbles up to the top level to allow easy stack analysis, that sounds nice & useful.

# ¿ May 18, 2013 00:39

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

um no wtf don't use exceptions for normal control flow, test for potential conditions that will cause exceptions and handle them in advance whenever possible

it's entirely possible for one section of code to be unable to handle an error condition (e.g. "missing file"), which a higher-level section of code can handle & recover from

this is in fact a canonical use of exceptions

and my point was that you probably don't want to fire a breakpoint every time that happens

# ¿ May 18, 2013 00:58

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

exceptions are a form of non-local goto and should only be used when you have a condition where halting your program and handling it is the only alternative to crashing

they are expensive as gently caress to throw in a lot of languages too

caveat: i'm a .net programmer primarily, i understand python does weird poo poo like using exceptions for control-flow

so, fun python trivia

iteration, e.g. "for foo in bar", uses the iterator interface, defined here. it's pretty simple. two methods: __iter__(), which returns the iterator object itself, and __next__(), which returns the next item to be iterated over. if there is no next item (e.g., you're at the end of a list), raise a StopIteration exception.

this 'makes sense', because the great majority of the time, __next__() will end up returning instead of throwing an exception (for lists longer than 1 item, etc). therefore, running out of items in a list is an exceptional condition.

python is mostly great but it has some really dumb ideas here and there.

THC posted:

It is literally a "break whenever an exception is thrown" breakpoint so if you have an exception somewhere thats crashing your program you can turn this on and it shows you the exact line of code instead of crashing and throwing up gobbledygook. The stanford prof recommends to have it on all the time. You can always disable it if it gets in the way of your regular testing but it seems like a lot of devs don't even know this is a feature.

ok yeah so what I said.

in the Real World, poo poo happens all the time, especially if you're dealing with big distributed systems. things are going to break, and your code is going to have to recover from this. even in a dev context, setting up a 'break on exception' breakpoint like that doesn't really make any sense.

of course, you're doing academic tiny homework assignments, so it makes a lot more sense there. doubly so if you're somehow not able to get stack traces or even line numbers on crashes (????), I guess, though it sounds like something's wrong there.

# ¿ May 18, 2013 01:06

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

less terrible coders than me talk about it here:

http://c2.com/cgi/wiki?DontUseExceptionsForFlowControl

I think we're actually agreeing but dear god I hate the page you linked me to

everything looks like it's written by a tvtropes reject

quote:

I HaveThisPattern, I always use return statements to jump out of nested work, it's a natural pattern when using LotsOfShortMethods, goes right along with GuardClauses to bail early.

I mean, what he's saying is totally reasonable, I do the exact same thing, but

uuuugh

# ¿ May 18, 2013 01:10

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

the higher order code should check for the file in advance and handle it then if its something that will happen often (ie normal code flow)

exceptions are reserved for unexpected error conditions

If it doesn't happen often then it won't hurt to have break on exception turned on and it will help you realize you have a problem if it starts happening suddenly even if your code is robust and recovers

ur wrong on this sorry

func A: opens a file with a given ID, streams the contents
func B: initializes configuration parameters (using A)

A doesn't know how the file is structured or what it contains, it's just streaming bytes/strings. B doesn't know where the file is, or even if it's a file (as opposed to a database record, a REST request, whatever); it just requests values. this is known as "separation of concerns".

now the file (or whatever) isn't there. A doesn't have the information necessary to recover from a missing file; it throws an error. B catches the error & sets up a default configuration of some kind.

alternately: I'm running a batch operation on a bunch of documents, fetching associated information on each of them across the network. as I go through the information, I find that some of it is corrupt & invalid! the parsing code throws an exception; the iteration code stores the information that there was an error to the database, and moves on. this happens maybe dozens of times across tens of thousands of documents, and it's a normal, expected part of operations.

# ¿ May 18, 2013 01:24

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

tbqh I don't really understand how you can reconcile

Cold on a Cob posted:

exceptions are reserved for unexpected error conditions

with the idea of "catching exceptions".

where exactly do you use exceptions? when do you catch them, if you're only supposed to use exceptions for situations you don't expect? I'm honestly really curious here.

# ¿ May 18, 2013 01:26

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Brain Candy posted:

its you, you are the coding horror. you check if the file exists in B. an exception is thrown if somebody somehow deletes the file from under you or fills it with spiders.

imagine we have an intermediary: A reads the file, B calls A to load a file & parses it, C calls B to get the values & sets the configuration. C doesn't know that a file even exists; it just calls B and says 'get me values'. B has no idea what it's being called for; it's just provided with some kind of resource identifier which it translates into a filename. what should B do when it checks and finds out the file isn't there? what values should it return?

(it should throw an exception)

JewKiller 3000 posted:

modern programming languages (not java, definitely not any p-lang) make it trivial to declare the return type of a function as an option type, i.e. "ok here's the value OR error", and furthermore the ok/error tag MUST be checked before the potential return value can be extracted

that's nice for people who get to use fun languages over in academia

for people who work in the real world, we have to deal with actual languages

good to know though!

# ¿ May 18, 2013 04:22

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

you use them for catching and handling exceptions that are a possibility but do your best to ensure they are never caught in the first place by guarding for them wherever possible

if it is a common scenario in your application that files may not be present or may not validate in some manner, you should be testing for that in the normal flow of your program and dealing with it within the normal flow of your program because it is expected. if that means more thorough testing in each function and passing poo poo back up the stack, so be it.

if it is an uncommon scenario in your application that files may not be present, then by all means use an exception, but treat it like the catastrophic event that it is. catch it and deal with it (eg stop program flow, log the error, have it send an expletive filled sms to your webserver cj's wife)

in c# a good example is using int.TryParse vs int.Parse - you use TryParse when you expect conversion to fail and you use Parse when you never expect it to fail and if it does you want an exception generated.

now, to be fair, i am arguing from authority (essentially, everyone knows non-local goto is bad and should be avoided ). i'm not going to get into all the reasons why non-locally scoped gotos are a bad idea, but if you want to argue that you like being able to shortcut your way up the stack in a non-obvious way when something you expect to happen 5% of the time happens and you don't mind incurring the performance hit for doing so, not to mention making your code less obvious in it's expected operation, have at it but i pity anyone that works on your code base 5 years from now.

hm. I guess the question is something like this:

you have a function. when called, it's unable to return a meaningful result. (a function that's supposed to read from a file doesn't find a file; a function that's supposed to parse formatted data is passed garbage.) what should the function do?

in my philosophy, the function should throw an exception, and that exception should pass upwards until it reaches a function that's capable of dealing with it. ("C" in my earlier example.) I don't think this is particularly controversial, tbqh.

your argument seems to be that exceptions should be used as more verbose quit() calls with nicer error-logging functionality, and only as that. in your scenario, our functions would return error codes instead of actual data in these cases, and every upstream caller would have to pass that on until they reached a function that could deal with the error. that's literally what exceptions were invented to get away from, because it turns control flow into a hideous nightmare, and you don't have any actual argument for returning to it (besides "authority"), so... I guess I'm not convinced!

thanks for articulating all this, though. I was wondering if there was a plausible alternative to the way I use exceptions other than 'error codes'. I guess not!

Cold on a Cob posted:

heyyyyy look at me i'm arguing on the internet about programming on friday night

owned

# ¿ May 18, 2013 04:30

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

you're avoiding my main point and a few of my side points.

main point:

if it's something that frequently or commonly happens that your program is expected to deal with and continue, you are dealing with control flow and should not rely on exceptions because they are an expensive non-obvious shortcut up the call stack. for example, if you're dealing with a resource in A that will frequently be unavailable and you need to notify C, it should be documented in the interface for A and B as a return/out value. yes this is more work.

if it's something that rarely happens, it's an exception and you should pass it up the stack, log it, probably halt the process or program depending on the exception type, etc.

side points:
- generating exceptions is an expensive operation. it's wasteful because you're rolling up the call stack and consuming excessive memory and processing power when a simple bool might be more than enough.
- you're hiding functionality. in your example, C knows that A might fail but since B doesn't know, if someone else consumes B they might not be prepared for the fact you're using a non-obvious method of controlling program flow, at least as far as the language is concerned (contrast this with an out parameter in a method signature). i guess checked exceptions might help with this, i'm not a java guy so i don't know much about them. and yeah, maybe python does it differently but like i said, they should at least call it something else then. semantics matter and words have meaning.
- you might accidentally swallow other exceptions (i didn't mention this before but it is a possibility, unless you start generating custom exceptions purely to handle control flow which is more work anyway so you probably wouldn't do that)

I don't really think I am avoiding your points, though. "expense" is language-dependent, and reeks of premature optimization in any case. "non-obvious" - there's nothing that's non-obvious about exceptions, especially if they're documented / in the interface. yes that is more work.

checked exceptions do solve exactly the ambiguity that you're complaining about, when everything needs to be nailed down. also I think this argument has driven me towards checked exceptions / shaggarism, which is a terrible feeling, but there you go.

there is no need to call python exceptions something else when they work in the exact same way as every other language's exceptions.

generating custom exceptions is super trivial & we do it all the time at my work.

Python code:

class ButtException(Exception):
   pass

throw ButtException("oh no butts")

--

honesty time: I think this argument has turned into "exceptions are fine to use for a lot of thing in Python!" "no they're terrible to use except for really rare cases in C#!" "no they're fine in Python!" "no they're terrible in C#!"

so maybe we should switch to mocking jewkiller 3k instead of continuing?

idk.

# ¿ May 18, 2013 06:28

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Cold on a Cob posted:

*high pitched voice* python coders code like thiiisssssss and *low pitched voice* c# coders code like thiiisssssss

# ¿ May 18, 2013 17:01

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

I leave out braces on for/ifs whenever I get the chance (when I'm using languages with braces)

I hate the sight of them

code:

			if (opIntValues && opIntValues.length)
				for each (var opIntValue:int in opIntValues)
					expectedOps.push(OpcodeValue.fromValue(new NumericValue(opIntValue)));
			else if (U.state)
				expectedOps = U.state.level.expectedOps.slice();

mmm

it's almost elegant

# ¿ May 19, 2013 05:43

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Ronald Raiden posted:

braces aside, please never have a nonsdescriptive variable name, particularly one that is just one letter. What the gently caress is U? Whatever it is, it could be called something meaningful.
We use modern technology that has at the very least local symbol autocomplete, presumable (if not, change the technology you use) and also minfiers/JIT compilers so there is no excuse to have a nondescriptive short variabe name, particularly in that context.

U is U(niverse/al); it's where the shameful globals live, all my poor design decisions come to roost in one place

I'm not aware of any way to have actual globals in this language, so I dumped them into a class as static members & referenced them by as short a name as possible

the good news is, it's a personal project which literally no one else will ever touch

(unless some maniac decides to mess around with it after I open-source it, in which case, good luck!)

so

# ¿ May 19, 2013 07:02

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

java question time. my understanding is that, taking advantage of the fact that java strings are immutable, identical strings are stored at the same location in memory. e.g.:

code:

String foo = "butts";
String bar = "butts"; //should be stored in the same place as foo!

googling tells me this is called "string interning", and that java's implementation is called the 'string pool'. anyway.

wouldn't that imply, then, that the == / != operators would work for comparing strings? I'd assumed that ==/!= were just comparing the values of the internal pointers (and wiki agrees with me here), so...?

# ¿ May 21, 2013 15:57

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Ronald Raiden posted:

I think its dumb that == compares identy (memory reference) by default.

In python, it uses either a default implementation (I think comparing the __dict__ of the objects) or calls the __eq__ method. If you want object identity, you use the word "is" istead of "==".

Ronald Raiden posted:

Java has that too only it does it backwards. The less common usecase, identity comparison, is the operator '==', while the more useful one is the object method object.equals. Also java generics suck.

Ronald Raiden posted:

It depends on the language. Most modern high level languages have sane object equality comparison, which would allow 2 different objects with thesame value tobe equal. Generally, in languages that allow that, the notion of identity comparison, which is what you are referring to, is different. (for instance, 'is' in python)

code:

while (ronald_raiden.hates(JAVA_EQUALITY))
    java.compare_to(python);

# ¿ May 21, 2013 18:03

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

also here's a fun bug I found in my code this morning

code:

		private function get MAX_SPEED():int {
			return 65 / currentZoomLevel;
		}
		private const ACCEL:int = MAX_SPEED / 2;

this compiled & sat in my codebase for the last few months

tbqh, I'm kind of really startled that it compiled at all.

# ¿ May 21, 2013 18:07

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

to clarify, I haven't actually worked with java in over a year, & don't intend to do so any time soon. I just ran into the notion of string interning a few months ago, and started wondering how it interacted with ==. I hadn't realized that only constant & manually specified strings were interned; now that I know that, everything has fallen into place.

it was a matter of idle curiosity and I am very satisfied with all answers, except tef because his answer assumed I knew more than I actually did (& was therefore useless w/o the other answers). actually - that's pretty flattering, so on second thought I'm happy with that answer too.

terrible programmer update: ran into a bug in my personal project, failed to fix it or even find the root cause of it over several attempts/hours. eventually gave up & slapped on a lovely patch that appears to have "fixed" the problem. putting the over/under on 2 weeks until it shows up again in some horrible metastasized form.

uugh.

# ¿ May 23, 2013 05:54

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Share Bear posted:

i just looked up what that is. holy poo poo

quote:

No single programming language exists that does all the things that typically require four. You need a server language (In FB5 this was ASP and PHP), a client language (probably JS), a content language (HTML), and a formatting language (CSS).

10 paragraphs of a lovely hacked-together cross-lingual PHP/ASP code generation system, and then this

wonderful

# ¿ May 28, 2013 21:10

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

NOTinuyasha posted:

what you actually are is a really really bad programmer, im a regular bad programmer and it only took me like five minutes to figure out lxml

quote:

I don't think I've ever seen you post something constructive or helpful. User loses posting privileges for 3 days. Louisgod angerbot

# ¿ May 29, 2013 07:52

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

tef posted:

https://github.com/mongodb/mongo-java-driver/blob/master/src/main/com/mongodb/ConnectionStatus.java#L213

aaaaaaaaa
aaaaaaaaaaaaaaaaa
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

# ¿ May 29, 2013 22:12

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

sent the horrible mongo thing to a friend & he discovered where it came from.

back in 2011, they noticed a problem that the mongo driver was flipped out whenever a server went down and spammed log exceptions left, right, & center. to fix it, they decided, "what if we just only log errors of that type... say... about one time in ten?"

the decision was made two years ago, and it remains in production code to this day.

god bless.

# ¿ May 29, 2013 23:18

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

we use mongo at my work but we're steadily transitioning off it, and the more I learn about mongo, the happier I am envisioning that future mongo-free day.

# ¿ May 29, 2013 23:19

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

dur posted:

i can think of jobs were i'd be happy but getting one of them is another thing entirely

being a not terrible programmer would probably help tho. how do i do that?

write lots of code

read other people's terrible code and figure out why your code is terrible

write more code

also maybe read a book? i don't know anything about that, though.

# ¿ May 30, 2013 22:36

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

OBAMA BIN LinkedIn posted:

ignoring the fact that 'toy language' isnt really even a defined thing, this statement is very wrong

good thing tef didn't actually say it!

tef posted:

a toy language: a language where the only substantial program written in it, is the compiler.

# ¿ Jun 16, 2013 02:33

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

OBAMA BIN LinkedIn posted:

can we not sperg too much about why c++ is or isnt a bad language as i think we all agree that c++ isn't well designed but nonetheless its still p.much the most important and practical language that currently exists

no that's C

# ¿ Jun 16, 2013 05:15

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

Zlodo posted:

games aren't buggy because c++, games are buggy because bad project management, lack of formalized development methods, over compressed development schedules or a combination thereof

and when you get lucky to work at a game studio with none of those problems it owns

but given that most bugs found in games happen at a high level (things like broken transitions between states, or errors caused by level layout changes and such) and not specific to the way things are some in c++ you'd have games just as buggy if they were written in a diff language like java or c# or whatever else really

you reminded me of a cool article so I'm posting it

:tipshat:

# ¿ Jun 17, 2013 19:16

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 20:21

PleasingFungus: Oct 10, 2012; idiot asshole bitch who should fuck off

polpotpi posted:

CUnit < CDoodad < CFlingy < CThingy

code:

class CUnit ... {
    #include "header_1.h"
    #include "header_2.h"
    #include "header_3.h"
    #include "header_4.h" //each of these headers is several hundred lines long
};

# ¿ Jun 17, 2013 19:23

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

«‹›3 »