I\'ve been programming for a little under a year and have some experience writin

Question

I've been programming for a little under a year and have some experience writing systems applications, web apps, and scripts for businesses/organizations. However, one thing I've never really done is working with a framework like Django, Rails or Zend.

Looking over the Django framework, I'm a little frustrated with how much is abstracted away in frameworks. I understand the core goals of DRY and minimal code, but some of this over-reliance on different modules and heavy abstraction of core functions feels like it:

Makes programs get dated really fast because of the ever-changing nature of modules/frameworks,

Makes code hard to understand because of the plethora of frameworks and modules available and all of their idiosyncrasies,

Makes code less logical unless you've read all of the documentation; i.e., I can read through some list comprehensions and conditional logic and figure out what a program is doing, but when you see functions that require passing in arbitrary strings and dictionaries, things get a little hard to understand unless you're already a guru in a given module; and:

Makes it difficult and tedious to switch between frameworks. Switching between languages is already a challenge, but it's manageable if you have a strong enough understanding of their core functionality/philosophy. Switching between frameworks seems to be more a matter of rote memorization, which in some ways seems to encourage the very inefficiency these frameworks were designed to eliminate.

Do we really need to put like 50 layers of abstraction on top of something as simple as a MySQL query? Why not use something like PHP's PDO interface, where prepared statements/input testing is handled but the universally understandable SQL query is still a part of the function?

Are those abstractions really useful? Isn't feature bloat making them useless, making applications more difficult compared to similar applications written without using a framework?

Explanation / Answer

Frameworks can be tricky indeed. Problems can easily arise when a framework is too "opinionated", i.e. when it really prefers one particular style of application and all parts are geared towards supporting this particular style.

For instance, if the framework completely abstracts the authentication process of a user by allowing you to just add one component, add a login template somewhere and voila, you get user authentication for free. This saved you a lot of repetitive work in worrying about cookies, session storage, password hashing and whatnot.

The problems begin when you realize that the default behavior of the framework's authentication code is not what you need. Maybe it's not following the latest best security practices. Maybe you need a custom hook in the process to trigger some action, but the framework doesn't offer one. Maybe you need to change the details of the cookie that is being set, but the framework offers no way to customize this.

The abstraction afforded by the framework allowed you to add an important feature to your site within minutes instead of days initially, but in the end you may have to fight against the framework to make it do what you need it to do, or you'll have to reinvent the functionality from scratch again anyway to suit your needs.

This is not to say framework abstractions are bad, mind you. It is to say that this is always a possibility you need to keep in mind. Some frameworks are explicitly geared towards this, they offer a way to get something up very quickly as a prototype or even production framework for a very specific, limited type of app. Other frameworks are more like loose collections of components which you can use, but which still allow you a lot of flexibility to change it around later.

When using an abstraction, you should always understand at least roughly what it's abstracting away. If you don't understand cookies and authentication systems, starting from an abstraction is not a good idea. If you do understand what you're trying to do and just need code which already does it instead of having to tediously write your own, abstractions are a great time saver. Poorly written abstractions can get you into trouble later though, so it's a double edged sword.

You should also distinguish between technical abstractions and "business rule" abstractions. Programming in a higher level language is an abstraction you probably don't want to miss (Python, PHP, C# vs. C vs. Assembler; Less vs. CSS), while "business rule abstractions" can be difficult if they don't meet your needs exactly (one-click authentication vs. hand-coding cookies).

That's because technical abstractions rarely "leak", i.e. you will hardly have to debug machine code when writing applications in Python. Business rule abstractions work on the same technical level though and are just "code bundles" really. You probably will need to debug the cookie that is set or the password hash that is created at some point, which means you'll be diving through lots of 3rd party code.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.