Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
1. Неявных приведений типов: (YourClass) myobject
2. Явных приведений типов: (myobject as YourClass)
3. Проверок типов: myobject is YourClass
4. Интроспекции: myobject.GetType()
5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам

Здравствуйте, naf2000, Вы писали:

N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
N>1. Неявных приведений типов: (YourClass) myobject
N>2. Явных приведений типов: (myobject as YourClass)
N>3. Проверок типов: myobject is YourClass
N>4. Интроспекции: myobject.GetType()
N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам


Если отказаться от ООП — наверно можно C считается "ЯП с жесткой типизацией"? Да и на С# можно при желании в процедурном стиле наваять достаточно сложную программу.

Только точно не нужно.

N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
N>1. Неявных приведений типов: (YourClass) myobject
N>2. Явных приведений типов: (myobject as YourClass)
N>3. Проверок типов: myobject is YourClass
N>4. Интроспекции: myobject.GetType()
N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам

Да.

Здравствуйте, naf2000, Вы писали:

N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:

Можно. На Haskell программы так и пишутся. Причём довольно сложные: компиляторы, системы контроля версий.

Здравствуйте, Temoto, Вы писали:

N>>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
N>>1. Неявных приведений типов: (YourClass) myobject
Типа нельзя привести int к double? Ты поясни, какие именно типы нельзя приводить. А то вот ты хочешь поделить 3 на 5, а в доброй половине языков это будет 0 потому что целочисленная арифметика. И если ты хочешь получить плавающий результат, то тебе так или иначе придется приводить аргумент к плавающему типу.

N>>2. Явных приведений типов: (myobject as YourClass)
То же самое.

N>>3. Проверок типов: myobject is YourClass
В рантайме или во время компиляции?

N>>4. Интроспекции: myobject.GetType()
См. №3.

N>>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
Исключения — удобный инструмент сообщения об ошибках. Можно, конечно, написать все на кодах возврата, но зачем?

В общем, непонятна цель ограничений. Это какие-то реальные ограничения или так, поговорить?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, naf2000, Вы писали:

N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
N>1. Неявных приведений типов: (YourClass) myobject
N>2. Явных приведений типов: (myobject as YourClass)
N>3. Проверок типов: myobject is YourClass
N>4. Интроспекции: myobject.GetType()
N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам

Интересно, в контексте этих ограничений является ли вызов унарного конструктора в С++ явным приведением типов?
Если нет, замена (YourClass) myobject на YourClass(myobject) — воркэраунд на первое ограничение.

Здравствуйте, naf2000, Вы писали:

N>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:
N>1. Неявных приведений типов: (YourClass) myobject
N>2. Явных приведений типов: (myobject as YourClass)
N>3. Проверок типов: myobject is YourClass
N>4. Интроспекции: myobject.GetType()
N>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам

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

Жесткое, в стиле C приведение если и используется, то где-нить в протоколах, сериализованные структуры собирать/разбирать, ибо такое приведение получается гораздо эффективней, чем читать побайтно и сдвигать 8 раз (на x64), вместо того, чтобы сразу прочесть машинное слово.

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

Здравствуйте, vdimas, Вы писали:

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

Разве это не динамическая диспетчеризация, которую предоставлют механизмы сопоставления с образцом?

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, naf2000, Вы писали:

N>>Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:

N>Можно. На Haskell программы так и пишутся. Причём довольно сложные: компиляторы, системы контроля версий.

Ну там Type Test заменяется неполным\wildcard паттерном в функции.
Напрмер

data T = A|B|C
f :: T -> a
f A = ...
f _ = ...

фактически функция f эквивалентна конструкции

if (t is A) {} else {}

Только PM оптимизирован для таких операций, а type test в ООП наоборот.

Здравствуйте, naf2000, Вы писали:

N>Используя ЯП с жесткой типизацией можно ли написать...

можно.

Используя ЯП с жесткой типизацией можно ли написать достаточно сложную программу (не HelloWord) и стоит ли это делать, в коде которой не будет:

Легко. В половине приложений на C++Qt ничего из вышеперчисленного нету за ненадобностью.

Скажу больше, надо стараться именно так и писать все время.

Только по приведению типов я не понял , считается ли приведения потомку к предку неявным приведением ?

