LINUX.ORG.RU

Гради Буч - о средствах разработки и их будущем


0

0

По ссылке вы найдете замечательное интервью с Гради Бучем.

Гради Буч (Grady Booch), главный исследователь корпорации Rational Software, признан всем международным сообществом разработчиков программного обеспечения благодаря его основополагающим работам в области объектно-ориентированных методов и приложений, а также благодаря созданию языка UML. Гради - постоянный автор в таких журналах, как "Object Magazine" и "C++ Report" и автор многих бестселлеров, посвященных объектно-ориентированному проектированию и разработке программ. Гради Буч участвует в написании серии "Разработка объектно-ориентированного программного обеспечения" ("Object-oriented Software Engineering Series"), издаваемой Addison-Wesley Longman.

P.S. Большая благодарность TanaT за интервью.

>>> Подробности

★★★★★

Проверено: maxcom

Re: Авторегулирование подкачки подсистемы виртуальной памяти

"Первое издание книги использовало несколько языков, но во время работы над вторым изданием именно С++ был самым популярным языком (Java тогда еще не набрала обороты). У меня хорошие связи с Бьярном Строуструпом - мы читали серию лекций вместе. Этот опыт, а также спрос со стороны отрасли позволили мне использовать только С++ в своих примерах. В третьем издании все примеры будут на Java."

"C++ будет по-прежнему широко распространен, слишком много уже написано на этом языке, да и программисты на языке С при переходе на объектно-ориентированный язык выбирают С++. Java, правда, забрала часть пользователей С++, но ничего не указывает на скорую гибель С++."

Я всё искал упоминания C++. Насколько, однако, сильна инерция ! Я недавно ощутил, что C++ уже давно некрасив ;) Думаю, не я первый. И потому мне интересно, что же может прийти на смену. Кто-то скажет: Jave/C#. Да, но неужели тотлько это ?

Буч от высказываний на эту тему упорно воздерживается, а жаль.

yakuza ()

Re: Гради Буч - о средствах разработки и их будущем

А чё... красивые картинки... :)

anonymous ()

Re: Re: Авторегулирование подкачки подсистемы виртуальной памяти

Мне вот надо написать интерпретатор одного языка моделирования на Java. С одной стороны все довольно не плохо, но чем дальше, тем больше я убеждаюсь, что C++ намного красивее и удобнее. А то что память надо руками распределять, так это скорее плюс, если есть опыт программирования, тем более, что в Java выделять память все равно руками надо, а их HotSpot не такой уж и горячий. А вообще, вопрос C vc Java (в широком смысле) очень продробно рассмотен у Кнута. Он 20 лет назад все грабли счетчиков ссылок и чборщиков мусора разобрал. Все равно, если писать что-то числожевательное, то Java или C# будут мешать, а не помогать.

Shaman007 ★★★★★ ()

Re: Гради Буч - о средствах разработки и их будущем

>Но самым любимым языком остается Smalltalk.
respect.

P.S. C++ в утиль.

anonymous ()

Re: Re: Гради Буч - о средствах разработки и их будущем

>P.S. C++ в утиль.

Главная концепция С++ это дать эффективность С + строгую типизацию + параметризаця типов при этом ни на чем не настаивать (доверять программисту) все опции без которых можно жить и за который приходится расплачиватся эффективностью лежат в библиотеках например сборщик мусора

У Java подход другой: 99%переносимость + жесткая модель защиты при этом зарание жертвуя эффективностю например жостко включая сборшика мусора или размещая все обекты в динамической памяти

Так что каждый выбирает САМ

З.Ы чтобы сравнивать языки программирования нужно быть экспертом в кажном из них ,а на это потребуется ~5-10лет на каждый :)

anonymous ()

Re: Re: Re: Гради Буч - о средствах разработки и их будущем

>P.S. C++ в утиль.

НЕ согласен. С++ еще повоюет, и это в основном благодаря *nix системмам и их бурному распространению. Но на самом деле прав был тот безымянный автор, который сказал, что " самый лучший язык программирования - это тот, на котором ты мыслишь и которым ты лучше владеешь". Для меня это С с небольшими вкраплениями С++ (то есть не люблю я пихать классы куда надо и не надо, а пихаю только когда надо). Так что люби smalltalk, если тебе он привычней. Но на другие языки не кати. В конце концов, пользователь глубоко насрать на язык, на котором написана прога.

