|
| 1.2, Онаним (?), 23:00, 08/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Есть же Elixir - и на Ruby похож, и производительность и прочие ништяки от Erlang-а.
| | |
| |
| |
| |
| 4.16, Crazy Alex (ok), 03:06, 09/08/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Она есть местами, но упоминать его как эталон скорости смешно. Эрланг - вообще не о том.
В обработке данных, особенно не укладывающихся в жёсткий паттерн (строки те же) - производительность не фонтан. Плюс иммутабельность - когда на неё хорошо логика ложится, а когда и нет. В архитектуре - с OTP и приложением мозгов нормально, но ничего сверхъестественного. Эрланг берёт надёжностью и целостностью платформы - единственное, с чем можно сравнить в плане поддержки всех фаз жизни софта - Java EE (хотя это всё же очень натянутая аналогия). А скорость... если нужна где-то скорость, то для эрланга самое верное решение - запихнуть в эту точку сишное расширение, подо что он заточен очень хорошо.
| | |
| |
| 5.53, rob pike (?), 16:02, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
Под сишные расширения он заточен очень хорошо? С FFI по "удобству" сравнимому только с PerlXS? C NIF, которые блокируют scheduler на сколько хотят и когда хотят? С NIF, которые крашатся, унося с собой всю эрланговскую VM?
Да, dirty scheduler помогает отчасти - но когда оно появилось?
| | |
| |
| |
| |
| 8.76, Аноним (-), 13:09, 10/08/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Нашли с чем сравнивать Lua 8212 в первую очередь встраиваемый язык на всяки... текст свёрнут, показать | | |
|
| 7.78, rob pike (?), 16:39, 10/08/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
ASN.1 и HLASM - тоже очень рабочие штуки.
Тем не менее, перловый XS остается одним из канонических примеров наиболее сложных и неудобных FFI c почти вертикальной learning curve.
| | |
|
|
|
|
| 3.25, Аноним (25), 08:20, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
 а вы использовали elixir для написания приложений уровня ROR или так по теоретизировать решили?
жду с нетерпением бенчарков.
| | |
| |
| 4.58, Crazy Alex (ok), 16:55, 09/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Даже смотреть не стану. Работа со строками и подобным в BEAM быстрой в жизни не была. Ну либо сишными сильно подпёрли, конечно - но тогда нужен либо набор расширений, сравнимый с питоновским, либо сишник в проекте, либо регулярно будете налетать на что-то нештатное, что просаживает производительность.
Опять же - я от вебни далёк ежу лет пять как, и даже смотреть в её сторону не собираюсь. Впрочем, помню, что быстрее ROR быть - не велика заслуга.
| | |
|
|
| 2.89, Аноним (-), 19:21, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
ну в принципе да, что руби что эрланг и эликсир - корнями частично уходят к ванильному прологу, который весьма труЪ в этом плане.
| | |
|
| 1.4, Xasd (ok), 23:18, 08/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
 > процессе разработки удобно использовать команду "crystal play" которая формирует web-интерфейс (по умолчанию localhost:8080) для интерактивного выполнения кода на языке Crystal.
всё больше и больше плодят тупых дыр (про которые раньше люди и не мыслили)..
..и ведь только недавно идиоты из Intellij Idea писали в своём блоге про их открытый socket-порт -- https://blog.jetbrains.com/blog/2016/05/11/security-update-for-intellij-based-
ды перестаньиы вы уже плодить без надобности сервера! в том месте там где они не нужны.. хипсторы чёртовы
| | |
| |
| 2.6, Павел (??), 00:46, 09/08/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
 По многим параметрам на Ruby даже приятнее писать чем на Python
