Здравствуйте, WolfHound, Вы писали:
_>>Обычно 1-2 экрана. ) WH>Те до 100 строк. WH>На таких объёмах динамика ещё не успевает превратиться в ад.
Ну так таких задач то множество. Кстати, если посмотреть на многие веб-решения, то хотя в целом система выглядит большой, но на практике всё сводится ко множеству не связанных между собой скриптов как раз такого размера (обычно просто прокладка между браузером и БД).
_>>DSL там реализует не сам Питон, а соответствующие библиотечки для него. Например типа таких: http://docs.fabfile.org/en/1.10/tutorial.html WH>Для любого статически типизированного языка такое пишется примерно за день.
Нуу не за день, а скажем за недельку (общее решение, а не частный скрипт), но да, ничего сложного. Только вот дело в том, что у меня есть множество других дел, гораздо более сложных, и тратить время на написание подобной ерунды нет никакого желание. Хочется просто скачать и чтобы всё работало из коробки. )
_>>Ну так назови хотя бы один. В чём проблема? ))) WH>10 секунд гугления. WH>http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html _>>1. Чтобы писалось не сложнее чем сейчас. Т.е. чтобы синтаксис языка был не тяжелее Питона и были в наличие нужные предметные библиотеки. WH>
WH>main = do
WH> cd "/tmp"
WH> mkdir "test"
WH> output "test/foo" "Hello, world!"-- Write "Hello, world!" to "test/foo"
WH> stdout (input "test/foo") -- Stream "test/foo" to stdout
WH> rm "test/foo"
WH> rmdir "test"
WH> sleep 1
WH> die "Urk!"
WH>
Это Хаскель то не тяжеловесный? ))) Ну да, если держаться строго в рамках этого DSL, то конечно всё выглядит просто. Только вот в таких случаях скрипты и не нужны особо (хватит обычных bat файлов). А стоит сделать малейших шаг в сторону (собственно ради чего и нужен Питон), как в данном случае всплывут кривые монады и прочие радости Хаскеля. При таком подходе я буду думать скорее не о требуемом алгоритме скрипта, а о том как же его записать на этом "модном" языке...)))
_>>3. Чтобы можно было увидеть ссылку на скачивание описанного чуда, а не утверждение, что это всё теоретически возможно (против этого никто и не возражал). )))) WH>Ещё 30 секунд гугления и ты найдёшь ещё много чего интересного.
Сомнительно. Я в целом не плохо ориентируюсь в мире языков программирования. Многие пробовал (для интереса, а не для работы), а про остальные хотя бы читал. Однако мне не приходит в голову ни один пример статически типизированного языка, который мог хотя бы приблизиться по удобству к Питону (и ему подобным) на таких задачах.
Здравствуйте, alex_public, Вы писали:
_>Ну так таких задач то множество. Кстати, если посмотреть на многие веб-решения, то хотя в целом система выглядит большой, но на практике всё сводится ко множеству не связанных между собой скриптов как раз такого размера (обычно просто прокладка между браузером и БД).
Вот только на практике они связаны.
_>Нуу не за день, а скажем за недельку (общее решение, а не частный скрипт), но да, ничего сложного.
Я говорю по запускалку.
Что там неделю писать?
_>Только вот дело в том, что у меня есть множество других дел, гораздо более сложных, и тратить время на написание подобной ерунды нет никакого желание. Хочется просто скачать и чтобы всё работало из коробки. )
Мы говорим не про то есть готовые инструменты или нет, а про то есть ли толк от динамической типизации.
Это сильно разные темы.
_>Это Хаскель то не тяжеловесный? ))) Ну да, если держаться строго в рамках этого DSL, то конечно всё выглядит просто. Только вот в таких случаях скрипты и не нужны особо (хватит обычных bat файлов). А стоит сделать малейших шаг в сторону (собственно ради чего и нужен Питон), как в данном случае всплывут кривые монады и прочие радости Хаскеля. При таком подходе я буду думать скорее не о требуемом алгоритме скрипта, а о том как же его записать на этом "модном" языке...))) Ты только что читал насквозь монадический код.
Слово do видишь? Это начало монадического кода.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexRK, Вы писали:
ARK>Если компилятор позволяет обойти проверки типов (и даже проверки наличия методов), вместо этого выбрасывая в рантайме исключения — то мы получаем по факту динамику.
Разница в том, что в случаи динамически типизированным языком ты не сможешь отключить этот ключик и получить все проверки.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ARK>>Если компилятор позволяет обойти проверки типов (и даже проверки наличия методов), вместо этого выбрасывая в рантайме исключения — то мы получаем по факту динамику. WH>Разница в том, что в случаи динамически типизированным языком ты не сможешь отключить этот ключик и получить все проверки.
Да, это я понял. Но, ИМХО, это и не требуется — набросал небольшой прототип или скрипт, задачу выполнил и забыл.
Зато некий ненужный мусорок в коде появляется — надо же написать названия хотя бы фейковых типов для параметров методов и возвращаемых значений.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, LaPerouse, Вы писали:
LP>>Пытаетесь объять необъятное? WH>Нет.
Но ощущение складывается именно такое.
LP>>Да ну? WH>Компилятор может написать любой профильный студент. И даже некоторые школьники. WH>Нормальных ИДЕ раз, два и обчёлся.
Ну и? Ты ведь говоришь не про компилятор под определенный язык, а универсальный компилятор. Я все жду, когда же ты скажешь наконец, что ваш продукт предоставляет (или собирается предоставлять) способ для более быстрого построения компилятора под конкретный язык (это именно то, что люди ждут от подобных инструментов), но ты все твердишь про полностью автоматический способ построения такого компилятора исходя лишь из формального описания языка, что можно реализовать лишь для определенного семейства похожих языков, но не для всего множества существующих языков.
LP>>Это сомнительно хотя бы потому, что универсальные генераторы IDE есть уже давно (https://eclipse.org/Xtext/), WH>Крайне ограниченная штука с кучей закатов солнца вручную.
Закаты вручную там начинаются как раз при компиляции. Иде делается достаточно прямо и тупо.
LP>>а вот действительно универсальные генераторы компиляторов — такого история не знает. Каков должен быть алгоритм, который лишь из одного метаописания языка С++ может комплировать С++ код, а из метаописания языка Prolog-a — Prolog-код? WH>https://en.wikipedia.org/wiki/Graph_rewriting закрывает процентов 90.
Универсальный алгоритм абсолютно бесполезен. Иначе все в этом мире писалось бы на Прологе, который работает на одном-единственном алгоритме перебора с откатами, ну и костылями, позволяющими ограничить перебор. Ну еще я не знаю ни одной реализации пролога, которая использовала бы graph rewriting. Это говорит о том, что использование этого алгоритма менее обравданов данном случае, ну или что все идиоты.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, DarkEld3r, Вы писали:
DE>>Вот только мейнстримовых (статически типизированных) языков с "выводом типов и метапрограммированием" (практически?) нет. А динамика вполне доступна и "пропихнуть в продакшен", наверное, легче чем немерле. WH>Пихать динамику в продакшен глупо. Всегда.
Кроме одного случая. Когда динамика используется для интеграции систем друг с другом (на уровне получить из одной системы и передать в другую) при отсутствии всякого метаописания, то есть без возможности автоматически сгенерировать классы. В этом случае почти не происходит повторного обращения к свойствам объектов, только единственное чтение и единственная запись, соответственно стат. верификатор почти не задействуется.
Здравствуйте, WolfHound, Вы писали:
WH>Ничего не сможешь с этим сервисом сделать. Даже обратится к нему не сможешь. WH>Либо тебе известен контракт. А если есть контракт, то уже есть типы.
При выполнении становится известен. На стадии компиляции нет.
WH>И что ты будешь дальше делать? WH>Максимум что ты можешь сделать, это распечатать то, что ты получил.
Да все что угодно. Например, что пользователь скажет (приложения или библиотеки).
WH>А вот если ты хочешь сделать что-то осмысленное, то тебе нужно знать что там лежит WH>Вот тут уже и появляются статическая типизация.
Ну вот json там лежит, к примеру, одному из тысячи. Осмысленность привнесет пользователь скриптом на JavaScript. Зачем мне тут статическая типизация?
_>>2) Динамика удобнее, когда статическая типизация в имеющихся альтернативах недостаточно гибка. Например когда нужно объединение типов — вот в Nemerle есть variant, но что делать если одна переменная имеет тип A | B | C | D, а другая — A | C | E | F? WH>Это легко делается. WH>Просто это нужно настолько редко что никто это не делает. WH>Но если тебе так хочется, к немерле 2 я это прикручу.
Поверю на слово, если приведешь типы этих двух переменных.
_>>Ну а если в языке даже неуклюжего variant/pm нет, то вообще туши свет — мысль, которая могла быть выражена лаконично, растекается. WH>Так в большинстве динамически типизированных языков этого тоже нет.
Чего нет, вариантов? (все-таки в примере упор на варианты, а не pm — что до pm, то где-то есть, а где-то его заменяют другие языковые средства).
_>>Да что там, в большинстве языков даже тип со значениями ( T | null (значение отсутствует) | undefined (значение не определено) ) уже страшная проблема. WH>Мы всё ещё говорим про динамическую типизацию, где в переменной может быть любое говно?
Нет же, про статическую (в языках, в которых проблемы с выражением простой дизъюнкции типов).
А в переменной будет то, что в нее положили.
_>>3) Системы с горячей заменой кода. Наверное, удачно совместить ее со статической типизацией в принципе возможно, но пока на этом поле играет динамика. WH>Ну, она много где играет только по тому, что никто статику засунуть не пробовал.
Когда засунут, тогда сравним. Пока засчитаем победу за неявкой соперника.
(На всякий случай, горячая замена кода — это киллер-фича для определенного класса задач).
_>>Когда в руках молоток, все вокруг кажется гвоздями. Если проблемы типизации должно решать метапрограммирование, то у типизации проблема. WH>Дело в том, что динамическая типизация позволяет некоторое метапрограммирование. WH>Так что если в языке нет метапрограммирования, то сравнение будет просто не корректным.
Ясно.
WH>Ну и вывод типов ты изящно проигнорировал.
А я просто не понял этот аргумент. Он позволяет писать меньше кода, экономя на явном указании типов? В контексте дискуссии это мелочи. Или что-то еще?
Ну и опять же, в динамическом Эрланге и типы можно указывать, и вывод типов есть. Просто проверка типизации происходит не при компиляции, а при статическом анализе.
_>>Как и все трюизмы, эти, верные в целом (если, конечно, опустить "100 строк"), могут не соответствовать действительности в конкретных условиях. WH>Когда конкретно они не соответствуют действительности?
Касательно ресурсов:
Как программисты мы решаем инженерные задачи. Наша программа должна работать в заданных ограничениях. Нет смысла говорить о "в общем низкой производительности" или "в общем высоком потреблении памяти". Память не имеет значения для cpu или io bound приложений на выделенном сервере. Допустимая производительность некоторых консольных приложений может варьироваться в пределах нескольких порядков. Игровой клиент должен выдать 60fps на заданной спецификации. Сервер должен обеспечить заданные ccu или количество запросов в секунду.
Как только мы выходим за рамки требований, разговор теряет всякий смысл. GC медленный, IL медленный, динамика медленная, трамваи медленные. Один C++ быстрый, и веб-сайты нужно писать на нем.
Касательно стоимости поддержки:
Технически у динамики есть свои плюсы, которые в ветке упоминались. Рефакторинг часто делать быстрее, хотя гарантий компилятора много меньше. Ввообще польза от статической компиляции при поддержке в первую очередь носит информационный характер. Баги типизации в динамике — относительная редкость, легко ловятся и очень легко чинятся. (Сужу по опыту, статистикой не владею).
Опять же, стоимость поддержки — задача в том числе экономическая, и если в моей деревне программиста поддержки, перешедшего, к примеру, с java на средних размеров проект с Питоном, Эрлангом, JS или пусть тогда и C# можно обучить максимум за месяц, после чего он начнет приносить пользу, то Nemerle и С++ сложнее и дороже.
_>>Например, почему-то поддержка того же Эрланга со стороны ИДЕ намного лучше, чем существующая на данный момент поддержка Nemerle. WH> Я ещё не видел ни одной ИДЕ для динамически типизированных языков, которую не мог бы запутать десятком строк кода.
Честно говоря, не вижу прямой связи между моим утверждением и твоим возражением.
_>>Резюмируя — чтобы тащить динамику в продакшн действительно нужны веские причины, но при их наличии динамика не табу. WH>Пока что таких причин так и не назвали.
Ну как же, называли, с одной ты даже согласился — есть ниши, где на данный момент статическая типизация не представлена.
Здравствуйте, LaPerouse, Вы писали:
LP>Ну и? Ты ведь говоришь не про компилятор под определенный язык, а универсальный компилятор. Я все жду, когда же ты скажешь наконец, что ваш продукт предоставляет (или собирается предоставлять) способ для более быстрого построения компилятора под конкретный язык (это именно то, что люди ждут от подобных инструментов), но ты все твердишь про полностью автоматический способ построения такого компилятора исходя лишь из формального описания языка, что можно реализовать лишь для определенного семейства похожих языков, но не для всего множества существующих языков.
Тут главная идея в иерархии языков.
Те если у нас в стандартной поставке будет
MSIL++ -> MSIL ибо MSIL ужасен. Делать переписывание напрямую в него весьма утомительное занятие.
MSIL -> LLVM
MSIL -> JavaScript
То реализовав C# -> MSIL++ мы автоматом получим компиляцию C# в MSIL, LLVM и JavaScript.
LP>Закаты вручную там начинаются как раз при компиляции. Иде делается достаточно прямо и тупо.
Когда я на него смотрел, они там были везде.
LP>Универсальный алгоритм абсолютно бесполезен. Иначе все в этом мире писалось бы на Прологе, который работает на одном-единственном алгоритме перебора с откатами, ну и костылями, позволяющими ограничить перебор. Ну еще я не знаю ни одной реализации пролога, которая использовала бы graph rewriting. Это говорит о том, что использование этого алгоритма менее обравданов данном случае, ну или что все идиоты.
Какое отношение пролог имеет к переписыванию одного языка в другой?
Да ни какого.
Он для этой задачи вообще плохо подходит.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, LaPerouse, Вы писали:
LP>Кроме одного случая. Когда динамика используется для интеграции систем друг с другом (на уровне получить из одной системы и передать в другую) при отсутствии всякого метаописания, то есть без возможности автоматически сгенерировать классы.
И когда такое происходит?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, meadow_meal, Вы писали:
_>При выполнении становится известен. На стадии компиляции нет.
Ну а что вообще можно сделать с чем-то, про что тебе ничего неизвестно когда ты код пишешь?
_>Да все что угодно. Например, что пользователь скажет (приложения или библиотеки).
Ты пользователю предлагаешь код писать?
_>Ну вот json там лежит, к примеру, одному из тысячи. Осмысленность привнесет пользователь скриптом на JavaScript. Зачем мне тут статическая типизация?
Я вообще не понимаю, что за сценарий ты описываешь.
_>Поверю на слово, если приведешь типы этих двух переменных.
Например, так. Синтаксис из головы. Каждая строчка может быть в своей сборке.
Либо они могут быть в одной и произвольно ссылаться друг на друга.
case A { ... }
case B { ... }
case C { ... }
case D { ... }
case E { ... }
case F { ... }
set Set1 = A | B | C | D;
set Set2 = A | C | E | F;
set Set3 = A | C;
Переменные типа Set3 можно без проверки во время исполнения присвоить переменным типа Set1 и Set2.
_>Чего нет, вариантов? (все-таки в примере упор на варианты, а не pm — что до pm, то где-то есть, а где-то его заменяют другие языковые средства).
Жуткий закат солнца вручную его заменят.
_>Нет же, про статическую (в языках, в которых проблемы с выражением простой дизъюнкции типов).
1)Это проблемы конкретных языков.
И я сразу написал, что есть плохие статически типизированные языки.
Единственный объективный аргумент в пользу динамической типизации: Нужно писать меньше кода.
Но если в случае с жабой выигрыш существенный. То в случае с языками, где есть вывод типов и метапрограммирование выигрыш сводится примерно к нулю.
Ну и в динамике вообще никакого контроля нет.
_>А я просто не понял этот аргумент. Он позволяет писать меньше кода, экономя на явном указании типов? В контексте дискуссии это мелочи. Или что-то еще?
Единственное преимущество динамической типизации: нужно писать меньше кода.
Других нет.
Вывод типов убивает это преимущество.
_>Ну и опять же, в динамическом Эрланге и типы можно указывать, и вывод типов есть. Просто проверка типизации происходит не при компиляции, а при статическом анализе.
Те отдельным инструментом превращаем эрланг в статически типизированный язык.
И почему появился этот инструмент?
Просто тут меня пытаются убедить, что это всё не нужно.
_>Как программисты мы решаем инженерные задачи. Наша программа должна работать в заданных ограничениях. Нет смысла говорить о "в общем низкой производительности" или "в общем высоком потреблении памяти". Память не имеет значения для cpu или io bound приложений на выделенном сервере. Допустимая производительность некоторых консольных приложений может варьироваться в пределах нескольких порядков. Игровой клиент должен выдать 60fps на заданной спецификации. Сервер должен обеспечить заданные ccu или количество запросов в секунду.
А потом происходит рост нагрузки и большие разборки в EVE online превращаются в пошаговые.
А всё по тому, что питон не тянет.
А если ещё вспомнить про то, что вычисления требуют энергию... а потом вспомнить про мобильные устройства...
Короче если приложение будет работать в 10 раз медленнее, то оно съест батарею в 10 раз быстрее.
Даже не смотря на то, что отклик у него будет удовлетворительным.
_>Как только мы выходим за рамки требований, разговор теряет всякий смысл. GC медленный, IL медленный, динамика медленная, трамваи медленные. Один C++ быстрый, и веб-сайты нужно писать на нем.
IL тормозит только по тому, что мелкософт не вложился в оптимизатор от слова совсем.
_>Технически у динамики есть свои плюсы, которые в ветке упоминались.
Не выдержали критики.
_> Рефакторинг часто делать быстрее, хотя гарантий компилятора много меньше. Это полнейшая чушь.
Если кода несколько мегабайт, то я меняю сигнатуру метода, и компилятор мне рассказывает, где нужно изменить код.
При этом про половину мест я забыл, ибо писал этот код год назад, а про другую не знал, ибо писал вообще не я.
Что мне даст динамика? Да ничего.
_>Опять же, стоимость поддержки — задача в том числе экономическая,
И статика тут очень неплохо помогает.
Ибо ловит очень большой класс ошибок.
_>и если в моей деревне программиста поддержки, перешедшего, к примеру, с java на средних размеров проект с Питоном, Эрлангом, JS или пусть тогда и C# можно обучить максимум за месяц, после чего он начнет приносить пользу, то Nemerle и С++ сложнее и дороже.
Про С++ согласен. Он очень запутанный.
А вот про немерле нет. Чтобы после жабы не выучить его за несколько дней нужно быть полный гоблином.
_>Честно говоря, не вижу прямой связи между моим утверждением и твоим возражением.
ИДЕ для динамики просто не работает.
А раз она не работает, она не может быть лучше, чем та, что работает.
_>Ну как же, называли, с одной ты даже согласился
С какой?
_>- есть ниши, где на данный момент статическая типизация не представлена.
Это ты про то, что какой-то диверсант засунул жабаскрипт в браузеры?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Ну так таких задач то множество. Кстати, если посмотреть на многие веб-решения, то хотя в целом система выглядит большой, но на практике всё сводится ко множеству не связанных между собой скриптов как раз такого размера (обычно просто прокладка между браузером и БД). WH>Вот только на практике они связаны.
Да ничего подобного. Вот у меня перед глазами весьма нетривиальный сайт (там и чаты и видео/аудио и обмен файлами). На сервере всё реализуется через пару десятков Питон скриптов размером как раз в 2-3 экрана. Эти скрипты заняты исключительно ответами на ajax запросы (сами страницы отдаются сервером статически, а вся динамика реализована на JS). Причём у них между собой почти ничего общего. Разве что они все используют WSGI и некую ORM, но это же уже сторонние библиотеки и к сайту отношения не имеют.
_>>Нуу не за день, а скажем за недельку (общее решение, а не частный скрипт), но да, ничего сложного. WH>Я говорю по запускалку. WH>Что там неделю писать?
Ты запускалкой называешь эту http://docs.fabfile.org/en/1.10/tutorial.html штуку (про неё же речь шла)? Там конечно ничего принципиально сложного нет, но есть множество мелкий нюансов, так что явно не один день. )))
_>>Только вот дело в том, что у меня есть множество других дел, гораздо более сложных, и тратить время на написание подобной ерунды нет никакого желание. Хочется просто скачать и чтобы всё работало из коробки. ) WH>Мы говорим не про то есть готовые инструменты или нет, а про то есть ли толк от динамической типизации. WH>Это сильно разные темы.
Так а это очень просто можно переформулировать: а о каком вообще толке от статической типизации может идти речь, если нет в наличие готовых инструментов? Нам же надо работать, а не теоретические рассуждения проводить...
Ну и кстати из этого тоже следует интересная тема для размышлений: а почему так сложилось, что на динамических языках полно подобных инструментов, а на статических считай что вообще нет? Предположения вида "потому что вся индустрия — идиоты" я обычно рассматриваю с очень большим сомнением... )))
_>>Это Хаскель то не тяжеловесный? ))) Ну да, если держаться строго в рамках этого DSL, то конечно всё выглядит просто. Только вот в таких случаях скрипты и не нужны особо (хватит обычных bat файлов). А стоит сделать малейших шаг в сторону (собственно ради чего и нужен Питон), как в данном случае всплывут кривые монады и прочие радости Хаскеля. При таком подходе я буду думать скорее не о требуемом алгоритме скрипта, а о том как же его записать на этом "модном" языке...))) WH> Ты только что читал насквозь монадический код. WH>Слово do видишь? Это начало монадического кода.
Я в курсе. ) Но там всё выглядит нормально только потому, что мы используем исключительно готовые функции (из DSL) и не пытаемся работать с переменными. А стоит нам заняться написанием своих функций (естественно работающих с IO) или захотеть попользоваться переменной с состоянием, то всё монадное уродство тут же вылезет в полный рост.
Вообще самая мысль о "простом и удобном Хаскеле" для меня звучит как странная шутка. ))) В принципе среди статически типизированных языков есть несколько вполне себе простых и удобных, но для скриптов они тоже не особо подходят из-за отсутствия соответствующей инфраструктуры. Но это хотя бы поправимо, если кто-то займётся (только почему-то все предпочитают использовать вместо этого динамику)... А у Хаскеля тут нет шансов, даже если ему полноценно разовьют инфраструктуру. )))
_>>Сервер должен обеспечить заданные ccu или количество запросов в секунду. WH>А потом происходит рост нагрузки и большие разборки в EVE online превращаются в пошаговые. WH>А всё по тому, что питон не тянет.
/o\
У EVE Online нагрузки, которые никто не потянет (или, вернее, очень мало кто потянет). Основные расчеты, которые требуют скорости они точно не на Питоне делают.
Только данные:
• EVE database is currently at 1.3 terabytes
• Database transactions are usually around 1500 per second, reaching 2000 per second at peak hours
• ‘Items’ table receives over 9 million insertions in a day (not counting update and select statements)
С нетерпением ждем «правильный статически типизированый язык Немерле» с такими же показателями
Главная проблема серверов в EVE Online — это банальное количество предметов, требующих взаимодействия. Ну типа
- Collision is defined as the intersection of two time-extruded spheres (cylinders with dome shaped end-caps)
— Collision response is highly elastic (conservation of momentum)
И таких столкновений на одну битву в EVE — десятки тысяч в секунду. И вот это все точно не в Питоне делается. И ты посмотри — не справляется, ага. Ах, да, информацию даже не о столкновениях, а о любом действии надо раздавать всем объектам в системе.
Здравствуйте, WolfHound, Вы писали:
_>>При выполнении становится известен. На стадии компиляции нет. WH>Ну а что вообще можно сделать с чем-то, про что тебе ничего неизвестно когда ты код пишешь? _>>Да все что угодно. Например, что пользователь скажет (приложения или библиотеки). WH>Ты пользователю предлагаешь код писать?
Если речь о библиотеке, то пользователю библиотеки. Например есть удаленный rpc-сервер, как автор библиотеки я ничего о схеме не знаю, а может схемы и вовсе нет, но пользователю это не помешает написать Service.SomeMethod(Arg), если я предоставил Service.
Если речь о приложении, то да, иногда предлагаю, да и ветка про dsl.
_>>Ну вот json там лежит, к примеру, одному из тысячи. Осмысленность привнесет пользователь скриптом на JavaScript. Зачем мне тут статическая типизация? WH>Я вообще не понимаю, что за сценарий ты описываешь.
Опять же, к примеру — свертку по документо-ориентированной базе, или обработку потока json событий при отсутствии схемы, или веб-робота, который знает как получить и выдать неструктурированные данные но не знает что с ними делать.
WH>Например, так. Синтаксис из головы. Каждая строчка может быть в своей сборке. WH>Либо они могут быть в одной и произвольно ссылаться друг на друга. WH>
WH>case A { ... }
WH>case B { ... }
WH>case C { ... }
WH>case D { ... }
WH>case E { ... }
WH>case F { ... }
WH>set Set1 = A | B | C | D;
WH>set Set2 = A | C | E | F;
WH>set Set3 = A | C;
WH>
WH>Переменные типа Set3 можно без проверки во время исполнения присвоить переменным типа Set1 и Set2.
можно? Если можно, то это круто, но довольно неожиданно. Если нельзя, то это не совсем то, конечно.
Но если после замены int на B все заработает, то задача, как я ее сформулировал, решена.
_>>Нет же, про статическую (в языках, в которых проблемы с выражением простой дизъюнкции типов). WH>1)Это проблемы конкретных языков. WH>И я сразу написал, что есть плохие статически типизированные языки.
Ну тогда C#, Nemerle — плохие? Да нет, просто есть вещи, которые просты для динамики и нетривиальны для статики.
WH>Единственное преимущество динамической типизации: нужно писать меньше кода. WH>Других нет. WH>Вывод типов убивает это преимущество.
Ну не просто меньше, а кода, который более логичным, очевидным образом передает намерения программиста. А не то, что явную декларацию типов выкинули, и меньше кода получилось. Вывод типов здесь вообще ортогонален. В nemerle вывод типов (в объеме большем чем в C#) не киллер-фича, а так, вишенка на торте, чтобы multiple clauses страшно не выглядели, а то что он есть для локальных функций — небольшое, но не критичное, удобство.
_>>Ну и опять же, в динамическом Эрланге и типы можно указывать, и вывод типов есть. Просто проверка типизации происходит не при компиляции, а при статическом анализе. WH>Те отдельным инструментом превращаем эрланг в статически типизированный язык.
Не превращается. Виртуальная машина соответствие типов указанным не контролирует.
WH>И почему появился этот инструмент?
Очевидно, была потребность. Да и разве кто спорит, что статический контроль типов очень важен?
WH>А потом происходит рост нагрузки и большие разборки в EVE online превращаются в пошаговые. WH>А всё по тому, что питон не тянет.
Может потому, что питон не тянет нормальное горизонтальное масштабирование. А не тянуть с ростом нагрузки характерно для любого языка, чудес не бывает. Ну и есть немалый шанс, что без питона Eve Online вообще бы не существовало.
_>>Как только мы выходим за рамки требований, разговор теряет всякий смысл. GC медленный, IL медленный, динамика медленная, трамваи медленные. Один C++ быстрый, и веб-сайты нужно писать на нем. WH>IL тормозит только по тому, что мелкософт не вложился в оптимизатор от слова совсем.
Да мне все равно, почему он тормозит. Мне важно, обеспечивает ли он нужную мне производительность.
_>> Рефакторинг часто делать быстрее, хотя гарантий компилятора много меньше. WH> Это полнейшая чушь. WH>Если кода несколько мегабайт, то я меняю сигнатуру метода, и компилятор мне рассказывает, где нужно изменить код. WH>При этом про половину мест я забыл, ибо писал этот код год назад, а про другую не знал, ибо писал вообще не я.
Да, а потом ты все эти места правишь полчаса, разбираясь в коде, который не ты писал год назад, когда все что ты хотел это прототипировать изменение api и посмотреть как будет выглядеть код в конкретном модуле, прогнать тесты и погонять в рантайме.
WH>Что мне даст динамика? Да ничего.
Зависит от языка. Для многих языков найти все вызовы конкретного метода — тривиальная задача.
_>>и если в моей деревне программиста поддержки, перешедшего, к примеру, с java на средних размеров проект с Питоном, Эрлангом, JS или пусть тогда и C# можно обучить максимум за месяц, после чего он начнет приносить пользу, то Nemerle и С++ сложнее и дороже. WH>Про С++ согласен. Он очень запутанный. WH>А вот про немерле нет. Чтобы после жабы не выучить его за несколько дней нужно быть полный гоблином.
У немерле:
1) Документация или отсутствует, или скудна и устарела
2) Макрописание намного сложнее, чем рассказывают евангелисты, поддержки ide при этом особой нет, пока не потыкаешься сам — не разберешься.
3) Синтаксис для новичка непривычный, одни .[] чего стоят — в отличие от языков на которых сел и пишешь, тут еще пальцы набить надо.
...
Ну и речь шла не просто об обучить языку, а о начать приносить пользу на проекте. Код на немерле (сужу по себе и скажем коду самого немерле, не боясь прослыть гоблином) — может варьироваться от четко выраженной мысли до "вообще ни хрена не понятно", со сдвигом среднего вправо во этой шкале. Тот же питон — открытая книга, даже если ты про него только вчера узнал.
При этом мне немерле в общем нравится, и в инфраструктурных проектах мы его используем.
WH>ИДЕ для динамики просто не работает.
Хотелось бы услышать подробности, что именно не работает.
_>>- есть ниши, где на данный момент статическая типизация не представлена. WH>Это ты про то, что какой-то диверсант засунул жабаскрипт в браузеры?
Хотя бы — ну и с горячей заменой кода тоже диверсанты отличились.
_>Хотя бы — ну и с горячей заменой кода тоже диверсанты отличились.
Как оказалось, в конце 90-х чуть ли не вся команда GHC в полном составе сидела в Эрикссоне и пыталась год натянуть систему типов на Erlang. Так и не смогли натянуть Главный камень преткновения — горячая замена кода, но были еще какие-то заморочки, уже не помню, какие.
Здравствуйте, meadow_meal, Вы писали:
_>Если речь о библиотеке, то пользователю библиотеки. Например есть удаленный rpc-сервер, как автор библиотеки я ничего о схеме не знаю, а может схемы и вовсе нет, но пользователю это не помешает написать Service.SomeMethod(Arg), если я предоставил Service.
Как так нет схемы?
А про SomeMethod откуда известно?
А про то, что ему можно передавать, откуда известно?
Это и есть схема.
Нельзя ничего сделать с сервисом, схема которого не известна.
_>Опять же, к примеру — свертку по документо-ориентированной базе, или обработку потока json событий при отсутствии схемы,
Схема есть.
Её не может не быть.
Она может быть описана не формально, но она всегда есть.
_>или веб-робота, который знает как получить и выдать неструктурированные данные но не знает что с ними делать.
И тут схема тоже есть.
_>можно? Если можно, то это круто, но довольно неожиданно. Если нельзя, то это не совсем то, конечно. _>Но если после замены int на B все заработает, то задача, как я ее сформулировал, решена.
Тут зависит от правил языка.
Технически можно без проблем из if'а возвращать объединение типов, если типы разные.
Но это плохой дизайн.
Так что в таком виде будет ошибка компиляции.
А вот если одну из веток привести объединению то без проблем.
_>Ну тогда C#, Nemerle — плохие?
C# плохой
Nemerle хороший
_>Да нет, просто есть вещи, которые просты для динамики и нетривиальны для статики.
Какие?
_>Ну не просто меньше, а кода, который более логичным, очевидным образом передает намерения программиста.
Пример можно?
_>Не превращается. Виртуальная машина соответствие типов указанным не контролирует.
Это уже не важно.
Процессор за типами вообще не следит.
_>Очевидно, была потребность. Да и разве кто спорит, что статический контроль типов очень важен?
Вот прямо сейчас ты пытаешься убедить меня, что не важен.
_>Да, а потом ты все эти места правишь полчаса, разбираясь в коде, который не ты писал год назад, когда все что ты хотел это прототипировать изменение api и посмотреть как будет выглядеть код в конкретном модуле, прогнать тесты и погонять в рантайме.
После чего ты будешь ещё несколько месяцев вылавливать все места, где ты забыл изменить код.
Короче рефакторинг в статике несравнимо быстрее.
_>У немерле: _>1) Документация или отсутствует, или скудна и устарела
Мне она вообще не понадобилась.
_>2) Макрописание намного сложнее, чем рассказывают евангелисты, поддержки ide при этом особой нет, пока не потыкаешься сам — не разберешься.
Для того чтобы поддерживать проект оно не нужно.
_>3) Синтаксис для новичка непривычный, одни .[] чего стоят — в отличие от языков на которых сел и пишешь, тут еще пальцы набить надо.
Сколько кода ты написал на немерле?
Сколько раз ты использовал этот синтаксис?
В реальности вывод типов полностью убирает необходимость его использовать.
_>Ну и речь шла не просто об обучить языку, а о начать приносить пользу на проекте. Код на немерле (сужу по себе и скажем коду самого немерле, не боясь прослыть гоблином) — может варьироваться от четко выраженной мысли до "вообще ни хрена не понятно", со сдвигом среднего вправо во этой шкале. Тот же питон — открытая книга, даже если ты про него только вчера узнал.
Это просто не правда.
На любом языке можно писать код разного качества.
WH>>ИДЕ для динамики просто не работает. _>Хотелось бы услышать подробности, что именно не работает.
Примерно всё.
Попробуй переименовать метод класса так, чтобы не переименовались все остальные методы с этим именем.
При том, что в статически типизированном языке можно даже отдельные перегрузки переименовывать.
Вот что показывает интеграция немерле при попытке переименовать две разные перегрузки метода Seq.
_>Хотя бы — ну и с горячей заменой кода тоже диверсанты отличились.
edit and continue я ещё в седьмой студии для С++ использовал.
А появился он ещё раньше.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Да ничего подобного. Вот у меня перед глазами весьма нетривиальный сайт (там и чаты и видео/аудио и обмен файлами). На сервере всё реализуется через пару десятков Питон скриптов размером как раз в 2-3 экрана. Эти скрипты заняты исключительно ответами на ajax запросы (сами страницы отдаются сервером статически, а вся динамика реализована на JS). Причём у них между собой почти ничего общего. Разве что они все используют WSGI и некую ORM, но это же уже сторонние библиотеки и к сайту отношения не имеют.
И json они друг другу не гоняют?
_>Ты запускалкой называешь эту http://docs.fabfile.org/en/1.10/tutorial.html штуку (про неё же речь шла)? Там конечно ничего принципиально сложного нет, но есть множество мелкий нюансов, так что явно не один день. )))
Из описания все, что она делает, это вызывает метод по имени.
Что там можно писать несколько дней я не знаю.
_>Так а это очень просто можно переформулировать: а о каком вообще толке от статической типизации может идти речь, если нет в наличие готовых инструментов? Нам же надо работать, а не теоретические рассуждения проводить...
Не переводи тему.
_>Ну и кстати из этого тоже следует интересная тема для размышлений: а почему так сложилось, что на динамических языках полно подобных инструментов, а на статических считай что вообще нет? Предположения вида "потому что вся индустрия — идиоты" я обычно рассматриваю с очень большим сомнением... )))
Если бы в индустрии были только умные люди, динамическая типизация не появилась бы вообще.
_>Я в курсе. ) Но там всё выглядит нормально только потому, что мы используем исключительно готовые функции (из DSL) и не пытаемся работать с переменными. А стоит нам заняться написанием своих функций (естественно работающих с IO) или захотеть попользоваться переменной с состоянием, то всё монадное уродство тут же вылезет в полный рост.
Так там же тот же сахар работает.
А чем плоха такая работа со значениями, я не понимаю.
do x1 <- action1
x2 <- action2
action3 x1 x2
Что касается переменных с состоянием, то они только запутывают код.
Единственная причина их использовать это необходимость уменьшить асимптотику некоторых алгоритмов.
Что-то я сомневаюсь, что в скриптах есть такие алгоритмы.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Если речь о библиотеке, то пользователю библиотеки. Например есть удаленный rpc-сервер, как автор библиотеки я ничего о схеме не знаю, а может схемы и вовсе нет, но пользователю это не помешает написать Service.SomeMethod(Arg), если я предоставил Service. WH>Как так нет схемы? WH>А про SomeMethod откуда известно?
Мне — автору библиотеки? Ниоткуда. Моя задача, чтобы пользователь, которому известно, мог этот метод вызвать без плясок с бубном.
_>>Опять же, к примеру — свертку по документо-ориентированной базе, или обработку потока json событий при отсутствии схемы, WH>Схема есть. WH>Её не может не быть. WH>Она может быть описана не формально, но она всегда есть.
Формально не описана = нет. Пока ты заставляешь пользователя что-то формально описывать, мой пользователь уже написал скриптик и пьет чай. Да и — в случае потока событий — что там насобирали с разных версий приложения, ни в какую схему не загонишь.
_>>или веб-робота, который знает как получить и выдать неструктурированные данные но не знает что с ними делать. WH>И тут схема тоже есть.
У робота? нет. Его задача данные собрать аккуратно и передать кому надо. Ему схему не просто знать не надо, а противопоказано, так как схема (которой, разумеется, формально и нет) во времени меняется намного чаще, чем робот.
_>>Да нет, просто есть вещи, которые просты для динамики и нетривиальны для статики. WH>Какие?
Наша песня хороша, начинай сначала.
_>>Ну не просто меньше, а кода, который более логичным, очевидным образом передает намерения программиста. WH>Пример можно?
Простейший:
if (accountUpdate.age != undefined)
account.age = accountUpdate.age;
где firstName имеет тип int? (возраст задан целым числом или не задан (null), либо accountUpdate не содержит информацию о возрасте). Вот на "плохом" C# так нельзя. "Хороший" nemerle может как-нибудь выкрутится.
Поэтому лучший пример — это Service.SomeMethod(...) для которого тебе придется возиться с генерацией кода по схеме, которой у меня нет.
_>>Не превращается. Виртуальная машина соответствие типов указанным не контролирует. WH>Это уже не важно. WH>Процессор за типами вообще не следит.
Прежде чем возражать, уточню: ты действительно утверждаешь, что Эрланг — статически типизированный язык?
_>>Очевидно, была потребность. Да и разве кто спорит, что статический контроль типов очень важен? WH>Вот прямо сейчас ты пытаешься убедить меня, что не важен.
Не надо мне глупости приписывать.
Напомню свои тезисы:
1) Есть ниши, где статика не представлена, по каким бы то ни было причинам.
2) Есть весьма ограниченное число задач, где статическая типизация больше мешает, чем помогает.
3) Есть весьма ограниченное число ситуаций, когда динамика выразительнее, чем доступные альтернативы из статически типизированных языков.
4) Динамическая типизация — не всегда абсолютное зло, но иногда хороший выбор.
При прочих равных выбор статически-типизированного языка предпочтителен.
_>>Да, а потом ты все эти места правишь полчаса, разбираясь в коде, который не ты писал год назад, когда все что ты хотел это прототипировать изменение api и посмотреть как будет выглядеть код в конкретном модуле, прогнать тесты и погонять в рантайме. WH>После чего ты будешь ещё несколько месяцев вылавливать все места, где ты забыл изменить код. WH>Короче рефакторинг в статике несравнимо быстрее.
Не вижу смысла продолжать спор по этому пункту. Оба останемся со своим опытом.
_>>У немерле: _>>1) Документация или отсутствует, или скудна и устарела WH>Мне она вообще не понадобилась.
Документация — для гоблинов? Ну ок.
_>>2) Макрописание намного сложнее, чем рассказывают евангелисты, поддержки ide при этом особой нет, пока не потыкаешься сам — не разберешься. WH>Для того чтобы поддерживать проект оно не нужно.
Ок.
_>>3) Синтаксис для новичка непривычный, одни .[] чего стоят — в отличие от языков на которых сел и пишешь, тут еще пальцы набить надо. WH>Сколько кода ты написал на немерле?
Вот честно полез в студию проверить Code Metrics, а она для Nemerle и не работает.
WH>Сколько раз ты использовал этот синтаксис? WH>В реальности вывод типов полностью убирает необходимость его использовать.
Сделал поиск по исходным кодам Nitra, скажу деликатно, что ты преувеличил.
_>>Ну и речь шла не просто об обучить языку, а о начать приносить пользу на проекте. Код на немерле (сужу по себе и скажем коду самого немерле, не боясь прослыть гоблином) — может варьироваться от четко выраженной мысли до "вообще ни хрена не понятно", со сдвигом среднего вправо во этой шкале. Тот же питон — открытая книга, даже если ты про него только вчера узнал. WH>Это просто не правда. WH>На любом языке можно писать код разного качества.
Я не про качество, а про количество и сложность концепций.
WH>>>ИДЕ для динамики просто не работает. _>>Хотелось бы услышать подробности, что именно не работает. WH>Примерно всё. WH>Попробуй переименовать метод класса так, чтобы не переименовались все остальные методы с этим именем.
В Эрланге нет классов. (Напоминаю, что я говорил о поддержке конкретно Эрланга). Проблемы переименовать функцию, естественно, не возникает.
_>>Хотя бы — ну и с горячей заменой кода тоже диверсанты отличились. WH>edit and continue я ещё в седьмой студии для С++ использовал. WH>А появился он ещё раньше.
Здравствуйте, Mamut, Вы писали:
M>Как оказалось, в конце 90-х чуть ли не вся команда GHC в полном составе сидела в Эрикссоне и пыталась год натянуть систему типов на Erlang. Так и не смогли натянуть Главный камень преткновения — горячая замена кода, но были еще какие-то заморочки, уже не помню, какие.
Возможно, message passing, тем более между разными нодами.
Здравствуйте, meadow_meal, Вы писали:
_>Мне — автору библиотеки? Ниоткуда. Моя задача, чтобы пользователь, которому известно, мог этот метод вызвать без плясок с бубном.
Какой ещё библиотеки?
Я тебя вообще перестал понимать.
Можешь чётко сформулировать задачу?
_>Формально не описана = нет. Пока ты заставляешь пользователя что-то формально описывать, мой пользователь уже написал скриптик и пьет чай.
Так откуда он вообще узнает что вызывать?
_>Да и — в случае потока событий — что там насобирали с разных версий приложения, ни в какую схему не загонишь.
Чего?
_>Простейший: _>
На статически типизированном будет примерно так же.
_>Поэтому лучший пример — это Service.SomeMethod(...) для которого тебе придется возиться с генерацией кода по схеме, которой у меня нет.
Да как ты вообще про этот метод узнал без схемы то?
_>Прежде чем возражать, уточню: ты действительно утверждаешь, что Эрланг — статически типизированный язык?
Мы говорим про статически типизированный диалект.
В котором типы описаны и проверяются статически.
То, что эрланг машина не использует эту информацию, ничего не меняет.
_>Напомню свои тезисы: _>1) Есть ниши, где статика не представлена, по каким бы то ни было причинам.
По дурости.
_>2) Есть весьма ограниченное число задач, где статическая типизация больше мешает, чем помогает.
Так ни одну и не назвали.
_>3) Есть весьма ограниченное число ситуаций, когда динамика выразительнее, чем доступные альтернативы из статически типизированных языков.
По сравнению с жабой.
_>4) Динамическая типизация — не всегда абсолютное зло, но иногда хороший выбор.
Всегда плохой.
WH>>После чего ты будешь ещё несколько месяцев вылавливать все места, где ты забыл изменить код. WH>>Короче рефакторинг в статике несравнимо быстрее. _>Не вижу смысла продолжать спор по этому пункту. Оба останемся со своим опытом.
Ну так что ты будешь делать в случае с динамикой то?
Каждую букву кода тестами покрывать?
_>Сделал поиск по исходным кодам Nitra, скажу деликатно, что ты преувеличил.
Там крайне специфический код.
Посмотри исходники немерла.
WH>>Это просто не правда. WH>>На любом языке можно писать код разного качества. _>Я не про качество, а про количество и сложность концепций.
Как думаешь, какое ощущение будет у среднего питониста от этого кода http://pyparsing.wikispaces.com/file/view/pythonGrammarParser.py/30100174/pythonGrammarParser.py
А такого?
def perm(l):
sz = len(l)
print (l)
if sz <= 1:
print ('sz <= 1')
return [l]
return [p[:i]+[l[0]]+p[i:] for i in range(sz) for p in perm(l[1:])]
_>В Эрланге нет классов. (Напоминаю, что я говорил о поддержке конкретно Эрланга). Проблемы переименовать функцию, естественно, не возникает.
Только методом глобальной замены имени.
Только это может любой текстовый редактор, который про код вообще ничего не знает.
_>И как это сделать на работающем сервере?
Ещё раз: Мы говорим про возможность.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
_>>Да ничего подобного. Вот у меня перед глазами весьма нетривиальный сайт (там и чаты и видео/аудио и обмен файлами). На сервере всё реализуется через пару десятков Питон скриптов размером как раз в 2-3 экрана. Эти скрипты заняты исключительно ответами на ajax запросы (сами страницы отдаются сервером статически, а вся динамика реализована на JS). Причём у них между собой почти ничего общего. Разве что они все используют WSGI и некую ORM, но это же уже сторонние библиотеки и к сайту отношения не имеют. WH>И json они друг другу не гоняют?
Друг другу? ) Как ты вообще представляешь, чтобы скрипты реакции на ajax взаимодействовали друг с другом? ) Они же живут в полностью отдельных мирах. Естественно они работают с общими данными, но только через БД или клиентский JS.
_>>Ты запускалкой называешь эту http://docs.fabfile.org/en/1.10/tutorial.html штуку (про неё же речь шла)? Там конечно ничего принципиально сложного нет, но есть множество мелкий нюансов, так что явно не один день. ))) WH>Из описания все, что она делает, это вызывает метод по имени. WH>Что там можно писать несколько дней я не знаю.
Какой ещё метод по имени? ) Там эмуляция шелла в языке, причём действующая одинаково и на локальной машине и на удалённой (по ssh). Так что там с одними нюансами ssh и перехвата ввода/вывода повозиться надо. )))
_>>Ну и кстати из этого тоже следует интересная тема для размышлений: а почему так сложилось, что на динамических языках полно подобных инструментов, а на статических считай что вообще нет? Предположения вида "потому что вся индустрия — идиоты" я обычно рассматриваю с очень большим сомнением... ))) WH>Если бы в индустрии были только умные люди, динамическая типизация не появилась бы вообще.
Ну это спорный вопрос. Вот скажем какой-нибудь там IDispatch (на котором очень много чего работает) — это динамическая типизация или статическая? )
WH>Так там же тот же сахар работает. WH>А чем плоха такая работа со значениями, я не понимаю. WH>
Да не о том речь. Ты вот попробуй написать свою функцию, которая скажем будет трансформировать какую-то строку и печатать в консоль результат. И сравни её объявление с аналогом на Питоне. )
WH>Что касается переменных с состоянием, то они только запутывают код. WH>Единственная причина их использовать это необходимость уменьшить асимптотику некоторых алгоритмов. WH>Что-то я сомневаюсь, что в скриптах есть такие алгоритмы.
Да ладно, for'ы в подобных скриптах на каждом шагу.
Ты только что читал насквозь монадический код.
(все-таки в примере упор на варианты, а не pm — что до pm, то где-то есть, а где-то его заменяют другие языковые средства). 