P.S.: Пока жив Linux, C/C++ будет жить!

LONGOBARD ()

Re: Гради Буч - о средствах разработки и их будущем

Самое забавное, что Rational при таких монстрах во главе выдает кривое и корявое ПО.

ARia

anonymous ()

Re: Re: Re: Re: Гради Буч - о средствах разработки и их будущем

Почти со всем согласен. Только пользователю не все равно. Язык - на многое влияет. На скорость например (полетел булыган в огород Жабки), на переносимость (ответный булыган из того же огорода). На возможность поддержки, расширения, сопровождения (орлиным взором окидывается широчайший рынок, полный разработчиков на smalltalk - и сравнивается со слабым выбором специалистов по Коболу).

И еще - униховые системы распространены скорее широко, чем бурно:)

svu ★★★★★ ()

Re: Гради Буч - о средствах разработки и их будущем

Степанов с generic progaming намного круче. Только русский, хотя и иммигрант, и поэтому не такой известный.

http://www.stlport.org/resources/StepanovUSA.html

ООП - дрянь.

anonymous ()

Re: Re: Гради Буч - о средствах разработки и их будущем

> Самое забавное, что Rational при таких монстрах во главе выдает кривое и корявое ПО.

Этих монстров-теоретиков во главе с Бучем надо гнать погаными трусами.

Сами програмировать не умеют, и других научить не могут - ихняя контора выдает такое глючное bloatware, которое еще поискать нужно. Единственная поделка, более-менее пригодная к использованию - ClearCase, да и тот, во-первых, куплен, а во-вторых, тормозит.

Все их ПО ориентировано не на программистов, а на начальство, начитавшееся правильных умных книжек про RUP.

pitekantrop ★★★ ()

Re: Re: Re: Re: Гради Буч - о средствах разработки и их будущем

>Пока жив Linux, C/C++ будет жить!

C - это совсем другая песня. А по поводу плюсов - как Linux связан с плюсами? У меня стоит RH9, есть подозрение, что при 1-2 Гб инсталляции плюсовых программ - кот наплакал.

anonymous ()

Re: Гради Буч - о средствах разработки и их будущем

C++ это просто ужасный язык. Беда в том, что лучше ничего нет.

Shaman007 ★★★★★ ()

Re: Гради Буч - о средствах разработки и их будущем

>Хотя Eclipse заставляет меня все больше и больше переосмысливать свой выбор >Java. Он мне нравится больше, чем Java

чего то я непонял: Eclipse это ж среда разработки а Java язык :-\

anonymous ()

Посоветуйте аналог Dreaweaver для linux

>>C++ это просто ужасный язык. Беда в том, что лучше ничего нет.
Это как посмотреть, последние десять лет просто расцвет новых языков программирования :
Eifel,Lua,Python,Ruby,...
Просматривается следующая тенденция:
Сложные типы данных (списки,хэш таблицы...) становятся частью языка,
запрет на адресную арифметику, автосборка мусора,
эквивалентность типов и классов-это общее для них.
Правда большая часть из них- интерпретаторы.
Как только кому-то удастся сделать подобную конструкцию
эффективно компилируемой и мультиплатформенной,
оно и будет лучшим выбором для болдьшинсва случаев.


IMHO, конечно.

obp ()

Re: Re: Гради Буч - о средствах разработки и их будущем

Ха! Сейчас ещё заявы пойдут, что это дурачок Степанов generic programming придумал (а про древнючий Лисп и мелкомаргинальный Форт и вспомнить забудут)...

anonymous ()
Ответ на: Посоветуйте аналог Dreaweaver для linux от obp

Re: Посоветуйте аналог Dreaweaver для linux

Тенденция сейчас другая - к гибели этой глобальной ошибки человечества - OOD/OOP. Лет через 10 про неё только особо фанатичные придурки помнить будут, ну и академики всякие...

anonymous ()
Ответ на: Re: Посоветуйте аналог Dreaweaver для linux от anonymous

