Минюст США разрешил Oracle купить Sun Microsystems

>А здесь - с читабельностью немного получше...

Да, только в хаскеле есть еще т.н. do-нотация и arrow-нотация для "монад" и "стрелок" соответствтенно, которая очень и очень сильно облегчает удобочитаемость.

И еще раз говорю. То что я привел - это самый простой и тривиальный случай. Есть намного более полезные вещи, но здесь их писать несколько проблематично.

И конечно же, что сам комбинаторы, что их параметры очень и очень серьезно типизированы. С очень серьезным использованием параметрического полиморфизма. Хотя с одной стороны - это здорово, с другой стороны иногда беспомощность накатывает.

Завтра отвечу.

> может, стоит перенсти общение в жаббер? какой он у тебя?

Есть гуглтолк, он же почта: eugeny.nikolaev@gmail.com

Но у меня не такие знания, как может показаться. С++, Ассемблер - знаю не много, сертификатов - мало, ой, я не такой крутой спец как Вы, и близко даже. :)

По ООП разве что чуть читал, конечно же... ;) Да и то - много недочитанного где...

> Меня интересуют, например, случаи, когда язык ведет себя не так, как интуитивно ожидается (например, virtual template), и случаи, когда очевидные вещи на язык плохо ложатся. Например, имеется класс чисел произвольного размера Integer, хочется сделать класс рациональных чисел произвольной точности Rational как родителя Integer. Какие ты видишь тут проблемы? Как бы спроектировал свой язык программирования, чтобы их не было?

Вот тут мои незаконченные знания и сказываются - "virtual template" - я до этого еще не дочитал, в книгах по С++

А вот дальше интересно.

"класс чисел произвольного размера Integer" - не совсем понятно, но с другой стороны, непонятно что имеется в виду. Варианты (догадки):

1) Вот например в ЯП FctionScript 1, 2 (Flash) был такой тип - Number. - Это единственный тип для чисел. Типизацию такой переменной можно было не использовать, много где срабатывало автоприведение типов, а на уровне самой виртуальной машины - сущестовала такая оптимзация (приближенный взгляд на вещи) - если число можно было представить как целое, то вирт. машина его таковым и считала. Если число можно было считать 5.0 (с одинарной точностью) - то виртуальная машина и JIT - пытались вот так таким числом и управлять. Если с двойной точностью - там кажется эмулировалась, она, двойная точность, на самом деле... При эмуляции терялась проивзодительность. Но были энтузиасты-супер-профи, один из них выпустил ассемблер/дизассемблер байткода (называется софтина Flasm), и можно было просто "тупо использовать опцию" программы, которая немного корректировала байт-код. Это один взгляд на вещи.

2) В C++/CLI (так же как, в принципе, и в любом ЯП из .NET ) - существуют типы Int32, Int64. Но можно писать и в "старом" стиле, при этом старый тип - маппится на "новые именования". Проблема, ранее, была в том, что на разные платформах тип мог отличаться, поэтому в C++ для .NET (C++/CLI), как и вообще во всех ЯП .NET - ввели такое точное указание типа чисел.

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

Я не против против нового (тафтология :) ), но на сколько в чем есть смысл и почему вот система типизации с Int32, Int64 - не достаточно удобна для любых целей?

У меня догадка, по тому что читал ранее - Вы хотите и классы создавать, заранее не зная какие именно понадобятся (Ваше внимание к eval), и типы данных - тоже не зная заранее, какие Система захочет создать...

Речь идет про AI, который сам придумает свои типы данных, во всяком случае не будут ограничен заранее определенными?.. ;)

Простите, если расскрыл Ваши карты. ;)

Просто я уверен, что как только кто-то построит AI, да еще с эмоциями, этот AI вырвется в сеть, на форуме его где-то обзовут придурком, он обидится и выключит и Инет, и может и ядерными электростанциями заняться...

Угроза будет мгновенной, и Человечество просто не успеет адаптироваться, будет или мгновенно уничтожено, или понесет такие потери (взрывы реакторов, управляемых компьютерами), что мы с Вами - будем скрываться где-то в гораз или еще где, где нет радиации.

