Здравствуйте, EvilChild, Вы писали:
VD>>Для функций такая фича явно не нужна, но для других типов это могло бы быть очень удобно. Например, если мы имеем разные системы координат, то можно было бы один раз объявить тип координата (как структура, например) и создать другой тип через "strong type def". Это избавило бы нас от подстановки координат созданных в одной системы в другую без преобразования.
EC>Разные типы эту проблему разве не решают?
А как ты создашь разные типы если в языке нет средств для этого?
Скажем для классов еще можно использовать наследование. А что делать для строк, целых, структур? А что делать если нужно запретить приведение к базовому типу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
EC>>Разные типы эту проблему разве не решают?
VD>А как ты создашь разные типы если в языке нет средств для этого? VD>Скажем для классов еще можно использовать наследование. А что делать для строк, целых, структур? А что делать если нужно запретить приведение к базовому типу?
Ну, можно строку сделать членом нового класса.
Для разных по смыслу строк заводит по классу, чтобы избежать описанной выше проблемы.
Коряво конечно, но вполне стандартно для языков с АлгТД.
И как эти стронг тайпдефы стыкуются с компонентностью?
now playing: SCSI-9 — Woodman
Re[12]: The future of programming languages by Хейлсберг
Здравствуйте, EvilChild, Вы писали:
EC>Ну, можно строку сделать членом нового класса. EC>Для разных по смыслу строк заводит по классу, чтобы избежать описанной выше проблемы. EC>Коряво конечно, но вполне стандартно для языков с АлгТД.
Конечно, конечно. Коряво, коряво.
Объем работы вообще супер. Еще можно предложить копипэстить код структур. В прочем ты уже это сделал когда предложил запихивать строки в классы.
EC>И как эти стронг тайпдефы стыкуются с компонентностью?
А почему они не должны стыковаться?
Компилятор (и в том числе джит) отслеживает типы и может применять множество техник для пометки типов или создания их копий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
L>>Можно ли из неверных по отдельности утверждений составить верно?
VD>Где ты увидел не верное утверждение? Там вообще вопрос был.
А ты про какой вопрос конкретно? Про
А метапрограммирование на шаблонах — это оказывается для неподготовленной аудитории?
или про
Не уж-то Руби более известен чем Лисп?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[18]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
L>>А ты про какой вопрос конкретно? Про L>>
А метапрограммирование на шаблонах — это оказывается для неподготовленной аудитории?
VD>Про первый.
Ок. Извини, я видимо недостаточно ясно сформулировал свою мысль, раз вознили вопросы.
Я имел в виду, что если кто-то намеревается говорить для широкой аудитории о метапрограммировании, то разумно в качестве примера использовать что-то из области метапрограммирования, что этой аудитории наиболее близко. Шаблоны C++ — как раз из этого разряда. Да, они не являются мейнстримом, но из того, что имеется (Template Haskell, Nemerle, etc) — они наиблее известны (все остальное известно еще меньше)
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[17]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
VD>Ну, тут можно было бы подискутировать о здравом смысле, но здравого смысла в этом уже будет совсем чуть-чуть.
Не о чем тут дискутировать. Это время мне никто не оплатить, а тратить на это столько свободного времени я не хочу.
AVK>>И еще — на основании чего ты оцениваешь уровень моего знакомства?
VD>А я и не оцениваю. Я просто отвечал на твои слова о том, что "жалко тратить время". На мой взгляд — зря. Но решаешь конечно ты.
Вот поэтому я и потратил ровно столько времени, сколько посчитал нужным. И не думаю, что если я потрачу больше времени, мое мнение сильно изменится.
AVK>>Тем не менее это не помешало тебе выбрать автомобиль, имея нулевой опыт вождения.
VD>Помешало. Я положился на опыт тех кто в этом понимал.
Ну вот тогда можешь считать, что я положился на твое мнение. Ну а то, что выводы я при этом сделал иные, ну уж как сложилось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Можно пример интересной концепции из ПХП которых нет в других языках? VD>Хотя... пойдут и дублирующиеся...
Ну ничего такого особого уникального в php нет, хотя возможностей скажем в php5 на порядок больше чем в джаваскрипте. Во-первых, там полноценное ООП (наследование, абстрактные классы, интерфейсы, перегрузка, есть даже конструкторы и деструкторы). Ну что еще... итераторы. Механизм рефлексии кстати тоже есть. Причем все это "по-взрослому" сделано — там области видимости, пространства имен.
Да и вообще довольно интересный язык в принципе. Работа с массивами организована интересно, даже конкатенация строк. Помнится, в свое время тебе нравилось что-то в стиле "My name is $name", если я ничего не путаю. По крайней мере по сравнению с джаваскриптом где всего-то парочка занятных фишек php5 выглядит очень даже внушительно
Re[12]: The future of programming languages by Хейлсберг
Здравствуйте, Starlight, Вы писали:
S>Неправда. Intel вполне успешно продаёт свой компилятор.
Он на этом не живёт. Интеловский компилятор (+ IPP + Math kernel Library) служат для демонстрации мощи их процессоров. Это даже больше реклама процессоров, на которой они немного зарабатывают (окупается ли?). Не исключено, что оно может стать в будущем бесплатным.
Re[13]: The future of programming languages by Хейлсберг
Здравствуйте, Starlight, Вы писали:
S>Неправда. Intel вполне успешно продаёт свой компилятор.
Intel его и бесплатно раздавать мог бы, никакого заметного влияния на доходы фирмы это бы не оказало. Продает за деньги скорее всего, чтобы иметь лучшее представление о пользователях.
Re[10]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
VD>Казалось бы мы защищены от пуска ракет?! Ан не тут то было. Код: VD>
int result = MyAlghorinmWhichNeedSquareFunc(Square(LaunchMissiles));
Такую ошибку допустить значительно сложнее.
VD>или даже: VD>
int result = MyAlghorinmWhichNeedSquareFunc(LaunchMissiles);
VD>Проходит на ура! И мы убиваем пол Европы простой ошибкой в передаче функции. VD>
А вот тут действительно проблема из-за неявного приведения. Если бы его не было, было бы безопаснее. Согласен, в C# делегаты Европу не спасут.
VD>В теории языкостроения есть понятия структурной совместимости и типовой совместимости. VD>Так вот делегаты используют типовую совместмость которая в данном случае не нужна.
А почему не нужна? Сделать ее более строгой, и ракеты останутся на базе.
VD>Лучше было бы ввести в язык некий механизм позволяющий порождать новые "жесткие типы".
И я о том же.
VD>Тогда имея функциональный тип int -> int мы бы смогли (если бы это потребовалось) создать два строгих типа: VD>
VD>strong type def Square = int -> int;
VD>strong type def LaunchMissiles = int -> int;
VD>
VD>эти типы не были бы совместимы между собой.
Вот это именно то, что хотелось бы.
VD>Для функций такая фича явно не нужна
Почему?
VD> но для других типов это могло бы быть очень удобно. Например, если мы имеем разные системы координат, то можно было бы один раз объявить тип координата (как структура, например) и создать другой тип через "strong type def". Это избавило бы нас от подстановки координат созданных в одной системы в другую без преобразования.
Именно. И где тут структурная совместимость?
Re[11]: The future of programming languages by Хейлсберг
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, VladD2, Вы писали:
VD>>Казалось бы мы защищены от пуска ракет?! Ан не тут то было. Код: VD>>
int result = MyAlghorinmWhichNeedSquareFunc(Square(LaunchMissiles));
DM>Такую ошибку допустить значительно сложнее.
Чем какую? Можно подумать, что в коде будут вот такие явные названия. Попробуй как сопоставить какой-нить Fanc<T> с другим делегатом.
DM>А вот тут действительно проблема из-за неявного приведения. Если бы его не было, было бы безопаснее. Согласен, в C# делегаты Европу не спасут.
Дело не в неявном приведении. Можешь создать делегат явно, от этого ничего не изменится. Ну, кроме того, что с таким кодом вообще работать будет противно. Дело именно в том, что нельзя провести корреляцию по названию функции и названию делегата. И в том, что уникальны именно типы делегатов, а вот засунуть в них можно все что хочешь. И это не спроста.
В общем, похожая ошибка была в С++. Ее тоже защищали толпы фанатов. Толку от этого было — 0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
VD>>На 58-ой минуте (точнее 58:20) появляется слайд на котором присутствуют все перечисленные языки: VD>>http://files.rsdn.ru/73/HejlsbergOnJaoo.PNG
VD>Кстати, что здесь делает PHP?
Да как обычно : хотели написать Nemerle, да опечатались.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
Re[12]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
VD>Дело не в неявном приведении. Можешь создать делегат явно, от этого ничего не изменится. Ну, кроме того, что с таким кодом вообще работать будет противно. Дело именно в том, что нельзя провести корреляцию по названию функции и названию делегата. И в том, что уникальны именно типы делегатов, а вот засунуть в них можно все что хочешь. И это не спроста.
VD>В общем, похожая ошибка была в С++. Ее тоже защищали толпы фанатов. Толку от этого было — 0.
Тебя стало сложно понимать. Делегат создпется по сигнатуре метода, но тип делегата определяешь сам Хочешь Func<...> а хочешь Функ<...>.
Типы этих делегатов разные, но запихнуть в них можно методы с одинаковыми сигнатурами.
Каково же твое предложение? Как сопоставить определенному делегату набор нужных функций? И насколько тогда такой делегат будет нужен?
Так же можно рассуждать и о интерфейсах. Не факт, что реализация некоего интерфеса подходит под понятия вызывающего?
и солнце б утром не вставало, когда бы не было меня
Re[9]: The future of programming languages by Хейлсберг
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>В PHP 5.3 (он пока еще в альфе) появились лямбды и замыкания.
VD>Мне кажется PHP на этой картинке явно лишний.
Я думаю, что он тут приведен не как чем-то выдающийся язык, а как чисто императивный, в котором начали появляться элементы присущие ФЯ. Вроде как, в подтверждение тенденции