Re: Re: Посоветуйте аналог Dreaweaver для linux

>> глобальной ошибки человечества - OOD/OOP

Можно поподробнее, в чём тут ошибка? ООП даёт возможность программировать в категориях поставленной задачи, т.е. разделять термины задачи (объекты снаружи) и термины программирования (объекты внутри - их методы и данные). ИМХО это великий рулез, своего рода аналог unix-way в программировании.

А вместо Dreamweaver можно попробовать vim+apache+mozilla+может быть пару скриптов в особо тяжких случаях.

bugmaker ★★★★☆ ()
Ответ на: Re: Посоветуйте аналог Dreaweaver для linux от anonymous

Re: Re: Посоветуйте аналог Dreaweaver для linux

Не расскажет ли умудренный мудростью мудрых, какая именно парадигма идет на смену ООП?

svu ★★★★★ ()

Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

А там что, есть что заменять? Она *реально* нужна? Её нужно просто *удалить* из употребления, без потерь. И тогда будет щастя для всех.

anonymous ()
Ответ на: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux от anonymous

Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Она (точнее - оно - ООП) *реально* помогает проектировать системы. Не на основе экранных форм и таблиц в БД - а на основе понятий из предметной области. Я учусь ООП уже лет десять (как известно, ни одной технологией нельзя овладеть до конца) - и я не видел ничего, чтобы было столь удобно и понятно - как разработчикам, так и заказчикам. Беседа ведется, так сказать, в терминах реальных бизнес-процессов. Только приходится следить, чтобы коллеги, пришедшие к ООП от БД, не затягивали обсуждение в сторону "экранов" и "записей".

Другое дело, что во всем нужен здравый смысл. И Буча&Co, похоже, забывают, что происходит с дураком, которого научили молиться богу - именно это _очень_часто_ происходит с разработчиками (особенно - менеджерами среднего уровня), вкусившими прелесть ООD/OOA, UML, RUP etc. Я не знаю, как относятся к этому господа из Rational (с одной стороны, им это прямо выгодно, с другой - у меня нет оснований подозревать их в откровенном мошенничестве, с третьей - они же производят впечатление действительно умных людей).

svu ★★★★★ ()

Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

2 svu:

Тогда расскажи мне, апологет поплюснутый, дятлу, почему ядро линукса написано на С, а не на С++. Может такая задача нихера недостойна ООП подхода и не катит под наследование, инкапсуляцию и прочую поцню?

anonymous ()

C++ apology

1. Мне всегда казалось, что есть два типа программистов: процедурщики и объектщики. Я не очень понимал процедурщиков, видимо потому, что был воспитан на книжке "программирование для математиков" от Лебедева с его "нарезчиками металла". Вообще, это вопрос психологии. Как бы то ни было, у всех есть своя правда. И у анархистов на Си и у республиканцев на Си++ и даже у монархистов на Фортране ;) (кстати Фортран 95 это нечто совершенно кромешное!)

2. С++ стал просто супером, когда в него было вшито STL. Теперь это просто законченный инструмент. В СТЛ есть все: от продвинутых алгоритмов сортировки (это по поводу того русского парня, что за алгоритмы, а не за данные) до чистки памяти, если вам так хочется. В общем, люблю я С++ с СТЛ.

3. Интересно, что даже новые книжки, которые _учат_ программировать на Си++ пишут коды вроде следующего:

#include <iostream.h>

const char *HELLO_WORLD = "Hello World";

int main(int argc, char ** argv){
int i;

for(i=1;i<=10;i++) cout << HELLO_WORLD << endl;
}

(взято из книжки "Parallel Scientific Computing in C++ and MPI" 2003 года)

Я к тому, что там все в этом духе!!! И это не исключение (я имею в виду книжку). Это полное непонимание С++! Возможно мужики программили на С раньше, а теперь вышли научить народ. А может пересели с Фортрана. Но мне кажется, что просто обкурились. Там просто отвратный код, с точки зрения С++ (но рабочий, с точки зрения С, например).

Я не говорю, что код нерабочий, поймите правильно. Я говорю, что он не С++. Это в книжке, которая учит С++!

-------

