Re[5]: Будущее программирования - обсудим?
От: minorlogic Украина  
Дата: 12.02.12 10:41
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, minorlogic, Вы писали:


M>>Я говорил про декомпозицию на всех уровнях

LVV>Ну, вы же понимаете, что граф связей — это только представление, для программиста?
LVV>В явном виде он же не хранится.

Не понимаю. Приведенный тут как пример , ДРАКОН как справляется с задачей декомпозиции ?
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[6]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 12.02.12 10:43
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, LaptevVV, Вы писали:


LVV>>Здравствуйте, minorlogic, Вы писали:


M>>>Я говорил про декомпозицию на всех уровнях

LVV>>Ну, вы же понимаете, что граф связей — это только представление, для программиста?
LVV>>В явном виде он же не хранится.

M>Не понимаю. Приведенный тут как пример , ДРАКОН как справляется с задачей декомпозиции ?

Дракон — никак.
Декомпозиция задачи — это творческий акт. Язык может поддерживать этот творческий акт или не поддерживать.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Будущее программирования - обсудим?
От: GlebZ Россия  
Дата: 12.02.12 21:16
Оценка:
Здравствуйте, IT, Вы писали:



IT>Мы тут говорим о программировании, а не о рисовании. Разве нет?

Программированние — это построение программ. Программа — это преобразование данных в другие данные сообразно некоторому алгоритму. Определения, только что выдуманные, но академические определения, думаю, подобны. Заметь, ни про перфоленту, клавиатуру или мышь нигде не сказано.

IT>>>ASP.NET навязчиво предлагал писать html не руками, а размазывать его по экрану мышкой.

GZ>>Через 10-20 лет я вообще не хочу видеть html.
IT>А придётся.
Думаешь он вечен как бэйсик?

IT>>>В первую очередь это DSL. В качестве примера возьмём Linq.

GZ>>Пример интересный. Однако следует напомнить о сложности интеграции. Нужно быть мазохистом в самой извращенной форме, чтобы добровольно реализовывать визитеров.

IT>Ты о чём?

О провайдерах LINQ. Делать их сложно. Даже на немерле

IT>>>Вторым направлением является, конечно же, функциональное программирование.

GZ>>Рок&ролл — мёртв. ФП — мёртв. Мы — зловещие мертвецы. 30 лет назад, это тоже было перспективным направлением. Если на основе различных ФП мозгляки придумывали различные непотребные вещи, которые потом ввели в мейнстрим, это не значит что сам ФП станет мейнстримом. Некоторые средства — да. Само ФП — нет. И это следует считать доказанным, опытным путем, фактом.
IT>Можно подробнее про опыты?
В каком году появился лисп? Практически полностью фп оформилось в 70-ых.

IT>>>Третья вещь – это метапрограммирование.

GZ>>Метапрограммирование вещь сама в себе. Метапрограммирование — может дать декларативность. Но в то же время, может и не дать. И тогда она чрезвычайно опасная штука, вводящая зависимости какие в ООП не снились, и сложность на уровне — перед тем как подойти к клавиатуре, давайте выучим Войну и Мир наизусть.

IT>Я выше приводил пример про баиндинг. Написать шаблон на T4, который решает проблемы, которые решают некоторые навороченные фреймворки, у меня заняло пол дня.

Т4 — система метапрограммирования? Ну можно и так сказать. С некоторым Ы. Только опять вопрос, сколько людей, хотя бы думают, что знают С#, а сколько Т4. Новым инструментом мы ввели излишнюю сложность. Но вопрос не об этом. Это низменное решение. Высокое решение состоит в том, чтобы человек ни разу не думал как у него проходит биндинг. Ему нужно знать что данные связаны по некоторым, управляемым законам, которые он может свободно менять. Желательно с рисованием, чтобы не сделать ошибку в тексте. И с проверкой семантики.

IT>Ну а хрен себе при желании отстрелить можно чем угодно. Не обязательно для этого использовать сложный, изощрённый механизм. Можно просто засунуть его в электрическую мясорубку. Нажимаем кнопку 'Вкл' до характерного звука 'счёлк' и вот тебе к столу фарш их хрена.

А вот в светлом будущем, все будут плеваться от нашей с тобой недоразвитости. Не нам одним плеваться на goto.
Re[5]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 13.02.12 04:09
Оценка:
Здравствуйте, uncommon, Вы писали:

U>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST.


