Abstraction considered harmful

From SICP:

We control complexity by building abstractions that hide details when appropriate

Which means that with abstraction the whole system will grow and bloat without the programmer noticing it.

Discuss

we should code everything in assembly to avoid abstract bullshit

>>1
IHBT

Abstraction is the key to computer science.

Discuss

Abstraction is the key to late binding, which is the key to computer programming.

>>4
Which is the key to anii haxing amirite?

Abstraction was always a way to keep the less educated programmers from knowing what really happens, by hiding things in the complexity. Have we deliberately limited the full capabilities of programmers in this fashion? You bring up an interesting topic.

More importantly though, abstraction means you don't have to fiddle with the details when doing the higher-order stuff. Hiding also means, in a way, making something automatic.

Also ^{HAX MY ANUS}

>>7
If you put the spoiler tag inside the sup tag, it won't show through like that.

^{HAX MY ANUS}

^/prog/

^>>8
I didn't really mind but thanks. Good to know.

>>5
Anuses NOT anii.

learn2 latin

>>11
learn2 hax anii

abstract my anus

>>6
>Have we deliberately limited the full capabilities of programmers in this fashion?

I know you are trolling, but abstraction is not just a crutch for weak programmers. Notation in mathematics is another form of abstraction -- are you going to say that every mathematician who invented a suitable notation was not an EXPERT?

>>1
when appropriate

Computer software is built on many layers of abstraction.

These abstractions make the modern computer possible.

Abstraction in practice is too heavily tied to black boxes.  Building things up in layers is fine, but not letting programmers look at what inside the layer below is not.  Just because the code doesn't need to know the implementation details doesn't mean I don't.

>>17
gdb / ollydbg
Thread over.

>>2-19
WHBT.

MY ANUS WAS HACKED AND I ABSTRACTED MYSELF VIGOUROUSLY

Abstraction allows for much more useful optimization than trying to hand-squeeze every line of code.  If all code uses a matrix library, or IO library, and that library is made faster, a shitload of programs become faster.  Plus, the eyes of optimizing programmers can be focused in one place, combining ideas and efforts instead of everybody having a half-assed fairly quick attempt bolted in to their shit.

From SICP:

We conjure the spirits of the computer with our spells

Which means that as wizards we are immune to the failings of feebler minds.

>>22

We hax the anuses of the computer with our spells

Abstraction makes the implementation indepedent of the usage. So you can change your matrix class to store the information differently, and it won't matter to the program that uses it.

You might want to read SICP again.

Abstraction can in some cases make systems much more complex.  Layers of Abstractions insulate you from the whole system which can be bad in a lot of cases.  In learning especially I believe that abstract bullshite should be layered on after the underlying systems are understood.  SICP is a good example of fundamental programming being taught then more layers added on as the book progresses.  A lot of modern textbooks, especially OO ones, do not do a good job of this.   

>>27
Continued.

Hell A lot of modern OO textbooks are basically how to fit abstract pieces together without understanding what the fuck is going on.

>>28
You get abstractions all through the complexity stack. Even assembly language is an abstraction of machine code. But sometimes you need to break the abstraction because it doesn't do what it should do, or what you expect, or what you need.

abstract ur anus

Every programmer should take the time to know each layer of abstraction he is standing on, but to go back to assembly... lol

I like standing on the penises of past programmers and using the power of their abstraction to hax anii at an ever higher level.

>>27
Why the fuck are all you kiddie shits so afraid of complexity?  Caches are complex, but add a hell of a lot of speed.  So do JIT compilers, load balancers, prefetchers, threading on multicore, and all the other shit you're so fucking afraid of because of OMG Co^M_pexity.

Get the fuck off my /prog/.

>>33
also, yeah lol "COMPEXITY" whatever, fuck you too.

>>33
Why the fuck are all you kiddie shits so afraid of complexity?

My parents read me this post once when I was younger:

http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html

(not sure who's that guy. found it through links from a friend's blog, and since I knew too little about java or systems programming, I probably gave it too much importance. bleh, anyway it's a good post)

>>35
Holy shit, what a load of horse shit.  The problem with that idiot is that he looks at all the fine-grained details and NEVER gets a big picture.  He doesn't understand architecture nor organization at all.  The only thing he knows is function-level algorithms and trying to peephole optimize.  Managing complexity is NOT a difficult task if you've got your shit together.

Many systems NEED to provide a ton of functionality, monitor and report on itself, be runtime flexible and interchangeable without restarting, and all sorts of stuff that requires the addition of complex systems.  Fuck, even on a hardware level, mainframe chips easily dedicate 30% of their silicon to monitoring and error conditions.  But complexity can be easily managed if you simply develop your code from a big picture instead of trying to collide a mish-mash of shitty "optimized" low-level leaves-before-the-forest algorithms together and pretend it's a working system.

>>36
Are you trying to troll >>1?

>>36
BTW, everything I've said applies as much to MMO servers as it does to banking systems and the like.  It's not just ENTERPRISE FAGGOTRY that needs to manage complexity, bedroom hackers need to learn it as well as his shitty handling of his game shows.

>>37
Are you trying to troll >>36 ?

>>35
Why did I bother reading that?  It doesn't matter at all how many lines of code a program is.  Say a 3000-line piece of Java code is equivalent to a 150-line Lisp package.  If they have the same features and the same granularity of use and processing, it's the _exact same_ amount of organization and maintenance.

You don't maintain lines of code, you maintain code modules, APIs, data stores, features, etc.  It simply doesn't matter how many lines each of those parts are, each "part" is one item in terms of complexity.