🥇1C - Good and evil. Arrangement of points in holivars around 1C

Friends and colleagues, recently on Habré articles with a hatred against 1C as a platform for development, and speeches by its defenders have become more frequent. These articles identified one serious problem: most often, critics of 1C criticize it from the position of “not mastered”, scolding problems that are de facto easily solved, and, on the contrary, not touching on problems that are really important, worth discussing and are not solved by the vendor . I believe that it makes sense to conduct a sober and balanced review of the 1C platform. What she can do, what she can't do, what she should do but doesn't do and, for dessert, what she does with a bang, and your developers at %technology_name% will do hundreds of years, throwing it to the wind more than one annual budget.

As a result, you, as a manager or an architect, will be able to get a clear understanding of what task it will be beneficial for you to take 1C for, and where it should be burned with a red-hot iron. As a developer of the “not 1C” world, you can see what is there in 1C because of which there is fuss. And as a 1C developer, you will be able to compare your system with the ecosystems of other languages and understand your position in the software development coordinate system.

Under the cut - a lot of thick sketches on 1C, on critics of 1C, on Java, .NET and in general ... The fan is fueled, welcome!

About Me

I have known the subject of conversation since about 2004. I have been programming since I was 6 years old, from the very moment I had a book about Professor Fortran with comics about a cat, a sparrow and a caterpillar. I analyzed the programs that the cat wrote from the pictures in the book and found out what they do. And yes, I didn’t have a real computer then, but there was a drawing on the spread of the book and I honestly pressed the paper buttons, entering the commands I had seen from the cat X.

Then there was BK0011 and Basic at school, C ++ and assemblers at the university, then 1C, and then so many things that I’m too lazy to remember. For the last 15 years, I have been mainly engaged in 1C, not only in terms of coding, but in general 1C. Setting tasks, adminstvo and devops here. For the last 5 years I have been doing socially useful activities in terms of developing development and automation tools for other 1C nicknames, writing articles and books.

Decide on the subject of discussion

To begin with, let's decide what will be discussed, since under the letters "1C" you can understand a lot of things. In this case, by the letters "1C" we mean exclusively the development framework "1C: Enterprise" of the modern, eighth version. We will not talk much about the manufacturer and its policies (but we will have to do a little), We will not discuss specific applications written using this framework. Technology is separate, applications aka configuration are separate.

High-level architecture 1C: Enterprise

I don't mention the word "framework" for nothing. From the developer's point of view, the 1C platform is exactly a framework. And you need to treat it exactly like a framework. Think of it as Spring or ASP.NET running some kind of runtime (JVM or CLR respectively). It so happened that in the world of conventional programming (“not 1C”), the division into frameworks, virtual machines and specific applications turns out to be natural, due to the fact that these components are usually developed by different manufacturers. In the world of 1C, it is not customary to explicitly single out the development framework and the actual runtime, in addition, specific applications written using the framework are mainly also developed by the 1C company itself. As a result, there is some confusion. Therefore, within the framework of the article, we will have to consider 1C from several sides at once and classify it along several coordinate axes. And in each coordinate axis we will put a shovel of brown matter and consider the features, advantages and disadvantages of the existing solution.

Points of view on 1C

1C for the buyer

The buyer acquires an automation system on which he can quickly solve the problems of automating his own business. A business can be a small stall, or it can be a large holding. It is clear that the needs of these businesses are different, but both are supported by a single platform code base.

For a 1C buyer, this is a quick time-to-market. Fast. Faster than Java, C# or JS. Average. By the hospital. It is clear that a business card site on react will turn out better, but the backend of the WMS system will launch faster on 1C.

1C as a tool

Each technological solution has limits of applicability. 1C is not a general purpose language, it does not live separately from its framework. 1C is advisable to use when you need:

server application
app for finance
with ready UI, ORM, Reporting, XML/JSON/COM/PDF/YourDataTransferingFormat
with support for background processes and jobs
with role-based security
with scripted business logic
with rapid prototyping and low time-to-market

1C you don't need if you want:

machine learning
GPU calculations
computer graphics
mathematical calculations
CAD system
signal processing (sound, video)
highload http calls with hundreds of thousands of rps