Т.е. если из работающего кода я просто тупо удалю все открывающие скобки, то в этот момент оно будет представлять из себя некое законченное AST?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 13.02.12 04:10
Оценка:
Здравствуйте, uncommon, Вы писали:

U>Не понял, при чем здесь сравнение Лиспа с машинными кодами. Лисп — язык высокого уровня, не уступающий по мощности, а в большинстве случаев превосходящий другие широко используемые языки программирования.


Может по мощности он и не уступает. Но вот по бесчеловечности точно не уступает.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Будущее программирования - обсудим?
От: uncommon СССР  
Дата: 13.02.12 05:22
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, uncommon, Вы писали:


U>>Программа на лиспе при редактировании в emacs'е в любой момент представляет из себя некое законченное AST.


IT>Т.е. если из работающего кода я просто тупо удалю все открывающие скобки, то в этот момент оно будет представлять из себя некое законченное AST?


Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.
Re[8]: Будущее программирования - обсудим?
От: uncommon СССР  
Дата: 13.02.12 05:27
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, uncommon, Вы писали:


U>>Не понял, при чем здесь сравнение Лиспа с машинными кодами. Лисп — язык высокого уровня, не уступающий по мощности, а в большинстве случаев превосходящий другие широко используемые языки программирования.


IT>Может по мощности он и не уступает. Но вот по бесчеловечности точно не уступает.


Почему? Я буквально полторы книги по лиспу прочитал и несколько программ написал. И в какой-то момент код на лиспе стал читаться и писаться без особых затруднений.
Re[9]: Будущее программирования - обсудим?
От: PSV100  
Дата: 13.02.12 13:14
Оценка: 12 (1)
Здравствуйте, LaptevVV, Вы писали:

LVV> ...


[...] Спасибо. У меня ещё пару мыслей по этой опере. Я затрону соседнюю тему рядом со всякими схемами — отчёты для печати. Я не в курсе о специфике вашего ВУЗа/кафедры и применима ли эта тема, но отчеты требуются во многих местах, и далеко за пределами коммерции. Так вот, я предлагаю глянуть на проектик "Script Reporter", архив можно взять здесь. С проектом возиться не нужно, достаточно глянуть хелп и примеры (там такого совсем чуть-чуть). Это старый проект 90-х годов для Delphi, уже умерший (но, имхо, только в интернете !). Представляет из себя простой скриптовый язык программирования для создания отчетов + небольшая инфрастуктура для него.
Поясню причины своей "приставалки".

Во-первых, это пример эффективного текстового представления, которого часто не хватает в реальной жизни простым смертным людям.
Например, отчёты часто вынужденны ваять поверх HTML-я, особенно в рамках веб-а/интранета, через всякие около-вебные фреймворки. Частенько вручную ваяют PDF. Но это всё — ещё та морока. Есть не мало готовых отчётных систем. MS Reporting Services, Crystal Reports, JasperReport и BIRT для джавы — это основной "ынтерпрайз". Плюс есть много чего для Delphi, Net-a, вот для джавы — совсем их мало, а также полно встроенных отчётов во всяких около-тыпрайзнутых системах. Часто они состоят из XML-программирования (то ещё удовольствие) + всякие дизайнеры и пр.
Часто визуальные хорошие системы очень нужны. Напр., до меня иногда доносятся стоны от тех людей, кто вынужден разрабатывать для всяких Акцапт, Ораклов, Sap R3 и т.п. (где стоимость систем с немалыми нулями), и они знают, как ваяются отчеты в 1С. Вот в 1С — удачная графическая система. 1С повлиял на популярный проект FastReport — отчёты для Delphi и Net-а — одна из лучших штучек в этой области (жаль, что нет для жабы и решений для серверов приложений, хотя что-то там сетевое есть). В своё время для дельфи был проектик PReport (уже давненько умер, но на просторах инета найти можно) — имхо, среди подобных систем в нём был самый гибкий алгоритм формирования отчётов, есть чему поучиться многим "ынтепрайзам".
Кстати, 1С, FastReport, PReport и указанный проект — наваяли их наши люди — нюх к практичности по сравнению с индусами имеется. Как минимум, наши люди не забывают о матричных принтерах и всяких печатных машинах — они ещё очень долго будут нужны, и ни чем их пока не заменят.

