Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Is too much abstraction a bad thing?

by silent11 (Vicar)
on Jul 26, 2005 at 18:33 UTC ( #478320=perlmeditation: print w/replies, xml ) Need Help??

My first formal introduction to programming ( and Perl ) was a book titled Perl and CGI for the World Wide Web.

I was so excited to have the ability to add some dynamic features to my then static website. All I was really doing was processing form information and sending emails. The really cool thing was that all I had to do was put some funny code at the top of my script and I got this $form{'xyz'} thingie that held all of my form's contents.

#!/usr/bin/perl require &parseForm; $name = $form{'name'}; ...
This parseForm thing was a good thing -- I didn't care what was inside the black box, I just knew that it worked.

Once I learned about the CPAN it was like I didn't even need to learn any more Perl to get my tasks done. I read RTFM for module X, copied the example out of the POD, changed a few variables and I was in business! I got the job done.

4 years later...

Lately I've been interested in taking my web apps to the next level past DBI and HTML::Template. I've been doing alot of reading and playing around with Class::DBI, Template Toolkit and these MCV web development frameworks (Catalyst & CGI::Application) that do alot of that old boring repetitive work for me.

I'm noticing that I'm still not really required to know much Perl to write these semi-robust apps. As long as I understand what method to call on what object then I'm ok.

I look back and realize that not much has changed for me over the last 4 years. I'm still writing web apps, there's just ALOT more abstraction between me and the actual Perl code that's doing the work.

As I look back I feel a bit cheated -- I use these OO modules every day and I don't really know what's under the hood. When I hit a road block I just post a question here, or to a news group and within minutes I have my answer.

Where will it end?

What will the future of Perl be once we have a framework written for most common applications?

Will the below code be the future of Perl?

#!/usr/bin/perl use strict; use My::Wiki; my $wiki = My::Wiki->new( config => 'file.txt' ); $wiki->run();

I know code reuse is a good thing, but don't let it hamper your programming skills. You just might wake up one day and realize that you're a Saint in The Monastery that can whip up a cool web app in an afternoon, but still needs to RTFM when dereferencing a complex hash ref.

-Just Another Module User

Replies are listed 'Best First'.
Re: Is too much abstraction a bad thing?
by chromatic (Archbishop) on Jul 26, 2005 at 18:45 UTC

    I've written and tested more than my fair share of constructors, accessors, and destructors, more than enough database connection, execution, and retrieval code, and plenty of parameter serializing and deserializing code. I won't miss any of those.

    My goal is not to write all of my code from scratch by hand. My goal is to do something. Anything that distracts me from that, including programming, is a problem.

Re: Is too much abstraction a bad thing?
by jeffa (Bishop) on Jul 26, 2005 at 18:45 UTC

    Have you seen CGI::Application yet? [update: yes, yes you have]

    use WebApp; my $webapp = WebApp->new(); $webapp->run();
    But ... there really is more to it than just that. You actually have to implement the WebApp class.

    I'm not going to write an essay on this, but do consider what you are doing 9 times out of 10 when you write a piece of software -- you are writing it for a client. And that client will ensure that no matter how much abstraction your tool provides, you will need to open the hood and change things around to fullfill the client's ever shifting requirements.

    "What will the future of Perl be once we have a framework written for most common applications?"
    A starting point. The client will always want something different, something more flexible, something that was not originally specified.

    Everything in moderation -- too much of anything surely is not a Good Thing ™.


    (the triplet paradiddle with high-hat)
      Is too much abstraction a bad thing?

      Yes. Abstraction, by definition, limits the amount of data that is available about a given topic at one time. It's bad to be flooded with too much data, so abstraction is clearly "good".

      Specification, by definition, gives specific details about a specific scenario. It's often important to get all specifics down to know what's going on, so specification is clearly "good".

      The two terms are opposites.

      Deciding how much information you want to specify, and how much should be left abstracted is a central problem for communications. Computer programming is all about communications: both a computer (via a programming language), and to fellow programmers ( via your choice of individual programming elements and constructs, as well as explict comments and documentation).

      If you have to ask: "Can there be too much of <X>", the answer is usually "yes".

      Everything in moderation -- too much of anything surely is not a Good Thing™.

      Too much abstraction is called Java™. ducks...

      Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
      The Code that can be seen is not the true Code
      "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: Is too much abstraction a bad thing?
by spiritway (Vicar) on Jul 26, 2005 at 20:00 UTC

    You have a good point, but consider something else: as software becomes more robust and more sophisticated, there is less reason to get under the hood, unless you happen to like to tinker.

    I like to compare this progress to, for example, using a TV set. Back in the day, you had to fiddle with the antenna, position the set just right, play around with the various controls, and your result was a fuzzy, black-and-white image that might be recognizable on a good day. Now you just turn the thing on and pick one of a gazillion channels, and it (usually) works. Sure, you can get in there and play around, but there's no compelling reason to do that unless you just like to know how things work.

    I believe it's a good thing to "reinvent the wheel" a bit and learn how some things are done. Just working on something (say, bubblesort) gives you an idea of what issues are involved. Chances are very good that you won't write anything as efficient as what is now available, but that's not the point. It's learning something about how it's done.

    So no, you probably aren't going to be able to rewrite all the modules you use. You may not even know what's in most of them - and that's OK, if you don't have a good reason to know. One of the wonderful things about Perl is, if you're curious, you can always check out the code and see what's going on. Another of the wonderful things is, you don't *have* to do that if you don't care, of if you're just too busy to do it.

    Another point is that there are simply too many topics for anyone to learn thoroughly. You developed your coding skills doing certain things that are now second-nature to you. They appear simple to you, but would likely give someone else a hard time. Until recently, you apparently had no need to worry about deferencing a complicated hash - so you didn't.

    Finally, it's not too late to learn. A third wonderful thing about Perl is the abundance of documentation that comes with it...FMTYEWTK.

Re: Is too much abstraction a bad thing?
by itub (Priest) on Jul 26, 2005 at 19:25 UTC
    Joel Spolsky once wrote on this topic:
    When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
Re: Is too much abstraction a bad thing?
by Ovid (Cardinal) on Jul 27, 2005 at 02:24 UTC

    Abstraction can be both good and bad. Whether there is too much abstraction for what you're trying to do depends upon what you need to get done. If you're writing a new database driver, you don't want to be testing it by writing Class::DBI code (too much abstraction.) If you're writing code to describe a business process, you probably shouldn't be worrying about the content length of your HTTP response (too little abstraction.)

    If your code is properly organized, you'll discover that you have different levels of abstraction in different sections of your code. That's fine. Don't sweat the "too much abstraction" problem too much. After a while, you'll get a feel for it.


    New address of my CGI Course.

Re: Is too much abstraction a bad thing?
by tilly (Archbishop) on Jul 27, 2005 at 03:12 UTC
    "Any problem can be solved by adding another abstraction layer, except that of having too many abstraction layers."

    Yes, it is possible to have too many abstraction layers. But as long as abstraction layers improve your productivity more than they cost, they pay for themselves.

    That said, when there is an obscure problem, someone has to be able to figure out enough to track it down. Just today I spent an hour tracking down a problem caused by a Mason upgrade. The solution was to change a call to Apache::Request->new to Apache::Request->instance instead. It was a one word bug fix, but how much energy was required to figure out that word! (The bug was that after moving to a current version of Mason, we were no longer able to set TEMP_DIR. If we moved to Apache2, the bug might or might not reappear. If it does, then fixing it will require a patch to Mason.)

Re: Is too much abstraction a bad thing?
by greenFox (Vicar) on Jul 27, 2005 at 06:18 UTC

    "Will the below code be the future of Perl?"

    Ahhh I see you have been looking at Kwiki, very good :-)

    #!/usr/bin/perl -w use CGI::Kwiki; CGI::Kwiki::run_cgi();

    I think you need to work harder at building your skills rather than worrying about them atrophying, even with a great application like Kwiki there are always extensions and Enhancements which can be written such as my own BlogarchivePlugin.

    Murray Barton
    Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

