When is it too early to bring up "advanced" topics

PHP
1

In [thread=710377]this thread about creating $_POST arrays[/thread] the question of when is it too early to bring up concerns such as separating business logic from presentation came up. I think it’s a valid concern for discussion here as this forum is a great place to learn about PHP and I’d like it to stay that way.

Often I don’t comment about such concerns when it’s clear that the OP is just coming to terms with the language. Some topics valuable to large scale dev are just, well, too much too soon in my opinion. That isn’t to say these concerns don’t need to be mentioned, but sometimes it’s best to gloss over them if they get brought up at all.

One reason I worry about it is that it can lead to the wrong impressions, and misapplying principles can be more harmful than not applying them. Take smarty for example.

Smarty templating is about the dumbest thing you can do to a PHP application. It introduces the concept of separating presentation from business logic but goes overboard by trying to separate PHP from HTML, a fool’s errand at best and a destructive influence on the lives of many programmers especially since it entirely misses the point – separate business logic from presentation.

Thing is, Display still has logic to it.


<? foreach( $table as $row ): ?>
  <tr>
    <td><?= $row['cell1'] ?></td>
    <td><?= $row['cell2'] ?></td>
  </tr>
<? endforeach ?>

This is quite valid, even necessary, but this basic example becomes an impenetrable mess in another syntax if smarty is used because smarty is, well, stupid.

When starting out though do we really need to worry about this sort of thing? Or perhaps, did we? I know I didn’t. It’s been a long 7 years getting to where I am now with this stuff, and while I’d like to save others from the painful stumblings I’ve had on the way, in the end those are necessary to truly grasp.

Yes, I once used smarty too :\

But anyway, I think it can be harmful to try to drive home this idea of “separate business logic from presentation” too early, especially before the student has a grasp of what constitutes “business” logic and “presentation” logic. Without that distinction the student conflates the two to “logic” from “presentation” then disasters like smarty happen.

And that’s not the only pitfall.

Don’t spare the novice the education of doing things wrong. Sometimes learning the details is useful. For example, I find my lessons in C++ data structures useful though I don’t code in C very often. While I use PDO now, the days of using my own Database interface on top of mysql (and later mysqli) was invaluable to me to understanding the language.

Just random thoughts this morning.

2

I disagree on your views on template engines. Decoupling the display logic from the HTML is worthwhile: it allows re-use of the display logic on alternative HTML or use of the HTML with substituted display logic, but this topic isn’t to do with the pros/cons of template systems… I’m not even sure why you brought smarty up.

Back on topic, should we tell novice programmers they’re doing things in an inefficient and/or messy way?

I think if it’s a simple case of “This solution is better, and here’s why” then it can’t hurt. However, responses which require complex changes to the architecture of someones code is a bit too much. Suggesting dependency injection or MVC to someone just starting out is ridiculous. I suppose it’s a case of time/benefit. Will the person actually notice the (often subtle) difference and will it be easy for them to implement into their existing code? More importantly, is it something which can be explained on its own without bringing in more advanced topics? If not it’s almost certainly going to be too much too soon.

Edit: Thought it might be worth having a list of things which may get introduced. Here’s a few off the top of my head:

-Separation of concerns
-Avoidance of globals (including static)
-OOP
-Dependency injection

3

You can write a template engine in PHP that accomplishes proper separation of concerns. I brought smarty up because it’s gross, gross overkill and does not accomplish the problem it sets out to solve. Nine times out of ten when I see source code using smarty I see smarty’s php tags enabled with all sorts of business concerns within them, which leads me to think what was the bloody point of using smarty to begin with??

Decoupling the display logic from the HTML is worthwhile: it allows re-use of the display logic on alternative HTML or use of the HTML with substituted display logic, but this topic isn’t to do with the pros/cons of template systems…

This is correct. Our views aren’t that different.

I’m not even sure why you brought smarty up.

Because it is a poster child example of doing things the wrong way and the sort of pitfalls that await programmers with incomplete training.

I think if it’s a simple case of “This solution is better, and here’s why” then it can’t hurt. However, responses which require complex changes to the architecture of someones code is a bit too much. Suggesting dependency injection or MVC to someone just starting out is ridiculous. I suppose it’s a case of time/benefit. Will the person actually notice the (often subtle) difference and will it be easy for them to implement into their existing code? More importantly, is it something which can be explained on its own without bringing in more advanced topics? If not it’s almost certainly going to be too much too soon.

Agreed.

Edit: Thought it might be worth having a list of things which may get introduced. Here’s a few off the top of my head:

-Separation of concerns
-Avoidance of globals (including static)
-OOP
-Dependency injection

OOP has multiple layers to itself. The concept of a class is one thing - extensions and interfaces are another entirely.

4

In my experience on this forum, sometimes those that are ready for more advanced topics generally make themselves known.

They start a thread entitled “I know I am doing this wrong” or “Surely there is a better way?” or give away some desire to learn more in a thread.

There are also those that ask “what books should I read next?”

Having said that, it dawns on me that has been quite a while since I saw a thread like any of the above.

In those cases all that is needed are some carefully selected links.

I think many people also wander into the PAD forum and linger around or search, but are generally prompted to learn more by their own motivations. TBH, the practices of which you speak are non-trivial and only for those that really want to learn and improve themselves.