Но, выше приведенные системы не дают такого профита, как этот указанный древний проект. Именно подобные системы позволяют небольшой команде или одному человеку ваять сотни, если не тысячи, отчётов, которые постоянно нужно подгонять под новые требования. В проекте небольшой текстовый язык, чем-то напоминающий SQL и полу-паскаль, там нечего осваивать. Ключевой момент — простота (!), при этом эффективная.
У себя имеются разработки в таком стиле, так что, всё проверено на своей шкуре.
И это именно тот проект, который мне когда-то раскрыл глаза, как можно решать практично сложные проблемы (почему, собственно, я о нем и вспомнил).

Во-вторых. На проект полезно глянуть для разработки тех же дракон-схем и им подобным. Сам по себе DSL в этом проекте не пригоден "в лоб" для драконов. Здесь декларативное описание, а драконы требуют явного императивного указания алгоритма (это их цель). Но, если о драконах говорить далее, чем рисование на бумажках, то обычно эти схемы от фонаря не создают. Необходимо иметь те же декларативные элементы для задания предметной области, какие-то базовые функциональные вещи (те же встроенные функции, для которых дробить алгоритм в рамках схем не имеет смысла) и т.п. Затем в таком стиле можно что-то нафантазировать и для задания прямых алгоритмов-схем. Как-то так.

Ну и последнее. Сам по себе такой язык программирования для отчётов — это, имхо, вполне хорошая тема для какой-то научной/дипломной работы. И главное — это востребовано в реальной жизни. Лично я ничего подобного не видел ни для жабы, ни для net-а. Сомнительна массовая потребность таких вещей в рамках C++, напр., того же Qt, но уверен, что многим людям и здесь чего-то такого не хватает.

Имхо, можно копать в такую сторону:

— обосновать, зачем нужен ещё один язык, пусть даже только для отчётов. Здесь можно напридумывать немало научных слов, но это не моя стихия. Я скажу прямо: в современном мэнстриме — C++, Java, C#, даже питон с руби и т.д. — не очень удобно ваять прикладную логику, если не сказать более "теплых" слов. Кстати, здесь
Автор: PSV100
Дата: 03.02.12
у меня недавно вырвался плевок в сторону ООП, там вроде и тема была несерьезная, но почему-то "зацепила".
И ещё, к слову. Имхо, уже упомянутый здесь Go — вполне хороший пример, где можно понять, как решаются те же проблемы, но без классовой иерархии, каких-то глобальных зависимостей. К тому же, имхо, Go — хорошая стартовая точка для освоения функциональных языков, при этом он проще, чем тоже около-системный D, или Rust, который сейчас мазиловцы ваяют. В Go сейчас не хватает пары вещей, напр., дженериков, не всё гладко с платформой. Может есть смысл для пилотного учебного комплекса "C#- Qt-BlackBox" попробывать и Go, даже вместо BlackBox — пользы будет больше. Правда могут быть проблемы, как минимум с GUI, но может быть это как раз повод сделать web-версию

— далее, набросать сам язык, плюс небольшая инфраструктура, хотя бы раскраска синтаксиса;

— нужен базовый движок для генерации отчётов. Лучше сначала ориентироваться на ынтерпрайз. Реализовать ядро на джаве, которое будет генерировать HTML по вкусу (с рядом ограничений, сам этот html — штука не фонтан для отчётов). Адаптировать ядро под возможность работы с серверами приложений. Если есть потребность интеграции в учебный комплекс — через HTML будет вполне добротно, и не чего страшного, если где-то рядом нужно будет жабку запустить, ее даже встроенной можно сделать.

Как-то так. Если тема будет "прокачена" — это не вылетит в трубу, а отличный задел на будущее: расширение форматов (PDF, свои бинарники, plain-text и т.д), какие-то JS-либы для расширенной работы в броузере, интеграция для десктопа (Swing, JavaFX, SWT), портирование на Net и конца этому не будет, если коммерчески себя оправдает


P.S. Пару слов в оправдание моего тутошнего офтопа. Я после студенчества быстро осознал, какой фигней приходилось заниматься в ВУЗ-е, и сколько времени было потрачено неэффективно. Тут так сложилась тема на форуме, что "задела былые раны".
Буду рад, если удалось выложить реально полезную инфу.
Re[6]: Будущее программирования - обсудим?
От: PSV100  
Дата: 13.02.12 13:55
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Не понимаю. Приведенный тут как пример , ДРАКОН как справляется с задачей декомпозиции ?


Сорри, но я, например, тоже не понимаю, о каком отсутствии декомпозиции в драконе идёт речь ?

