Is coding hard for you?

Just don't give up

http://www.youtube.com/watch?v=oRx3cQ91sJQ

>>1

if (language != c++)
    return true;

Don't give up, learn D.

die unless ($lang eq 'perl');

>>4
use Perl or die;

"use javascript"

import python

#include <c>

#ifndef C
    exit(-1);
#endif

$ sh || killall init

(unless (lispp x) (setf x 'shit))

Have you listened to your _Roland Edi^rol Romantic Tp. today?

http://www.youtube.com/watch?v=JsMAwPzacjc
http://www.youtube.com/watch?v=zE9YWucTiq4
http://www.youtube.com/watch?v=ClGJ1UhX90A
http://www.youtube.com/watch?v=1i4J9yiGCJs
http://www.youtube.com/watch?v=EpJlExc87mY

http://www.youtube.com/watch?v=B-m6JDYRFvk

>>12
That song doesn't have _Roland Edi^rol Romantic Tp., therefore it's shit.

no but my penis is

>>10

(unless (lisp? it)
  (declare (optimize (safety 0))
           (shit it))
  #|your C/C++ code goes here|#)

(if (eq patch rol:romantic-tp)
  'not-shit
  'shit)

lisp is shit.
if it ain't lisp, it's crap.

Coding is not hard. Coding is extremely easy. However, being someone else's code monkey is hard.
I pity those fools who actually do programming as a job or part of their job. Slaves with white collars.

>>18
creative control really isn't that important. And if you want it, all you have to do is develop some of your own solutions for the problems at hand, and then prove to the superiors that they'll improve things. If they are interested in the success of the product, and if you happen to be correct, and if you are able to communicate the ideas, then that is what will be done. But if they are more interested in preserving the current implementation or design, or if they have to answer to someone who is more interested in the implementation or design, then nothing will change. But, you can practice the art of working around an unfixable design, to get the functionality or performance you need. This in itself can be interesting. Whether or not it is the most efficient way to develop a product isn't really a concern. You are simply presented with another limitation to engineer around.

>>19
No, I meant the hard part is making the code understandable for someone else. My code would be indecipherable even with comments, and I don't want to write a fucking thesis for everything I do.
You may, however, be right in the sense that coding for society could let me improve my (inadequate) social skills, and make me think more objectively.
Still, the idea of arguing with people disgusts me. Why? Because I would run into conversations like this:

Them: Why did you set the variable to 2.7329 instead of 2.0 or some other exact variable?
Me: So that when the program has iterated millions of times through this recursive loop and I get an exact result, it's less likely to be due to the inherent nature of the number 2 or some other accidentally implemented concept, but due to the emergent properties of the loop.
Them: Inherent nature of number 2? What the shit?
Me: Or something like that.
Them: You don't have a clue what you are doing, do you? You're fucking fired, you retarded faggot. Go spout your technobabble somewhere else.

>>19
if you are able to communicate the ideas,
Yes, this is the problem. I hate being an attack target that has to defend itself against constant bombing. I invent a theorem, and the burden of proof is of course on me. That's understandable. But I have to somehow translate the proof into something this person likes to hear. I don't want my coding to be about psychology. I want it to be about coding. Yes, I'm a functionalist.

>>20
I see what you did there. Unfortunately not everyone does. If you ever have to justify things like that to people not familiar with such things, you can always make a few test cases and measure differences in performance between the two methods. People will respond to measurable results, even if they don't want to try to understand the techniques used in the underlying design. In the position of an educator, your goal is to confront voids of understanding with clear involving explanations, and to leave the other person with their own accurate interpretation of what it is, and methods for thinking about the subject. But in the position of a coworker, people feel threatened by concepts they don't understand, as exposure of their temporary lack of understanding may threaten their job security. So they are more likely to react defensively to your explanations than as someone willing to learn something new. But this isn't always the case.

>>21
It can be difficult when the theorem is complicated and involved, but examples and analogies of the final statement can be useful to aid their intuition. For a lot of people, it doesn't matter if they can rigorously prove it, just that it sounds reasonable. But if the context is sufficiently abstract, then it can be hard to think of an example that they can even relate to, let alone find reasonable. But then you can always bring the generality down to a few specific and trivial examples.