Writing code in Russian. Pros and cons of such a programme. - page 3

 
Реter Konow:

1. How many years have you been programming?

11 apart from uni.

2. Have you ever tried (for yourself) to write a program in Russian?

Of course.

The question is: do the stereotype exist and are we not hostage to it?

It is a question of attitude. I prefer to write in English because it is more convenient for me in every way. Supportive, concise, confusing, communicative.

I would even say that your reluctance to write in English is a stereotype, fuelled by an unwillingness to learn English properly.

 

If external variables are in Russian, you might run into ?????? if there is no font on the system, e.g. on the server.

1C - yes, Russian is somehow more familiar there. But in other languages only English (once in the late 90's tried "Russian-language" Visual Basic, since then I have cured myself).

 
Initially, compilers did not understand variable and function names written in non-Roman characters at all. The compilers initially did not understand variable and function names written in non-Latin characters.
 
Nikolay Demko:

Well, you can write in Russian in OOP as well.

What is the essence of the cutoff for rejecting OOP?

The essence of OOP is that the programmer can set the scope of variables. If you ignore this, what do you gain?

You constantly have to use new counters, and new variables, because you no longer control the scope.

Names have to be written longer with suffixes and prefixes.

You lose the ability to reuse code (one of the pillars of OOP).

That's not all of course, but in brief.

Which approach do you prefer?

And by the way, if you're developing a program rather than just typing in text, the ability to transform is important. With OOP, you only have to rewrite one bible. With other approaches, you must modify the entire program.

You can also write in Russian using OOP. I agree. However, I have my own claims concerning the OOP. The claimed effectiveness of this method was completely disproved in my practice and I rejected this approach as ineffective. Really, OOP allows you to "humanize" a program language but it fills it with unnecessary entities the machine does not need at all. It turns out even more - these entities are not really needed by a human and one can do without them. Are you talking about the scope of variables? Organize your variables in a global three-dimensional array. Call each field of this array a class, and each row of fields, let's say, an enumeration. Localising the value of each variable would be very easy, as would accessing it...

We need to think about transformation... There is an idea to make a universal software engine, which will work with a logical core. The logic chains will be prescribed in the kernel. The engine will use the kernel to access functions by their indexes. This will be very easy to transform.

 
Реter Konow:
Look at advanced C++. It feels as if this programming language has already acquired its own slang... There's probably no other language that has such a jumble of entities. If you do some research and leave only the essentials in it, it will shrink by several times. Consequently, it would become more comprehensible and accessible to most people. However, I have the feeling that someone doesn't want this language to become understandable and accessible to everyone and therefore complicates it immensely...

A lot of features are layered in C++. It is still the main system language and to be able to write anything you want, various features have been preserved in it.

From ACMe to OpenCL and thread management.

If you want pure OOP, welcome to C#.

 
The topic starter probably just hasn't fully understood the benefits of OOP as opposed to the previously adopted procedural programming method. Before the procedural method, programs were written using unconditional jump operators. And programs written this way were very difficult to debug and trace the logic of their work, they were even called "spaghetti dish".
 
Vitalii Ananev:
The topic starter probably just hasn't fully understood the benefits of OOP as opposed to the former procedural programming method. Before the procedural method, programs were written using unconditional jump operators. And programs written in such a way were very difficult to debug and to trace the logic of their work, they were even called "spaghetti dish".
Yes, Goto is a real bummer.
 

The principle of my approach is as follows:

1. we index calls to software functions. We divide the functions themselves into those that check events (logical functions, - return yes/no), procedural functions (executive functions), and computational functions.

2. Create the logical core in the form of a global three-dimensional array. We prescribe in it indexes of logical functions in a certain hierarchy (division by the importance of events that they check: global and local events). We create a kind of perimeters of these events in the kernel field.

3. We index procedural and computational functions at the ends of logical chains.

4. Create a logic engine that loops around the perimeter events in the kernel at timer frequency and calls the required functions via their indices.

5. Rebuild the program will only consist of rebuilding specific logical chains or building new ones.

 
Комбинатор:
11 apart from uni.
Of course.

A question of attitude. I prefer to write in English as it is more convenient for me in every way. Support, brevity, search for misunderstandings, community.

I would even say that your reluctance to write in English is a stereotype, fuelled by an unwillingness to learn English properly.

I read Dostoevsky in English. That's not the point at all... Russian is more convenient for me in programming on a genetic level.
 
Реter Konow:
I read Dostoevsky in English. That's not the point at all... Russian is easier to program on a genetic level for me.

No problem, the 47th chromosome is power.

OOP was created by the smartest people, professors. They spent years refining and modifying it to suit the needs of programmers, so that it would be most convenient to write programs.

MQ's OOP is also refined in terms of code safety.

Want to become a prophet of the new religion? No problem, after all, it is your time.