Я давно смотрел на "стандарт" дракона (да собственно, от дракона, кроме как идеи направленного графа — больше ничего ненужно, это и весь "стандарт"), я не помню, чтобы он запрещал в блоках (каких-то прямоугольниках) указывать какие-то свои команды перехода на другие схемы, т.е. можно указать какой-то процесс, а "раскрыть" его — отдельной схемой (что и делалось на практике — вполне себе какая-то декомпозиция).
Возможно и огромные схемы, с большим количеством всяких сущностей, весьма востребованы. Какому-то инженеру, м.б., удобно разбирать схему на A1, где всё сразу перед глазами, он к этому привык.
Re[7]: Будущее программирования - обсудим?
От: minorlogic Украина  
Дата: 13.02.12 14:16
Оценка:
Здравствуйте, PSV100, Вы писали:

PSV>т.е. можно указать какой-то процесс, а "раскрыть" его — отдельной схемой (что и делалось на практике — вполне себе какая-то декомпозиция).


Это и есть один из механизмов поддержки иерархической декомпозиции.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[9]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 13.02.12 14:34
Оценка:
Здравствуйте, uncommon, Вы писали:

IT>>Может по мощности он и не уступает. Но вот по бесчеловечности точно не уступает.

U>Почему? Я буквально полторы книги по лиспу прочитал и несколько программ написал. И в какой-то момент код на лиспе стал читаться и писаться без особых затруднений.

Бывает. Я не отрицаю мазохизм как явление.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Будущее программирования - обсудим?
От: IT Россия linq2db.com
Дата: 13.02.12 14:35
Оценка:
Здравствуйте, uncommon, Вы писали:

U>Удаление открывающей скобки удаляет и закрывающюю. Я же говорю, emacs редактирует код на лиспе таким образом, что все скобки всегда сбалансированны.


При чём тут emacs? Мы разве его обсуждаем?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Будущее программирования - обсудим?
От: PSV100  
Дата: 13.02.12 15:23
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, PSV100, Вы писали:


PSV>>т.е. можно указать какой-то процесс, а "раскрыть" его — отдельной схемой (что и делалось на практике — вполне себе какая-то декомпозиция).


M>Это и есть один из механизмов поддержки иерархической декомпозиции.


Понятно, я так и думал. Скорее всего, Вы смотрели или только примеры, или плюс какие-то визуальные среды для этих драконов, где на глаза попалось то, что во всяких прямоугольниках обычно внедряются какие-то конечные действия. Так, кстати, и делают ряд редакторов, которыми я когда-то баловался. Какая есть система в тех местах, где этот дракон родили — сие есть "тайна", но где-то какая-то инфа проскакивала, и вроде там что-то стоящее. А так, если нужны схемки — бумага, карандаш, линейка и "рефакторинг"-резинка — это лучшее, что пока есть.
Re[9]: Будущее программирования - обсудим?
От: minorlogic Украина  
Дата: 13.02.12 18:17
Оценка:
Смотрел поверхностно.

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

В тесте исторически используются много гетерегонных средств , начиная от разбивки по файлам и сборкам заканчивая пустой строкой для групировки выражений по смыслу.
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[8]: Будущее программирования - обсудим?
От: m e  
Дата: 13.02.12 23:09
Оценка:
PSV>По сему, лучше смотреть на вим/эмакс при изучении какого нибудь питона/руби. Здесь и монстры-иде не сильны в плане развитого автокомплита, код-броузера, рефакторинга и т.д. в силу динамичной природы таких языков.

1. в виме есть автокомплит и прочее (хотя никогда не пользовался)

2. kdevelop позволяет в качестве компонента-редактора использовать вим, не теряя автокомплита и прочего (опять сам никогда не пользовался)
Re[7]: Будущее программирования - обсудим?
От: m e  
Дата: 13.02.12 23:27
Оценка:
я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич)
Re[9]: Будущее программирования - обсудим?
От: PSV100  
Дата: 14.02.12 10:27
Оценка:
Здравствуйте, m e, Вы писали:

PSV>>По сему, лучше смотреть на вим/эмакс при изучении какого нибудь питона/руби. Здесь и монстры-иде не сильны в плане развитого автокомплита, код-броузера, рефакторинга и т.д. в силу динамичной природы таких языков.


ME>1. в виме есть автокомплит и прочее (хотя никогда не пользовался)


ME>2. kdevelop позволяет в качестве компонента-редактора использовать вим, не теряя автокомплита и прочего (опять сам никогда не пользовался)