Re: Is too much abstraction a bad thing?
by Adam (Vicar) on Jul 27, 2005 at 15:52 UTC
    Abstraction is the essence.

    In the begining there was the electron, and it was good.
    Then came the electronic adder, and it was better.
    Then came the machine - the computer controlled by machine code, and it was complicated.
    But the engineers invented programming languages to abstract away details like memory registers and complex math, and it was Perl.

    Abstractions make it easier to handle the complex. This is true in all things, not just programming. Consider the modern car. We get in and drive. We don't need to know how combustion or how a universal gear works, only that when we put our foot on the gas, the car goes. We've abstracted away the details of the car and made it easier for people to use. The same is true for code.

Re: Is too much abstraction a bad thing?
by nothingmuch (Priest) on Jul 28, 2005 at 09:21 UTC
    In my opinion there is no such thing as too many layers of abstraction...

    <update>Note - i do think there such a thing as too many bad layers of abstraction</ypdate>

    Abstraction is just scoping - you should know what each layer is about, even if you've only scratched the surface, but think of how many successful levels of abstraction you've been ignoring:

    • TCP/IP stacks
    • kernel task switching
    • MMU mapping of addressing space
    • interrupts and faults
    • compilation to byte code
    • compilation of c code to machine code, to compile and run that byte code (the perl interpreter)
    • dynamic linking of a bajillion modules like your database driver
    • the sql parser, query planner, executer and so forth in your database server (which is a complicated application too)
    • the fact that even your database doesn't really know in what exact disk block your data is - you've got a file system

    anyway, i coluld go on for a long while more, but as you can see you've got hundreds of layers of abstraction, but if we don't look at it that way, since they aren't really layers but more like a tree, we have 2 main layers that we care about:

    • The operating system that gives us something perl can run on
    • The perl lanugage as provided by perl
    That doesn't sound like so much anymore, right?

    My point is really this: know what's going on. Go read the Catalyst and Class::DBI source code. They are slightly tricky reads, since it's hard to see exactly what they are doing unless you've got the big picture, but the code is well written, clear, concise and useful. (Just think what would happen if they were written in assembler, eh?)

    Once you know what's going on under the hood, you can forget the details. In fact, you don't even have to learn the details. If you practice this often enough you can read any module in 2-3 minutes, just to see what's going on structure wise, and guess most of the rest. When there's something you're not 80% sure of (80% is good enough) go check.

    This way you can use your tools with confidence, work less, and still have control.

    The only problem I have with abstraction that comes in one huge chunk all at once is the question "where to start". From a business perspective this means: is it going to be cheaper to learn this, or to rewrite what I need?

    As you can see some modules (e.g. catalist) are more successful than others (e.g. openframe or whatever it's called) for doing pretty much the same thing. I guess it's really a matter of how much abstraction that introduces all at once, and how it's presented, because I tried reading the latter's docs and didn't really see what was happenning or what they want from me, but with Catalyst it was a breeze.

    The reason abstraction is good (if it's good abstraction, that is ;-) is that you can capture repetitiveness in a well contained model. Functional programming is powerful but hard because the style it promotes is "abstract anything and whatever's next to that" - functions applying functions to the applications of another function, on data structures which might really be functions themselves ;-)... Object oriented programming gives us a style where we abstract slightly bigger things, and concentrate on how data looks alike, not how algorithms look alike. In this day of all these MVC frameworks I think that the functional approach is starting to apply on the application scale, to object oriented design.

    Anyway, i have to leave now, but I think i'm sort of done... =)

    zz zZ Z Z #!perl
Re: Is too much abstraction a bad thing?
by astroboy (Chaplain) on Jul 28, 2005 at 19:39 UTC
    I used to write in binary, but since learning Perl, I don't have much use for ones and zeroes any more...

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://478320]
Approved by Tanktalus
Front-paged by Tanktalus
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (4)
As of 2023-12-10 20:05 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (41 votes). Check out past polls.