1C as a manufacturer

It is worth understanding what the business of 1C is, as a software manufacturer. Firm 1C sells solutions to business problems through automation. Different businesses, big or small, but that's what she sells. The means to achieve this goal are business applications. For accounting, for payroll accounting, etc. To write these applications, the company uses its own platform for developing business applications. Specially tailored for common tasks of these same business applications:

financial accounting
easy customization of business logic
wide integration opportunities in heterogeneous IT landscapes

As a manufacturer, 1C believes that it is this strategy that allows you to work with partners and customers in win-win mode. You can argue with this, but this is how the company promotes itself: ready-made solutions to business problems that can be quickly customized by partners and built into any IT landscape.

All claims or wishes to 1C as a framework should be considered exclusively through this prism. “We want OOP in 1C,” say the developers. “How much will it cost us to support OOP in the platform, will it help us increase box sales?” says 1C. Opens its "prism" of selling a solution to business problems:

— Hey, business, do you want OOP in your 1C?
Will this help me solve my problems?
- How to know...
- Then you don't need to.

This approach can be good or bad depending on who is looking at it, but that's just the way it is. Speaking about the fact that there is no feature X in 1C, you need to understand that it is not there for a reason, but in the context of the choice “sales cost vs profit size”.

Technological classification

“In fact, one-stoppers use the best patterns carefully selected by caring methodologists and developers of the 1C platform with might and main.
When you write your stupid code for a simple managed form, you are actually using model-view-controller с double-way data binding в three-layered-data-app-engine, flavored high level object-relation-mapping on the base declarative metadata description, which has its own platform-independent query language, C declarative data-driven user interface, complete transparent serialization, and domain-oriented program language.

Where 1C developers differ from Western colleagues is in PR. They love to give any bullshit a big name and rush about with it, like with a hand-written sack.
A. Orefkov

The 1C platform has a classic 3-tier architecture, in the center of which is the application server (or its emulation for little money for small shopkeepers). As a DBMS, either MS SQL or Postgres is used. There is also support for Oracle and IBM DB2, but this is rather esoteric, no one knows what will happen if 1C is implemented on these bases under medium and high load. I suppose the 1C company itself does not know this either.

The client part is either a thin client installed on the user's machine or a web client. The key feature is that programmers do not write 2 different codes, they write one application, in one language, and you can put it in the browser if you want or need it. Who out there wanted a true full stack and a single language for the front and back end, node.js? They haven't been able to do exactly the same. A real full stack exists, but you will have to write in 1C. Irony of fate, such things 🙂

The cloud SaaS solution 1C: Fresh also works in browser mode, in which you can not buy 1C, but rent a small base and keep records of shawarma sales there. Just in the browser, without installing or configuring anything for yourself.

In addition, there is a legacy client, which is called a “regular application” in 1C. Legacy is legacy, welcome to the world of applications in 2002, but we are still talking about the current state of the ecosystem.

The 1C server part supports clustering and scales by adding new machines to the cluster. Quite a few copies have been broken here, and there will be a separate section in the article about this. In short, this is not exactly the same as adding a couple of exactly the same instances behind HAProxy.

The application development framework uses its own programming language, which roughly resembles a slightly improved VB6 translated into Russian. People who hate everything Russian, who do not believe that "if" is translated as "if", the second version of the syntax is offered. Those. if you wish, you can write in 1C in such a way that you can’t distinguish it from VB.

It is this very programming language that is the main reason for the hatred of 1C-nicknames towards their platform. Let's face it, it's not unreasonable. The language was conceived as as simple as possible, designed to fulfill the mantra "DEVELOPERS, DEVELOPERS" on the scale of at least the CIS. The commercial essence of such a solution, in my opinion, is clearly visible: more developers, more market coverage. This came true according to various estimates from 45% to 95%. I’ll say right away that writing in the language you think in is really easier. And I know quite a lot of programming languages.

Let's start with the language.

Programming language 1C