Otherwise yes, you should interject with advice, its not just the OP who will be reading your reply and a brief explanation and a simple link to a resource that explains the principle in greater detail should be enough - unless the OP expresses an interest.

Perhaps there should be more of this.

5

No reason to move to advanced topics until you master at least all types of loops (for, foreach, while, loop and a half), all built-in array functions in php, all string manipulation functions and some regular expressions.

Anything that has to do with OOP is kind of an advanced topic. Design patterns should be taught only after a person has strong understanding of OOP

6

I suppose I’ve seen a few answers in a few forums where the writers were bragging more than being helpful. :lol:

Uh, erm, other forums. :blush:

7

I wish I’d been taught OOP and design patterns while I was learning the basics (programming in general, not just PHP); I found myself stuck in bad habits for quite a while before things started making sense!

8

Yes, unless they can earn valuable badges for submitting the ‘best answer’

9

Jay.P, problem is - if you didn’t learn the procedural way and used bad habits - you’d have problems realizing why OOP / patterns make sense when doing certain things (maybe not, but generally that is learning curve is).
I find it helpful when someone mentions a certain way of doing things in a different manner when replying to a topic.

Only problem is that this forum recycles problems that have been solved 10000 times so interesting topics drown quickly in the sea of regular “help required” topics.
Usually, many people looking for help aren’t interested in long-term development.

10

<!-- off topic

I don’t want to get off topic, but you can’t really blame this on smarty. This is to blame on the person developing the template. The only way smarty or any template library could prevent such code is sand-boxing the template, not allowing any interaction with the application language. Smarty or anything else, placing business logic in the template is the fault of the programmer, not the tool. Besides, it paves the way for the more “advance” stuff.

on topic –>

I don’t think there is anything wrong with early on introducing separation of concerns. Whether your writing procedural or object-oriented code the same principles are interchangeable and very important. A procedural page can easily be written that follows a procedural MVC paradigm just as one that adheres to a strict oo MVC architecture can be. Separation and organization is something never to early to consider.

Avoidance of globals is another that I believe should be taught early on. Its a pretty simple concept, really.

Anything having to directly with oo programming and especially patterns should be taught once an intermediate understanding has been reached. I would never expect someone to starting out to understand the wide-world of OO architecture. This is why I don’t get people using complex oo methodology to solve simple problems when people asking the questions are obviously not familiar with object-oriented programming. I do think its more showing off, than anything. Thinking about it I believe its something most of us have done though…

11

Here’s an analogy. I do a bit of squash coaching (racquet sport). In squash it’s good if your opponent doesn’t know what shot you are going to play. So when an advanced player plays a drop shot (soft, gentle) they will probably still have a high back swing, and quick swing to disguise it as a hard shot. Teaching a beginner to play a drop shot like that won’t work. They need to learn to do it the simplest way first, then progress. In other words what is correct as a beginner may not be to an advanced player.

In programming there’s always more to learn, another way of doing things, another iteration of understanding and improvement. Mixing your business and presentation logic is not so bad if you’re just starting and trying to get a simple form to do something. It’s a lot worse later when you’re building a big app. Or if you keep doing it for years. There’s also a risk of analysis paralysis where nothing happens because people are afraid of doing it wrong.

So I think the advice needs to be relative to where a person is at and what they are trying to do (just solve today’s problem, or develop their skills)

12

I was kind of thinking along the same lines … People who come here asking questions aren’t students and there isn’t a curricula to follow when preparing answers.

Give the best answer you can if you want to help someone. If you intentionally withhold information in your answer you may not be giving the best possible help to the person that requested assistance here.

$0000000000000000.02

13

I think we fall into this trap: good programming practices these days revolve around object orientation and design patterns; therefore object orientation and design patterns result in good programming practices; therefore procedural coding is poor programming practice. But that’s not true, of course. Bad programming comes in all forms.

Indeed, I think people should learn procedural and know it well before moving on to OO because to really appreciate OO, you have to have run into the limitations of procedural coding. Then the benefits of composition and design patterns, especially for larger projects, starts making sense.

14

The best answer to a novice is not the best answer for a master. That is true of all walks of life, not just programming, and there is no malice on my part at least if I withhold information that I believe is outside the scope of the questioner’s skills to make sure of. Also, you can gauge user skill by questions asked - someone asking about a parse error isn’t ready for MVC lectures at length.

Or are they? Well, not in the scope of the project. One thing I’ve been paying attention to with the framework I’m working on is its learning curve. While I don’t want to cripple it’s functionality, if an easier to understand pattern exists for doing something I’ll take that pattern.

I learned PHP from vbulletin 3.0, used for this forum. I owe the team of vbulletin a debt I can never repay in part because of how well their code self documents and the thoroughness of its documentation and code comments. The best way to repay that I suppose is to create a framework who’s main goal is transparency for the code.

This is true, further object methods remain just small procedures. Until you know how to write procedures method writing isn’t going to help.

That said, there is a time and place. My framework has 1 function - main. That function reads the config file and then starts all other objects the system uses. The procedure is long, but its fairly ummutable. The behavior of the application as a whole can be utterly chanced since all the objects in the system - without exception - can be overridden by changing the config file. The main function won’t need to be touched once the structure gels completely.