Вы как хотите жить в своей старости - в горах, или в городе, с удобствами?

Самое главное - никто не успеет адаптироваться, ни одна из стран/правительств.

Не знаю как про наших внуков (все равно же кто-то придумает, это) но давайте хоть мы поживем в мире и спокойствии... ;)

Извините, если выдал/угадал планы. Я хочу еще пожить... :)

> 1) Вот например в ЯП FctionScript 1, 2 (Flash)

Опечатка. Правильно:

ActionScript 1, 2

>> А здесь - с читабельностью немного получше...

> Да, только в хаскеле есть еще т.н. do-нотация и arrow-нотация для "монад" и "стрелок" соответствтенно, которая очень и очень сильно облегчает удобочитаемость.

> И еще раз говорю. То что я привел - это самый простой и тривиальный случай. Есть намного более полезные вещи, но здесь их писать несколько проблематично.

> И конечно же, что сам комбинаторы, что их параметры очень и очень серьезно типизированы. С очень серьезным использованием параметрического полиморфизма. Хотя с одной стороны - это здорово, с другой стороны иногда беспомощность накатывает.

Хм... Да, любопытно...

Большой момент - читабельность кода. А, ну да, Вы и написали про дот-синтаксис.

Можно сказать что и IronPython здесь "тоже", "каким-то боком", аналогичное? Или нет? Есть принципиальные различия? Очень любопытно, кто-нибудь может оценить, Хаскель и IronPython - какие есть принципиальные отличия между ними (кроме самих фактов, что они родились по разному, это понятно).

>Да вот там, похоже, хреново с *моделированием*.


Еще есть Xtext http://www.eclipse.org/Xtext/documentation/latest/xtext.html#getting-started

>- в общем прошу отбросить (на время) рассовую неприязнь ;) и перевести выступление одного из разработчиков ядра Win 7:

http://channel9.msdn.com/shows/Going+Deep/Arun-Kishan-Farewell-to-the-Windows.. .


http://74.125.79.132/translate_c?hl=ru&u=http://news.softpedia.com/news/W...

Большое спасибо.

Вспомнил, что недавно еще обнаружил, вроде на русском, видео про архитектуру вин 7. Скачал, еще не смотрел.

Варез на ЛОРе запрещен, поэтому максимально что могу сказать.

Только что вспомнил.

Еще раз спасибо, сейчас почитаю...

> Вспомнил, что недавно еще обнаружил, вроде на русском, видео про архитектуру вин 7. Скачал, еще не смотрел.

> Варез на ЛОРе запрещен, поэтому максимально что могу сказать.

В смысле что линк для скачки был на варез сайте.

>JavaME... - тупиковые ветви

вы уверены в своих словах? хотя глупость, да...

Не, на переводе гугла прочитать еще сложнее. :)))

Сейчас прочту на английском, вот первоначальная Ваша ссылка:

http://news.softpedia.com/news/Windows-7-Increased-Performance-and-Optimal-Us...

Спасибо, но... но... это не на русском, было. :)

В видео-презентации - архитектор еще пытается объяснить все "на пальцах", рисует диаграммки, но по ним не сильно все понятно, т.к. он в основном устно поясняет, диаграммки только для большей понятности его слов...

Я на треть тогда посмотрел, потом просто скачал на винт видео в наивысшем качестве, решил отложить на потом.

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

Может там что-то вроде неблокирующего чтения, в таком духе, идея?

Как же синхронизируют состояния...

Ладно. Нужно учить английский...

Если на тему чисел по каким-то причинам есть интерес, то можно прочитать про этот Flasm, вот страничка продукта.

http://www.nowrap.de/flasm.html

Когда-то существовал и перевод на русский (в котором в том числе и я принимал участие), но сейчас (это давно было, и переводили мы доки к более ранней версии Flasm) - много битых ссылок, искать так лениво, да и там на английском принципы понятны...

Краткие пояснения:

1) ActionScript версий 1, 2 или 3 - это язык программирования, встроенный во Flash. Аналог Java или C# - управляемая "куча", нет указателей, GC, байткод. В 1-ой версии языка очень походило на JavaScript по коду, типизации не было. Во 2-ой - типизировать можно, а можно и не типизировать; после компиляции код превращается в то же, что и было бы, если программировать в 1-ой версии. Классы, интерфейсы - все сводится к типу Function, или, другие типы данных - к другим типам (String, Number). Есть корневой объект _global, к нему атачится все остальное, может через foreach перебрать, в том числе и рекурсивно, все это "остальное" - потому что все атачится по принципу hash-значений в каждой из такой области видимости - _global.anyClass.anyVariable. Затипизировали конечное как Function и если есть ссылка у этого на его прототип (вроде можно было и ручками приделать ссылку на прототип) - можем инстацировать получившееся. Классы поддерживаются прототипами. Прототипы позволяют Системе отслеживать наследование. В прототипе функции можно использовать static-переменные. ActionScript 3 - это уже почти Java/C# (с кастрированной функциональностью - нет абстрактных классов, например, разработчики спешили, Macromedia продавалась Адобу, выпустили недоделанный язык, чтобы получше продаться, с зарелизенной такой 3-ей версией языка). Здесь уже типизировать все переменные - обязательно. Хотя хаки, в духе доступа к массиву как a[i] - по прежнему позволяют не типизировать какие-то вещи. В ActionScript 3 - используется виртуальная флеш-машина 2-ой версии. Современный флеш-проигрыватель - имеет на борту обе виртуальные машины, можно запускать код, созданный в любой версии языка... Еще раз - ActionScript 1 (классы были в зародыше) и ActionScript 2 (есть классы и интерфейсы, можно программировать практически полностью в Java-стиле) - в обоих случаях получается один и тот же байткод, выполняющийся в виртуальной флеш-машине 1-ой версии. ActionScript 3 если компилируем - получаем байт-код для выполнения в виртуальной флеш-машине 2-ой версии. В которой уже не все так просто, на счет прототипов, "поддерживающих" классы - схема этого была изменена.

2) Утилита (возвращаясь назад ко Flash - утилите ассемблирования/дизассемблирования флеш-байт-кода, давно уже она не обновлялась, по моему поддерживает только ActionScript 1 и 2, а значит - только виртуальную флеш-машину 1-ой версии). Утилита работает из командной строки. Можно, конечно, встроить вызовы ее и в командную оболочку по клику на файлы определенного типа, что и как сделать для этого - на странице описано (это чтобы было проще понять остальное там - что оно зачем).

Используемая специфичная конструкция языка __bytecode__ - в некотором роде это аналог ассемблерной вставки в С++. Более лучше не скажешь, нюансы пояснит оригинальный текст - "It takes a string filled with hexadecimal numbers". :) В общем прямая вставка байткода - в наш код, который мы пишем, с помощью такой вот конструкции.

Остальное там вроде не такое специфичное для данного ЯП...

> 2) Утилита (возвращаясь назад ко Flash - утилите ассемблирования/дизассемблирования флеш-байт-кода

Опечатка. "Возвращаясь назад ко Flasm ..."

Программисты нынче разбаловались - хорошую IDE им подавай, языки типизированные, dot-синтаксис, от одного упоминания функционального программирования и мат. теорий - в обморок не падают, все им реальную полезность вынь да положь... фреймворки только от IBM или от JBoss... компилирование чтобы было и в байткод, и в нативный, на одно уже не все согласны... и чтобы еще унаследоваться можно было от класса, созданного в другом ЯП, да, при чем, чтобы и к неуправляемой куче доступ имели, и ассемблером слинковать или вставкой сделать можно было... и API им подавай, покруче - доступ к GPU как минимум чтобы могли использовать при написании "Hello, World!", и GUI чтобы могли через XML описать, и многопоточность и многоядерность... и полную документацию на русском, обновляемую постоянно, и DirextX/OpenGL одновременно, последних версий со всеми дополнительными спецификациями... под все платформы...

Совсем разбаловались, ай-ай-ай...

http://www.3dnews.ru/news/roboti_nauchilis_chiterstvu/

"Возможно, не так уж и долго осталось до появления у роботов таких механизмов, как самозащита с целью выживания и _принятие решений с оптимальной выгодой для себя вопреки приказам создателей_ ."

- при этом речь идет о простейших существах.

Много ли вы видели "высокопорядочных особей" "нашего вида"?

Дайте каждому из нас по кнопке взрыва реакторов и я засеку сколько _секунд_ Человечество протянет...

Дожить бы хоть свой срок, пока кто-то не придумал...

Легкий утренний троллинг ;) по поводу ФП:

http://community.livejournal.com/ru_scala/3420.html

"Т.е. ещё в 10 раз быстрее (или в 5 раз быстрее твоего). Тогда функциональное решение на scala (да и хаскелл) окзывается в далёкой-далёкой попе..."

;)

> главное не берись за Perl, он тебе мозг сожжёт, как лоровец советую

...чтобы мне конкурентов было поменьше... :)

Неа, eclips это единственный софт кой заставляет меня всерьез думать о принудительном введении HIG.

лор(л)-аналитики предрекают mysqlкапец и гордятся причастностью к serious business ? и почему я не удивлен ?

В отличии от них, в sun есть свои аналитики, и они знают, что из mysql ключевые разработчики ушли давно. http://en.wikipedia.org/wiki/Monty_Program_Ab. Эти 15 человек вытянут mysql, не беспокойтесь. Закрытие sun mysql вызовет ТОЛЬКО лишь потерю бизнеса по поддержке этого mysql.

> ведь Сан была единственной оставшейся компанией, которая не являлась анальным рабом M$.

Сан, если мне не изменяет склероз, в числе первых заплатил SCO за "лицензирвание UNIX", и даже помню статейки с попытками гнать волну волну на тему "пользователи Солярис защищены от патентных проблем, а Линукс, и в т.ч. Ред Хет ... "

Так что не надо идеализировать.

И кстати, еще одной крупной конторой, которая вместе с Сан заплатила СКО была та самая МС. Уж не знаю какие у них с саном были интимные связи в те времена.

вот пример паттерн матчинга на с++, остальное откомментирую другим постом

/// выхлоп:
/// virtual print: (1,(2,3))
/// pattern_match_print: (1,(2,3))

#include <iostream>
using namespace std;

class Tree
{
    public:
        virtual void print() const = 0;
        virtual ~Tree() {}
};
class Node: public Tree
{
    public:
        Node(const Tree* const left, const Tree* const right): left(*left), right(*right) {}
        virtual void print() const { cout<<'('; left.print(); cout<<','; right.print(); cout<<')'; }
        const Tree& left;
        const Tree& right;
};
class Leaf: public Tree
{
    public:
        Leaf(int value): value(value) {}
        virtual void print() const { cout<<value; }
        const int value;
};
void pattern_match_print(Tree* t)
{
    if( Node* n=dynamic_cast<Node*>(t) ) {
        cout<<'('; n->left.print(); cout<<','; n->right.print(); cout<<')';
    }
    if( Leaf* l=dynamic_cast<Leaf*>(t) ) {
        cout<<l->value;
    }
}
int main()
{
    Tree* t=new Node( new Leaf(1), new Node( new Leaf(2), new Leaf(3) ) );
    cout << "\n virtual print: ";
    t->print();
    cout << "\n pattern_match_print: ";
    pattern_match_print(t);
    cout << '\n';
    return 0;
}

> Ну начнем, с того, что класс должен быть параметризован. Правада ведь?

И не исключено, что в сложном случае полиморфизма появятся void*. Хотя простые проходят без него.

> В любом уважающем себя ФП языке я могу разбирать эту струкуту с помощью паттерн матчинга.

запостил уже пример

1. виртуальные функции гарантируют полный разбор случаев

2. если же ты добавишь еще один тип узла MySuperLeaf, то тебе придется переписывать все матчинги, а виртуальную функцию необходимо будет *добавить*, причем *именно* у MySuperLeaf.

> А потом мне потребуется добавлять какие-нибудь операции с моим деревом. Опять делать новый класс со статическими методами.

это про яву? не понял.

> А потом какой-нибудь урод сделает класс SuperLeaf : public Tree, несовместимый по поведению с Leaf.

почему урод? наоборот, расширяемость это хорошо.

> А потом мне понадобится чуть чуть подправить интерфейс класса Tree.

не понял.