Simultaneously strong and weak point of the system. Provides easy entry, readability. On the other hand, it has not been updated since the release of version 8 in 2002 and is obsolete. Someone will say “the main drawback is that there is no OOP” and will be wrong. Firstly, the PLO does not like not only Nuraliev, but also Torvalds. And secondly, OOP still exists.

From the developer's point of view, he has a framework with base classes displayed on the DBMS. The developer can take the base class "Directory" and inherit the "Clients" reference from it. It can add new class fields to it, for example, TIN and Address, and also, if necessary, it can override the methods of the base class, for example, the OnWrite / On Write method.

The framework is designed in such a way that deeper inheritance is rarely required, and the limitation in OOP makes sense in my opinion. 1C focuses on Domain Driven Development and makes you think, first of all, about the subject area of the solution being developed, and this is good. Not only is there no temptation, but also the need to write 10 different DTOs and ViewModels just to show some data from the domain somewhere. The 1C developer always operates with one entity, without clogging up the context of perception with a dozen classes with similar names representing the same entity, but from the other side. Any .NET application, for example, will necessarily contain a couple of ViewModels and a DTO for serializing to JSON and transferring data from the client to the server. And about 10-15% of your application code will be taken up by transferring data from one class to another with pens or crutches like AutoMapper. This code must be written and programmers paid to create and maintain it.

It turns out that the 1C language is difficult to develop without complicating it to the level of mainstream languages, thus losing the advantage of simplicity. After all, what is the vendor’s task essentially being solved: to issue a standard solution that any student caught on the street can customize with the proper level of quality (i.e., the case of coverage from a stall to a large factory is being fulfilled). If you are a stall - take a student, if you are a factory - take a guru from an implementation partner. That implementation partners sell students at the price of a guru is not a problem with the framework. Architecturally, the framework should solve the problems of both, the code of typical configurations (which we sold to the business with the promise of customization) should be able to be understood by the student, and the guru will understand whatever you want.

What, in my opinion, is really missing in the language, which forces you to write more than you could, something that burns through the time paid by the customer.

The ability to type at the level, for example, TypeScript (as a result, more developed code analysis tools in the IDE, refactoring, fewer offensive jambs)
Having functions as first class objects. A slightly more complicated concept, but the number of standard boilerplate-codes could be greatly reduced. The understanding of the code by the student, IMHO, would even increase by reducing the volume
Generic collection literals, initializers. The same thing - reducing the amount of code that needs to be written and / or viewed with the eyes. Filling collections is over 9000% of programming time in 1C. Writing this without syntactic sugar is long, expensive, and error-prone. In general, the number of LOCs in 1C solutions exceeds all conceivable limits compared to available open frameworks and, in general, all your enterprise Javas combined. The language is verbose, and this degenerates into the amount of data, memory, IDE brakes, time, money ....
finally constructions I have a hypothesis that this construction is missing due to the fact that they did not pick up a successful translation of it into Russian 🙂
Own data types (without OOP), analogues of Type from VB6. Allows you not to type structures using comments in the BSP and magic methods that construct these structures. We get: less code, a hint through a dot, a faster solution to the problem, fewer errors due to typos and missing properties of structures. The typing of custom structures now rests entirely with the Standard Subsystems Library development team, which, to its credit, carefully writes comments on the expected properties of the passed parameter structures.
No sugar when working with asynchronous calls on the web client. callback-hell in the form of NotificationProcessing is a temporary crutch caused by a sudden change in the API of major browsers, but you can’t live like this all the time, the advantage of “student understanding” of asynchronous code is being lost more and more. Throw in no support for this paradigm in the main IDE and things get even worse.

This is one of the pressing problems, it is clear that the list can be much larger, but we must not forget that this is still not a general-purpose language, there is no need for multithreading, lambda functions, access to the GPU and fast floating point calculations. It is a scripting language for business logic.

A programmer who has already worked a lot with this language, looked into js or c #, becomes bored within this language. It is a fact. He needs development. On the other side of the scale, the vendor has the cost of implementing these features vs the increase in revenue after their implementation. Here I have no information about what in the eyes of the company at the moment outweighs.

Development environment

Everything is not smooth here either. There are two development environments. The first is the Configurator included in the delivery. The second is the Enterprise Development Tools, abbreviated as EDT, developed on the basis of Eclipse.

