Ways of development of Internet technologies
IBM has just announced the release of the IBM Lotus Symphony office suite. Sounds like another StarOffice option ( Sun Microsystems' free office suite). But I suspect that they are trying to erase the original version of Lotus Symphony, which is presented and promoted almost less than the new coming of Christ, but in the end it turned out to be rather faded.
In the late 80s, Lotus tried to decide what to do next with their main product for working with tabular data and graphics - Lotus 1-2-3. There were 2 obvious ways: first, they could just add new functionality. For example, work with text. This product was called Symphony. Another obvious idea was to create a program for working with 3-dimensional tables. So 1-2-3 became version 3.0.
Both ideas quickly came up against a serious problem: the old memory limit in DOS at 640K. IBM just started producing computers with 80286 chips that could address more memory, but Lotus did not think the market was wide enough for software that required $ 10,000 computers. Therefore, they were squeezed and squeezed. They spent 18 months trying to get Lotus 1-2-3 to work in DOS with its limitation of 640K of RAM, and eventually, after a heap of time spent, were forced to abandon the functionality of working with 3-dimensional tables in order to fit your product under the limitation of RAM. In the case of Symphony, they just chopped off the functionality left and right.
')
None of the strategies turned out to be correct. By the time Lotus 123 3.0 was released, everyone had an 80386 processor and 2M of RAM. And Symphony had a non-modern mechanism for working with tables and working with text and some other obsolete things.
“Well, okay, mate,” you say. “Who cares about some old programs?”
But give me a minute, because history repeats itself again and again, and the smart strategy is to make a bet that the same results will repeat again.
From the beginning of time to, say, 1989, programmers were very concerned about performance issues. Because, computers simply did not have much memory and high performance of the processor.
In the late 90s, a couple of companies, including Microsoft and Apple, noticed (a little earlier than all the others) that Moore's law means that they should not pay too much attention to performance and memory savings ... just create good products, and wait for the appearance of iron, on which it will all work. Microsoft first released Excel for Windows when the 80386s were too expensive for most users, but they were patient. 80386SX came out no longer than 2 years later, and anyone who was able to afford to allocate $ 1500 could work in Excel.
As a programmer, I say thanks to the lower price of RAM. And the number of CPU cycles doubled every year, you have a choice. You could spend 6 months rewriting your internal cycles in Assembler or better for 6 months pounding the drums in a rock band, and in either case, your program will work faster. Programmers in Assembler have ceased to be popular.
So now we no longer care too much about optimization and performance.
In addition to one point: JavaScript, running on browsers in Ajax applications. And for some time this is the direction in which almost all software developers are moving, because this is a big deal.
Many of today's Ajax programmers have megabytes, or even more client-side code. At the same time, this is not a RAM or a processor creates a restriction: this is the load time on a limited network channel, and the compile time. In any case, you really have to squeeze in order to create good complex Ajax applications.
However, the story repeats. Broad internet channels are becoming cheaper. People think about how to create precompiled JavaScript.
Developers who invest a lot of time in optimization, compacting and speeding up will wake up one day and find that the effort has been wasted, or at least you can say that it didn’t give them significant advantages "if you are one of those people speak the language of economists.
Developers who did not pay attention to performance and preferred to add cool and comfortable things to their applications over long distances will have the best applications.
The C programming language was invented with the explicit goal of simplifying the transition of applications from one instruction to another. And this allowed us to make a huge step forward. But it did not create a 100% portable language, so we got Java, which was even more portable than C. Mmmm ...
Right now there is a huge gap in portability history. And this is Taadaaam! - The client side of JavaScript, especially DOM (Document Object Model) in Web browsers. Writing applications that should work in all existing different browsers is just a nightmare. There is no alternative, except how to fully test in Firefox, IE6, IE7, Safari, and Opera, and you know what? I do not have time to test on Opera. Opera sucks. Startups have no way to the browser market.
And how will the situation develop further? Well, well, you can try to beg Microsoft and Firefox to be more compatible. Good luck with that. You can follow p-code / Java models and create sandboxes (sandbox) - a superstructure above the internal system. But this is not the best option. Sandboxes are slow and sloppy, which is why Java applets die. To create a sandbox, your sentence is to work at 1/10 of the speed of the platform on which you created the add-in. And your fate is that you can never use the functions that are on some platforms, but not on others. (I'm still waiting for at least one person who will show me a Java applet for phones that can access any function on the phone, such as a camera, a list of contacts, SMS messages or a GPS receiver).
Sandboxes have never worked and they do not work now.
And what will happen next? Leaders go the way that worked at Bell Labs in 1978: build a programming language like C, which would be portable and efficient. It should compile (compile down) into native code (native code that would be JavaScript and DOM) with different backends for different platforms, where the compiler developers would take care of the performance, and you would not have to do it. Such a language will have all the power of pure JavaScript with full access to the Document Object Model (DOM). And it will be compiled into the native languages ​​of IE and Firefox flexibly and automatically. And yes, it will enter your CSS in a frightening, but logical way, so that you never again have to think about the inconsistencies of different browsers when working with CSS. Forever and ever! Oh pleasure, when finally this day comes.
The IBM 360 system used a user interface called CICS, which you can still meet at the airport when you pass the checkout. There are 80 characters on 24 characters green screen, and only text mode is natural. The main system (mainframe) sends the form to the client (the client is the 3270th terminal). The terminal is smart; He knows how to display the form and give you the opportunity to enter data without interacting with the main system. This was one of the reasons why the mainframe systems were much more powerful than Unix: the central processor did not have to manage the editing of individual lines, it was entrusted to a smart terminal. (If you couldn’t afford to install smart terminals for everyone, you would buy System / 1 - a minicomputer that is installed between the terminals and the main system and controls the editing process).
In any case, after you have filled out the form, you click “Submit” and your answer is sent to the server for processing. And then the server sends you the following form. And so on and so forth.
Horror. How do you create a word processor in this type of environment? (You really can't. And in fact, there has never been a decent word processor for such systems).
This was the first level. It reportedly corresponds to the HTML phase of the Internet. HTML is the same CICS, only with fonts.
At the second level, everyone buy a PC for their desktop, and of course, programmers were able to shove text anywhere on the screen where they wanted and when they wanted it, and you really could read every keystroke from the user when he typed. Thus, you could create great fast applications that don’t have to wait until you click on the “Send” button before the processor can begin processing the data. For example, you could create a word processor that automatically ended a line by moving words down to the next line. At once! Oh my God. Can you do that?
The problem at the second level was that there were no clear user interface standards ... programmers had too much flexibility, so everyone wrote in his own way, which created great difficulties. If you knew how to use X, you also used Y. WordPerfect and Lotus 1-2-3 had completely different menu systems, keyboard interfaces, and command structures. And about copying data between him was not even a question.
And this is exactly where we are using Ajax to date. Of course, the convenience is much more than with the first generation of DOS applications, because we have learned some things since then. But Ajax applications can be incompatible and have many problems to work together - you cannot cut an object from one Ajax application and paste it into another, for example. Therefore, I'm not sure that you can transfer the image from Gmail to Flickr. Come on guys! The cut-paste method was invented 25 years ago.
The third phase with personal computers was Macintosh and Windows. A standard, consistent user interface with such functionality as many windows on the screen and a clipboard created so that applications can work together. We gained tremendous usability and power from these new graphical user interfaces, which led to the very rapid spread of personal computers.
So, if the story repeats itself again, we can expect some standardization in the Ajax interfaces of the applications, so that the development will take place in the same way as when we received Microsoft Windows. Someone is going to write an SDK (Software Development Kit) that can be used to create powerful Ajax applications with common user interface elements that work well together. And such an SDK will win over the minds of most developers and gain the same competitive advantage that Microsoft gained by creating its Windows with its API.
If you are a web developer and you don’t want to adhere to the SDK standards that everyone else’s adhere to, you will meet more and more people who don’t want to use your web application because it doesn’t allow you to cut and paste and don’t allow synchronize with the address book and does not support any other functionality that we will have in 2010.
Imagine, for example, that you are a Google with your GMail, and you feel a growing complacency. But soon, someone you have never heard of, some beginner start-up may have made ridiculous attempts to distribute a new SDK, which integrates a good portable programming language that compiles into JavaScript, and even more, a huge library of Ajax chips. . Not just cut-and-paste: cool, exciting things, such as synchronization and identity management from a single point (single-point identity management), so you don’t need to tell Facebook and Twitter what you are doing, you can just log in through a single point. And you laugh at them because the new SDK has a frightening size of 232 megabytes ... 232 megabytes! JavaScript alone and takes 76 seconds to load the page. And your application, GMail will not lose its customers.
But then, when you see on your owl a guugl-chair in a gugle-plex, sipping your own guuglino and feeling arrogant, arrogant, arrogant, new versions of browsers come out that support caching, compiled javascript. And of course the new SDK is now really fast. And Paul Graham gives them 6000 more boxes of instant noodles to eat, so they stay in business for another three years to improve what they have started.
And your programmers say that GMail is too huge and they cannot port it to this stupid new SDK. They would have to change every line of code. Therefore, it must be completely rewritten, the entire software is confused and contains many recursions and the portable programming language contains so many parentheses that even Google cannot buy. The last line of almost each of the functions contains 3396 right parentheses. You need to hire a special editor to count them.
People using the new SDK have already developed a decent word processor. And a decent mail system. And a damning Facebook / Twitter event publisher that can sync with everything, so people started using it.
And while you do not pay attention, everyone starts writing in the new SDK applications, and they are really good, and, of course, business, only applications written on the new SDK want. And all these old-fashioned, primitive Ajax applications look pathetic and cannot even perform a cut-paste and synchronize operation and interact well with each other. And GMail becomes a legacy of the past. WordPerfect from email. And you will tell your children how delightful you felt when you received 2GB of disk space to store mail, and they will laugh at you.
An improbable tale? Replace “Google Gmail” with “Lotus 1-2-3”. New SDK will be the second coming of Microsoft Windows. This is exactly how Lotus lost control of the tabular data market. And it will happen again on the Web, because in all of this is the same dynamic. The only thing that we do not yet know is the details, but it will happen.
This article appeared on the Joel on Software homepage. Here I posted my translation.
What do you think?
In the late 80s, Lotus tried to decide what to do next with their main product for working with tabular data and graphics - Lotus 1-2-3. There were 2 obvious ways: first, they could just add new functionality. For example, work with text. This product was called Symphony. Another obvious idea was to create a program for working with 3-dimensional tables. So 1-2-3 became version 3.0.
Both ideas quickly came up against a serious problem: the old memory limit in DOS at 640K. IBM just started producing computers with 80286 chips that could address more memory, but Lotus did not think the market was wide enough for software that required $ 10,000 computers. Therefore, they were squeezed and squeezed. They spent 18 months trying to get Lotus 1-2-3 to work in DOS with its limitation of 640K of RAM, and eventually, after a heap of time spent, were forced to abandon the functionality of working with 3-dimensional tables in order to fit your product under the limitation of RAM. In the case of Symphony, they just chopped off the functionality left and right.
')
None of the strategies turned out to be correct. By the time Lotus 123 3.0 was released, everyone had an 80386 processor and 2M of RAM. And Symphony had a non-modern mechanism for working with tables and working with text and some other obsolete things.
“Well, okay, mate,” you say. “Who cares about some old programs?”
But give me a minute, because history repeats itself again and again, and the smart strategy is to make a bet that the same results will repeat again.
Limiting memory and processor power.
From the beginning of time to, say, 1989, programmers were very concerned about performance issues. Because, computers simply did not have much memory and high performance of the processor.
In the late 90s, a couple of companies, including Microsoft and Apple, noticed (a little earlier than all the others) that Moore's law means that they should not pay too much attention to performance and memory savings ... just create good products, and wait for the appearance of iron, on which it will all work. Microsoft first released Excel for Windows when the 80386s were too expensive for most users, but they were patient. 80386SX came out no longer than 2 years later, and anyone who was able to afford to allocate $ 1500 could work in Excel.
As a programmer, I say thanks to the lower price of RAM. And the number of CPU cycles doubled every year, you have a choice. You could spend 6 months rewriting your internal cycles in Assembler or better for 6 months pounding the drums in a rock band, and in either case, your program will work faster. Programmers in Assembler have ceased to be popular.
So now we no longer care too much about optimization and performance.
In addition to one point: JavaScript, running on browsers in Ajax applications. And for some time this is the direction in which almost all software developers are moving, because this is a big deal.
Many of today's Ajax programmers have megabytes, or even more client-side code. At the same time, this is not a RAM or a processor creates a restriction: this is the load time on a limited network channel, and the compile time. In any case, you really have to squeeze in order to create good complex Ajax applications.
However, the story repeats. Broad internet channels are becoming cheaper. People think about how to create precompiled JavaScript.
Developers who invest a lot of time in optimization, compacting and speeding up will wake up one day and find that the effort has been wasted, or at least you can say that it didn’t give them significant advantages "if you are one of those people speak the language of economists.
Developers who did not pay attention to performance and preferred to add cool and comfortable things to their applications over long distances will have the best applications.
Portable (portable) programming language.
The C programming language was invented with the explicit goal of simplifying the transition of applications from one instruction to another. And this allowed us to make a huge step forward. But it did not create a 100% portable language, so we got Java, which was even more portable than C. Mmmm ...
Right now there is a huge gap in portability history. And this is Taadaaam! - The client side of JavaScript, especially DOM (Document Object Model) in Web browsers. Writing applications that should work in all existing different browsers is just a nightmare. There is no alternative, except how to fully test in Firefox, IE6, IE7, Safari, and Opera, and you know what? I do not have time to test on Opera. Opera sucks. Startups have no way to the browser market.
And how will the situation develop further? Well, well, you can try to beg Microsoft and Firefox to be more compatible. Good luck with that. You can follow p-code / Java models and create sandboxes (sandbox) - a superstructure above the internal system. But this is not the best option. Sandboxes are slow and sloppy, which is why Java applets die. To create a sandbox, your sentence is to work at 1/10 of the speed of the platform on which you created the add-in. And your fate is that you can never use the functions that are on some platforms, but not on others. (I'm still waiting for at least one person who will show me a Java applet for phones that can access any function on the phone, such as a camera, a list of contacts, SMS messages or a GPS receiver).
Sandboxes have never worked and they do not work now.
And what will happen next? Leaders go the way that worked at Bell Labs in 1978: build a programming language like C, which would be portable and efficient. It should compile (compile down) into native code (native code that would be JavaScript and DOM) with different backends for different platforms, where the compiler developers would take care of the performance, and you would not have to do it. Such a language will have all the power of pure JavaScript with full access to the Document Object Model (DOM). And it will be compiled into the native languages ​​of IE and Firefox flexibly and automatically. And yes, it will enter your CSS in a frightening, but logical way, so that you never again have to think about the inconsistencies of different browsers when working with CSS. Forever and ever! Oh pleasure, when finally this day comes.
High interactivity and user interface standards.
The IBM 360 system used a user interface called CICS, which you can still meet at the airport when you pass the checkout. There are 80 characters on 24 characters green screen, and only text mode is natural. The main system (mainframe) sends the form to the client (the client is the 3270th terminal). The terminal is smart; He knows how to display the form and give you the opportunity to enter data without interacting with the main system. This was one of the reasons why the mainframe systems were much more powerful than Unix: the central processor did not have to manage the editing of individual lines, it was entrusted to a smart terminal. (If you couldn’t afford to install smart terminals for everyone, you would buy System / 1 - a minicomputer that is installed between the terminals and the main system and controls the editing process).
In any case, after you have filled out the form, you click “Submit” and your answer is sent to the server for processing. And then the server sends you the following form. And so on and so forth.
Horror. How do you create a word processor in this type of environment? (You really can't. And in fact, there has never been a decent word processor for such systems).
This was the first level. It reportedly corresponds to the HTML phase of the Internet. HTML is the same CICS, only with fonts.
At the second level, everyone buy a PC for their desktop, and of course, programmers were able to shove text anywhere on the screen where they wanted and when they wanted it, and you really could read every keystroke from the user when he typed. Thus, you could create great fast applications that don’t have to wait until you click on the “Send” button before the processor can begin processing the data. For example, you could create a word processor that automatically ended a line by moving words down to the next line. At once! Oh my God. Can you do that?
The problem at the second level was that there were no clear user interface standards ... programmers had too much flexibility, so everyone wrote in his own way, which created great difficulties. If you knew how to use X, you also used Y. WordPerfect and Lotus 1-2-3 had completely different menu systems, keyboard interfaces, and command structures. And about copying data between him was not even a question.
And this is exactly where we are using Ajax to date. Of course, the convenience is much more than with the first generation of DOS applications, because we have learned some things since then. But Ajax applications can be incompatible and have many problems to work together - you cannot cut an object from one Ajax application and paste it into another, for example. Therefore, I'm not sure that you can transfer the image from Gmail to Flickr. Come on guys! The cut-paste method was invented 25 years ago.
The third phase with personal computers was Macintosh and Windows. A standard, consistent user interface with such functionality as many windows on the screen and a clipboard created so that applications can work together. We gained tremendous usability and power from these new graphical user interfaces, which led to the very rapid spread of personal computers.
So, if the story repeats itself again, we can expect some standardization in the Ajax interfaces of the applications, so that the development will take place in the same way as when we received Microsoft Windows. Someone is going to write an SDK (Software Development Kit) that can be used to create powerful Ajax applications with common user interface elements that work well together. And such an SDK will win over the minds of most developers and gain the same competitive advantage that Microsoft gained by creating its Windows with its API.
If you are a web developer and you don’t want to adhere to the SDK standards that everyone else’s adhere to, you will meet more and more people who don’t want to use your web application because it doesn’t allow you to cut and paste and don’t allow synchronize with the address book and does not support any other functionality that we will have in 2010.
Imagine, for example, that you are a Google with your GMail, and you feel a growing complacency. But soon, someone you have never heard of, some beginner start-up may have made ridiculous attempts to distribute a new SDK, which integrates a good portable programming language that compiles into JavaScript, and even more, a huge library of Ajax chips. . Not just cut-and-paste: cool, exciting things, such as synchronization and identity management from a single point (single-point identity management), so you don’t need to tell Facebook and Twitter what you are doing, you can just log in through a single point. And you laugh at them because the new SDK has a frightening size of 232 megabytes ... 232 megabytes! JavaScript alone and takes 76 seconds to load the page. And your application, GMail will not lose its customers.
But then, when you see on your owl a guugl-chair in a gugle-plex, sipping your own guuglino and feeling arrogant, arrogant, arrogant, new versions of browsers come out that support caching, compiled javascript. And of course the new SDK is now really fast. And Paul Graham gives them 6000 more boxes of instant noodles to eat, so they stay in business for another three years to improve what they have started.
And your programmers say that GMail is too huge and they cannot port it to this stupid new SDK. They would have to change every line of code. Therefore, it must be completely rewritten, the entire software is confused and contains many recursions and the portable programming language contains so many parentheses that even Google cannot buy. The last line of almost each of the functions contains 3396 right parentheses. You need to hire a special editor to count them.
People using the new SDK have already developed a decent word processor. And a decent mail system. And a damning Facebook / Twitter event publisher that can sync with everything, so people started using it.
And while you do not pay attention, everyone starts writing in the new SDK applications, and they are really good, and, of course, business, only applications written on the new SDK want. And all these old-fashioned, primitive Ajax applications look pathetic and cannot even perform a cut-paste and synchronize operation and interact well with each other. And GMail becomes a legacy of the past. WordPerfect from email. And you will tell your children how delightful you felt when you received 2GB of disk space to store mail, and they will laugh at you.
An improbable tale? Replace “Google Gmail” with “Lotus 1-2-3”. New SDK will be the second coming of Microsoft Windows. This is exactly how Lotus lost control of the tabular data market. And it will happen again on the Web, because in all of this is the same dynamic. The only thing that we do not yet know is the details, but it will happen.
This article appeared on the Joel on Software homepage. Here I posted my translation.
What do you think?
Source: https://habr.com/ru/post/50433/
All Articles