Здесь можно ещё добавить и Eclim для эклипса, но я им не пользовался. Я лишь хотел сказать о том, что пробовать освоить С/С++ и одновременно вим/эмакс — сугубо моё личное имхо, будет как-то тяжеловато. С тем же комплитом и пр. хорошие IDE справляются по-приятнее, чем какой-нибудь ctags или cscope и им подобные, да и перезапускать всякий ctags на каждый чих — тоже не фонтан. Для тех, кого устраивает ctags, он не такой уж и частый помощник. В виме/эмаксе есть тоже отличные "иде", например, не мало лисперов свой SLIME ни на что не променяют. Да и к тому же, как минимум клавиатурное управление в этих редакторах быстро с наскока не возьмёшь, особенно, если вим/эмакс — не основная сфера деятельности (теоретически есть возможность раскладки попеределовать по-своему, но, к примеру, тогда это уже будет не совсем вим).
Re[8]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 14.02.12 15:05
Оценка:
Здравствуйте, m e, Вы писали:

ME>я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич)

Нет, не структурный.
Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды.
И его можно запускать и использовать совершенно так же, как и любой стандартный.
То есть компонентный паскаль — это не только язык программирования, но и внутренний язык развития системы.
Микрософт подобную штуку сделала только 10-й студии, когда на Додиезе стало возможно саму среду.
До того в среде был механизм макросов, реализованный на VB.
Окно редактора ББ представляет собой документ, в котором можно писать как в ворде.
Причем можно смешивать обычный текст и программу.
Более того, тут же в документа можно написать и входные данные (если их немного).
И тут же из окна запустить программу.
Меню бб — это такой же документ, который можно редактировать в том же редакторе. Поэтому из ББ можно сделать такую систему, которая требуется.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[9]: Будущее программирования - обсудим?
От: WolfHound  
Дата: 14.02.12 16:34
Оценка:
Здравствуйте, LaptevVV, Вы писали:

ME>>я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич)

LVV>Нет, не структурный.
LVV>Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды.
Это не фишка.
Это идеологическая бага.
Причем она делает компонентный паскаль просто неработоспособным в реальном мире.
Ибо один злобный или глючный модуль, который начнет создавать объекты из других модулей и складировать их у себя съест всю память.
И его даже срубить нельзя будет. Ибо в этом случае будет нарушена целостность графа объектов.

Я уже не говорю о том, что переменная модуля это фактически глобальная переменная. То, что она скрыта за интерфейсом модуля, ничего не меняет. Все основные проблемы глобальных переменных остаются.

Что делать если нужно запустить несколько копий модуля?
А если разным модулям нужны разные версии модуля одного?

Это же dllhell на стеройдах.

И об этом уже не раз сказано. Но каждый раз игнорируется.
И через некоторое время опять начинается песнь про то что это мегафича.

LVV>Микрософт подобную штуку сделала только 10-й студии, когда на Додиезе стало возможно саму среду.

Это лож. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.

LVV>Окно редактора ББ представляет собой документ, в котором можно писать как в ворде.

Только так и не ясно нахрена оно нужно.
Вот подсветка синтаксиса, подсветка ошибок, автокомплит, навигация, рефакторинг,... нужны.
Помнишь голосование: http://www.rsdn.ru/poll/3001.aspx
Автор: WolfHound
Дата: 19.04.11
Вопрос: Нужна ли подсветка синтаксиса в редакторе кода?
А то тут некоторые говорят что не нужна :-/

А писать программу как в ворде раскрашивая код руками не нужно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Будущее программирования - обсудим?
От: LaptevVV Россия  
Дата: 14.02.12 17:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, LaptevVV, Вы писали:


ME>>>я что-то не понял -- в blackbox реализовано что-то типа структурного редактора? ссылка на этот редактор есть? (а лучше на описание его предполагаемых киллер-фич)

LVV>>Нет, не структурный.
LVV>>Фишка ББ в том, что любой модуль, написанный на компонентном паскале становится частью среды.
LVV>>Микрософт подобную штуку сделала только 10-й студии, когда на Додиезе стало возможно саму среду.
WH>Это ложь. Если мне не изменяет склероз то для студии с самого начала можно расширения на .НЕТ писать. Для 2008 точно можно.
Фигню глаголешь, отрок! Вот передо мной книжка по среде Visual Studio 2008. Авторы Ларс Пауэрс, Майкл Снелл.
Глава 12. Пишем макросы. Страница 418.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.