> Ну начнем, с того, что класс должен быть параметризован. Правада ведь?

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

Насчет "цены" -- весь код на плюсах сделан достаточно параллельно хаскелю и имеет достаточно параллельный смысл, хотя конечно от const в глазах рябит, да и забыть я его мог еще где-то поставить.

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

Ну ты же собираешся хранить в дереве какое-то значение, правда. Не ради дерева же ты делаешь дерево.

Насчет примеров - просто классические пример http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-core.html

>вот пример паттерн матчинга на с++

Нет. Это всего лишь динамика. Ты не знаешь какого типа у тебя будет Твой Tree* t, пока его не вычислишь.

А если какой-то умник добавит класс SuperNode, то твой pattern_match_print просто не будет работать. И тот прискорбный факт ты смоежешь выяснить только запустив программу.

> Ну ты же собираешся хранить в дереве какое-то значение, правда. Не ради дерева же ты делаешь дерево.

И храню. В примере -- int.

> Нет. Это всего лишь динамика. Ты не знаешь какого типа у тебя будет Твой Tree* t, пока его не вычислишь.

И в каком языке статика? Везде динамика в этом случае.

> А если какой-то умник добавит класс SuperNode, то твой pattern_match_print просто не будет работать. И тот прискорбный факт ты смоежешь выяснить только запустив программу.

Ага, понял мысль. Нужно прикрыть возможность расширения (т.е. наследования) ради весьма похожей на ненужную (ибо есть вирт. функции) возможности паттерн матчинга.

Ну я подумаю как это сделать.

Кстати, мысль "либо dynamic_cast, либо возможность дальнейшего наследования SuperLeaf, но не оба сразу" выглядит интересной.

>Для всего прогрессивного человечества и мира было бы больше пользы и эффективности, если все разрабы плюнули на Линукс и начали развивать на выбор из следующего списка: *BSD, Haiku, Minix, (Open)Solaris, Plan 9.

только Plan9 и Hurd, остальное унылое устаревшее говно.

Но так как этого не будет, я из зол выбрал наименьшее - ляликс.

>И в каком языке статика? Везде динамика в этом случае.

В любом со статической типизацией ;) Если, конечно система типов поддерживает полиморфные типы.

>> И в каком языке статика? Везде динамика в этом случае.

> В любом со статической типизацией ;) Если, конечно система типов поддерживает полиморфные типы.

Тогда объясни подробно, где ты увидел там преимущество хаскеля в типизации. У меня по тимизации ничем не хуже и не лучше.

> А если какой-то умник добавит класс SuperNode, то твой pattern_match_print просто не будет работать. И тот прискорбный факт ты смоежешь выяснить только запустив программу.

А как ты будешь поступать, если тебе захочется вместо Tree=Node|Leaf сделать Tree=Node|Leaf|HalfNode, и у тебя куча сериализованных на диск старых деревьев?

Тебе придется переписать *все* твои паттерн матчинги, нет? А на с++ надо всего лишь добавить определение одного класса (с вирт. функциями).

Что же касается матчинга -- да, со стороны компилятора нужна поддержка "исчерпывающего перебора вариантов". Т.е. гарантия, что в switch мы прошлись по *всем* вариантам enum-a, что в match мы прошлись по *всем* производным классам, ...

http://www.google.ru/insights/search/#q=C%2B%2CJava%2CC%23%2CHaskell%2BScala%...

В древние времена были популярны шаманы, пытающиеся толковать те или иные природные явления, что они означают.

Позднее некоторые наблюдения вошли в обиход - "Солнце красно с вечера - моряку бояться нечего", "Солнце красно по утру - моряку не по нутру", "Если чайка села в воду - жди хорошую погоду", "Чайка ходит по песку - моряку сулит тоску".

Почувствуй себя шаманом - интерпретирую результат Гугла!

>А как ты будешь поступать

Тут очень интересная штука. Иногда бывает так, что ветка которую будет возвращать выражение будет известна на этапе компилаяции: напр., let blah-blah = Leaf 5. Тогда компилятор может использовать полученную информацию для оптимизации.