Здравствуйте, minorlogic, Вы писали:

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

M>Только по приведению типов я не понял , считается ли приведения потомку к предку неявным приведением ?

Нет, это использование принципа подстановки на практике.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, minorlogic, Вы писали:

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

M>>Только по приведению типов я не понял , считается ли приведения потомку к предку неявным приведением ?

H>Нет, это использование принципа подстановки на практике.

Мгм ... ну тогда именно так и необходимо писать , а вы пишете по другому (вопрос не лчно к hardcase а риторически )?

Здравствуйте, hardcase, Вы писали:

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

H>Разве это не динамическая диспетчеризация, которую предоставлют механизмы сопоставления с образцом?

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

Чем же такой подход отличается от обычных скриптовых нетипизированных языков? Лишь тем, что еще в статике задаются ограничения мн-в типов значений, принимаемых в динамике. Например, подтипом дотнетного System.Object является любой дотнетный тип (кроме unsafe указателей), а подтипом варианта Хаскеля — лишь ограниченное множество типов, перечисленное в виде конструкторов варианта.

Здравствуйте, nikov, Вы писали:

N>Можно. На Haskell программы так и пишутся. Причём довольно сложные: компиляторы, системы контроля версий.

Вряд ли алгебраические типы попадают под понятие "жесткой типизации". Это же абсолютные аналоги VARIANT из COM. Но ведь упомянутый VARIANT по общему мнению за динамическую фичу COM-а сходил. Или надо было вопрошающему определить для нас своё понимание "жесткой типизации".

В общем, это всё рантайм полиморфизм, и мы имеем лишь различные механизмы его реализации: где-то в виде виртуальных ф-ий, где-то в виде алгебраических типов, а где-то в виде ссылки на полное описание типа, как в managed или скриптовых языках. И в общем случае, что можно написать на одной системе с рантайм-полиморфизмом, можно в очень похожем виде (т.е. без дорогостоящей эмуляции отсутствующих фич) написать на другой системе с рантайм-полиморфизмом.

Здравствуйте, vdimas, Вы писали:

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

V>Чем же такой подход отличается от обычных скриптовых нетипизированных языков? Лишь тем, что еще в статике задаются ограничения мн-в типов значений, принимаемых в динамике.

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

Здравствуйте, hardcase, Вы писали:

H>Отличие языков со встроенной поддержкой алгебраических типов данных от языков, в которых происходит их эмуляция существующими средствами (Си)в том, что первые умеют (и об уже говорилось) делать консервативные предположения: проверять целостность сопоставления с образцом, тогда как вторые языки делать этого не умеют и оставляют программисту возможность ошибиться.

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

Там только единственный слабый момент в этой архитектуре — это случай использования одного и того же типа внутри варианта более одного раза, но с разными дискриминаторами.
Решается с помощью способности С++ специализировать шаблоны константами. Т.е. вариант мог бы быть типизирован не просто типом хранимого значения, а парой: значение дискриминатора+тип. И все без дополнительных расходов в рантайм.

Здравствуйте, vdimas, Вы писали:

V>Вряд ли алгебраические типы попадают под понятие "жесткой типизации". Это же абсолютные аналоги VARIANT из COM. Но ведь упомянутый VARIANT по общему мнению за динамическую фичу COM-а сходил. Или надо было вопрошающему определить для нас своё понимание "жесткой типизации".

V>В общем, это всё рантайм полиморфизм, и мы имеем лишь различные механизмы его реализации: где-то в виде виртуальных ф-ий, где-то в виде алгебраических типов, а где-то в виде ссылки на полное описание типа, как в managed или скриптовых языках. И в общем случае, что можно написать на одной системе с рантайм-полиморфизмом, можно в очень похожем виде (т.е. без дорогостоящей эмуляции отсутствующих фич) написать на другой системе с рантайм-полиморфизмом.

В общем, если в программе есть if, то она тоже пролетает.

Здравствуйте, jazzer, Вы писали:

N>>>5. Конструкций обработок исключений try catch если система не обращается ко внешним неуправляемым ресурсам
J>Исключения — удобный инструмент сообщения об ошибках. Можно, конечно, написать все на кодах возврата, но зачем?

В случае lazy evaluation исключения часто вредны.