Чтобы избежать кривотолков, напишу как считаю нужным ту же демонстрационную программу, так например:

#include <iostream>
#include <string>
using namespace std;

//если уж так надо заводить константу
const string HelloWorld = "Hello World";

int main()
{
for(int i=0;i<10;++i)
cout << Hello_World << endl;

return 0;
}

atoku ★★★ ()
Ответ на: C++ apology от atoku

C++ apology

Естественно у программы были отступы, которые форум потер!

atoku ★★★ ()
Ответ на: C++ apology от atoku

C++ apology

Имел в виду cout << HelloWorld << endl;

atoku ★★★ ()

Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Коллега, известен ли Вам тот факт, что между ООП и ОО языками есть некоторая разница? В частности, можно писать _объектно_ на С. И даже на асме (правда, последнее крайне неудобно - но можно). А вот примеров объектного кода на С - море. Посмотрите на windows.h (не к ночи будь помянут). Посмотрите на библиотеки GTK/GNOME. Вот Вам примеры ОО библиотек для не-ОО языка. Я не смотрел на код ядра, но, насколько, я представляю, там тоже в очень многих местах ОО-подход (характерный пример из классики - vfs/vnode с его полиморфизмом). Почему люди пишут ОО способом на не-ОО языках - тема отдельной дискуссии (начинать будем?). Короче, я утверждаю - на сегодняшний день приличную ОС без ОО подхода не сделать. И таких просто нет. Даже если ОС написана на С.

А С++ я и сам не люблю (заберите слова про "апологета поплюснутого" назад). Очень. Поэтому и пишу под Гном, а не под КДЕ. Хотя как язык из поп-языков мой любимый - Жабка.

svu ★★★★★ ()
Ответ на: C++ apology от atoku

Re: C++ apology

Мне Ваш вариант тоже нравится больше. Только несколько маленьких вопросов:

1. Согласны ли Вы, что количество выполненных инструкций процессора (он начала программы и до конца) в Вашем случае немного больше? И памяти, вроде, Ваш вариант скушает на несколько байтиков поболее. Т.е. исходный вариант - эффективнее.

2. Что произойдет, если конструктор объекта string не справится со своей работой? Как в этом случае Вы собираетесь обрабатывать ошибку? Я не помню точно, выделяет ли память оный конструктор, но если да - вполне может произойти нехватка памяти (да, я знаю. не в реальной жизни - но пример-то тоже не из реальной жизни).

Соббсно, это только вопросы, чтобы показать - у каждой "красоты" есть цена. И нужно всегда ее представлять - а не просто зачарованно идти вслед этой красоте. Согласны?

svu ★★★★★ ()
Ответ на: Re: C++ apology от svu

C++ apology

Да, конечно, согласен, что есть цена.

В данном коде однако, такой проблемы не возникнет. Просто если не хватит памяти под строку, то программа не запустится с некоторой диагностикой на выходе, точно так же, как она не запустится и с кодом из книжки. Объект этот будет распределен статически, так что либо хватит памяти при старте, либо нет ;)

Я скомпилировал оба кода и действительно, моя версия заняла на полкило больше. Но, право, :) это меньше 5 процентов. Причем, неизвестно, что будет, если код увеличится. Я готов спорить, что разница эта будет нивелироваться с толщиной кода.

А ОО - это действительно супер. А апологетом С++ я готов называться вместо вас ;)

Не в тему: посоветуйте хороший каталог для книжек под Линуксом. Замаялся искать. То что в гнутой директории лежит - отстой. А монстры типа bookcase bookbase либо падают (первый), либо требут майскул, что не очень хочется возиться.

atoku ★★★ ()

Re: Гради Буч - о средствах разработки и их будущем

Буч - жалкий плагиатор, блок-схемы придуманы в СССР.

PS А фэмы лучше!

anonymous ()
Ответ на: Re: C++ apology от svu

Re: Re: C++ apology

>2. Что произойдет, если конструктор объекта string не справится со своей работой?

Этоже элементарно!

#include<>

try{
//если уж так надо заводить константу
const string HelloWorld = "Hello World";
}
catch(){
cout<<"ShIt happen"<<endl;
}