| | |
| |
| |
| 4.33, Michael Shigorin (ok), 09:06, 09/08/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Марсианину - несомненно ©
А что, венерианская логика уже окончательно решила вопрос с табиками и пробельчиками? :)
| | |
| |
| 5.43, Snm (?), 11:25, 09/08/2016 [^] [^^] [^^^] [ответить]
| +6 +/– |
Да даже чиорт с ними с табами-пробелами, к этому в конце концов привыкаешь со временем.
Вот что действительно раздражает - так это встроенные функции, особенно вперемешку с методами классов. Непонятно откуда читать выражение в итоге.
| | |
|
|
| 3.36, robux (ok), 09:13, 09/08/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > По многим параметрам на Ruby даже приятнее писать чем на Python
Сравнил тоже!
Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби).
Нет, мопед конечно тоже неплохой, но уровень эргономики несопоставим.
| | |
| |
| 4.63, _ (??), 17:06, 09/08/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби).
... ну ты держись там, Туарег :))))
| | |
| 4.92, Аноним (-), 23:43, 12/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Это как сравнивать советский мопед "Рига" (пистон) и фольксваген "Туарег" (руби).
Это как сравнивать советский мопед и стремный китайский мотороллер. Ездят конечно оба, но оба медленные и с рядом проблем. Главной из которых является ездок, пытающийся доказать что круче него только яйца.
| | |
|
|
|
| 1.7, Аноним (-), 01:18, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +9 +/– |
> удобный как Ruby
> быстрый как Си
Как они до такого догадались? До них все пытались сделать ровно наоброт.
| | |
| 1.8, angra (ok), 01:22, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +17 +/– |
 Я так понимаю, что сравнительные бенчмарки с С или Go решили не приводить только из скромности. И вообще джентельмены верят на слово, сказали "производительность Си", значит так и есть.