Если до вычисления выражения ветка неизвестна, то придется узнавать через что-то типа RTTI, но намного более простого т.к. тип все-равно известен, неизвестна только ветка.

Твое же решение сначала "стирает" тип до Tree, а затем пытается его восстановить поочереди приводя к типам-кандидатам.

>В Silvelight 3, загруженного на рабочий стол, есть возможность автообновления приложения.

>По моему это намного удобнее, что уже реализовано, чем реализовывать это самому.

а чего там реализовывать? два треда и ядро в виде dll, тьфу а не код

> а чего там реализовывать? два треда и ядро в виде dll, тьфу а не код

Пример с автообновлением приложения по Интернету - был приведен в контексте AOT.

Использовать JIT в Интернете удобнее. Так же как и АОТ удобнее для своих задач.

>http://www.google.ru/insights/search/#q=C%2B%2CJava%2CC%23%2CHaskell%2BScala%...

Самые популярные запросы
1. c e c
2. c & c
3. c discount
4. c++
5. vitamin c
6. c 言語
7. hepatitis c
8. a b c
9. mercedes c
10. mercedes

Что там у нас на второй строчке? Аха Comand & Conqueror, в общем по ходу дела смахивает на epic fail

Идем дальше
1. download java
2. java script

Какое там у нас отношение java имеет к javascriptу? Ну кроме похожих названий.

Ещё дальше
1. monty python
2. la scala

Ой ну это даже просто no comments, такого эпикфейла давно не видел

> JK? (Java Kopetz?)

врядли. зачем покупать продукт за стоимость целой компании, а затем продукт выкидывать? Oracle будет носить java на руках и вкладывать бабло в JVM.

Вопрос что будет с MySQL?

> ахз, мне в потроха лезть лень но GF запускается минуту, а JBoss - 5

а чего его постоянно запускать то? запустил и пусть работает. JBoss как то привычнее СтеклоРыбы

>> IL -> машинный код

> Да, странно что под Java такого вроде нет. Очень странно... Тут я согласен, что например игрушку скомпилить - было бы очень хорошо...

Давно но без особого успеха продаются компиляторы java -> натив x86. По сути нафиг не нужно.

Ил-2 рассмытривали вариант с пре-компиляцией, но отказались поскольку прирост скорости не окупал сложности. А также нативная компиляция проще ломалась.

>Ил-2 рассмытривали вариант с пре-компиляцией

А какого рода была прекомпиляция? Игровые скрипты?

>>> IL -> машинный код >> Да, странно что под Java такого вроде нет. Очень странно... Тут я согласен, что например игрушку скомпилить - было бы очень хорошо... > Давно но без особого успеха продаются компиляторы java -> натив x86. По сути нафиг не нужно. > Ил-2 рассмытривали вариант с пре-компиляцией, но отказались поскольку прирост скорости не окупал сложности. А также нативная компиляция проще ломалась.

В книгах пишут, что наши разработчики игр так и не научились хорошо защищать свой код, чаще всего используют он-лайн материалы по защите, которые давно известны хакерам.

Крис Касперски, Ева Рокко "Искусство дизассемблирования", 2009 г.

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

В книге просто смеются над ними. И описывают что и как.

Стр. 104, Раздел "Мелкие промахи, ведущие к серьезным последствиям". Ну а вообще начиная со стр. 88 - подробный разбор полетов.

Из прикольных моментов:

"*Не следует противодействовать пассивным отладчикам.*

Многие системные программисты постоянно работают с SoftICE в фоновом режиме, и делают это совсем не для хакерских целей. Однако когда необходимая им программа начинает ругаться на SoftICE, отказываясь запускаться, вот тогда-то решают тряхнуть стариной и разносят защиту в пух и прах, очень часто при этом выкладывая crack на всеобщее обозрение." (с)

> Рекурсивные структуры - это такие структуры которые содержат сами себя. Самый простой пример - список.

Каковой был реализован почти во всех языках. Влючая Виртовски Паскаль :-)

> Но как ты задашь тип такой простой структуры: двоичное дерево - это (левое двоичное дерево, правое двоичное дерево) или лист.

См.выше. Инструменты введения рекурсивной логики и рекурсивных определений во все ныне живые языки были введены еще бог знает когда.