I'm stealing China's Wall. Ignore all their demands to give it back
@Arantor:
Finally, a genuine reply.
First, as I imagined you are stretching the definitions for a logical fallacy. Slippery Slopes are a moot point for one simple reason:
Slippery Slopes are not Logical Fallacies.
It's a myth, a misconception by the skeptic community. Probably because doomsday sayers make much use of Slippery Slopes in their antics, slippery slopes which never come true. But here is the thing: they never come true because the slippery slopes they describe are filled with actual logical fallacies, so the logic doesn't follow, so they never materialize, but not because Slippery Slopes aren't real. They are a real thing, even on sheer logic they are a real thing, they can even be mathematically described as systems of redundant exponential growths.
They are even more real if you're working with a non-logical system, a system where human behavior is a dominant factor. For human behavior is arbitrary, is not bound by the rules of logic, it has great potential for redundant growth. That's why the concept is taken so seriously in fields such as Law Making or Social Engineering.
You can't refute an argument by simply calling it a slippery slope, you have to refute the underlying logic inside the Slippery Slope, why the events don't follow, why the slippery slope will not happen. So far, all you have pointed is that opposite forces happen as well, which is a pretty obvious point, but you never say which of them end up dominant on the long term, which is my point.
As for strawmanning, I would like to know where. This is about Template Engines, something which greatly affects theme developers. It's about the upsides and downsides such engines will have on theme development. If the discussion went somewhere else... it's a thing discussions do, they wander far to give points, give examples, makes connections, make analogies to better explain, to make the idea clearer in everyone's mind... the focus has never been lost however.
Same for Ad Hominem. By the Law of First Aggression I know I wasn't the first to attack directly the person professing an idea rather than the idea itself. Actually, so far in this whole discussion you have been the only one to say I'm being an “arrogant and elitist” rather than deal with the idea itself.
My probing on your behavior is not an attack. You were behaving against everything you have professed so far. Either you changed your mind about some of your beliefs or you're being a hypocrite. Good to know it's the first, shows good character
As for your other points:
Performance considerations are not just about how fast the instructions will happen, most of the time these are negligible. It's mostly about scalability, debugging and what kind of code such philosophies attract. As you use more and more of these higher layers, the small losses on performance starts to stack up to become greater losses, for a variety of reasons, from lack of control, to bloat, to improper form. So you end with the famous 90% of the time will be spent on 10% of your code. And chunks of that 10% will be all spread over the bloat generated by the higher abstractions, in small chunks of 0,5% there, 0,7% some 500 lines down the code... 2,5% at most, that's one of the reasons it becomes a debugging hell. And all that is even assuming you're using the engines smartly. Dumb code will be even worse.
And yes, dumb code happens everywhere, it's just statistics, but by removing basic PHP requirement you are giving it MORE room for it to happen. It's not about whether it happens or not, but at which scale they will start to happen.
Something similar (based on this kind of philosophy) has already affected the status quo of css. Bootstrapping is one of the most popular tools out there, and it was one of the worst things that ever happened to the Front-End Industry. It has gotten to the point that the browser has to ignore 90% of the code generated by such tools. 90% of the code is just sheer bloat. 90% of the lines are meaningless. Completely meaningless, wasteful and useless. This is not hyperbolic, just one of the latest work I did, to convert some code to be accepted under certain limitations, went from JS + html + css files totaling 158kb to html + css files at 6kb. Even the links were a sort of JS button, I suppose adding an <a> is too complicated. Bad JS like this is no news, but you see the same effect in css. I get so many jobs where what has been achieved in 3000 lines of code could be achieved with 300, on better user performance at that. Many times it's just better to scrap everything to the trash and start over, because it's such a ball of knots impossible to untangle, it's a waste of time to try to debug it, it's better to just start over. The saddest part of it all is this sort of thing is very widespread in the industry, so it's not just one or another code that does this, it's most of them.
And then on top of this people build tools to "clean the css", "clean that other piece of code", and are amazed to see "how well it works" when it reduces the files from 120kb to measly 15kb (which it should have been all along). And now in most people's mind, if you build a site without bootstrap or similar, its because you don't know what you are doing, when it should be the exact opposite.
Why all that? Most bootstrappers would answer you: “Dealing with CSS is too much work, it takes too long...”. It would be akin to backend developers saying CGIs or databases are too complicated, too much of a hassle to deal with. It's absurd.
Users vs themers: They are miles apart, starting at the basics (one should know, at the very least, HTML/CSS and the other will possibly not even know what that is), and I think that should be a separate discussion to see what can be done to make user life easier. One of the common things they want to edit can already be helped by adding sass variables (if by the time we do this, css variables are not already usable by themselves, but progress in new css functions is slow as always).
As for what this particular discussion reflects on the common user, I do not think whatever choice is made (to use a template engine or not) will make much difference to them. You could even say using plain PHP would benefit common users slightly more than anything else, based on the fact all code editors highlight php files properly by default (which many, if not most, common users will not even have), while other file types are often a downloadable package, that surely, they won't even know they have to get, or how. For most users, a template engine's code is just as greek as PHP, it's just an incomprehensible block of text-code.
The 'one syntax for another' argument is interesting. Let me reframe the situation, maybe it'll help you understand my perspective: why does TypeScript exist? what about CoffeeScript? These things literally do nothing that JavaScript can't do (because they compile down to JavaScript), but people like them because they abstract away some of the really annoying things in the underlying language. That's all that's going on here, really.
I do not know about TypeScript, but Coffescript doesn't seem to be a equivalent comparison. There could be cases in which such changes make sense, for example if you are dealing with a language that has terrible syntax to begin with, but this is not the case for PHP. The only really bad aspect of it in it are the echoes for HTML, and it is overkill to change everything else just to make this one part better. And, frankly, some (not all) of these templating engines manage to make the rest of the syntax even worse. If the idea is to have the templates redone and simplified to have less PHP in them, there is not going to be much difference in question of learning/usage curve when all you are doing is replace one way to write an if or a variable with a different one. It becomes simply unnecessary for something that does not come consequence-free. There simply isn't enough value in this change.
The kicker though, is that this debate reminds me of me. Everything I see in this debate echoes me, and this isn't a good thing. It makes me begin to question how much of a force I personally have been for good in this environment, and makes me think that my naive idealisms over the years have encouraged others to do the same - and I'm not convinced in some of those positions of argument that I was right. There was certainly a time when I argued against frameworks as a whole, and certainly a time when I argued against template engines, too. I find a lot of the same old issues, though, an over-cautious conservatism at a time when the entire fleet of platforms in the forum space are routinely castigated for failure to innovate, and it's harder to drive innovation on any level when the platform decides it wants a barrier to entry for even modest things like putting something to the screen. It's the same reason we don't use C to build a forum, we like having the abstractions. I'm just arguing for one more abstraction because it feels like it benefits everyone.
The wonders of growing older and noting the ****** you did before
I have been in the position of denying frameworks as a whole in the past too, it is the case that you mistake the erroneous usage with the thing itself. Yes, frameworks have their place. Maybe even bootstrap could have a useful use case somewhere, but it would be so specific it almost doesn't justify it's existence. It is however something to be very careful with to not fall into the same trap that most have fallen. You need to choose well what you will use and where, even more so when you can't rely on what most people are doing being right, since so often it is quite the opposite. When the Status Quo bar is so low, following it should be decided on much caution.
* people who are admins who want to do simple customisations of their own - these people aren't programmers, they just want to insert the bit of JavaScript for Google Analytics by copy and paste like GA tells them to, except surprise, they have to figure out quoting syntax. Or the people who just want to tweak a little bit like the header. They're then dealing with what amounts to mostly HTML and CSS, as opposed to PHP, actual HTML and CSS - and all evidence suggests that people find this easier to do simple changes. There's a reason people like the theme stuff in XenForo and IPB - it lets them make little changes without any hassle. They feel empowered, they feel like they can own something even though they're not technical. Not every SMF admin is a programmer or a designer.
Yes, that is nothing I disagree on, but this again goes back to the example I gave
here, you don't need to use one of these templating engines to fix that. I'm all for improving admins customizations features, but it should not do so at the expense of developer tools, they're different things.
Also, refer to the user vs themers above for the rest, and my reply to Suki below on the same subject.
* people who are theme people get to play with something closer to what they normally use rather than stepping through hoops. Yes, it means people can do stupid things more easily - but at the same time, it lets people who know the tools do so without having to remember to escape quotes. And people will always do stupid things, this shouldn't be a barrier to making tools easier for non-stupid use cases.
Again, same as above. Yes, things could be better. But why these templating engines over other methods?
* when I build Moodle plugins, even though I'm not even required to use the template system because Moodle doesn't mandate it (because Moodle doesn't use it itself for most of its plugins for historical reasons), most clients are requesting it so they can have a designer customise it without knowing Moodle's code innards. And Moodle certainly has PHP 'templates' in its core in the renderer system. Though that's a level of mind-killer with its many classes and layers of abstraction that I wouldn't impose upon anyone. But I digress - designers are the people who would like this.
Just as what happens anywhere, you have good and bad professionals, and those focused in a multitude of areas. You'll also find many designers who refuse to work without bootstrap or other css frameworks, that doesn't mean we should do as they say. You will never be able to please everyone, and I believe we should focus on getting good themers into SMF, not pleasing as many people as possible just for the sake of it.
Also, on an ironic note, this debate somehow ended up talking about C. Who remembers the doomed project smflib, that reimplemented bits of SMF as C so they would be PHP extensions for the really really big forums? I do...
This is the first time I hear about this. This seems interesting to see, in the least
@Suki:
Even though multiple reasons were exposed, you chose to focus solely on this point. You haven't addressed any point about helping development, for example.
There have been arguments about helping themers and helping regular users, you decided each was a separate argument which is not, as I have been saying, this thing AFFECTS everyone, not just you, not just themers.
You just showed you clearly haven't given proper attention to my posts then.
I'm not criticizing it for the sake of criticizing it, I'm trying to give better solutions.
They aren't assumptions. It is quite clear you haven't used a template engine. It is quite clear you haven't worked on a big project either. All the arguments you try to make were already made a few years ago. Really sorry to say this to you but get on with the times
They are assumptions for you don't know me. You don't know my history, you don't know the projects I have worked on, you don't know the people I know.
“Get on with the times” is a bull****** argument. It's pure rhetorics. It implies that whatever is “new and popular” is always better. It's a progressive misconception. Mankind doesn't always go forward, there are many new ideas and concepts that are crap, many popular customs that are wrong. It's a terrible argument.
Just FYI, I have worked from Real State companies to Financial Data companies. I know how big projects look like, I know how they behave. It’s a myth you need frameworks or huge teams to work on them. On the contrary, a small smart team working hard and close to the big bosses produce better output than huge teams divided by many hierarchies of command, working on “easy to write and read” languages as frameworks. These kind of projects tend to develop to bloated debugging hells, when the project doesn’t fall so far off the rails where you have to simply scrap everything and start over, losing millions in the process (or, as is most often the case, they just keep going while patching it over with even more bloat).
I have also met with people who are actual low level coders who work on huge projects with no more than a dozen teammates. The army, for one, still uses assembly coding for everything, from simple trajectory calculating algorithms to whole missile guiding system. Not because they deal with too many hardware input, you can code around hardware input even on higher levels as it happens with car's softwares, but different than car's softwares, bloated bugged code means dead people for the army, so they have to set the bar higher.
My point here is: You don't know me and it's possible to do work well without crutches, without frameworks and layers upon layers of higher abstractions, even on big projects. PHP + HTML/CSS is fine, it's on a fine balanced level of performance and abstractions. You're making assumptions.
Again, the chose for using a template engine comes from measuring all those aspects (and others who aren't directly related to programming) and based on all that info we decided a template engine is the best choice.
And I'm saying they are a bad choice and saying why I think so. Or are you above making bad choices and decisions?
By definition, an engine will keep presentation away from logic, this means heavy logic CANT be performed on a theme file. This actually prevents doing dumb stuff.
Of course, the engine itself will do the dumb stuff for the developer. They just hide the logic from the developer but there still an underlying logic working in there for which the developer loses control, and in many situations the standard engine logic will not fit the best requirements for one situation, that’s why high abstractions will always lose efficiency sooner or later. The engines will try to fit a ball in a square shaped hole sooner or later and the developer, most of the time, will have no knowledge about it, let alone control over it.
Reducing the tools available is also a two-edged sword. We are talking about something that theme makers will use, we should not be removing options from them. Developers need profiling and precision tools, not cradles and playgrounds so he doesn't hurt or learn anything.
This is yet another thing you conveniently ignore. Whoever gets in charge of building the next version has to take into account all the different types of people who are going to use SMF. From devs to themers to admins to users to hostings.
Ignore my ass. So far this discussion started on and is focused around Themers, because they are the ones who will have to work with the Template Engine. And here's the thing you don't seem to understand:
Themers are not users. Themers are developers, for they develop themes for users to use. They're Front-end developers, not Users. It's their job to know basic PHP to develop themes for a PHP Forum, because they're developers, not users. Otherwise you'll have developers who have no idea where they are developing upon and that makes for bad development process. It's good form to require basic PHP knowledge to develop a theme for a PHP Forum. By removing such requirements you do gain popularity, you do gain all those developers who don't care about PHP (and somehow, are perfectly fine learning a templating engine that will have much of the same stuff), but at the expense of losing good form. Now you have more room for bad form, and such system will invariably attract bad form sooner or later, it's what has happened in all similar systems.
What are you essentially arguing is that every user should have the option to be a developer, therefore we should simplify developer tools for developers so users can develop as well. That's why I call it dumbing it down.
This shouldn't be about forum users, this should be about developers, because it affects their work much more than the common user, be it a member or an admin.
I was saying I could reply with random text and you will still focus on your ideas. This whole thing was been a big waste of time since you don't really want to have a discussion, all you want to do is showing you are right.
So you would rather have me focus on random text unrelated to the discussion than the discussion itself then? Because otherwise that is a useless point.
I'm pressing the same key because you are making light of it and avoiding it so far.
And again, the one that has ignored most of what has been argued is you. I have already replied to all your points (and if there is one you believe I have not addressed, then please point it out and I will do so). If you wish to have a fair discussion, maybe you should start debunking the given arguments and answering the questions instead of avoiding them and lowering the level down to rhetorics.
It's actually dumbfounding that you come in all grandeur about your experience as PM and then tell me to get off my high horse.
As a general note, I'll say this again, since there seems to have been some confusion in this regard:
I am against the use of the proposed templating engines (or similar ones). I am not against making the templates better. I am also not against trying to find a better alternative to fixing the aforementioned problems with echoes either, while keeping the downsides to a minimum. I'm following the old engineering mantra: "There's a better way to do this". We should be making it easier for budding developers to learn
basic PHP, not replace its learning curve entirely with something else. You do not need to use a complete template engine to do any of the above, doing that just brings more problems than it solves. I don't believe the immediate gains in popularity such engines bring is worth all the headaches they will cause down the road.