| | |
| |
| 2.9, vdevrvtgrb (?), 01:46, 09/08/2016 [^] [^^] [^^^] [ответить]
| –6 +/– | |
Вы так говорите как будто у Go производительность на уровне С... Единственный язык который достиг цели быть высокоуровневым и иметь производительность на уровне С это Swift.
"As an aside, my Swift implementation of the Mersenne Twister ended up 20% faster than the official mt19937-64.c implementation. Curious to understand what I had done, I ended up “fixing” the C version to be just as fast as the Swift version. Yes, it’s true: with a little tuning, C can be just as fast as Swift.
Welcome to C with love." - http://www.cocoawithlove.com/blog/2016/05/19/random-numbers.html
| | |
| |
| 3.15, chinarulezzz (ok), 02:43, 09/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Getting C-level performance in Swift for numerical algorithms is quirky but not particularly difficult. If you limit yourself to value types (no classes or existentials), use unsafe pointers and tuples instead of arrays, use overflow discarding operators &+/&-/&* instead of normal +/-/*, use while or repeat/while for your loops, then Swift and clang C will generally compile to identical instructions.
Так что
>Единственный язык который достиг цели быть высокоуровневым и иметь производительность на уровне С это Lisaac.
фикс.
| | |
| |
| 4.93, Аноним (-), 23:45, 12/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Getting C-level performance in Swift for numerical algorithms is quirky but not
>> particularly difficult. If you limit yourself to value types (no classes or existentials)
В результате пока сишник просто пишет код, адепт Новых Модных Языков получает знатный брейнфак с заучиванием всех интимных особенностей своего 100-мегабайтного рантайма и где он может стормозить и лагнуть невовремя.
Как там у жабистов говорится? Write once, profile everywhere? :D
| | |
|
| 3.17, Аноним (-), 04:44, 09/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если "official implementation" подразумевает эталонность, то эталонность обычно подразумевает правильность работы и никак не быстродействие.
| | |
| |
| 4.22, Аноним (-), 06:33, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> эталонность обычно подразумевает правильность работы и никак не быстродействие.
одно другому никак не мешает.
| | |
|
| 3.19, angra (ok), 05:24, 09/08/2016 [^] [^^] [^^^] [ответить] | +2 +/– | Не я так говорю, а вы так интерпретируете мои слова Go был упомянут по совсем д... большой текст свёрнут, показать | | |
| |
| 4.56, Аноним (-), 16:47, 09/08/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Ну вот зачем этот маркетоидный булщит? Про жабу точно такие песни были.
При этом Java (с JIT, разумеется) довольно близко подходит к C по производительности.
| | |
|
|
| 2.11, Crazy Alex (ok), 02:09, 09/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
какое, на фиг, тестирование производительности у суровой альфы? Хоть где-то показывает хороший результат - и то хорошо
| | |
| |
| 3.18, angra (ok), 05:11, 09/08/2016 [^] [^^] [^^^] [ответить] | +3 +/– | Если ставишь задачей производительность, то она должна быть уже в альфе А то со... большой текст свёрнут, показать | | |
| |
| 4.21, Аноним (-), 06:29, 09/08/2016 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> rakkudo(реализация perl6)
Там его пилят какие-то аутисты, ушибленные рубями. Добавили ещё столько же операторов (причём ОЧЕНЬ специализированных), убили простые типы, сломали совместимость, завязались на jvm.
Хотя казалось бы, вектор развития (в рамках perl6) очевиден:
* use strict/use warnings по дефолту,
* сделать синтаксис однозначно разбираемым (пусть и ценой частичной потери совместимости),
* стандартизировать объектную систему (чтобы положить конец её переизобретению в виде Moo/Moose/Mouse и пр.),
* признать RPerl официальным подмножеством (как cpython),
* выкинуть из базы всё legacy типа CGI, DB_File и прочий шлак.
| | |
| 4.41, Аномсис (?), 10:40, 09/08/2016 [^] [^^] [^^^] [ответить] | +/– | Не должна, т к в первой альфе намного важнее совсем другое Ну и да, производит... большой текст свёрнут, показать | | |
| |
| 5.45, angra (ok), 11:56, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то первая альфа была зарелизена два года назад, развитие началось четыре года назад. Ну и для очередного выходца из криокамеры сообщаю, что разница в скорости на основе "интерпретатор или компилятор" осталась в далеком прошлом, есть куда более серьезные факторы, ограничивающие производительность. И этот язык тоже никогда не будет равен С по скорости.
| | |
|
| 4.55, Crazy Alex (ok), 16:42, 09/08/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Вообще-то далеко не все хотят максимально возможной производительности, ей часто жертвуют ради каких-то ещё фич. Тот же питон взять - приоритеты совсем другие. И если у этих товарищей желаемый баланс другой - логично, что и диапазон возможного будет другим.
А что до кристала - ну так кое-где там и виден прирост. Но требовать от альфы, чтобы она была быстрее везде - чересчур. Это даже для первого релиза чересчур, собственно.
А отломать динамическую типизацию, отказавшись от фич, которые от неё зависят - вкупе с нормальной компиляцией - вполне нормальная заявка на победу, вагон их таких - те же HipHop и Cython вспоминаются сходу.
| | |
|
|
| 2.39, Аномсис (?), 10:16, 09/08/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Я так понимаю, что сравнительные бенчмарки с С или Go решили не приводить только из скромности. И вообще джентельмены верят на слово, сказали "производительность Си", значит так и есть.
Читать надо внимательней.
Там не написано, что у него производительность, как у Си, а написано лишь то, что такая производительность является целью авторов языка.
Не факт, что они добьются своей цели.
И уж тем более они не продемонстрируют приближённые к цели результаты в альфа версии, т.к. это является очень сложной задачей и её реализация растянется на годы.
| | |
|
| 1.12, Аноним (-), 02:29, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
> на текущей альфа-стадии развития в одних тестах Crystal опережает Ruby в 40 раз
это называется "эффект низкой базы". Сравните с cpython или go и получите свои (минус?) полтора-два раза.
| | |
| 1.23, _KUL (ok), 06:39, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Логика бессмысленная - язык Ruby удобен, но не быстр. С быстр, но не удобен. Нужно создать язык "Crystal" который будет иметь удобство Ruby и скорость С.
ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???
| | |
| |
| 2.28, 12de (?), 08:25, 09/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Логика бессмысленная - язык Ruby удобен, но не быстр. С быстр, но
> не удобен. Нужно создать язык "Crystal" который будет иметь удобство Ruby
> и скорость С.
> ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???
потому что философия языка позволяет все сделать как тебе удобно, 100500 способами. Ну и конечно GC не хитрый. Попробуй, например, с помощью Net::HTTP из stdlib скачать какой нибудь относительно большой файл с сети, или пропарсить несколько тысяч xml тем же Builder. С extenstions наше все. Узкие места подпереть придется.
| | |
| 2.29, Аноним (25), 08:27, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
потомучто там:
- идеология бредовая - "Все есть объект"
- возможность манкипатчить в рантайме
и может чтото еще, что мешает - не особо использовал руби
| | |
| |
| 3.48, Аноним (-), 12:54, 09/08/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> - идеология бредовая - "Все есть объект"
чем плохо иметь простую и регулярную модель языка, в которой всё предельно понятно и сведено к единственной сущности - объект?
> - возможность манкипатчить в рантайме
манкипатчить технически можно где угодно на любых языках (иногда со вставками "станного кода") и везде это плохо.
Но вот чем плохо иметь возможность в динамике переопределять методы объектов и классов?
| | |
| |
| 4.50, Аноним84701 (?), 14:35, 09/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> почему нельзя просто Ruby сделать быстрым как С и всё???
> Но вот чем плохо иметь возможность в динамике переопределять методы объектов и
> классов?
Оптимизация-с сэр.
Вы не поверите, но вызывать нужный метод каждый раз через таблицу может оказаться ощутимо медленне прямого вызова или инлайна. А уж тем более, тот же простой ADD REG1, REG2 будет куда быстрее какого-нибудь универсального
[CODE]
PUSH REG1
PUSH REG2
CALL [METHOD_TABLE + ADD_METHOD]
...
ADD_METHOD:
stackframe creation
MOV REG, [STACKREG-4]
ADD REG, [STACKREG-8]
RET
[/CODE]
особенно когда считать придется действительно много.
Ваш Кэп
| | |
| 4.69, Аноним (-), 23:09, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Но вот чем плохо иметь возможность в динамике переопределять методы объектов и классов?
Динамика и производительность/скорость сочетаются чуть лучше, чем никак.
| | |
|
|
| 2.34, robux (ok), 09:09, 09/08/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> ВОПРОС - почему нельзя просто Ruby сделать быстрым как С и всё???
ОТВЕТ: потому что Ruby - интерпретатор, а Си - компилятор. А интерпретатор никогда по скорости не догонит компилятор. Объяснять почему?
Потому что у интерпретатора при выполнении добавляется промежуточная операция - преобразование текста или байт-кода в машинный код. А компилятор выдаёт сразу машинный код.
Ну а по теме: авторы Crystal пытаются написать Vala :)
Вот зачем они это делают, когда есть Vala - не очень понятно :-)
| | |
| |
| 3.40, angra (ok), 10:22, 09/08/2016 [^] [^^] [^^^] [ответить]
| –3 +/– | |
А если стадия jit занимает доли процента от времени выполнения? А если jit еще и позволяет сгенерировать при этом чуть более эффективный код, который будет выполняться достаточно долго, чтобы перекрыть время затраченное на однократный jit?
На самом деле разница в производительности совсем в другом месте. Но ничего, ты со временем наверстаешь пропущенное за десятилетия в криокамере.
| | |
| |
| 4.42, freehck (ok), 10:56, 09/08/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Это решает скорее проблему распространения, нежели проблемы производительности.
То, что jit откладывает до рантайма можно было бы сделать на этапе компиляции, тем самым обеспечив себе высокую производительность сразу же после запуска программы, минуя фазу jit. Так не делают лишь потому, что скомпилированные под некоторую архитектуру программы надо распространять по машинам данной архитектуры, некоторые из которых поддерживают одни расширения набора команд, некоторые - другие... Вот и берут некоторое общее подмножество, чтобы добиться работы на всех машинах данной архитектуры.
Ничто не мешает вам пересобрать пакет с либой, чтобы добиться в компилируемых языках более высокой производительности. Вон в Debian это делается в пол-пинка. Gentoo изначально под это заточен. Бери - не хочу.
Единственная проблема в том, что фанатам Java и адептам Jit банально лень. Хочется людям ничего не делать, ни о чём не думать, но чтобы оно всё само заработало и показало хорошие результаты.
| | |
| |
| 5.44, angra (ok), 11:44, 09/08/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
Ну давай на этапе компиляции определи мне размер переменной, которая будет считана из конфига или получена иным путем во время выполнения. А ведь в случае иммутабельности после получения инициирующего значения можно сразу определить, можно ли ограничится одним из нативных типов процессора или надо будет оборачивать в какой-нибудь bignum.
| | |
| |
| 6.51, freehck (ok), 15:50, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Ну давай на этапе компиляции определи мне размер переменной, которая будет считана
> из конфига или получена иным путем во время выполнения. А ведь
> в случае иммутабельности после получения инициирующего значения можно сразу определить,
> можно ли ограничится одним из нативных типов процессора или надо будет
> оборачивать в какой-нибудь bignum.
Вряд ли. Раз мы говорим о jit, значит мы говорим о демоне, ибо иначе
jit не окупится. Если мы говорим о демоне, то он скорее всего он
регулярно перечитывает конфиг, и какая тогда иммутабельность?
Короче, сложно представить такую ситуацию. Мысль конечно интересная,
но я не думаю, что мы когда-то столкнёмся с подобным на практике.
| | |
| |
| 7.62, Аноним (-), 17:04, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Раз мы говорим о jit, значит мы говорим о демоне, ибо иначе jit не окупится.
Еще как окупится!
> Если мы говорим о демоне, то он скорее всего он регулярно перечитывает конфиг, и какая тогда иммутабельность?
Иммутабельность не JIT-а, а переменной в программе, которую JIT оптимизирует. Если мы прочитали число, которое влезает в int и процессор имеет команды для работы с int-ами, то JIT сгенерирует нативный код с такими командами, а если нет, то будет работать обёртка (которая тоже может быть оптимизирована JIT-ом, но уже не так эффективно).
| | |
|
| 6.57, Crazy Alex (ok), 16:48, 09/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ну вот на практике в 99.9% случаев можно заранее предсказать (и ограничить) осмысленный диапазон, который будет вполне эффективно реализован. В результате bignum не будет вообще.
| | |
|
|
|
|
| 2.99, Akzhan (?), 13:45, 19/05/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Все просто, разница между статической типизацией и динамической типизацией в скомпилированном коде составляет не менее трех раз по производительности и около 3-10 раз по памяти.
Crystal - статически типизированный язык.
| | |
|
| 1.26, Аноним (25), 08:24, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
не нужно.
т.к. для масшабируемых высокопроизводительных приложений есть elixir на базе стабильного и нажежного erlang vm.
ну а для всяко типовой фигни и ruby (ROR) сойдет - хоть и медленно но зато более менее привычно и есть много готовых гемов.
| | |
| 1.38, Demo (??), 09:26, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Crystal развивается новый язык программирования,
> разработчики которого намерены создать язык
> удобный как Ruby при разработке, но быстрый как Си при выполнении
А как же Smalltalk? o_O
| | |
| 1.46, Аноним (-), 12:22, 09/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно было бы увидеть синтаксические отличия от руби. Статическая типизация с параметрическим полиморфизмом, и возможность компиляции -- весьма недурно.
| | |
| |
| |
| 3.82, Аноним84701 (?), 18:14, 10/08/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Ещё одна Scala.
> По своей идеологии скорее Rust.
У раста, справедливости ради, в "идеологии" много внимания уделяется управлению памятью. И оно по умолчанию "ручное" (с поддержкой компилятора и прочими плюшками).
Ну и "классического" OOП в расте нет.
| | |
|
|
| |
| 2.88, вввв (?), 14:38, 11/08/2016 [^] [^^] [^^^] [ответить]
| +/– |
ява и так как с, только урезана и объектно ориентированна
| | |
| |
| 3.95, Аноним (-), 23:51, 12/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> ява и так как с, только урезана и объектно ориентированна
Нифига себе урезана - рантайма на 100 метров. А оопешные фичи это здорово. Но только не когда у тебя работа со строками окажется в 100 раз медленнее чем ты ожидал и не когда gc начнет тормозить и лагать именно там где этого меньше всего хотелось.
| | |
|
|
| 1.90, Аноним (-), 19:22, 11/08/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
"производительность С" доставило :)
когда он в 1-й тройке-пятерке семых шустрых был? :)
| | |
| |
| 2.96, Аноним (-), 23:53, 12/08/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> когда он в 1-й тройке-пятерке семых шустрых был? :)
Он обычно второй в очереди - сразу после ассемблера. Это, конечно, зависит от, но критичные к скорости вещи не зря пишут на си + ассемблерные вставки. Но ты можешь показать нам чудо - перепиши какой-нибудь декодер H.264 на своем любимом ЯП и покажи как малохольный компьютер без аппаратного ускорителя вдруг заиграет мажорское FullHD. Тебе сразу толпа юзерей памятник поставит при жизни.
| | |
| |
| 3.97, КО (?), 17:07, 16/08/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>Он обычно второй в очереди - сразу после ассемблера.
Так вот с им родимым и сравнивают, когда особо пропиариться хотят.
Даже Оракул с Явой в этом был замечен. :)
Некоторые, из ныне забытых, были даже быстрее оного. :)
P.S. Язык (компьютерный) сам по себе не быстрый и не медленный. Если безотносительно его реализации и программиста рассматривать. :)
| | |
|
|
|
