Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, Курилка, Вы писали:
К>>Задачи типизации, т.е. гарантии контрактов. Z>Тут недавно гейм девелоперы мерялись ассертами — 1 ассерт на 5 строк кода. Не доверяют, видать, статической типизации
Вопрос — на каком языке гейм-девелоперы?
На Ocaml? Или C++?
Z>>>Вот пример D.Mon-а. Как бы вы избавились бы от тегов? К>>Там изначально был нужны тэги, так что вопрос некорректен. Я говорил как раз о варианте, когда тэги требуются после. Z>Например о каком? Мы то сначала говорили о SYB.
Речь как раз о вещи аля SYB. Только я говорю что у тебя есть 2 разных "момента написания кода": 1) написание исходной структуры данных; 2) написание собственно решения задачи на SYB (или обхода по тэгам как ты показывал). И в моменте 1 разработчик может быть совершенно не в курсе возможности момента 2, т.е. получим, что нужные тэги придётся добавлять.
К>>Но как вариант "развития ситуации": что будет если в код, которому был нужен этот "байткод" (именно тот код, а не тот, который работает просто с массивами) я передам [1,1,1]? Переходим к переходу к обработке контрактов в рантайме (или падению).
Z>Это зависит — если это компилятор — то все "неинтересные" случаи мы просто пропускаем. В ерланге, например, можно подождать с этим пару недель — пока код не проапдейтят. Иногда имеет смысл исключение бросить. В чем проблема то?
В чём может быть проблема зависит от конкретной ситуации, я же говорю о исходном факте (вроде бы тривиальном), что проверка контракта для статики происходит заметно раньше, т.е. ещё до запуска программы. Хотя мощность выразимых контрактов очень зависит от языка, безусловно, и просто статика не покрывает 100% необходимых вариантов (хотя, если будет развиваться что-то аля total function programming, то покрытие можно очень близко к этому приблизить).
Ну и никто не мешает автору "ручками" перепроверять контракты, безусловно
Пусть даже с использованием полуавтоматических средств, аля юнит-тесты и т.п.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, z00n, Вы писали:
Z>>Здравствуйте, Курилка, Вы писали:
К>>>Задачи типизации, т.е. гарантии контрактов. Z>>Тут недавно гейм девелоперы мерялись ассертами — 1 ассерт на 5 строк кода. Не доверяют, видать, статической типизации
К>Вопрос — на каком языке гейм-девелоперы? К>На Ocaml? Или C++?
А что, Ocaml уже поддерживает dependent types?
Z>>>>Вот пример D.Mon-а. Как бы вы избавились бы от тегов? К>>>Там изначально был нужны тэги, так что вопрос некорректен. Я говорил как раз о варианте, когда тэги требуются после. Z>>Например о каком? Мы то сначала говорили о SYB. К>Речь как раз о вещи аля SYB. Только я говорю что у тебя есть 2 разных "момента написания кода": 1) написание исходной структуры данных; 2) написание собственно решения задачи на SYB (или обхода по тэгам как ты показывал). И в моменте 1 разработчик может быть совершенно не в курсе возможности момента 2, т.е. получим, что нужные тэги придётся добавлять.
Я, извините, уже писал выше, что не предствляю. Как вы представляете себе XML без тегов? Как плоский текст? Тогда придется написать компилятор — как-то так
К>В чём может быть проблема зависит от конкретной ситуации, я же говорю о исходном факте (вроде бы тривиальном), что проверка контракта для статики происходит заметно раньше, т.е. ещё до запуска программы.
А вот представьте себе что вы пишете программу на Smalltalk, Lisp или Erlang, и запуск прграммы уже произошел несколько лет назад и у вас есть дебагер, который позволяет исправлять ошибки рантайм. Так ли ценна в таких условиях взможность находить опечатки в программе до запуска?
К>Хотя мощность выразимых контрактов очень зависит от языка, безусловно, и просто статика не покрывает 100% необходимых вариантов К>(хотя, если будет развиваться что-то аля total function programming, то покрытие можно очень близко к этому приблизить). К>Ну и никто не мешает автору "ручками" перепроверять контракты, безусловно К>Пусть даже с использованием полуавтоматических средств, аля юнит-тесты и т.п.
Вот я например пишу компилятор, или рефакторер какой-нибудь на статически типизированном языке. Он мне замечательно указывает когда я передал в функцию [Int] вместо Int, а за это, когда я трансформирую AST он просит описывать все случаи. Я не могу сказать — для всех своих субтермов сделай тоже самое рекурсивно, а вот тут замени x на y. Самая маленькая трансформация занимает строк 200 кода. Когда вы напишете эти 200 строк десятый раз (у вас кстати полно шансов ошибиться), вы вполне можете задуматься — а не променять ли исправление опечаток на возможность писать 5 строк вместо 200, а тестов у компилятора заведомо будет полно. (SYB решает эту проблему для Haskell — остальные пока cjcen
Другое дело, если вы пишете, например ядро OS. И это все совершенно нормально.
Здравствуйте, z00n, Вы писали:
Z>Здравствуйте, Курилка, Вы писали:
К>>Вопрос — на каком языке гейм-девелоперы? К>>На Ocaml? Или C++?
Z>А что, Ocaml уже поддерживает dependent types?
Не сочти за личный наезд, но ты еврей?
А "скипанье" вопросов несколько "гасит" желание общаться.
Плюс я не раз повторил, что 100% покрытия не будет, но приводить в пример не лучшие языки статической типизацией по меньшей мере не корректно.
К>>Речь как раз о вещи аля SYB. Только я говорю что у тебя есть 2 разных "момента написания кода": 1) написание исходной структуры данных; 2) написание собственно решения задачи на SYB (или обхода по тэгам как ты показывал). И в моменте 1 разработчик может быть совершенно не в курсе возможности момента 2, т.е. получим, что нужные тэги придётся добавлять. Z>Я, извините, уже писал выше, что не предствляю. Как вы представляете себе XML без тегов? Как плоский текст? Тогда придется написать компилятор — как-то так
ОК, для корректного XML тебе понадобится XSD, что есть по сути типизация.
К>>В чём может быть проблема зависит от конкретной ситуации, я же говорю о исходном факте (вроде бы тривиальном), что проверка контракта для статики происходит заметно раньше, т.е. ещё до запуска программы. Z>А вот представьте себе что вы пишете программу на Smalltalk, Lisp или Erlang, и запуск прграммы уже произошел несколько лет назад и у вас есть дебагер, который позволяет исправлять ошибки рантайм. Так ли ценна в таких условиях взможность находить опечатки в программе до запуска?
ОК, у тебя свич в продашкне на котором крутятся постоянно звонки, по нему ты пойдёшь дебагером? Плюс не только опечатки ловятся, некоторый класс логических ошибок тоже можно избежать (пусть и не так много)
Т.е. из 2 вариантов: 1)с меньшим числом гарантий и 2) с большим числом; я скорее склонюсь ко второму (если не будут существенны другие факторы).
Ну и флеймить больше что-то не охота
Здравствуйте, nikov, Вы писали:
N>Вот я, честно говоря, не вижу никаких преимуществ у динамических языков перед языками со статической типизацией, поддерживающими вывод типов и structural typing (например, Scala). Если мне кто-то их укажет, я буду очень благодарен.
А кто-нибудь может перечислить преимущества статически типизированных языков перед динамическими?
Например можно ли считать таковым более простой способ реализации поддержки IDE, или это проблемма разработчиков инструментов и к языку не имеет относится?
Здравствуйте, dotneter, Вы писали:
D>Тогда что нибудь типа анонимного union type, D>["a", 1, "b"] string|int list D>["a", 2, true] string|int|bool list D>А потом патерн мачингом бежим по этому списку и радуемся жизни.
Не пойдет — элементами списка могут быть другие такие списки. Т.е. дерево обычное. Придется по-хорошему описать все дерево.
Здравствуйте, Курилка, Вы писали:
К>Вот об этом-то тебе я и пытаюсь сказать: при переходе к dll мы теряем типизацию
При переходе к dll мы вообще оказываемся за рамками языка.
К> Т.е. если упростить, то фактически решение почти равносильно перезагрузке программы.
Ничего не понял.
К> В отличие от этого, эрланговские процессы при хотсвопе продолжат работу с новым кодом
Ну и что? Во-первых какое это имеет отношение к типизации, если сей процесс принципиально происходит в рантайме и выходит за рамки контроля компилятора, а во-вторых нафига нужна эта мегафича?
К>Можно ли сделать обновление кода без какого-то отказа от типизации по-моему большой вопрос.
Это не большой вопрос, это абсолютно ортогональный статической типизации вопрос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, D. Mon, Вы писали:
DM>Первый пришедший на ум пример — гетерогенные структуры данных без предварительного описания.
Анонимные типы? Нет, конечно в существующем виде они не очень гибки, но саму возможность наличия подобной фичи в статических языках они, имхо, вполне демонстрируют. А дальше никто не мешает их, к примеру, скрестить с алгебраическими типами данных.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, dotneter, Вы писали:
D>>Тогда что нибудь типа анонимного union type, D>>["a", 1, "b"] string|int list D>>["a", 2, true] string|int|bool list D>>А потом патерн мачингом бежим по этому списку и радуемся жизни.
DM>Не пойдет — элементами списка могут быть другие такие списки. Т.е. дерево обычное. Придется по-хорошему описать все дерево.
Не вижу противоречий
Здравствуйте, dotneter, Вы писали:
D>Не вижу противоречий D>
["a", [1]] : list<string|list<int>>
Все еще нету желаемой произвольной глубины — я же говорил "другие такие списки".
D>или написать что нибудь типа...
Вот мы и пришли к полному описанию всего типа. А в динамических языках оно не требуется.
И еще — что это за ML такой, что позволяет делать (int | string) list?
Здравствуйте, D. Mon, Вы писали:
DM>Вот мы и пришли к полному описанию всего типа. А в динамических языках оно не требуется.
Можно предположить что этот тип идет в стандартной поставке вместе с list. DM>И еще — что это за ML такой, что позволяет делать (int | string) list?
Вымышленный, хотя в трилиарде деалектов может где такое и реализовано.
Здравствуйте, dotneter, Вы писали:
D>А кто-нибудь может перечислить преимущества статически типизированных языков перед динамическими?
Скорость исполнения. При наличии статической типизации компилятор способен генерировать быстрый код сразу. В случае статической типизации нужно иметь что-то типа HotSpot со сбором статистики и пр.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Скорость исполнения. При наличии статической типизации компилятор способен генерировать быстрый код сразу. В случае статической типизации нужно иметь что-то типа HotSpot со сбором статистики и пр.
Ничего не понял.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Курилка, Вы писали:
К>>Так вот, собственно: есть такая штука, как декорированные имена. И для С++ных dll это прекрасно работает. Хотя C++ в отказе от типизации обвинить сложно
К>И для них есть хотсвоп?
Для С++ — нет. Там даже ручная загрузка проблематична, поскольку сам язык очень убого поддерживает позднее связывание.
Конечно же, можно
typedef int (*PFN_Int_Int)(int);
#define MANGLE_Int_Int(s) s "@XZ"// наобум :) - лень смотреть настоящую декорацию
PFN_Int_Int foo = (PFN_Int_Int) GetProcAddress(hDLL, MANGLE_Int_Int("foo"));
И даже, наверно, можно как-то автоматизировать это.
Но вот классы уже прогрузить таким способом будет мучительно.
А для COM эта задача вполне решаема.
Другое дело, что не всем это нужно: разводить в программе зоопарк из сосуществующих версий.
Здравствуйте, AndrewVK, Вы писали:
E>>Скорость исполнения. При наличии статической типизации компилятор способен генерировать быстрый код сразу. В случае статической типизации нужно иметь что-то типа HotSpot со сбором статистики и пр.
AVK>Ничего не понял.
Очепятка, последнее предложение читать следует как: "В случае динамической типизации нужно иметь что-то типа HotSpot со сбором статистики и пр."
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Курилка, Вы писали:
К>Стандартное хаскельное дерево
Разумеется, можно описать дерево со всеми его особенностями (как обычно AST записываем). Просто тогда сразу возникают проблемы (задачи), которые призван решать SYB, но он доступен не везде. И работать с ним так же просто, как с массивом, уже не получится. Хотя на практике это редко нужно..
Здравствуйте, eao197, Вы писали:
E>Очепятка, последнее предложение читать следует как: "В случае динамической типизации нужно иметь что-то типа HotSpot со сбором статистики и пр."
Опять не очень понятно. HotSpot сделали для статически типизированной джавы, для того чтобы съэкономить в некоторых сценариях на JIT компиляции. Ты имеешь в виду, что типы придется в рантайме ресолвить? Вполне возможно, но к хотспоту это отношения не имеет.
Кстати, на C# 4, по идее, такую фичу можно забацать сравнительно просто.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>Очепятка, последнее предложение читать следует как: "В случае динамической типизации нужно иметь что-то типа HotSpot со сбором статистики и пр."
AVK>Опять не очень понятно. HotSpot сделали для статически типизированной джавы, для того чтобы съэкономить в некоторых сценариях на JIT компиляции. Ты имеешь в виду, что типы придется в рантайме ресолвить? Вполне возможно, но к хотспоту это отношения не имеет.
Насколько я помню историю, корни HotSpot-а идут из самой быстрой реализации VM для Smalltalk-а под названием Strongtalk. И, если не ошибаюсь, сейчас увеличение скорости работы VM для динамических языков достигается за счет того, что после нескольких обращений к одному методу одного и того же объекта вызов этого метода заменяется простой инструкцией call вместо поиска тела метода через таблицу методов (включая унаследованные из базовых типов). Для чего и требуется сбор статистики.
Скажем, если в статически-типизированном языке у нас может быть:
// Для примера C++, в котором виртуальные методы нужно объявлять явно.class B {
};
class C : public B {
public :
void a() { std::cout << "C::a" << std::endl; }
};
C a;
a.a(); // Транслируется в call C::a.
a.b(); // Не транслируется вовсе.
Тогда как в динамически-типизированном языке:
# Ruby, поскольку я его хоть чуть-чуть знаю.class B
end
class C < B
def a; puts 'C#a'; end
end
a = C.new
a.a # Напечатает C#a
a.b # Выдаст ошибку времени исполнения. Но, если ее перехватить и продолжить...
# Класс B обновляется.class B
def b; puts 'B#b'; end
end
a.b # Ошибки уже не будет, а будет напечатано B#b.
Т.е. в динамическом языке любой вызов, по умолчанию, должен проходить через поиск метода в таблице методов конкретного объекта (поскольку даже у объекта набор методов может не совпадать с набором методов класса, к которому объект изначально принадлежал). Но, если ни объект, ни его тип не изменялись с момента последнего вызова, то обращение к конкретному методу можно сделать более эффективным. Что, с другой стороны, требует затрат в run-time, которых, в принципе, нет в случае статически-типизированных языков (где даже в случае виртуальных методов возможны оптимизации еще во время компиляции/линковки и выбрасывание лишней косвенности).
AVK>Кстати, на C# 4, по идее, такую фичу можно забацать сравнительно просто.
Извини, но это напоминает "кто о чем, а вшивый о бане" Не .Net-ом единым
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Перекуём баги на фичи!