The configurator provides a full range of development tasks, supports all features and is the main environment on the market. It is also morally obsolete, does not develop, according to rumors - because of the amount of technical debt within itself. The situation could be improved by the opening of an internal API (in the form of friendship with snowman A. Orefkov or on an independent basis), but this is not the case. Practice has shown that the community itself will file features in the IDE, so long as the vendor does not interfere. But we have what we have. The configurator was great in 2004-2005, it was very reminiscent of the Visual Studio of those times, in some places it was even cooler, but it was still stuck in those days.

In addition, the volume of the average typical solution has grown several times since then, and today the IDE stupidly cannot cope with the amount of code that it is fed. Usability and refactoring capabilities are not even at zero, they are in the red. All this does not add enthusiasm to developers and they dream of dumping into other ecosystems and continuing to shit-code there, but already in a pleasant environment that does not spit in your face with its behavior.

As an alternative, an IDE written from scratch based on Eclipse is offered. There, the source codes, as in any other software, live in the form of text files, are stored in GIT, pull request branches, all this is here. Of the minuses - for many years it has not left the beta status, although it gets better with each release. I will not write about the cons of EDT, that today is a minus, tomorrow a fixed feature. The relevance of such a description will quickly come to naught. Today, developing in EDT is possible, but unusual, you need to be prepared for a certain number of IDE bugs.

If you look at the situation through the aforementioned "1C prism", you get something like this: the new IDE does not increase sales of boxes, but it will probably reduce the outflow of DEVELOPERS. It is difficult to say what awaits the ecosystem in terms of developer comfort, but Microsoft has already blown away mobile developers once by offering them its services too late.

Development management

Everything is much better here than in writing code, especially recently, when the efforts of the community brought to light the problems of administration automation, launched prototypes calling for throwing the 1C repository into the dump and using git, quick blame, code-review, static analysis, auto-deploy and etc. Many features have been added to the platform that increase the level of automation of development tasks. However, all these features were added only and exclusively for the development of their own large products, when it became obvious that there was no way without automation. There were auto-merges, three-way KDiff comparison and all that. Launched on github gitconverter, which, honestly, was ideologically pulled from the project gitsync, but modified for the processes of the vendor company. Thanks to the stubborn guys from open-source, development automation in 1C has moved off the ground. The open API of the configurator, IMHO, would also shift the moral backwardness of the main IDE.

Today, storing 1C sources in git with linking commits to tasks in Jira, reviews in Crucible, pushing with a button from Jenkins and Allure reports on code testing in 1C, and even static analysis in SonarQube - this is far from news, but rather the mainstream in companies where there is a lot of development on 1C.

Administration

There is a lot to say here. Firstly, it is, of course, the same server (cluster of 1C servers). A wonderful thing, but due to the fact that this is a completely black box, documented in sufficient detail, but in a specific way - overpowering the launch of uninterrupted work in highload mode on several servers is the lot of the elite who wear a medal with the inscription "Technology Expert". It is worth noting that, in principle, the administration of a 1C server does not differ from the administration of any other server. It is a networked, multi-threaded application that consumes memory, CPU, and disk resources. Provides ample opportunities for collecting telemetry and diagnostics.

The problem here is that the vendor does not offer anything special in terms of ready-made solutions for this very diagnostic. Yes, there is 1C: KIP and TsUP, they are even not bad, but they are very paid and not everyone has them. The community has a number of developments on connecting grafana, zabbix, ELK and other things from the typical admin set, but there is no single solution that will suit the majority. The task is waiting for its hero. And if you are a business that plans to launch on a 1C cluster, you need an Expert. Your inside or outside, but you need it. It's normal that there is a separate role with competencies for server operation, not every 1C nickname should know this, you just need to understand that such a role is needed. Let's take SAP as an example. There, the programmer, most likely, will not even get up from his chair if he is offered to configure something on the application server. He can stupidly not know how and he will not be ashamed. In the SAP methodology, there is a separate employee role for this. For some reason, in the 1C industry, it is believed that this should be combined in one employee for the same salary. It's a delusion.