int main(.........



anonymous ()

Re: Re: Re: Re: Гради Буч - о средствах разработки и их будущем

>Так что люби smalltalk, если тебе он привычней. Но на другие языки не кати.

Почему это? Совершенно напроти - только программист на smalltalk'e, CLOS'е и их потомках имеет моральное и интелектуальное право рассуждать о ЯП вообще и ОО-языках в частности.

C++'цы при этом _обязаны_ становиться на задние лапки и внимательно слушать, что им говорят. ...что впрочем после лоботомии произведённой при участии г-на Страустропия не всегда может привести к выздоровлению.

>В конце концов, пользователь глубоко насрать на язык, на котором написана прога.

Да ну? То-то пользователям 1c насрать на ейный интерпретатор, ползователям R3 насрать на их 4GL, а пользователям MS Office насрать на VB. Страшно подумать, что бы было с Emacs'ом если б он был написан на perl'е... или даже tcl'е...

>P.S.: Пока жив Linux, C/C++ будет жить!

о гспди. Зврубите себе на носу С и С++ два принципиально разных языка. С непересекающимися нишами. Причём ниша С++ для правильного его применения исчезающе мала. И прямая угроза linux'у, как имплементации идей заложенных в UNIX.

dsa ()
Ответ на: Re: Re: Посоветуйте аналог Dreaweaver для linux от bugmaker

Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

>> глобальной ошибки человечества - OOD/OOP >Можно поподробнее, в чём тут ошибка? ООП даёт возможность программировать в категориях поставленной задачи,

Во-первых. Просто рекламный bullshit.

Во-вторых. Можно поинтересоваться какие альтернативы вы знаете? Если никаких - то, сами понимаете, ваше мнение идёт в попу.

В-третьих. http://www.paulgraham.com/

dsa ()

Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

>Тогда расскажи мне, апологет поплюснутый, дятлу, почему ядро линукса написано на С, а не на С++. Может такая задача нихера недостойна ООП подхода и не катит под наследование, инкапсуляцию и прочую поцню?

А аналогично - раскажите мне, не менее дятлу, почему ядро OS400 написано на C++? Причём не то,что "ядро", а даже и то, что, при желани можно назвать "микроядром"?

dsa ()
Ответ на: C++ apology от atoku

Re: C++ apology

Всё больше распаляясь в стиле г-на Луговского...

>1. Мне всегда казалось, что есть два типа программистов: процедурщики и объектщики.

Тебе казалось. Потому, что нихера не знаешь.

>2. С++ стал просто супером, когда в него было вшито STL.

гспди. Убогие темплейты, не идущие ни в какое сравнение с макросами Common Lisp'а 15-летней давности, тупорылая библиотека, пораждающая гигабайты неэффективного кода, отсасывающая не то, что у того же CL, но и у простеньких нынешних реализаций Scheme.

3> Я не говорю, что код нерабочий, поймите правильно. Я говорю, что он не С++.

...потому, что _нельзя_ учить ОО на С++. Язык ублюдок. Нужно иметь железные нервы и эйнштейновские мозги, чтобы пользоваться им правильно.

dsa ()
Ответ на: Посоветуйте аналог Dreaweaver для linux от obp

Re: Посоветуйте аналог Dreaweaver для linux

>Правда большая часть из них- интерпретаторы. Как только кому-то удастся сделать подобную конструкцию эффективно компилируемой и мультиплатформенной, оно и будет лучшим выбором для болдьшинсва cлучаев.

1)дучшего выбора быть неможет и не должно. Панацея - расширяемые и страиваемые языки (а этим свойством обладают все вами перечисленные)

2) Ocaml ...и это даже MS понимает.

dsa ()

Re: Гради Буч - о средствах разработки и их будущем

Фигня все!!!
Perl6 - рулит!!!

sabonez ★☆☆☆ ()
Ответ на: Re: Посоветуйте аналог Dreaweaver для linux от anonymous

Re: Re: Посоветуйте аналог Dreaweaver для linux

>>Но вроде как eiffel - компилируемый, а луа и пистон компилят в байт-код?
В общем верно,
только байт-код это все таки не машинный код и его интерпретировать надо.А про eiffel не скажу точно, но сдается мне(возможно я и ошибаюсь) что он тоже шьет байт код и интерпретатор оного в один исполняемый файл

