что? переформулируйте мысль на более литературном или техническом языке.



ня?

Это сообщение отредактировал(а) k0rvin - 24.4.2010, 00:43

есть, но только в рантайме


как вы все ### тыкать сюда эту абсолютную истину
вот приведи пример задачи, которая выигрывает от нестрогой типизации


товарищ главнокомандующий, вы путаете строгую типизацию и статическую типизацию

Любая задача, выполнение которой занимает меньше времени, чем написание кода для неё. Например, скрипты.

Хм... Что-то я сомневаюсь. 

Итак,


JackYF, я бы ещё понял, если бы речь шла о преимуществах динамической типизации в плане высокой скорости прототипирования. Но нестрогая будет только мешать. Если исходить из вышеупомянутых определений, то, скажем, в Python типизация динамическая строгая, а в PHP - динамическая нестрогая. Бенефиты от динамической типизации получим и там и там, а вот об грабли нестрогой типизации, расставленные в PHP, мы весь лоб расшибём.

P.S. В Python типизация не совсем строгая...

пример:

будь типизация сильно строгой, результат assoc необходимо было бы писать "(when (not (null x)) ..." или типа того
мелочь, но чем больше кода, тем количество таких мелочей растет в геометрической прогресси => растёт трудность восприятия кода


не совсем, чем строже типизация, тем уверенней компилятор может производить оптимизации, ведь он может однозначно установить тип, а не думать "тут возможны такие типы: ..."

Это сообщение отредактировал(а) k0rvin - 24.4.2010, 19:51

k0rvin, я смотрю ты Лисп(?) используешь строго по назначению - толстый троллинг.  Ты бы хоть пояснял нам, императивным нищебродам, что там происходит.  


qweqwe, вот, смотри. И ещё один путает. Речь идёт о том, что со строгой типизацией нужно явно указывать свои намерения при приведении типов. Таким образом транслятор языка со строгой типизацией будет увереннее находить ошибки, которые транслятор языка с нестрогой типизацией будет "проглатывать", предполагая неявное приведение типов. Эти ошибки очень часто являются логическими ошибками. Чем раньше они будут отловлены, тем лучше.

Логическую ошибку можно:

• отловить в compile-time;
• отловить в run-time;
• не отловить вовсе.

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

Это сообщение отредактировал(а) kemiisto - 24.4.2010, 20:15

какие слова не понятны? буду разъяснять их значение.

 Попробуйте скрипты документировать. И сравните )

k0rvin, кстати говоря, все Лиспы, вроде как, строго типизированные языки. 

нестрогая типизация, это когда компилятор видит, скажем сравнение строки и null, и генирирует такой код, который проверяет, пустая ли строка, и если она пустая - сравнение возвращает true, это крайне весело и остроумно, но к счастью - не ведет к ускорению программ (иначе ПэХаПэ был бы самым быстрым языком на свете)  


так точно, лиспы не пальцем деланы  

Нет такого языка "лисп". а Common Lisp весьма императивный язык. в том числе.


Добавлено @ 21:27

все слова понятны. по-отдельности. вместе же они у Вас составляют кашу

Добавлено @ 21:37

откуда такая уверенность? "диалектов лиспа больше, чем программ, написанных на нём".

в Common Lisp типизация не сильно строгая:
nil используется и как пустой список, и как "ложь",
истиной является значение любого типа, кроме nil.
ну и полиморфизм никто не отменял, благо CLOS предоставляет классы для всех встроенных типов, соответственно можно написать свои сколь угодно нестрогие функции =)

в Scheme чуть по-строже, есть специальные булевы константы: #t и #f, пустой список '() не является "ложью", однако как и любое другое значение, отличное от #f, является "истиной"

ну и конечно же и в том, и в другом списки и массивы гетерогенны
однако типизация в CL и Scheme построже Сишной

Это сообщение отредактировал(а) k0rvin - 24.4.2010, 22:08

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

впрочем Вы правы, для статически типизированных языков разницы в производительности никакой. для динамически типизированных разница есть, ведь проверки типов придётся проводить в рантайме

проверки типов есть всегда, только в случае строгой типизации - проверка приведет к одному результату, а в случае не строгой - к другому

 Жаль (
Тогда советую перечитывать до тех пор, пока полностью не поймете смысл, но не более 4 часов подряд.

Добавлено через 4 минуты и 39 секунд

При динамической типизации(как правило она "в комплекте" с нестрогой типизацией, за исключением языков типа C) все равно приходится вести phpdoc/etc теги для работы автокомплита типов и документации, в итоге кода больше выходит...

у вас PHP головного мозга, уважаемый
нестрогая и динамическая типизация - ортогональные вещи  

qweqwe, а у вас ПГМ)
читаем первую часть моего поста, долго думаем. Специально же РАЗДЕЛИЛ эти понятия в сообщении.