Cons server 1C

There is exactly one minus - reliability. Or, if you like, unpredictability. Sudden oddities in server behavior have already become the talk of the town. A universal remedy - stopping the server and clearing all caches is even described in the expert's handbook and even a batch file is recommended that does this. If your 1C started doing something that it shouldn’t even theoretically do, it’s time to clear the session data cache. In my opinion, there are three people in the whole country who know how to operate the 1C server without this procedure, and they do not share secrets, because. live from it. Perhaps their secret is that they clean session data, but they don't tell anyone about it, geege.

Otherwise, the 1C server is the same application as any other and is administered in much the same way, by reading the documentation and knocking on a tambourine.

Docker

The usefulness of using a containerized 1C server in production has not yet been proven. The server is not clustered by simply adding nodes behind the balancer, which reduces the advantages of production containerization to a minimum, and the practice of successfully operating in containers in highload mode has not been developed. As a result, only developers use docker + 1C to raise test environments. There it is very useful, applied, allows you to play with modern technologies and take a break from the despondency of the configurator.

Commercial component

In terms of investment, 1C allows you to close the task of quickly launching business ideas due to the wide possibilities of application classes. 1C out of the box gives a very decent Reporting, integration with anything, a web client, a mobile client, a mobile application, support for various DBMS, incl. free, cross-platform both server and installed client parts. Yes, the UI of applications will be yellow, sometimes this is a minus, but not always.
By choosing 1C, a business gets a set of software solutions that allow building a very wide range of applications, as well as a lot of developers on the market who want less money than javaists and at the same time produce results faster.

For example, the task of sending a PDF invoice to a client is completed in an hour of student work. The same task on .NET is solved by buying a proprietary library, or a couple of days or weeks of coding by a stern bearded developer. Sometimes, both at once. And yes, I was talking only about PDF generation. We didn't say where this bill would come from. The web frontender must catch up with the form where the operator will drive the data, the backender will have to create dto-models in order to transfer JSON, models for storage in the database, the structure of the database itself, migrations to it, the formation of a graphical display of this account itself, and only then - PDF. On 1C, the whole task is done from scratch in exactly one hour.

A full-fledged accounting system for a small stall with one business process bought / sold is done in 3 hours. With sales reporting, accounting for goods at purchase and sale prices, broken down by warehouses, access rights control, web client and mobile application. Okay, I turned down the application, with the application not in 3 hours, in six.

How long will this task take for a .NET developer from the moment visual studio is installed on a clean computer to the demonstration to the customer? What about development costs? That's the same.

Strengths of 1C as platforms

1C is strong not because it has something specific best in the world. On the contrary, in each individual subsystem you can find a more interesting analogue in the world's software. However, due to the combination of factors, I do not see a platform similar to 1C. This is where commercial success lies. The advantages of the platform are scattered all over it and are most clearly visible when you see how it is done in other platforms. Basically, these are NOT even features, but rather the rejection of features in favor of one particular paradigm. A few examples:

Unicode. What the hell could be easier? It is not necessary to use single-byte ASCII encodings in 2019 (except for integration with dense legacy). Never. But no. Anyway, someone in some table uses a single-byte varchar and the application will have problems with encodings. In 2015, LDAP authorization fell off for gitlab due to incorrect work with encodings, for JetBrains IDE it still does not always work with Cyrillic in file names. In 1C, high-quality isolation of application code from the layer of working with the database. There it is impossible to type tables at a low level and jambs of incompetent juniors at the DB level are impossible there. Yes, other shoals of incompetent juniors are possible there, but the variety of problems is much less. You will now tell me that your application is designed correctly and the database access layer is isolated as it should be. Take another look at your enterprise custom Java application. Closely and honestly. Conscience does not torment? Then I'm happy for you.
Numbering of documents/handbooks. In 1C, it is definitely not the most flexible and not the best. But what they do in banking software and self-written accounting systems - well, this is just darkness. Either identity is stuck (and then “oh, why do we have holes”), or vice versa, they will make a generator that works with a lock at the DBMS level (and will become a bottleneck). In fact, it is quite difficult to make this seemingly simple task - a through enumerator of entities, with a cut of uniqueness for a certain set of keys, prefixed, so that it does not block the database during parallel data entry.
Record IDs in the database. 1C made a strong-willed decision - all link identifiers are absolutely synthetic and that's it. And there are no problems with distributed bases and exchanges. Developers of other systems stubbornly sculpt something like identity (it's shorter!), dragging them into the GUI until it's time to make several related instances (and then they will be discovered). Don't you have one? Honestly?
Lists. In 1C, there are quite successful mechanisms for paging through (large) lists and navigating through them. Immediately make a reservation - with the correct application of the mechanism! In general, the topic is quite unpleasant, it is not ideally solved: it is either intuitive and simple (but the risk of huge recordsets on the client), or one or another paging curvature. Those who do paging often do it crookedly. Those who make an honest scrollbar put the database, channel and client.
managed forms. No doubt, in the web client, the interface does not work perfectly. But it works. But for many other accounting and banking systems, making a remote workplace is an enterprise-level project. Disclaimer: fortunately for those who originally made the web, this will not affect.
Mobile app. Recently, you can also write mobile applications while in the same ecosystem. It’s a little more complicated here than with a web client, the specifics of devices make you write specifically for them, but, nevertheless, you don’t hire a separate team of mobile developers. If you need an application for the company's internal needs (when a mobile solution to a corporate problem is more important than a yellow UI design), just use the same platform out of the box.
Reporting. By this word, I mean not a BI system with big data and a lag on the ETL process. This refers to operational reports of personnel, allowing to assess the state of accounting here and now. Remains, mutual settlements, sorting, etc. 1C comes out of the box with a reporting system with flexible settings for groupings, filters, and visualization on the user's side. Yes, there are better ones on the market. But not within the framework of an all-in-one solution and at a price sometimes higher than an all-in-one solution. And more often it’s even the opposite: only reporting, but more expensive than the whole platform, and worse in quality.
Printed forms. Well, solve the problem of sending payroll in PDF to employees by mail using .NET. And now the task of printing invoices. And with saving their copies in the same PDF? For 1C-nick output to PDF of any layout is +1 line of code. And that means + 40 seconds of working time, instead of days or weeks in another language. Printable form layouts in 1C are amazingly easy to develop and powerful enough to compete with paid counterparts. Yes, probably, there are not so many interactive features in 1C spreadsheet documents, you can’t quickly get a 3D chart with scaling using OpenGL. But is it really necessary?

These are just a handful of examples where limiting functionality or implementing trade-offs proves to be an important architectural advantage in the future. Even a compromise or not the most effective option - it is already in the box and is taken for granted. Its independent implementation will either be impossible (because such decisions must be made at the beginning of the project, and there is no time for that, and there is no architect at all), or several expensive iterations. In each of the listed items (and this is by no means a complete list of architectural solutions), you can mess up and lay restrictions that block scaling. In any case, you, as a businessman, need to make sure that your programmers, when making a "system from scratch", have direct hands and will do fine system moments right away.

Yes, as in any other complex system, 1C itself has solutions in the same way that block scaling in one way or another. However, I repeat, in terms of a combination of factors, in terms of the cost of ownership, in terms of the number of problems already resolved in advance - I do not see a worthy competitor on the market. For the same price, you get a financial application framework, a clustered balanced server, with a UI and a web face, with a mobile application, with reporting, integration and a bunch of other things. In the Java world, you hire a front-end and back-end team, debug low-level jambs of self-written server code, and pay separately for 2 mobile applications for 2 mobile OSes.

I'm not saying that 1C will solve all cases, but for an internal corporate application, when there is no need to brand the UI - what else is needed?

Fly in the Ointment

Probably, there was an impression that 1C will save the world and all other ways of writing corporate systems are wrong. It's not like that at all. From the point of view of a businessman, if you choose 1C, then in addition to the fast time-to-market, you must also take into account the following disadvantages:

Server reliability. Really high-quality specialists are required, capable of ensuring its smooth operation. I am not aware of a ready-made training program for such specialists from the vendor. There are courses to prepare for the "Expert" exam, but this, in my opinion, is not enough.
Support. See previous point. To have support from the vendor, you need to buy it. For some reason, this is not accepted in the 1C industry. And at SAP - it is almost obligatory for acquisition and this does not bother anyone. Without corporate support and without an expert in the state, you can be left alone with 1C glitches.
Still, on 1C you can’t do everything at all. It is a tool and like every tool it has limits of applicability. In a landscape with 1C, it is very desirable to have a "non-1C" system architect.
Good 1C nicknames are not cheaper than good programmers in other languages. Although, bad programmers are expensive to hire regardless of the language they write in.

Let's dot

1C is a framework for rapid application development (RAD) for business and is tailored for this.
Three links with support for the main DBMS, client UI, a very good ORM and reporting
Ample opportunities for integration with systems that can do what 1C does not. If you want machine learning, take Python, and merge the result into 1C via http or RabbitMQ
No need to strive to do everything on 1C, you need to understand its strengths and use them for your own purposes
Developers who gravitate towards digging into technological gadget frameworks and reworking every N years with a new engine are bored in 1C. Everything is very conservative there.
Developers are also bored due to very little care for them on the part of the manufacturer. Boring language, weak IDE. They require modernization.
On the other hand, developers who can't find fun by applying and learning another technology they like are bad developers. They will whine and move on to another ecosystem.
Employers who do not allow their 1C nicknames to file something in Python are bad employers. They will lose employees with an inquisitive mind, and in their place will come monkey-coders who, being in agreement with everything, will drag corporate software into the swamp. It will still have to be rewritten, so maybe it would be better to invest in Python a little earlier?
1C is a commercial company and implements features solely on the basis of its own interests and expediency. You can’t blame her for this, business must think about profit, such is life.
1C earns by selling solutions to business problems, not to the problems of the developer Vasya. These two concepts are correlated, but the priority is exactly what I said. When the developer Vasya becomes ready to pay for a personal license for 1C: Resharper, he will appear quite quickly, A. Orefkov's Resharper is a confirmation of this. If the vendor supported it, and did not fight it, you might see a market for software for developers. Now there are one and a half players in this market with dubious results, and all due to the fact that integration with the IDE is negative and everything is done on crutches.
The practice of a multi-machine specialist will go into oblivion. Modern applications are too large to be remembered from both the code side and the business use side. The 1C server is also becoming more complicated; it will be impossible to keep all types of expertise in one employee. This should entail the demand for specialists, which means the attractiveness of the 1C-nick profession and the growth of salaries. If earlier Vasya worked three-in-one for one salary, now you need to hire two Vasya and competition among Vasya can spur the overall growth of their level.

Conclusion

1C is a very worthy product. In my price range, I don’t know any analogues at all, write in the comments if there are any. However, the outflow of developers from the ecosystem is becoming more and more noticeable, and this is a “brain drain”, whatever one may say. The industry is in need of modernization.
If you are a developer, do not get hung up on 1C and do not think that everything is magical in other languages. As long as you're June - maybe. As soon as you need to solve something bigger, you will have to look for ready-made solutions longer and finish them more intensively. In terms of the quality of the "cubes" from which you can build a solution - 1C is very, very good.

And one more thing - if a 1C-nickname came to you to be hired, then 1C-nickname can be safely put in the position of a lead analyst. Their understanding of the task, the subject area, and decomposition skills are excellently developed. I am sure that this is precisely due to the forced use of DDD in development on 1C. A person is trained to think about the meaning of the task in the first place, about the relationships between the objects of the subject area, while having a technical background in integration technologies and data exchange formats.

Be aware that the perfect framework does not exist and take care of yourself.
All good!

PS: thanks a lot speshuric for help in preparing the article.

Only registered users can participate in the survey. Sign in, you are welcome.

Do you have 1C at the enterprise?

13,3%Not at all.71
30,3%There is, but only in the accounting department somewhere. Core systems on other platforms162
41,4%Yes, the main business processes work on it221
15,0%1C must die, the future is %technology_name%80

534 users voted. 99 users abstained.

Source: habr.com

1C - Good and evil. Arrangement of points in holivars around 1C