obp ()

Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

>> Во-первых. Просто рекламный bullshit.

аргументы?

>> какие альтернативы вы знаете? Если никаких -

А если знаю какие-нибудь? А если меня ООП само по себе вполне устраивает и поэтому альтернатив не ищу? Без аргументов ваше мнение идёт гораздо быстрее, гораздо дальше, и остаётся там до конца времён.

bugmaker ★★★★☆ ()

Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

>> Во-первых. Просто рекламный bullshit.

>аргументы?

А где почва под утверждениями, что ООП первый,единственный и лучший способ программировать в терминах предметной области? Кроме невежества.

>> какие альтернативы вы знаете? Если никаких - >А если знаю какие-нибудь?

тогда придётся сравнивать, доказывать и интегрировать

>А если меня ООП само по себе вполне устраивает и поэтому альтернатив не ищу?

...ну в принципе рождённого слепым палочка тоже вполне устраивает

dsa ()
Ответ на: Re: C++ apology от dsa

Re: Re: C++ apology

> нихера не знаешь.
Отличный аргумент в споре! А за ногу укусить не пробовали?

>Убогие темплейты, не идущие ни в какое сравнение с макросами Common
>Lisp'а 15-летней давности

Между макросами cl и template'ами C++ точно такая же разница как и
между макросами m4 например и template'ами C++.

>тупорылая библиотека, пораждающая гигабайты неэффективного кода,

Код порождает не библиотека, а компилятор. Запомните на будующее -
пригодится.
Если речь идет об stl то это отлично сработанная вещь.
boost тоже классная штука, а loki - вообще произведение
искусства. Рекомендую. Хотя наверное зря. Вы там ничего не
поймете...

Вообщем не знаете С++ - не позорьтесь.

>Язык ублюдок.
Ваш язык ?

>Нужно иметь железные нервы и эйнштейновские мозги, чтобы пользоваться
>им правильно.

Вот с этого и начинайте. Если Вы не можете использовать инструмент
( по причине скудоумия или психического нездоровья ) не значит
что он плох.

Captain.

anonymous ()

Re: Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

Совершенно верно! C - лучший OO язык. Кроме шуток.

А всё потому, что он не требует переносить смутное представление об объектах в голове программиста сразу в код, а допускает эффективный инкриментный подход и в отличие от C++ и Java ПОЛНОСТЬЮ скрывает интерфейс от реализации. В С++ тоже можно этого добиться... используя C-шный подход:-).

anonymous ()

Кино для настоящих линуксоидов ;)

2dsa

а можно поподробнее про "ублюдочность" C++ ?

А то пока только крики - а аргументов 0

hint: C++ _гибридный_ язык - именно в этом его _сила_ а никак не в теоретической стройности потому как в мире мало реальных задач которые 100% ложились бы под какую либо "чистую" парадигму - именно поэтому он так распространен и так популярен.

Возможно он неэффективен в часностях но зато для решения задачи _в_комплексе_ он оказывается эффективнее любого "чистого" языка

sS ★★★★★ ()
Ответ на: Re: Re: C++ apology от anonymous

Re: Re: Re: C++ apology

>Между макросами cl и template'ами C++ точно такая же разница как и между макросами m4 например и template'ами C++.

только наоборот.

...остальное скипнуто, как пустопорожний флейм

dsa ()

Re: Re: Re: Re: Re: Re: Посоветуйте аналог Dreaweaver для linux

>> А где почва под утверждениями, что ООП

а где сами утверждения такого рода? Лично я могу утверждать, что ООП вполне сносно справляется с тем, для чего предназначено и не имеет принципиальных недостатков, которые бы мешали его использованию.

>> тогда придётся сравнивать, доказывать и интегрировать

тогда да. Приведи пример достаточно сложной проги, написанной без применения технологии ООП, чтобы можно было сравнивать на реальном примере.

>> ...ну в принципе рождённого слепым палочка тоже вполне устраивает

и что бы он сделал, если бы не устраивала?

bugmaker ★★★★☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.