About coffee and about the Web, or why PHP is a bicycle
No no. The article is not about the attitude to the writing of bicycles in PHP, namely, that PHP is a bicycle in itself. And no, the author is not trying to join those who are not lazy and want to kick PHP. Rather, to say that the author is going to kick not only PHP. Caution: the article is extremely verbose.
PHP is a fairly unique phenomenon of modernity. PHP has a low threshold of entry, PHP is good because it is tra-la-la, tra-la-la. You yourself know all this better than me. It is on PHP that a huge number of websites and blogs are spinning, the creators of which sometimes have absolutely no idea about programming. Joomla and Wordpress vivid confirmation. And I'm talking about the creators of such sites, and not about the authors of these engines. However, without any sarcasm, I note that PHP is really good in many ways, and I personally can not consider it an absolute evil in bytecode. Simply, many, well, very, very many, for some reason, forget that PHP is just a templating engine.
')
Well yes. It's just a very, very advanced template engine. So advanced that it even has OOP, namespaces, and all sorts of different useful and convenient things. And even already have a built-in web server, they say. I do not know for sure, I personally did not check it, because I don’t follow it.
I think it would be appropriate to ask for forgiveness from each and every one in case any judgment seems offensive or disrespectful to someone. There was no thought. Rather, on the contrary: I sincerely admire selflessly often writing very, very good code people, and immensely respect such work and such people. Forgive generously and do not judge strictly. Just looking at everything that is happening today in IT and, in particular, in WEB, and it becomes more and more difficult to be silent. Therefore, the article is a semi-philosophical reflections and considerations, and does not contain absolutely no practical recommendations. But, nevertheless, I really want to hope that I, nevertheless, will be able to convey some practical sense. This opus is inspired by numerous publications on Habré and not only about the web and its sunset, about HTML5 / CSS / JS and not only about template engines, frameworks and design; as well as comments on all of this.
Well, as usual, a little about the author. The author is not a team lead, not a CEO, not a junior and not a liege. And in general, the career of the author as a programmer has not yet somehow developed for various reasons, although there were prerequisites for this. In particular, at the age of pre-adult age, the author received a fair amount of pleasure from decompiling of toy toys and programming in the Z80 mnemonic. But, further, personal changes and lack of prospects in that place and at that time pushed all this into the category of a hobby, and the unsuccessful attempt to master FoxPro 2.6 on an unfamiliar platform with an unfamiliar, and completely incomprehensible, after the assembler, OOP from MS. But the fact that in the future they began to be called the loud abbreviation IT, did not let go, as a result, they lived for many years in a small state office as a sysadmin. However, thoughts about programming led the author through varying degrees of immersion in VB / VBA / VBS, Delphi, MS VC ++, terrible and misunderstood MFC, after which the author for some time found rest with Borland C ++ and his VCL. After that, the literature on the methods of programming and designing systems and interfaces went into motion. Then there was PHP, ActionScript (which is 3.0), Python and, of course, the holy trinity of HTML / CSS / JS. Java was not long taken into account for ideological reasons, but this, as it turned out, is not unchanged. I repeat (this is important), all the above abbreviations and names were studied and tried out exclusively as a hobby; practical applications (including on a commercial basis) did not happen often, but they did happen. So the Chukchi, after all, is more a reader than a writer. At the moment, the public sector is in the past due to the author’s transition to self-sufficiency in the field (déjà vu) of programming, including web-oriented programming. And yes, it was necessary to dump earlier.
Also, the author is often scolded by friends for ignoring the principles of JFDI (the author respects the popular wisdom from the category of "quieter ride" and "measure seven times"), as well as extreme verbosity.
And the last: the author uses the appeal to himself in the third person exclusively in the context of self-irony, because all of the above seems to him very funny (but also in something sad too). But enough about that.
So, template engine. Think for a minute, but what does the thing that is considered to be a template engine do? In most cases, the template engine, roughly speaking, accepts a template at the input (or, more often, a link to the template file) and a set of variables, and gives the finished text in the form of a template filled with variable values. Also, the default template can often be used. In principle, it is often possible not to transfer variables, then the output will be a clean pattern. Also, some template engines are able to request some data from the database and insert it into the template, however, such liberty is considered by many unacceptable due to inconsistencies with the concepts of MVC. I think many have already guessed what I'm getting at.
Actually, I did not say anything new, because PHP was conceived as a template engine. It works like a template engine: received a request — processed — returned an answer — we were sleeping (or the end of the work). I am absolutely not against its use. But I’m totally against using PHP as a toolkit for creating template engines. I am also against writing PHP frameworks and CMS, in particular, using OOP (and even if the class hierarchy grows to thousands).
However, this is all just an introduction. The tale is just beginning, because the problem here is much wider and deeper. But let's get a little distracted and look at the bikes. In the literal sense. Wheel, pedals and a pair of wheels. What do you think is the world record for cycling speed? Until recently, I did not even guess. However, the simplest search displays 268 km / h . Just think: it turns out, you can ride a bicycle at a speed that not every car is capable of! Of course, this speed can not be developed on any road, and various tricks will be required.
Now let's see who uses bikes:
And in what situations:
The above can also be combined in various variations. As we see, the use of the bicycle in practical terms is rarely used by the masses (most of Europe and Asia will not agree with this, but there are reasons for this). It is understandable - why, if you can be more comfortable and faster? In addition, not everyone can afford to ride a bike, say, to a business meeting. Because for this you need enough courage and some neglect of comfort (tritely sweat when you pedal). Yes, and a man in a strict suit with a tie with a case, and, at the same time, on a bicycle, it is difficult for me to imagine. But then again - it is not everywhere like this, somewhere it is normal.
So, what we have for comparing two entities from different worlds:
The last point is the most obvious. With regard to PHP, perhaps, you can exclude "not for long", but the rest - almost complete ideological comparison. We need a "cap" / "air corridor", which will have to be organized specifically for this occasion, and which, most likely, will never be useful again. Need a smooth road, which is not everywhere. However, a smooth road is preferable for any land transport. And it is very desirable that it was "not uphill." Although, perhaps, with "not long" I hurried. A large or very large PHP project without taking special measures for its stability will sooner or later collapse. Not enough either hardware or programmer abilities. At this point, decide for yourself what it is like, but I like this analogy:
In principle, here the author can be reproached with bias - after all, a web server is needed for any website written in any language! Etaa, onooo, kaneshna, uh ... yes ... - the author creases. But. The author after all promised to kick not only PHP. Let's look at the process from the other side. On the part of the end user (for example, a site visitor) and his browser. And also for some moments in the life of HTTP. You can see more from the customer site, but we will not. Because if the customer will choose, then only from what is. In the meantime, let us assume that the developer of the site is his own master. This also happens.
In a general sense, the main task of the end user is to obtain the necessary (and sometimes necessary) information. In the private - “push into the net” (hand-drive / copy / paste the address into the line) and see the desired. And in the overwhelming majority of cases, he doesn’t care what kind of hardware there is, what kind of software is there. He even on the route to the server do not care, and the entire HTTP, along with all its answers and states. He has no idea what is there, why, and why. From which it clearly follows that neither muscle, nor puff, nor even a ngink (I know that it is not so pronounced) does not need him. He needs "infa". And the point. And the only thing that the user sees is images / text / video / sound. Someone else pays attention to the design / convenience, but not all. Someone else is looking at the speed of loading / reaction of the site, but, again, not all.
What is the site developer looking at? In the fullest sense - for everything. But for this you need to have an idea about the system administration, and about programming, and about web design (I propose to include “usability” in the design for simplicity, although this is often not the case). There are not so many of them, we have a division of labor in fashion. As a result, sometimes these three branches of government are so independent of each other that you simply wonder how it even manages to work. Let's just list in geographic / temporal order the path from the request to the page in the form in which it currently exists. I am sure most of those who are in the subject know this better than me, and if I lie, they will correct it. But I am in a general sense, so that it appears in all its glory, so to speak. So:
A very standard procedure, as you can see. Nothing unusual, nothing fatal, all in standard frames. I would not steamed myself, but. I am constantly visited by the feeling that "something is wrong here." Let's try to figure it out. Even a cursory inspection reveals one frequently used expression: "taken from the cache." And if you try to run through the forums dedicated to improving the performance of the site in PHP - you are so stumbled into this very cache that you will search everywhere, what else would you do? And to your question “why should you cash in?” You will be very popularly explained how useful this is. I will give my favorite wording:
- And how without a cache?
- The bottleneck of any site - DB! Cache everything you can!
- Memkashd taxis!
And only the most compassionate, hard sighing, for the hundredth or thousandth time will give you a brief lecture about the fact that PHP is an interpreter, that it is compiled every time, but it can be done, how slow the work with the database and finally can be, put nginx for static- proxy, and let apache twist scripts. And also use cookies, sessions and local storages, because HTTP ...
I will give one more inconspicuous, at first glance, list. A small list of technologies that are needed in order to create a website easily and simply (here I’ll still lag behind PHP, because the rabbit hole begins here):
Server side:
Client side:
All this is somehow tied to HTTP over TCP over IP over Ethernet (although interprocess communication sockets can be used inside a single server). Seven (!!!) technologies for one site! No, well, is this really normal? Not even, not like that. For one request-response cycle, all of them are still needed and still work. Even if this is a request for a page like “me and my dog” that will change every six months - seven different technologies that constantly cache and cache themselves, is that really normal? Of course! - professionals will answer. And justify their response to the policies and specifics of shared-hosting, etc. etc. And by the way, they will be right. With reference to today. Because for the current day such a scheme has shown itself to be the most flexible and enduring. Moreover, in the comments they will throw a couple more, or even more. I for one forgot something or even worse, did not know.
But only to me personally this does not seem normal. And now I will try to explain my position.
Lyrical digression number one. About six years ago, the author became acquainted with web technologies in the form of maintenance and adding of sites built on PHP / MySQL. At first, of course, it was very strange and new, but very quickly it came to the realization that mixed in a bunch of HTML and JS, output through echo, then through print, then just outside <? Php?> - this is not so fun. In parallel with this, it suddenly turned out that writing a browser-based online game is not only cool and profitable, but also damn easy! Familiar? :) As a result, a browser-based online game was launched on an allegedly open-source engine, written (of course, not by the author, but by an unknown third party) in PHP, after looking inside the code of which the hair moved, and the practice of working with the database in an amount of about 180 -ty requests for each click just terrified. And the bulk of requests implemented what is so lacking in PHP over HTTP in relation to such projects - the current state of the player and the gameplay. Here it would be more appropriate to kick the author for the useless choice of technology, and indeed it serves him. Of course, the code corresponded, a lot of things were changed in the mechanics of the game, but we could not overcome the main drawback of the engine at that time - we needed to completely rewrite it from scratch. What was conceived and started. And our greatest desire at that time was to organize some kind of “demon” that would manage the database and its contents in order to unify and simplify the engine mechanics. At about the same time, stored procedures and a scheduler appeared in the muscle, and it seemed to us that this would finally solve all our problems. At first we didn’t have enough courage to take C or Python, then time, and after some time it became clear that the planned creation would not bring the desired income due to its specificity, and all the best thoughts were put off to the charming “later”. Which, so far, has not yet come. The key point of the above: it is the absence of built-in mechanisms for working with the current state and their implementation of the crutch on their own accelerated the inevitable collapse of that engine.
Lyrical digression number two. The author is to some extent an idealist, a perfectionist and a dreamer. The author likes to drink freshly brewed coffee in the morning and dream a little in the morning. Including the fact that the coffee brewed somehow himself. But, since this particular pattern of dreams is of absolutely no applied nature, the author likes to dream up on this topic some other nonsense, in the manner of nonsense. It is possible, to stretch our brains or just suffer with garbage - I do not know for sure. So, at that time, I was lying and arguing something like this:
Well, let's say, you can pour water and pour coffee in Turku in the evening. Gas stove with piezoelectric ignition - they can click on the timer relyushku, it's easy. It remains to come up with a simple way to turn the knob of the burner tap to open and close the gas ... And it was here that it dawned on me. We are so accustomed to this familiar process that we completely ceased to notice the details of the process, and we began to think stepwise through the steps that had been worked out long ago. What you need to make coffee? Turk, water, coffee, open the gas, set fire to the gas ... Stop! And here in general gas? In order to heat the water. So - we checkers or go? Do we need open gas or do we need hot water? ..
That is, in fact, according to this scheme, we usually reason. Well-established, proven, good or just convenient practices and algorithms we reserve as an example of a successful solution of life problems, and in similar cases we try to apply these technologies that have proven themselves. This is one of the basic foundations of the foundations of our thinking, and this is good, and often this approach will be the appropriate solution to the task. But not always. Here is an abstract example, which, in more concrete variations, I had the good fortune to observe hundreds of times in ordinary life, including among my own actions. Suppose we need to take a friend to drink water. We quickly in terms of thinking conditions: the number, range, ease of carrying, and we find quite a normal solution. We take a mug, pour water, we carry a friend. Buddy is happy - so are we. The problem is solved, everyone is happy. Sample solution created. After a couple of hours, a friend asks to repeat - we do not hesitate to take the same cup and repeat the procedure. All is well. The sample passed the first stage of consolidation - confirmation of the truth. A week later, a friend again looks at the light, and - according to the same scenario. The sample is ready for industrial use. And when in a month a couple of friends ask for water - we boldly take two circles and, well, no problems at all! Industrial application in action, scaling implemented, tested and tested. From now on, in our consciousness “drinking water” will be reinforced concrete associated with “from the circle”. The trap is ready. Because once to our hearth, a noisy group of fifteen people suddenly collapses, on July and +30 Celsius on the street. In short, habraeffekt. From seven to ten flights with circles, plus the potential to split several of them. Instead of taking a few empty mugs, just putting them on the fingers of one hand (they no longer need to be carried horizontally, they are empty) and the bottle / carafe / jug of water into the other hand. In fact, it is about this that ideas are born, really original ones - just take a step or two in thought and look at the situation from the outside. Otherwise, we begin somehow to simplify our task to rest against 15 cups of water in one go. You can, for example, put them all on one tray. And you can roll up with scotch tape ... And then, God forbid, solve this problem successfully. Because after some time there will be a task to bring ten liters from the well of water, and the neighbor will laugh for a long time, watching us, drawing a cup of water from the well for a mug, and carefully observing the composition and encapsulation that make up these cups goals bag specially sharpened by horizontal_kruzku_kruzhek. And, in response to his mocking nod in the direction of the bucket standing next to the well, we will want to hit him very heavily with something heavy, for example, this very bucket. Because it is very unpleasant and painful to realize that he is right, calling us idiots ...
At one time, I watched the spectacular AS3 procession with great enthusiasm, but Mr. Ay came and ruined everything . Of course, let's curse the ancient technology of three years ago for its stagnation and cumbersome, let's not try to optimize it, having agreed and tackled technological issues with a couple of dozen final manufacturers of hardware and software, and instead take the new decade-old developments based on flat text with the support of ineffective coloring and super-fast interpreted language, which almost without problems adds to our already magnificent pages a bit of an interactive, if, of course, you use Subscribe to this great framework and by-pass all your dynamically changing primitives, and very soon make candy out of all this, just a couple of years left! .. Very, very much respect Uncle Steve for a lot of things, but specifically in this matter I'm with him I do not agree. Although, I do not exclude that he really wanted the best. But adoby either misunderstood, or just wilt, and, as a result, in fact, they profiled the web ...
Lyrical digression number three. On my wall is hanging a relatively new TV with Smart technology, a built-in browser and keyboard / mouse support. But attempts to enter any video hosting service fail in 90% of cases. For a start, it is difficult to simply type the address if it is sealed, because the keyboard arrows control the mouse cursor (!!!). But, even if you manage to successfully enter the site, it’s not a fact that you will get to watch a movie. Either it will not be possible to get the cursor into the movie because of the crazy scrolling, or the browser will die under the weight of JS scripts carefully pointed by the site owner, and everything will have to start all over again. People who develop vaunted Smart-applications, it seems, have never seen keyboards, because the character layout of the on-screen keyboard is for some reason alphabetic in most cases. There even sometimes there is a button for switching the input language, but not a single well-established keyboard shortcut, usually used for this, works. Why are there a language - the keyboard itself in these applications does not always work. And, in fact, the fact that the very same flash is used there doesn’t mean anything at all. Just because somewhere it works as it should, but somewhere it does not. And what, this is progress?
When I turned that same AS3 - I, again, was horrified by what was written on it. For the most famous toys, kazualki created on the basis of examples from educational books, and the graphics in many worse than the "spectrunny" thirty-year (!!!) prescription, about the animation generally keep quiet. But this, fortunately, is not a problem of the tongue, but of curved hands. Because by the time of relatively wide distribution of various engines, the quality has improved in some places. At that time, a considerable number of talented guys, including our compatriots, were doing smart things on AS3, including implementing almost full-fledged 3D and physics, because there was no third dimension before the tenth version of flash player. In the 10th version, they screwed the Z coordinate, although not everything was cloudless, but this is not important. It is important that Adobe realized that there was a very obvious and almost fatal flaw, and took steps to eliminate it. By the way, here's a simple little exercise of two years ago in the size of 4825 bytes. The source code contains about 250 lines of code; only built-in classes are used, no third-party engines. The orbits are elliptical, the position of the planets is calculated by the mean anomaly (accelerated motion, according to Kepler). There were no optimizations either in terms of speed of execution or in size. Here and zabatsayte me something similar to the size of the code transmitted to the client and the speed of execution on the same bare JS even with the canvas, at least like. Or on CSS, gee-gee. Maybe then I recognize the triumph of HTML5 & associates ...
Now let's take a quick look at the evolution of the programmer and programming in languages ​​other than PHP for platforms other than HTML (we will look at these later). Usually, the programmer’s development path goes through several key stages for him:
Step 00. We write "hello world". Hooray! I am a programmer!
Step 10. We write Cool Window Application.
Step 20. What a lot of variables, a bunch of functions and variables is tilted by copy-paste. Corrected in ten places already tired, something must be done about it.
Step 30. Aha! Need to use classes!
Step 40. Something I have more and more copy-paste, and one FIG has to rule in ten places.
Step 50. Aha! Design patterns will solve all my problems!
Step 99. Damn, how I was an idiot ... Well, that's just simple ...
Step 100. Zen.
Step numbers and method names are chosen almost arbitrarily. They are not important in themselves, but the fact that the programmer changes paradigms of thinking. At least that was the case with me, and with people with whom I am familiar and whose code I saw. True, in my critical opinion, none of them have reached the 99th step yet, just as I myself did. And not too many programmers I know. But when you look into the code of the authors of some frameworks / libraries / programs, you take aback and you get the feeling that people have long since walked over some five hundredth step ...
I have one observation that concerns me. In various textbooks, there are recommendations not to look at the process of designing software programs for the hardware capabilities of computing equipment, and also appeals not to wonder why it works that way, but simply to use it. It seems to me fundamentally wrong for the preparation of a quality programmer. And I have seen a lot of evidence for this - most of the really good programmers have a strong idea of ​​how “this is all in general” works, sometimes up to the assembler and the TCP level. But what is remarkable: such a recommendation is really valuable for raising a monkeypatcher. It is understandable. Animal training is usually done in a similar way: it doesn’t matter why or why, it’s important to do exactly that and it will be delicious. And on this unpleasant note, we turn to the cherished couple of PHP / HTML.
I personally tend to conditionally divide PHP'sshnikov into two big categories: those who know other programming languages ​​(for such, as a rule, PHP was not the first language, although it happens the other way around), and those who don't know anything other than PHP. The first category often develops according to the previous scenario, and I have no questions for them - they usually write good code in PHP and use it competently and reasonably. But the second category - everything is different there. Generally everything. Because, going through the development in the first scenario, people often initially directly use only one or two non-language-specific technologies (for example, the console or WinAPI / X11), and cause-and-effect relationships do not break: here they are, command line arguments, they and in the code, we use. What can not be said about the second category.
Because people who have not programmed at all to PHP turn out to be alone with a ready-made, large, already working and very incomprehensible system. On the one hand, here's echo 'hello world' for you — the browser — F5 — that's it, and on the other, it's not entirely clear how it got there and why it didn't refresh itself. No, basic concepts like “put the file into the root of the web server” are, of course, assimilated, but the questions “where does the web server have root?” And “what does it look like at all?” Are often left without proper explanation with a vague hope of filling this gap in the future . Over time, the number of such incomprehensible places only grows, all sorts of TESES / JeES / Hataccess / Oope / templates / fonts / Zhipegi are added, the insides of which are not particularly clear, but (and this is very important) - all of this, it turns out, you can definitely not use reflecting on what, why and how. Over time, the “not to think” paradigm sometimes turns out to be prevalent, and then this is completely sad. Somewhere some psychologists have once determined that a person’s perception of a new text stops at the place where he met an incomprehensible word. In this case, the most correct would be to return to this word, explain its meaning, and continue. In the case of web technologies (and most often on the web they start with PHP) - there are a lot of incomprehensible words. Incredibly many, for some - so almost everything. But: if we start explaining the whole chain from a request to a browser via a web server using a tspipu - we’ll get to the actual programming very soon. And so here lies lie. Either the teachers (in a broad sense - it can be both senior comrades, and friends — forum users, and lecturers from video lessons) lie to the trainees, then everything will become clear, or the students themselves begin to lie to themselves and the teachers (because it’s embarrassing to admit ): “Yes, lan, then I understood everything.” “Yes, you don’t understand,” they wave a hand of the teacher and give out the next portion of training. Over time, the trainees become so accustomed to the state of “a little misunderstood, but let's do it that way” that a complete dump of concepts, methods, formats and everything that is possible accumulates in the mind.
At the output, we can get a “specialist” who has been programming in PHP for several years, but he still cannot clearly explain how a file uploaded to one server appears in the browser when it is requested to another server. No, on the whole, he, kaneshna, bugs, but if you ask for clarification, the output will be something between “something like this” and “yes, what a difference”.
An additional headache for PHP is OOP in any sense, and all sorts of other runtime buns. And the evolution of a PHP programmer will eventually differ somewhat from the one hundred steps described above to Zen. Because, on the one hand, all of them know that the script will work, collapse and forget everything, and on the other hand, they write code as if it were software that has been running continuously for years and centuries. Carefully considering the structure of classes, static methods, implementing interfaces and even (!!!) signals, they produce code kilometers.The apotheosis begins with the implementation of "lazy loading" - after all, they still understand that this code may be unfulfilled, so why bother to embed it? Trick is not felt yet? This code may never be executed, but it is written! And time was spent on its writing, time wasting, and often money ...
And if for a programmer in a language with a long execution time, once initiated a variable in a good half of cases can be used even after a year of the program, then in PHP it is all initialized, instantiated literally in response to every sneeze from the user's browser, often in response to an ajax request, after which everything instantly collapses and is forgotten. The author is sometimes a little slow, and the realization of this fact for him once was a not-bad blow to the psyche.
Of course, I never discovered America again, but why am I talking about this and why I consider it important. Because the common mess in the heads of many programmers prevents them from abstracting from the whole process and reflecting on theessence of beingthat which is worth all this for. And in response to their attempts to vymyashit they, accustomed to the fact that "it still does not change this," refuse to understand anything. Sometimes, because there is no other way than the browser — the web server — PHP — the DB — the PHP — the web server — the browser simply does not represent. Well, since the output in any case is still HTML with buns, then it goes into the category of immutable and immutable truths, not subject to proof of axioms. And, since PHP today is in the majority, and it is for it that a separate web server is needed, programmers in other languages ​​start attaching to separate web servers, because they are still installed and configured, and why reinvent the wheel? And really, why? Still, it seems, and so it works fine?
In order to answer this question, let us touch upon another topic. Namely: separate_web-server. What does he usually do and how did it all begin? In other words, why is it done that way? The fact is that the first web serverwas created a long time ago. Then there was little RAM and it was expensive. The files were also small then, and the graphic elements for the design were practically not used. There was no PHP, no JS, no CSS. There was only bare HTML. The browser was then not a means of satisfying the hunger for information, but a new program, by launching which, it was possible to get some information (if you have an internet connection, which was also very small and slow then). And websites were not a way to show off (though ... :)), but a way to share some information. Disk arrays also did not differ in large capacity, but still, they were cheaper than RAM. It was then simply considered (and indeed it was) impossible to keep files in RAM, even if they were used frequently.In addition, the connection speed was then measured in units and tens of kilobits. Therefore, the first web servers, in response to a user request, started several tens of bytes per second to read the file from the server's hard disk and transfer it to the client in slices through the network. And the transfer of one file did not always take less than one second. Yes.Since then, a little more than twenty years have passed. Everything has changed. Any middle server of that time would probably have become envious of a modern average smartphone by any parameter, be it the capacity of RAM, the frequency of the CPU, and the capacity of ROM, probably, too. And even the screen resolution.
But we still store files on disks, read them by web servers and feed our browsers in batches. Only ponapridumyvali still a lot of all sorts of beautiful and amenities like a rich internet application with scripting languages. And all this on top of technology twenty years ago. They invented not to strain the poor puff with static files and distribute them separately to a web server. Smart people, tired of CSS imperfections, even came up with LESS and SASS, and maybe there is something else. And now the dilemma is where and when to compile it? Whether on the server, or on the client. Whether to cache, or recompile after each change and add to static? But for some reason, no one wants to see what the cache is, in essence, and how the web server distributes the static.Although each uses a wording like "files will still be cached by the system and will not be re-read from the disk every time." Well, take this last step already! After all, everyone can already see that the files, being cached, in fact, are not stored on disk, but in RAM! Why reinvent the next type of cache - just load these files into memory, and give them away directly. If this requires compilation - compile into a final view and give, again, from the RAM. And already that which is truly variable - load from the database or where you store it there ...If this requires compilation - compile into a final view and give, again, from the RAM. And already that which is truly variable - load from the database or where you store it there ...If this requires compilation - compile into a final view and give, again, from the RAM. And already that which is truly variable - load from the database or where you store it there ...
In this place, someone should poke the author in the side of Occam's razor, and argue, they say, why do we need extra entities, if everything works anyway? And why do you need a car, if a little more than a hundred years ago, the majority lacked a horse and two of them? Why does a person need a personal computer and a graphical interface with browsers and tyrnets? After all, it was not so long ago that it was asserted very authoritatively ... So, gentlemen, okkamists. Penetrating At Any Designing Omnipresent Cache, in fact, is the very superfluous essence! After all, everything will work without him, right? And if so, why should we? Let's be consistent in judgment. But no, nobody hurries to give up the cache, an extra cache is never superfluous. And why?Because the cache, as we are told, speeds up the work of applications. But, gentlemen, let me, this is nonsense! How can you speed up something without overclocking it? The CPU is still running at the same frequency, the operating frequency of the RAM is the same, the exchange rate with disk arrays also does not increase. But, however, it really works faster with cache. The great Sacred Truth is that the cache never accelerates anything - it just removes the brakes. I mean, it allows you to bypass slowly working areas when re-passing through them, just briefly remembering their condition. Well, if you still have to bypass them - then they are. But where did they come from? So we piled them up there, actually ...
That's the question - why, for the sake of what are we building this slow-working code? Why don't we make it fast? As a rule, either out of ignorance or inability. Sometimes by misunderstanding. But let's see: the average modern not very complex site contains from hundreds of kilobytes to a few megabytes of graphic and other styling. With current prices for RAM - this is nothing. On the other hand, if it is in the cache, no matter at what level, it will still take this RAM. Moreover, it can be in the caches of different levels of different parts of the system and can eat off this RAM several times. And not always in the best way. So why do we need extra layers, we are not Shrek and not onions? Just when starting the system, load them into memory and use. And the cache turns out, is not needed at all.But it is precisely in this place that all the weakness of PHP manifests itself ... It cannot do this. It will not be possible to gain anything, even if it is serialized and stored - anyway, with the next query, you will have to first initialize the object hierarchy and then deserialize. Superfluous, unnecessary, accelerating work.
Lyrical digression number four. Do you know why VAZ2101 without improvement is unlikely to be able to accelerate to a speed of 200 km / h? Not even because of the engine. Because already at 130 km / h, the poor “penny” starts to be thrown from side to side, so that it becomes scary to go. Because the 15-degree steering play at 20 km / h is almost not noticeable, and at 200 km / h, you can easily fly off the road literally on level ground. It is simply not intended for such speeds. On the bike, by the way, driving fast is also dangerous. No depreciation, direct steering ... One inaccurate movement can cost considerable physical losses. It is also not designed for high speeds. But at high speeds calculated prorv results of the modern automotive industry. And do you know what makes a modern car different from an average bicycle fifteen years old? Yes,right. Everybody.But what is most important in it is that all the nodes in it are maximally fitted to each other by professional designers so that you do not even need to think about it. You just get into the car and drive. And when for your organization a car suddenly becomes necessary, why you will not hire specially trained car mechanics, who will hoarsely argue with each other regarding the number of installed cylinders, such as brakes, chassis design, to make for you such a car, which you need and no one will ever have this again? Yes, someone collects cars for themselves, but this is either a hobby or an industrial order, and it is always expensive. But even in this case, almost no one will calculate the engine parameters for you and design it, but simply take the appropriate parameters. Of courseYou are interested in the finished car, and not the process of calculating engine parameters. In this allegory, the important thing is that what is calculated by experts in most cases is better and more reliable than the knee-length assembly, and sometimes even cheaper. Not without exception, of course.
Then they will tell me: the author also speaks about CMS or frameworks! Like yes and no. Yes, because both of them are designed to save the programmer from unnecessary routine work, and no, because their work is still performed at the application level. In other words, if you do reverse allegorization to a motor vehicle - a framework or CMS, it is semantically similar to a car assembled from a designer with various degrees of abstraction detailing. Also, of course, has the right to life, but somehow ... Not in a mass application, perhaps. But for some reason, programming is still the case.
In many frameworks on the same python, for example, and, more recently, in PHP, there is an embedded web server for development, but it is not recommended to use them on production, because specialized solutions are faster and more reliable. Developed and extensions and protocols for working with web servers. Farther.Data storage. Most languages ​​have built-in capabilities for working with the file system and various ways of storing data. But on an industrial scale, again, they recommend using specialized DBMS - for, again, more reliable. Although not always easier. Although for many projects, I confess, SQLite-base, located in RAM, is quite a high-speed and reliable solution. In other words, the specialized solution wins again. Now let's look at the majority of today's sites and try to highlight some semantic features common to all. Offhand:
And what about the web? Here is HTML5 - flash killer. Here is JS - AS3 killer. Straight some kind of popular front. But who is fighting with someone? The Neanderthal war with the Cro-Magnon, and defeated, for some unknown reason, turns out to be Cro-Magnon. And this is strange, and leads to bad thoughts that it can be beneficial to someone. What is not pleased with flash technology? Ugly annoying banners? So questions to manufacturers and locators, and not to technologists, actually. And what, vyrviglaznye blinking designs HTML-sites of the early 2000s - it was better? Everything shining beyond measure sooner or later goes away, and that would be gone. Why do we need flash, we now have a canvas? Nu-nu.In place of adobe, I would have screwed all the methods for working with the new elements into the next version of ActionScript, and indeed the business. I haven’t been following them for a long time, I don’t know, maybe they have already done so. For recently, something flash player puffs like a pastry dough. So, the author for flash instead of HTML? Not. The author for a reasonable approach.
Lyrical digression number five, the last. Not so long ago, the author began a free life, among other things, it was decided to return to the development of sites on the principle “I slap quickly in Tsmsk for a penny, and it’s okay” as a non-core business profile. But the question of choosing a CMS for PHP just killed me, one might say. A lot of time was spent, but the silver bullet of my dream remained undiscovered. In a vain attempt to gain Zen, even Yii was considered. Awesome code, awesome features, extensive, though English-language, documentation, as they say, is a good community. But niasilil. Well, I can not, as a function argument, pass an array of arrays of arrays, which is right there and specified. Cool framework, cool written code, but why ??? And permanent forums “How to do? “Go dock!” But damn it,if the same questions arise again and again with different people at different times, it means that something is wrong with this place! In all the forums of all programming languages ​​the same questions are always the same. How to make a user, how to store them, what to hash, how to write a request, and what is finally so, and why is that? .. And now a programmer of one thousand people spends, probably, the hundred billionth global man-hour, to implement the same users storage, then_the same encryption passwords, te_zhe_samy queries to the database, in_tech_zhe_samyh_plakhova connects te_zhe_zamye caches, so that exactly_that_zhe_non_transaction ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedsomething is wrong with this place! In all the forums of all programming languages ​​the same questions are always the same. How to make a user, how to store them, what to hash, how to write a request, and what is finally so, and why is that? .. And now a programmer of one thousand people spends, probably, the hundred billionth global man-hour, to implement the same users storage, then_the same encryption passwords, te_zhe_samy queries to the database, in_tech_zhe_samyh_plakhova connects te_zhe_zamye caches, so that exactly_that_zhe_non_transaction ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedsomething is wrong with this place! In all the forums of all programming languages ​​the same questions are always the same. How to make a user, how to store them, what to hash, how to write a request, and what is finally so, and why is that? .. And now a programmer of one thousand people spends, probably, the hundred billionth global man-hour, to implement the same users storage, then_the same encryption passwords, te_zhe_samy queries to the database, in_tech_zhe_samyh_plakhova connects te_zhe_zamye caches, so that exactly_that_zhe_non_transaction ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedand why is that? .. And now the 100,000th programmer spends, probably, the hundred-billionth global person-hour, to create the same user storage, then the same password encryption, exactly_the_the_the most requests to the database, connect to the_the_the_themstheyes of the database, exactly_the_the_the_the_the_the_the_first_your_to_the_the_the_the_the_the_first_year requests to the database code? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedand why is that? .. And now the 100,000th programmer spends, probably, the hundred-billionth global person-hour, to create the same user storage, then the same password encryption, exactly_the_the_the most requests to the database, connect to the_the_the_themstheyes of the database, exactly_the_the_the_the_the_the_the_first_your_to_the_the_the_the_the_the_first_year requests to the database code? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedto accurately_tak_zhe_ne_tormozilo ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedto accurately_tak_zhe_ne_tormozilo ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedsend away from PHP in the direction of the python, which I have been looking at for a long time, and also write this article.
So what does the author want, and why all this verbiage?
My most unloved answer to the asked question from the category: “Why is this being done / is this happening exactly?” Is “What do you want?”. For some reason, it seems to me obvious that I meant something else that is different from what is happening, therefore, in fact, I ask. So, please answer a few questions:
It’s time to thank the browsers for their service, long and faithful, and donate them to history museums along with stencils and typewriters, get some modern-fashioned device out of your pocket, and enjoy genuine interactive, built on the triumph of modern technologies, not fragments technology thirty years ago. Just kidding:) But seriously, it’s really time to critically review the entire stack of technologies of the existing web, in my subjective opinion. As for PHP, it’s not going anywhere. I do not exclude that he will find a place in the new web. Especially if enthusiasts stop trying to make a " faster horse ." And the good old simple sites will work on it for a very, very long time.
One more thing. In the questions posed, I deliberately put down the stick in some places and quite consciously expect legitimate criticism. As practice shows, reasoned criticism reveals well the weak points, and there, really, something really useful can be born. The only thing I would ask to refrain from is to comment in the spirit of "what to do with the existing equipment and the army of trained specialists." I am not so naive as to expect an explosive effect with an immediate revolution. In truth, I’m not at all sure that anything in the world will change, but some hopefor the triumph of reasonStir up at least someone still there. I would also like to caution against self-assertions like “it’s immediately obvious that the author is not a programmer” - this is not about the code in the framework of existing technologies, but about the expediency and convenience of the technologies themselves. On the narrow-mindedness of an experienced gaze, accustomed to precisely this state of affairs. And about whether it is possible to make the world better and cleaner, and what is needed for this.
I thank everyone for their attention and patience while reading this opus. And I apologize for such a voluminous statement. And no, the author is not a schizophrenic. Both of us are absolutely sure of this - both I and the author. :)
PHP is a fairly unique phenomenon of modernity. PHP has a low threshold of entry, PHP is good because it is tra-la-la, tra-la-la. You yourself know all this better than me. It is on PHP that a huge number of websites and blogs are spinning, the creators of which sometimes have absolutely no idea about programming. Joomla and Wordpress vivid confirmation. And I'm talking about the creators of such sites, and not about the authors of these engines. However, without any sarcasm, I note that PHP is really good in many ways, and I personally can not consider it an absolute evil in bytecode. Simply, many, well, very, very many, for some reason, forget that PHP is just a templating engine.
')
Well yes. It's just a very, very advanced template engine. So advanced that it even has OOP, namespaces, and all sorts of different useful and convenient things. And even already have a built-in web server, they say. I do not know for sure, I personally did not check it, because I don’t follow it.
I think it would be appropriate to ask for forgiveness from each and every one in case any judgment seems offensive or disrespectful to someone. There was no thought. Rather, on the contrary: I sincerely admire selflessly often writing very, very good code people, and immensely respect such work and such people. Forgive generously and do not judge strictly. Just looking at everything that is happening today in IT and, in particular, in WEB, and it becomes more and more difficult to be silent. Therefore, the article is a semi-philosophical reflections and considerations, and does not contain absolutely no practical recommendations. But, nevertheless, I really want to hope that I, nevertheless, will be able to convey some practical sense. This opus is inspired by numerous publications on Habré and not only about the web and its sunset, about HTML5 / CSS / JS and not only about template engines, frameworks and design; as well as comments on all of this.
Well, as usual, a little about the author. The author is not a team lead, not a CEO, not a junior and not a liege. And in general, the career of the author as a programmer has not yet somehow developed for various reasons, although there were prerequisites for this. In particular, at the age of pre-adult age, the author received a fair amount of pleasure from decompiling of toy toys and programming in the Z80 mnemonic. But, further, personal changes and lack of prospects in that place and at that time pushed all this into the category of a hobby, and the unsuccessful attempt to master FoxPro 2.6 on an unfamiliar platform with an unfamiliar, and completely incomprehensible, after the assembler, OOP from MS. But the fact that in the future they began to be called the loud abbreviation IT, did not let go, as a result, they lived for many years in a small state office as a sysadmin. However, thoughts about programming led the author through varying degrees of immersion in VB / VBA / VBS, Delphi, MS VC ++, terrible and misunderstood MFC, after which the author for some time found rest with Borland C ++ and his VCL. After that, the literature on the methods of programming and designing systems and interfaces went into motion. Then there was PHP, ActionScript (which is 3.0), Python and, of course, the holy trinity of HTML / CSS / JS. Java was not long taken into account for ideological reasons, but this, as it turned out, is not unchanged. I repeat (this is important), all the above abbreviations and names were studied and tried out exclusively as a hobby; practical applications (including on a commercial basis) did not happen often, but they did happen. So the Chukchi, after all, is more a reader than a writer. At the moment, the public sector is in the past due to the author’s transition to self-sufficiency in the field (déjà vu) of programming, including web-oriented programming. And yes, it was necessary to dump earlier.
Also, the author is often scolded by friends for ignoring the principles of JFDI (the author respects the popular wisdom from the category of "quieter ride" and "measure seven times"), as well as extreme verbosity.
And the last: the author uses the appeal to himself in the third person exclusively in the context of self-irony, because all of the above seems to him very funny (but also in something sad too). But enough about that.
So, template engine. Think for a minute, but what does the thing that is considered to be a template engine do? In most cases, the template engine, roughly speaking, accepts a template at the input (or, more often, a link to the template file) and a set of variables, and gives the finished text in the form of a template filled with variable values. Also, the default template can often be used. In principle, it is often possible not to transfer variables, then the output will be a clean pattern. Also, some template engines are able to request some data from the database and insert it into the template, however, such liberty is considered by many unacceptable due to inconsistencies with the concepts of MVC. I think many have already guessed what I'm getting at.
Actually, I did not say anything new, because PHP was conceived as a template engine. It works like a template engine: received a request — processed — returned an answer — we were sleeping (or the end of the work). I am absolutely not against its use. But I’m totally against using PHP as a toolkit for creating template engines. I am also against writing PHP frameworks and CMS, in particular, using OOP (and even if the class hierarchy grows to thousands).
However, this is all just an introduction. The tale is just beginning, because the problem here is much wider and deeper. But let's get a little distracted and look at the bikes. In the literal sense. Wheel, pedals and a pair of wheels. What do you think is the world record for cycling speed? Until recently, I did not even guess. However, the simplest search displays 268 km / h . Just think: it turns out, you can ride a bicycle at a speed that not every car is capable of! Of course, this speed can not be developed on any road, and various tricks will be required.
Now let's see who uses bikes:
- Athletes - everything is clear with them, sport is sport. It is so, because it happened historically.
- Children - these have not yet grown, either to the physiological ability to drive a car, or to legal. In general, small yet. Only bikes and remain.
- People who do not have the financial opportunity to purchase a car.
- People ideologically committed to this type of transport for various reasons (ecology, health, again, money, but “out of principle”).
And in what situations:
- Cycle tracks / Olympic tracks.
- Just "drive" / ride.
- "Drive in a quick way" somewhere nearby.
- In the absence of alternatives, you can go far away, but it will not be easy.
- You can also bring or roll something too heavy on it for manual carrying.
The above can also be combined in various variations. As we see, the use of the bicycle in practical terms is rarely used by the masses (most of Europe and Asia will not agree with this, but there are reasons for this). It is understandable - why, if you can be more comfortable and faster? In addition, not everyone can afford to ride a bike, say, to a business meeting. Because for this you need enough courage and some neglect of comfort (tritely sweat when you pedal). Yes, and a man in a strict suit with a tie with a case, and, at the same time, on a bicycle, it is difficult for me to imagine. But then again - it is not everywhere like this, somewhere it is normal.
So, what we have for comparing two entities from different worlds:
- and get and go - easy and affordable
- but not far and slow
- You can go far, but it will be quite slow and tiring
- You can go quickly, but not for long, and already, in general, is not cheap, and even more tiring. And, most likely, not far. And not everywhere this trick will pass.
The last point is the most obvious. With regard to PHP, perhaps, you can exclude "not for long", but the rest - almost complete ideological comparison. We need a "cap" / "air corridor", which will have to be organized specifically for this occasion, and which, most likely, will never be useful again. Need a smooth road, which is not everywhere. However, a smooth road is preferable for any land transport. And it is very desirable that it was "not uphill." Although, perhaps, with "not long" I hurried. A large or very large PHP project without taking special measures for its stability will sooner or later collapse. Not enough either hardware or programmer abilities. At this point, decide for yourself what it is like, but I like this analogy:
- DB is like a road. The flatter the better.
- WEB-server - as air resistance. The less he tupit from hits, the better.
- Caches of various kinds - this is the “cap” and the accompanying technique - without this, of course, it is possible, but with it it is better.
In principle, here the author can be reproached with bias - after all, a web server is needed for any website written in any language! Etaa, onooo, kaneshna, uh ... yes ... - the author creases. But. The author after all promised to kick not only PHP. Let's look at the process from the other side. On the part of the end user (for example, a site visitor) and his browser. And also for some moments in the life of HTTP. You can see more from the customer site, but we will not. Because if the customer will choose, then only from what is. In the meantime, let us assume that the developer of the site is his own master. This also happens.
In a general sense, the main task of the end user is to obtain the necessary (and sometimes necessary) information. In the private - “push into the net” (hand-drive / copy / paste the address into the line) and see the desired. And in the overwhelming majority of cases, he doesn’t care what kind of hardware there is, what kind of software is there. He even on the route to the server do not care, and the entire HTTP, along with all its answers and states. He has no idea what is there, why, and why. From which it clearly follows that neither muscle, nor puff, nor even a ngink (I know that it is not so pronounced) does not need him. He needs "infa". And the point. And the only thing that the user sees is images / text / video / sound. Someone else pays attention to the design / convenience, but not all. Someone else is looking at the speed of loading / reaction of the site, but, again, not all.
What is the site developer looking at? In the fullest sense - for everything. But for this you need to have an idea about the system administration, and about programming, and about web design (I propose to include “usability” in the design for simplicity, although this is often not the case). There are not so many of them, we have a division of labor in fashion. As a result, sometimes these three branches of government are so independent of each other that you simply wonder how it even manages to work. Let's just list in geographic / temporal order the path from the request to the page in the form in which it currently exists. I am sure most of those who are in the subject know this better than me, and if I lie, they will correct it. But I am in a general sense, so that it appears in all its glory, so to speak. So:
- user clicks the link
- the browser finds out the server address (or takes it from the cache, if not the first time. But the first time you still have to do it).
- the browser forms a GET | POST (less often other HTTP) -query to the web-server and performs it.
- web server:
- or analyzes the request (for example, on the subject of "static / dynamic") and, if static, gives the file
- either just calls the script
- the script understands, whether static or dynamic. You can even generate a file on the fly. And begins to collect the text of the answer. In standard cases with respect to PHP, this procedure proceeds somehow like this:
- the script is read from the disk (or taken from the file system cache), parsed, executed
- depending on the contents of the script, configs, templates usually start to be read (taken from the cache), templates start to be parsed, compiled (well, or taken from the PHP cache) and executed; queries are made to the database for data, and sometimes for templates (if possible, it is also cached here)
- on the basis of everything read and executed, a ready answer text is formed
- the script returns the plain text of the response to the web server
- The web server (in general) sends the browser header and script response.
- the browser parses the server's response and decides what to do with it:
- if HTML partners parse and display / execute
- if media shnyaga, again, displays / loses, by itself or with the help of plugins
- profit! (if not 404 or some other dirty trick, but let's not talk about it; we are fine)
A very standard procedure, as you can see. Nothing unusual, nothing fatal, all in standard frames. I would not steamed myself, but. I am constantly visited by the feeling that "something is wrong here." Let's try to figure it out. Even a cursory inspection reveals one frequently used expression: "taken from the cache." And if you try to run through the forums dedicated to improving the performance of the site in PHP - you are so stumbled into this very cache that you will search everywhere, what else would you do? And to your question “why should you cash in?” You will be very popularly explained how useful this is. I will give my favorite wording:
- And how without a cache?
- The bottleneck of any site - DB! Cache everything you can!
- Memkashd taxis!
And only the most compassionate, hard sighing, for the hundredth or thousandth time will give you a brief lecture about the fact that PHP is an interpreter, that it is compiled every time, but it can be done, how slow the work with the database and finally can be, put nginx for static- proxy, and let apache twist scripts. And also use cookies, sessions and local storages, because HTTP ...
I will give one more inconspicuous, at first glance, list. A small list of technologies that are needed in order to create a website easily and simply (here I’ll still lag behind PHP, because the rabbit hole begins here):
Server side:
- web server or even several
- scripting (usually but not necessarily) language
- database server
Client side:
- HTML
- CSS
- Js
- quite often both AS (Flash) and not only
All this is somehow tied to HTTP over TCP over IP over Ethernet (although interprocess communication sockets can be used inside a single server). Seven (!!!) technologies for one site! No, well, is this really normal? Not even, not like that. For one request-response cycle, all of them are still needed and still work. Even if this is a request for a page like “me and my dog” that will change every six months - seven different technologies that constantly cache and cache themselves, is that really normal? Of course! - professionals will answer. And justify their response to the policies and specifics of shared-hosting, etc. etc. And by the way, they will be right. With reference to today. Because for the current day such a scheme has shown itself to be the most flexible and enduring. Moreover, in the comments they will throw a couple more, or even more. I for one forgot something or even worse, did not know.
But only to me personally this does not seem normal. And now I will try to explain my position.
Lyrical digression number one. About six years ago, the author became acquainted with web technologies in the form of maintenance and adding of sites built on PHP / MySQL. At first, of course, it was very strange and new, but very quickly it came to the realization that mixed in a bunch of HTML and JS, output through echo, then through print, then just outside <? Php?> - this is not so fun. In parallel with this, it suddenly turned out that writing a browser-based online game is not only cool and profitable, but also damn easy! Familiar? :) As a result, a browser-based online game was launched on an allegedly open-source engine, written (of course, not by the author, but by an unknown third party) in PHP, after looking inside the code of which the hair moved, and the practice of working with the database in an amount of about 180 -ty requests for each click just terrified. And the bulk of requests implemented what is so lacking in PHP over HTTP in relation to such projects - the current state of the player and the gameplay. Here it would be more appropriate to kick the author for the useless choice of technology, and indeed it serves him. Of course, the code corresponded, a lot of things were changed in the mechanics of the game, but we could not overcome the main drawback of the engine at that time - we needed to completely rewrite it from scratch. What was conceived and started. And our greatest desire at that time was to organize some kind of “demon” that would manage the database and its contents in order to unify and simplify the engine mechanics. At about the same time, stored procedures and a scheduler appeared in the muscle, and it seemed to us that this would finally solve all our problems. At first we didn’t have enough courage to take C or Python, then time, and after some time it became clear that the planned creation would not bring the desired income due to its specificity, and all the best thoughts were put off to the charming “later”. Which, so far, has not yet come. The key point of the above: it is the absence of built-in mechanisms for working with the current state and their implementation of the crutch on their own accelerated the inevitable collapse of that engine.
Lyrical digression number two. The author is to some extent an idealist, a perfectionist and a dreamer. The author likes to drink freshly brewed coffee in the morning and dream a little in the morning. Including the fact that the coffee brewed somehow himself. But, since this particular pattern of dreams is of absolutely no applied nature, the author likes to dream up on this topic some other nonsense, in the manner of nonsense. It is possible, to stretch our brains or just suffer with garbage - I do not know for sure. So, at that time, I was lying and arguing something like this:
Well, let's say, you can pour water and pour coffee in Turku in the evening. Gas stove with piezoelectric ignition - they can click on the timer relyushku, it's easy. It remains to come up with a simple way to turn the knob of the burner tap to open and close the gas ... And it was here that it dawned on me. We are so accustomed to this familiar process that we completely ceased to notice the details of the process, and we began to think stepwise through the steps that had been worked out long ago. What you need to make coffee? Turk, water, coffee, open the gas, set fire to the gas ... Stop! And here in general gas? In order to heat the water. So - we checkers or go? Do we need open gas or do we need hot water? ..
That is, in fact, according to this scheme, we usually reason. Well-established, proven, good or just convenient practices and algorithms we reserve as an example of a successful solution of life problems, and in similar cases we try to apply these technologies that have proven themselves. This is one of the basic foundations of the foundations of our thinking, and this is good, and often this approach will be the appropriate solution to the task. But not always. Here is an abstract example, which, in more concrete variations, I had the good fortune to observe hundreds of times in ordinary life, including among my own actions. Suppose we need to take a friend to drink water. We quickly in terms of thinking conditions: the number, range, ease of carrying, and we find quite a normal solution. We take a mug, pour water, we carry a friend. Buddy is happy - so are we. The problem is solved, everyone is happy. Sample solution created. After a couple of hours, a friend asks to repeat - we do not hesitate to take the same cup and repeat the procedure. All is well. The sample passed the first stage of consolidation - confirmation of the truth. A week later, a friend again looks at the light, and - according to the same scenario. The sample is ready for industrial use. And when in a month a couple of friends ask for water - we boldly take two circles and, well, no problems at all! Industrial application in action, scaling implemented, tested and tested. From now on, in our consciousness “drinking water” will be reinforced concrete associated with “from the circle”. The trap is ready. Because once to our hearth, a noisy group of fifteen people suddenly collapses, on July and +30 Celsius on the street. In short, habraeffekt. From seven to ten flights with circles, plus the potential to split several of them. Instead of taking a few empty mugs, just putting them on the fingers of one hand (they no longer need to be carried horizontally, they are empty) and the bottle / carafe / jug of water into the other hand. In fact, it is about this that ideas are born, really original ones - just take a step or two in thought and look at the situation from the outside. Otherwise, we begin somehow to simplify our task to rest against 15 cups of water in one go. You can, for example, put them all on one tray. And you can roll up with scotch tape ... And then, God forbid, solve this problem successfully. Because after some time there will be a task to bring ten liters from the well of water, and the neighbor will laugh for a long time, watching us, drawing a cup of water from the well for a mug, and carefully observing the composition and encapsulation that make up these cups goals bag specially sharpened by horizontal_kruzku_kruzhek. And, in response to his mocking nod in the direction of the bucket standing next to the well, we will want to hit him very heavily with something heavy, for example, this very bucket. Because it is very unpleasant and painful to realize that he is right, calling us idiots ...
At one time, I watched the spectacular AS3 procession with great enthusiasm, but Mr. Ay came and ruined everything . Of course, let's curse the ancient technology of three years ago for its stagnation and cumbersome, let's not try to optimize it, having agreed and tackled technological issues with a couple of dozen final manufacturers of hardware and software, and instead take the new decade-old developments based on flat text with the support of ineffective coloring and super-fast interpreted language, which almost without problems adds to our already magnificent pages a bit of an interactive, if, of course, you use Subscribe to this great framework and by-pass all your dynamically changing primitives, and very soon make candy out of all this, just a couple of years left! .. Very, very much respect Uncle Steve for a lot of things, but specifically in this matter I'm with him I do not agree. Although, I do not exclude that he really wanted the best. But adoby either misunderstood, or just wilt, and, as a result, in fact, they profiled the web ...
Lyrical digression number three. On my wall is hanging a relatively new TV with Smart technology, a built-in browser and keyboard / mouse support. But attempts to enter any video hosting service fail in 90% of cases. For a start, it is difficult to simply type the address if it is sealed, because the keyboard arrows control the mouse cursor (!!!). But, even if you manage to successfully enter the site, it’s not a fact that you will get to watch a movie. Either it will not be possible to get the cursor into the movie because of the crazy scrolling, or the browser will die under the weight of JS scripts carefully pointed by the site owner, and everything will have to start all over again. People who develop vaunted Smart-applications, it seems, have never seen keyboards, because the character layout of the on-screen keyboard is for some reason alphabetic in most cases. There even sometimes there is a button for switching the input language, but not a single well-established keyboard shortcut, usually used for this, works. Why are there a language - the keyboard itself in these applications does not always work. And, in fact, the fact that the very same flash is used there doesn’t mean anything at all. Just because somewhere it works as it should, but somewhere it does not. And what, this is progress?
When I turned that same AS3 - I, again, was horrified by what was written on it. For the most famous toys, kazualki created on the basis of examples from educational books, and the graphics in many worse than the "spectrunny" thirty-year (!!!) prescription, about the animation generally keep quiet. But this, fortunately, is not a problem of the tongue, but of curved hands. Because by the time of relatively wide distribution of various engines, the quality has improved in some places. At that time, a considerable number of talented guys, including our compatriots, were doing smart things on AS3, including implementing almost full-fledged 3D and physics, because there was no third dimension before the tenth version of flash player. In the 10th version, they screwed the Z coordinate, although not everything was cloudless, but this is not important. It is important that Adobe realized that there was a very obvious and almost fatal flaw, and took steps to eliminate it. By the way, here's a simple little exercise of two years ago in the size of 4825 bytes. The source code contains about 250 lines of code; only built-in classes are used, no third-party engines. The orbits are elliptical, the position of the planets is calculated by the mean anomaly (accelerated motion, according to Kepler). There were no optimizations either in terms of speed of execution or in size. Here and zabatsayte me something similar to the size of the code transmitted to the client and the speed of execution on the same bare JS even with the canvas, at least like. Or on CSS, gee-gee. Maybe then I recognize the triumph of HTML5 & associates ...
Now let's take a quick look at the evolution of the programmer and programming in languages ​​other than PHP for platforms other than HTML (we will look at these later). Usually, the programmer’s development path goes through several key stages for him:
Step 00. We write "hello world". Hooray! I am a programmer!
Step 10. We write Cool Window Application.
Step 20. What a lot of variables, a bunch of functions and variables is tilted by copy-paste. Corrected in ten places already tired, something must be done about it.
Step 30. Aha! Need to use classes!
Step 40. Something I have more and more copy-paste, and one FIG has to rule in ten places.
Step 50. Aha! Design patterns will solve all my problems!
Step 99. Damn, how I was an idiot ... Well, that's just simple ...
Step 100. Zen.
Step numbers and method names are chosen almost arbitrarily. They are not important in themselves, but the fact that the programmer changes paradigms of thinking. At least that was the case with me, and with people with whom I am familiar and whose code I saw. True, in my critical opinion, none of them have reached the 99th step yet, just as I myself did. And not too many programmers I know. But when you look into the code of the authors of some frameworks / libraries / programs, you take aback and you get the feeling that people have long since walked over some five hundredth step ...
I have one observation that concerns me. In various textbooks, there are recommendations not to look at the process of designing software programs for the hardware capabilities of computing equipment, and also appeals not to wonder why it works that way, but simply to use it. It seems to me fundamentally wrong for the preparation of a quality programmer. And I have seen a lot of evidence for this - most of the really good programmers have a strong idea of ​​how “this is all in general” works, sometimes up to the assembler and the TCP level. But what is remarkable: such a recommendation is really valuable for raising a monkeypatcher. It is understandable. Animal training is usually done in a similar way: it doesn’t matter why or why, it’s important to do exactly that and it will be delicious. And on this unpleasant note, we turn to the cherished couple of PHP / HTML.
I personally tend to conditionally divide PHP'sshnikov into two big categories: those who know other programming languages ​​(for such, as a rule, PHP was not the first language, although it happens the other way around), and those who don't know anything other than PHP. The first category often develops according to the previous scenario, and I have no questions for them - they usually write good code in PHP and use it competently and reasonably. But the second category - everything is different there. Generally everything. Because, going through the development in the first scenario, people often initially directly use only one or two non-language-specific technologies (for example, the console or WinAPI / X11), and cause-and-effect relationships do not break: here they are, command line arguments, they and in the code, we use. What can not be said about the second category.
Because people who have not programmed at all to PHP turn out to be alone with a ready-made, large, already working and very incomprehensible system. On the one hand, here's echo 'hello world' for you — the browser — F5 — that's it, and on the other, it's not entirely clear how it got there and why it didn't refresh itself. No, basic concepts like “put the file into the root of the web server” are, of course, assimilated, but the questions “where does the web server have root?” And “what does it look like at all?” Are often left without proper explanation with a vague hope of filling this gap in the future . Over time, the number of such incomprehensible places only grows, all sorts of TESES / JeES / Hataccess / Oope / templates / fonts / Zhipegi are added, the insides of which are not particularly clear, but (and this is very important) - all of this, it turns out, you can definitely not use reflecting on what, why and how. Over time, the “not to think” paradigm sometimes turns out to be prevalent, and then this is completely sad. Somewhere some psychologists have once determined that a person’s perception of a new text stops at the place where he met an incomprehensible word. In this case, the most correct would be to return to this word, explain its meaning, and continue. In the case of web technologies (and most often on the web they start with PHP) - there are a lot of incomprehensible words. Incredibly many, for some - so almost everything. But: if we start explaining the whole chain from a request to a browser via a web server using a tspipu - we’ll get to the actual programming very soon. And so here lies lie. Either the teachers (in a broad sense - it can be both senior comrades, and friends — forum users, and lecturers from video lessons) lie to the trainees, then everything will become clear, or the students themselves begin to lie to themselves and the teachers (because it’s embarrassing to admit ): “Yes, lan, then I understood everything.” “Yes, you don’t understand,” they wave a hand of the teacher and give out the next portion of training. Over time, the trainees become so accustomed to the state of “a little misunderstood, but let's do it that way” that a complete dump of concepts, methods, formats and everything that is possible accumulates in the mind.
At the output, we can get a “specialist” who has been programming in PHP for several years, but he still cannot clearly explain how a file uploaded to one server appears in the browser when it is requested to another server. No, on the whole, he, kaneshna, bugs, but if you ask for clarification, the output will be something between “something like this” and “yes, what a difference”.
An additional headache for PHP is OOP in any sense, and all sorts of other runtime buns. And the evolution of a PHP programmer will eventually differ somewhat from the one hundred steps described above to Zen. Because, on the one hand, all of them know that the script will work, collapse and forget everything, and on the other hand, they write code as if it were software that has been running continuously for years and centuries. Carefully considering the structure of classes, static methods, implementing interfaces and even (!!!) signals, they produce code kilometers.The apotheosis begins with the implementation of "lazy loading" - after all, they still understand that this code may be unfulfilled, so why bother to embed it? Trick is not felt yet? This code may never be executed, but it is written! And time was spent on its writing, time wasting, and often money ...
And if for a programmer in a language with a long execution time, once initiated a variable in a good half of cases can be used even after a year of the program, then in PHP it is all initialized, instantiated literally in response to every sneeze from the user's browser, often in response to an ajax request, after which everything instantly collapses and is forgotten. The author is sometimes a little slow, and the realization of this fact for him once was a not-bad blow to the psyche.
Of course, I never discovered America again, but why am I talking about this and why I consider it important. Because the common mess in the heads of many programmers prevents them from abstracting from the whole process and reflecting on the
In order to answer this question, let us touch upon another topic. Namely: separate_web-server. What does he usually do and how did it all begin? In other words, why is it done that way? The fact is that the first web serverwas created a long time ago. Then there was little RAM and it was expensive. The files were also small then, and the graphic elements for the design were practically not used. There was no PHP, no JS, no CSS. There was only bare HTML. The browser was then not a means of satisfying the hunger for information, but a new program, by launching which, it was possible to get some information (if you have an internet connection, which was also very small and slow then). And websites were not a way to show off (though ... :)), but a way to share some information. Disk arrays also did not differ in large capacity, but still, they were cheaper than RAM. It was then simply considered (and indeed it was) impossible to keep files in RAM, even if they were used frequently.In addition, the connection speed was then measured in units and tens of kilobits. Therefore, the first web servers, in response to a user request, started several tens of bytes per second to read the file from the server's hard disk and transfer it to the client in slices through the network. And the transfer of one file did not always take less than one second. Yes.Since then, a little more than twenty years have passed. Everything has changed. Any middle server of that time would probably have become envious of a modern average smartphone by any parameter, be it the capacity of RAM, the frequency of the CPU, and the capacity of ROM, probably, too. And even the screen resolution.
But we still store files on disks, read them by web servers and feed our browsers in batches. Only ponapridumyvali still a lot of all sorts of beautiful and amenities like a rich internet application with scripting languages. And all this on top of technology twenty years ago. They invented not to strain the poor puff with static files and distribute them separately to a web server. Smart people, tired of CSS imperfections, even came up with LESS and SASS, and maybe there is something else. And now the dilemma is where and when to compile it? Whether on the server, or on the client. Whether to cache, or recompile after each change and add to static? But for some reason, no one wants to see what the cache is, in essence, and how the web server distributes the static.Although each uses a wording like "files will still be cached by the system and will not be re-read from the disk every time." Well, take this last step already! After all, everyone can already see that the files, being cached, in fact, are not stored on disk, but in RAM! Why reinvent the next type of cache - just load these files into memory, and give them away directly. If this requires compilation - compile into a final view and give, again, from the RAM. And already that which is truly variable - load from the database or where you store it there ...If this requires compilation - compile into a final view and give, again, from the RAM. And already that which is truly variable - load from the database or where you store it there ...If this requires compilation - compile into a final view and give, again, from the RAM. And already that which is truly variable - load from the database or where you store it there ...
In this place, someone should poke the author in the side of Occam's razor, and argue, they say, why do we need extra entities, if everything works anyway? And why do you need a car, if a little more than a hundred years ago, the majority lacked a horse and two of them? Why does a person need a personal computer and a graphical interface with browsers and tyrnets? After all, it was not so long ago that it was asserted very authoritatively ... So, gentlemen, okkamists. Penetrating At Any Designing Omnipresent Cache, in fact, is the very superfluous essence! After all, everything will work without him, right? And if so, why should we? Let's be consistent in judgment. But no, nobody hurries to give up the cache, an extra cache is never superfluous. And why?Because the cache, as we are told, speeds up the work of applications. But, gentlemen, let me, this is nonsense! How can you speed up something without overclocking it? The CPU is still running at the same frequency, the operating frequency of the RAM is the same, the exchange rate with disk arrays also does not increase. But, however, it really works faster with cache. The great Sacred Truth is that the cache never accelerates anything - it just removes the brakes. I mean, it allows you to bypass slowly working areas when re-passing through them, just briefly remembering their condition. Well, if you still have to bypass them - then they are. But where did they come from? So we piled them up there, actually ...
That's the question - why, for the sake of what are we building this slow-working code? Why don't we make it fast? As a rule, either out of ignorance or inability. Sometimes by misunderstanding. But let's see: the average modern not very complex site contains from hundreds of kilobytes to a few megabytes of graphic and other styling. With current prices for RAM - this is nothing. On the other hand, if it is in the cache, no matter at what level, it will still take this RAM. Moreover, it can be in the caches of different levels of different parts of the system and can eat off this RAM several times. And not always in the best way. So why do we need extra layers, we are not Shrek and not onions? Just when starting the system, load them into memory and use. And the cache turns out, is not needed at all.But it is precisely in this place that all the weakness of PHP manifests itself ... It cannot do this. It will not be possible to gain anything, even if it is serialized and stored - anyway, with the next query, you will have to first initialize the object hierarchy and then deserialize. Superfluous, unnecessary, accelerating work.
Lyrical digression number four. Do you know why VAZ2101 without improvement is unlikely to be able to accelerate to a speed of 200 km / h? Not even because of the engine. Because already at 130 km / h, the poor “penny” starts to be thrown from side to side, so that it becomes scary to go. Because the 15-degree steering play at 20 km / h is almost not noticeable, and at 200 km / h, you can easily fly off the road literally on level ground. It is simply not intended for such speeds. On the bike, by the way, driving fast is also dangerous. No depreciation, direct steering ... One inaccurate movement can cost considerable physical losses. It is also not designed for high speeds. But at high speeds calculated prorv results of the modern automotive industry. And do you know what makes a modern car different from an average bicycle fifteen years old? Yes,right. Everybody.But what is most important in it is that all the nodes in it are maximally fitted to each other by professional designers so that you do not even need to think about it. You just get into the car and drive. And when for your organization a car suddenly becomes necessary, why you will not hire specially trained car mechanics, who will hoarsely argue with each other regarding the number of installed cylinders, such as brakes, chassis design, to make for you such a car, which you need and no one will ever have this again? Yes, someone collects cars for themselves, but this is either a hobby or an industrial order, and it is always expensive. But even in this case, almost no one will calculate the engine parameters for you and design it, but simply take the appropriate parameters. Of courseYou are interested in the finished car, and not the process of calculating engine parameters. In this allegory, the important thing is that what is calculated by experts in most cases is better and more reliable than the knee-length assembly, and sometimes even cheaper. Not without exception, of course.
Then they will tell me: the author also speaks about CMS or frameworks! Like yes and no. Yes, because both of them are designed to save the programmer from unnecessary routine work, and no, because their work is still performed at the application level. In other words, if you do reverse allegorization to a motor vehicle - a framework or CMS, it is semantically similar to a car assembled from a designer with various degrees of abstraction detailing. Also, of course, has the right to life, but somehow ... Not in a mass application, perhaps. But for some reason, programming is still the case.
In many frameworks on the same python, for example, and, more recently, in PHP, there is an embedded web server for development, but it is not recommended to use them on production, because specialized solutions are faster and more reliable. Developed and extensions and protocols for working with web servers. Farther.Data storage. Most languages ​​have built-in capabilities for working with the file system and various ways of storing data. But on an industrial scale, again, they recommend using specialized DBMS - for, again, more reliable. Although not always easier. Although for many projects, I confess, SQLite-base, located in RAM, is quite a high-speed and reliable solution. In other words, the specialized solution wins again. Now let's look at the majority of today's sites and try to highlight some semantic features common to all. Offhand:
- First, the design principle. HTML / CSS / JS c with buns. Everything is pretty much the same. In essence, only the typefaces / sizes / colors of fonts and the sizes / styles / arrangement of block design elements differ.
- -, . , , , (, , ). , . — — - , - .
- -, . - , . , , - . , , , — , , - HTML+CSS+JS. , , , .
And what about the web? Here is HTML5 - flash killer. Here is JS - AS3 killer. Straight some kind of popular front. But who is fighting with someone? The Neanderthal war with the Cro-Magnon, and defeated, for some unknown reason, turns out to be Cro-Magnon. And this is strange, and leads to bad thoughts that it can be beneficial to someone. What is not pleased with flash technology? Ugly annoying banners? So questions to manufacturers and locators, and not to technologists, actually. And what, vyrviglaznye blinking designs HTML-sites of the early 2000s - it was better? Everything shining beyond measure sooner or later goes away, and that would be gone. Why do we need flash, we now have a canvas? Nu-nu.In place of adobe, I would have screwed all the methods for working with the new elements into the next version of ActionScript, and indeed the business. I haven’t been following them for a long time, I don’t know, maybe they have already done so. For recently, something flash player puffs like a pastry dough. So, the author for flash instead of HTML? Not. The author for a reasonable approach.
Lyrical digression number five, the last. Not so long ago, the author began a free life, among other things, it was decided to return to the development of sites on the principle “I slap quickly in Tsmsk for a penny, and it’s okay” as a non-core business profile. But the question of choosing a CMS for PHP just killed me, one might say. A lot of time was spent, but the silver bullet of my dream remained undiscovered. In a vain attempt to gain Zen, even Yii was considered. Awesome code, awesome features, extensive, though English-language, documentation, as they say, is a good community. But niasilil. Well, I can not, as a function argument, pass an array of arrays of arrays, which is right there and specified. Cool framework, cool written code, but why ??? And permanent forums “How to do? “Go dock!” But damn it,if the same questions arise again and again with different people at different times, it means that something is wrong with this place! In all the forums of all programming languages ​​the same questions are always the same. How to make a user, how to store them, what to hash, how to write a request, and what is finally so, and why is that? .. And now a programmer of one thousand people spends, probably, the hundred billionth global man-hour, to implement the same users storage, then_the same encryption passwords, te_zhe_samy queries to the database, in_tech_zhe_samyh_plakhova connects te_zhe_zamye caches, so that exactly_that_zhe_non_transaction ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedsomething is wrong with this place! In all the forums of all programming languages ​​the same questions are always the same. How to make a user, how to store them, what to hash, how to write a request, and what is finally so, and why is that? .. And now a programmer of one thousand people spends, probably, the hundred billionth global man-hour, to implement the same users storage, then_the same encryption passwords, te_zhe_samy queries to the database, in_tech_zhe_samyh_plakhova connects te_zhe_zamye caches, so that exactly_that_zhe_non_transaction ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedsomething is wrong with this place! In all the forums of all programming languages ​​the same questions are always the same. How to make a user, how to store them, what to hash, how to write a request, and what is finally so, and why is that? .. And now a programmer of one thousand people spends, probably, the hundred billionth global man-hour, to implement the same users storage, then_the same encryption passwords, te_zhe_samy queries to the database, in_tech_zhe_samyh_plakhova connects te_zhe_zamye caches, so that exactly_that_zhe_non_transaction ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedand why is that? .. And now the 100,000th programmer spends, probably, the hundred-billionth global person-hour, to create the same user storage, then the same password encryption, exactly_the_the_the most requests to the database, connect to the_the_the_themstheyes of the database, exactly_the_the_the_the_the_the_the_first_your_to_the_the_the_the_the_the_first_year requests to the database code? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedand why is that? .. And now the 100,000th programmer spends, probably, the hundred-billionth global person-hour, to create the same user storage, then the same password encryption, exactly_the_the_the most requests to the database, connect to the_the_the_themstheyes of the database, exactly_the_the_the_the_the_the_the_first_your_to_the_the_the_the_the_the_first_year requests to the database code? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedto accurately_tak_zhe_ne_tormozilo ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decidedto accurately_tak_zhe_ne_tormozilo ... But what about the praised code reuse? Around that time, the situation described above occurred with coffee, after which I finally and irrevocably decided
So what does the author want, and why all this verbiage?
My most unloved answer to the asked question from the category: “Why is this being done / is this happening exactly?” Is “What do you want?”. For some reason, it seems to me obvious that I meant something else that is different from what is happening, therefore, in fact, I ask. So, please answer a few questions:
- Why do we often use development tools that imply different levels of parsing and parsing at each stage of code execution, first on the server side and then on the client side?
- , - , ?
- -, --- FAQ' , , ?
- CRUD, ( IT-, ) ?
- User/Password Post/Comments - — , , ?
- , , ( __JS_, ) — , 20 , , ? , . , MVC , , , , ?
- , , , ?
- , , , , MVC, -, ? , ?
- - ? - RichWebDataServer, web-, , , , , , ? , . - HTTP_2.0 . MVC, , . , ActionScript, - , plain_text GET|POST. , - X.Org RDP, , , .
It’s time to thank the browsers for their service, long and faithful, and donate them to history museums along with stencils and typewriters, get some modern-fashioned device out of your pocket, and enjoy genuine interactive, built on the triumph of modern technologies, not fragments technology thirty years ago. Just kidding:) But seriously, it’s really time to critically review the entire stack of technologies of the existing web, in my subjective opinion. As for PHP, it’s not going anywhere. I do not exclude that he will find a place in the new web. Especially if enthusiasts stop trying to make a " faster horse ." And the good old simple sites will work on it for a very, very long time.
One more thing. In the questions posed, I deliberately put down the stick in some places and quite consciously expect legitimate criticism. As practice shows, reasoned criticism reveals well the weak points, and there, really, something really useful can be born. The only thing I would ask to refrain from is to comment in the spirit of "what to do with the existing equipment and the army of trained specialists." I am not so naive as to expect an explosive effect with an immediate revolution. In truth, I’m not at all sure that anything in the world will change, but some hope
I thank everyone for their attention and patience while reading this opus. And I apologize for such a voluminous statement. And no, the author is not a schizophrenic. Both of us are absolutely sure of this - both I and the author. :)
Source: https://habr.com/ru/post/186574/
All Articles