The /prog/matic programmer

ANyways, so... I was reading The Pragmatic Programmer [1] and it occurred to me that we should probably boil these principles down for the novices amongst us. ITT things you want to carve into your colleagues' faces.

* KEEP IT FUCKING SIMPLE, MOTHERFUCKER!
* You're code is not ``clever'', it is autistic.
* Code is /not/ poetry or art. Go away! Fuck your OCD.
* This shit has been solved a thousand times over.
* You do not need to design with the latest and greatest in gang-of-four approved OOP design patterns, using infinitely scalable NoSQL solutions in hip new languages that compile down to JavaScript (srsly WTF?!), just to create a CRUD application.
* Not everyone gets off on code, some of us just want to make a living doing the least amount of effort that is required to deliver a consistent quality for an extended period of time.

I swear by god if I see one more AbstractControllerFactoryInterface

[1] http://pragprog.com/the-pragmatic-programmer, easily found online.

No

You're code is not ``clever''
Nor is your ironic misuse of the English language.

You do not need to design with the latest and greatest in gang-of-four approved OOP design patterns, using infinitely scalable NoSQL solutions in hip new languages that compile down to JavaScript (srsly WTF?!), just to create a CRUD application.
I don't even know what that means!

>>null
nice dubs bro

This issue largely comes from traditional CS curriculum (SICP included). They start off by saying that complexity and abstraction are good things (only in moderation), "premature optimisation is evil" (it's never premature), and use those as arguments to convince the students that all software needs to be multi-layered elephantine systems broken up into hundreds of classes, packages, design patterns, and other cruft.

Quoting from the first SICP lecture:
"And these techniques for controlling complexity are what
this course is really about. And in some sense that's really
what computer science is about. Now that may seem like a
very strange thing to say, because after all a lot of people
besides computer scientists deal with controlling complexity. A large airliner is an extremely complex system. And the aeronautical engineers who design that air, you know, are dealing with the men's complexity. But there's a difference between that kind of complexity and what we deal with in computer science. And that is that computer science in some sense isn't real. You see, when an engineer is designing a physical system that's made out of real parts, the engineers who worry about that have to address problems of tolerance and approximation and noise in the system. So, for example, as an electrical engineer I can go off and easily build a one-stage amplifier or a two-stage amplifier, and I can imagine cascading a lot of them to build a million-stage amplifier, but it's ridiculous to build such a thing, because by the --- long before the millionth stage the thermal noise in those components way at the beginning is gonna get amplified and make the whole thing meaningless. Computer science deals with idealized components. We know as much as we want about these little programming data pieces that we're fitting things together. So there's... We don't have to worry about tolerance and that means that in building a large program there's not all that much difference between what I can build and what I can imagine. Because the parts of these abstract entities that I know as much as I want. I know about them as precisely as I'd like. So as opposed to other kinds of engineering where the constraints on what you can build are the constraints of physical systems, the constraints of physics and noise and approximation, the constraints imposed... in building large software systems are the limitations of our own minds."

Rubbish. CS is as real as any other science. Computers are physical entities in this universe like any other, and need to obey the laws of physics too. Thinking that abstraction and complexity has no cost is stupid.

(I enjoy some SICP myself but that's just mental masturbation.)

>>6
Computers are physical entities in this universe like any other, and need to obey the laws of physics too. Thinking that abstraction and complexity has no cost is stupid.
B-B-But, think of the purity !

>>6
All the codes go in main()!

Nice try, Cudder-sama. It won't be that easy to make me stop liking you.

>>6
A computer is a layer of abstraction itself. Circuitry down the hood is enough to cast magic spells and create Touhou games.

I'd just like to bump all the actual /prog/ threads.

ABSTRACT MY ANUS

I'd just like to bump all the actual /anus/ threads.

>>12
Same here, man.

I love Cudder-様.

LLLLLLLLEEEEEEEEEEEELLLLLLLLLLLLLLLLLLLLLLLLLLL
>POUNDING A PILLOW WITH A FLESHLIGHT
>OMG MFW LLEELLLLL EGGIINNNNN!!!!!

>>6

Indeed. Programming only feels limited by the mind when your mind stays within the boundary of what's feasible.

>>16
When I program, I feel limited by hardware and preexisting software quite often.

For instance, when I program in C, I want for a more natural dynamic array type.

Not to mention primitive types greater than 2^64, easy-to-implement concurrent execution of loops, a sane way to provide syntactically-sweet language extensions (C++ classes/operator overloading are NOT sane), the list goes on...

>>17
LISP

>>9
The cost of the sequential machine abstraction is far less significant than the flexibility it provides... at least for most tasks. But for everything else... have you heard of FPGAs?

>>17
When I program, I feel limited by hardware and preexisting software quite often.
That's why CS is engineering just like any other type of engineering; you have to work within the constraints of the system you're building.
For instance, when I program in C, I want for a more natural dynamic array type.
If you're irritated by that then move to C++ and use std::vector, although then you have not much control over resizing/allocation.

Not to mention primitive types greater than 2^64, easy-to-implement concurrent execution of loops, a sane way to provide syntactically-sweet language extensions (C++ classes/operator overloading are NOT sane), the list goes on...
All those things have additional costs, and making them easier to use encourages overuse where they're absolutely NOT needed. "Let's make all integers arbitrary-precision, then we'll never have to worry about overflow!" >>18 is an example of that. Now your code is a few orders of magnitude larger than it really needs to be, and correspondingly slower. Dynamic arrays are a perfect example of this, and IMHO not having them by default in C makes you think more about whether you actually need them in the first place, possibly making you reconsider and come up with a simpler algorithm (static allocation, in-place streaming) that does not require them.

One of my favourite interview questions is something like this:
"Write a program, in your language of choice, that adds line numbers to a file by prefixing each line with a decimal integer followed by one space. You may assume files have no more than 2^32-1 lines." No hints (you should try this youself) but I can tell you that if you thought of needing an array of some sort, you're not getting the job.

>>19
Are you kidding me? That's question requires almost no effort at all.
perl -pe 's/^/$. /'

>>20
hahhaha cudderfag doesnt know what a regexp is

although GC is still shit

>>21
Wrong, but it's completely overkill for this.

>>20
Sorry, you failed. That code uses an array.

>>22
Ok so an iterative method is what you want, correct?
I don't see why anyone would use an array for this, unless they're a very inexperienced programmer.

I don't get it. There's got to be a buffer SOMEWHERE to do this, even if it holds only one element/char (a la code]char tmp;[/code]), so how would it be possible without? Or is this what you meant?

Also,
^BB_code failure

>>20 already numbered his files while you fuck around creating an optimized solution.

hahahahaha I just saw this and laughed my ass off at OP, then I checked the date and realized I was the one that posted it all those years ago

>>22
Where does that use an array? Unless you're counting the implied $_ as a character array, though perl considers it a scalar.

>>19

Allow me to rephrase >>18.
TURING COMPLETE MACRO SYSTEM TO PROVIDE ANY ABSTRACTION YOU WISH TO HAVE ON TOP OF YOUR MEMORY INSECURE STATICALLY TYPED STACK BOY SCOPED NOOB LANGUAGE

Using a static array is an optimization over using a dynamic array. It can be performed if the compiler is aware of an upper bound to the length of the array. This should be built in to the language: an array with an upper bound provided by the programmer. The upper bound can then be statically verified (to the fullest extent possible), tested dynamically with assertions, and taken for granted in the release.

In place streaming is one way to evaluate a lazy map/reduce. So you're favorite lazy functional language can do this too, although you typically wont have control over the buffer size.

did..did I get the job Cudder-sama?


(define (number in)
 (letrec ((start-line (lambda (in line-number)
           (append (string->list (number->string line-number)) (list #\space) (loop in line-number))))
          (loop (lambda (in line-number)
           (cond ((null? in) '())
                 ((eq? (car in) #\newline) (cons (car in) (start-line (cdr in) (+ line-number 1))))
                 (else (cons (car in) (loop (cdr in) line-number)))))))
  (start-line in 1)))

>>30
No.

The most important thing to know about strings in Common Lisp is probably that they are arrays[sub][1][/sup]

_{1. http://cl-cookbook.sourceforge.net/strings.html}

>>30
yo! pimped ur sexps

ㅑdefine ㅑnumber inㅕ
 ㅑletrec ㅑㅑstart-line ㅑlambda ㅑin line-numberㅕ
           ㅑappend ㅑstring->list ㅑnumber->string line-numberㅕㅕ ㅑlist #\spaceㅕ ㅑloop in line-numberㅕㅕㅕㅕ
          ㅑloop ㅑlambda ㅑin line-numberㅕ
           ㅑcond ㅑㅑnull? inㅕ 'ㅑㅕㅕ
                 ㅑㅑeq? ㅑcar inㅕ #\newlineㅕ ㅑcons ㅑcar inㅕ ㅑstart-line ㅑcdr inㅕ ㅑ+ line-number 1ㅕㅕㅕㅕ
                 ㅑelse ㅑcons ㅑcar inㅕ ㅑloop ㅑcdr inㅕ line-numberㅕㅕㅕㅕㅕㅕㅕ
  ㅑstart-line in 1ㅕㅕㅕ

>>32
Shalom! JEWED your goyish sexps
✡define ✡number in✡
 ✡letrec ✡✡start-line ✡lambda ✡in line-number✡
           ✡append ✡string->list ✡number->string line-number✡✡ ✡list #\space✡ ✡loop in line-number✡✡✡✡
          ✡loop ✡lambda ✡in line-number✡
           ✡cond ✡✡null? in✡ '✡✡✡
                 ✡✡eq? ✡car in✡ #\newline✡ ✡cons ✡car in✡ ✡start-line ✡cdr in✡ ✡+ line-number 1✡✡✡✡
                 ✡else ✡cons ✡car in✡ ✡loop ✡cdr in✡ line-number✡✡✡✡✡✡✡
  ✡start-line in 1✡✡✡

>>19
Please employ me to fuck you until one of us die. I want you so much, Cudder氏. Please.

#include <stdio.h>

void print(unsigned int x)
{
    if (x > 9) {
        print(x/10);
    }
    putchar('0' + (x%10));
}

int main()
{
    unsigned int i = 0;
    char c;
    while (EOF != (c = getchar())) {
        print(i++);
        putchar(' ');
        do {
            putchar(c);
            if (c == '\n') break;
        } while (EOF != (c = getchar()));
    }
    return 0;
}

>>34
Relying on the integer encodings being sequential 0-based?  Fool!  Don't you know Cudder's company targets machines based on Baudot-Murray?

>>35
Fuck you, I am a free man and character encoding is the least of my problems.
_{Sorry for the delay, I was masturbating to Cudder氏. ;__;}

>>34
putchargetchar
I/O buffers detected.  You're fired.

>>37
so, read/write instead ?
I'm interested in your solutions, also.

char c;
while (EOF != (c = getchar())) {
Your fired

>>39
THIS IS NOT LISPPPPPPPPPPPPPPP