LINUX.ORG.RU

Об отсутствии кота

 ,


5

5

(cons cat (cons other-cat nil))

Как можно заметить, отсутствие коробки с котом не является ни коробкой, ни котом, но одновременно и тем, и тем.

Кроме того, наличие отсутствия кота по очевидным причинам определяется только в рантайме.

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

К тому же, единственное, что нам и правда важно, так это то, что мы посадили котов в коробки, или скорее даже то, что они там сейчас сидят.

Отсюда:

Третья Теорема Лавсана (о бесполезности статической типизации)

Статическая типизация не добавляет ничего действительно полезного и только лишь отбирает время.

Дискач.

★★

Последнее исправление: cetjs2 (всего исправлений: 1)

Ответ на: комментарий от anonymous

ой-ой-ой

[toDyn cat, toDyn otherCat]

это если гоняться за коротким кодом ценой всего и с тем же уровнем гарантий, что и в лиспе. Но оно надо?

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от lovesan

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

ты не дебил, ты написал классную функцию расчёта огурцов. Да и твой коллега тоже написал неплохой код для карандашей. Конечно дебил другой твой коллега, который сделал код для подсчёта числа коробок, в которые надо складывать карандаши и огурцы. Он и сложил два целых числа от ваших функций, и поделил на вместительность коробки.

то что код рабочий доказывается работающей программой.

а, ок. Добавил в комментарий к твоему нику данный диагноз.

emulek
()
Ответ на: комментарий от emulek

ты не дебил, ты написал классную функцию расчёта огурцов. Да и твой коллега тоже написал неплохой код для карандашей. Конечно дебил другой твой коллега, который сделал код для подсчёта числа коробок, в которые надо складывать карандаши и огурцы.

в треде запахло манатками

anonymous
()
Ответ на: комментарий от qnikst

это если гоняться за коротким кодом ценой всего

Чего «всего»?

с тем же уровнем гарантий, что и в лиспе

Ты так говоришь как будто на хаскеле можно получить бОльший уровень гарантий.

[toDyn cat, toDyn otherCat]

Ну ты же понимаешь, что если у тебя весь код будет в fromDyn/toDyn, то это будет куча нечитабельного говна?

anonymous
()
Ответ на: комментарий от emulek

Он и сложил два целых числа от ваших функций, и поделил на вместительность коробки.

А что, хаскель не позволил бы тут сложить карандаши с огурцами?

anonymous
()
Ответ на: комментарий от anonymous

не знаю как хаскель, а C++ не позволил-бы, пока не пропишешь метод огурцы::operator+(const карандаши&).

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

emulek
()
Ответ на: комментарий от emulek
    const int
предметы = огурцы.size() + карандаши.size();
anonymous
()
Ответ на: комментарий от fmdw

вакансий для них в природе не существует.

Сасай лалка, я вот нашёл вполне годную вакансию кложуриста в подзалупинске.

Debasher ★★★★★
()
Ответ на: комментарий от Kuzy

Все крохотное подмножество полезного метапрограммирования

anonymous
()
Ответ на: комментарий от terminator-101

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

fmdw
()
Ответ на: комментарий от Debasher

ОПу от этого не легче. На чём он там пишет за еду-то, на джаве?

fmdw
()
Ответ на: комментарий от terminator-101

Лел. О неконсистентности статической типизации с тем, что ты там про неё выдумал, разве что.

anonymous
()
Ответ на: комментарий от terminator-101

это говорит лишь о неконсистентности статической типизации

Если статическая типизация «неконсистентна», то динамическая, являясь частным случаем, — тоже :)

http://plato.stanford.edu/entries/lambda-calculus/#ConLCal

http://plato.stanford.edu/entries/type-theory/ (вопросы propositions as types & consistency, м?)

Можно, конечно, «консистентно» фигачить в рамках единственного типа и его подтипов, но почему бы не иметь ещё эти подтипы как выделенные языковые сущности — разные типы (типизированные структуры данных, типизированные функции, зависимые структуры данных и функции).

Если есть f : Dyn -> Dyn < Dyn, то forall B < Dyn, x : B, f x — ок, но если ещё есть f : A -> A < Dyn, то даже с подтипированием some B < Dyn, B !< A, x : B, f x никак не должно существовать — вполне ожидаемое («консистентное») поведение.

motto
()
Ответ на: комментарий от anonymous

Ты так говоришь как будто на хаскеле можно получить бОльший уровень гарантий.

Конечно, например в задаче выше известно что лежит в коробках и размер уже в compile time. Можешь написать что тебе этого не нужно, но факт остаётся фактом, в лиспе их нету, в хацкелях есть. Если хочешь поспорить на эту тему, то приведи лиспокод, который будет такие гарантии давать.

Ну ты же понимаешь, что если у тебя весь код будет в fromDyn/toDyn, то это будет куча нечитабельного говна?

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

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

Ты так говоришь как будто на хаскеле можно получить бОльший уровень гарантий.

Конечно можно.

{-# LANGUAGE ExistentialQuantification #-}

data Cat = forall a . Cat a

cats = [Cat 1, Cat "preved"]

Что можно делать с элементами типа Cat? :]

sf ★★★
()
Ответ на: комментарий от sf

Ну dyn было исключительно потому, что в за десяток предыдущих тредов мне уже достало писать existential типы :).

Да впрочем оно отличается только дополнительным требованием Typeable и десятком вспомогательных методов.

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)

Переместите это в talks, пожалуйста.

anonymous
()
Ответ на: комментарий от emulek

не знаю как хаскель, а C++ не позволил-бы, пока не пропишешь метод огурцы::operator+(const карандаши&).

Позволил бы, хз.

Тогда сложит без проблем(правда в результате получится хрень полная).

Так в том и дело что оплучится вполне осмысленная вещь.

anonymous
()
Ответ на: комментарий от fmdw

. Статическая типизация всегда ограничивает множество термов, которое можно выразить на языке.

Только это синтаксис, а не семантика.

anonymous
()
Ответ на: комментарий от motto

Если статическая типизация «неконсистентна», то динамическая, являясь частным случаем, — тоже :)

Да, только дело же наоборот - статическая типизация частный случй динамической :)

anonymous
()
Ответ на: комментарий от qnikst

Конечно, например в задаче выше известно что лежит в коробках и размер уже в compile time. Можешь написать что тебе этого не нужно, но факт остаётся фактом, в лиспе их нету, в хацкелях есть. Если хочешь поспорить на эту тему, то приведи лиспокод, который будет такие гарантии давать.

Так какие нетривиальные гарантии тут дает хаскель?

Ты же понимаешь, что для решения этой задачи хватит обычных списков

Мы уже увидели решение на обычных списках - в 25 длинее, чем на лиспе.

anonymous
()
Ответ на: комментарий от anonymous

Нет - решение на обычных списках это использование [a], в случае лиспа тип a фиксирован единственным существующим в лиспе типом.

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

Т.е. то, что untyped lambda calculus полно по Тьюрингу, а simply typed — нет, это исключительно синтаксическое различие? Ясно.

fmdw
()
Ответ на: комментарий от anonymous

Ты же сам понимаешь, что динамическая типизация является частным случаем статической, в которой существует единственный тип, являющийся value universe (чёрт знает как по русски это правильно). При этом имея статическую систему типов можно гарантировать вывод типов в даже в динамических языках. В общем вся твоя лисповселенная отоюразится на один ADT/GADT. Можно попытаться говорить о мифических языках, в которых динамически могут появляться новые примитивы невыразимые в рамках существующих, но у меня нет знакомых единорогов чтобы спросить у них литературу на сей счёт.

qnikst ★★★★★
()
Ответ на: комментарий от fmdw

Ну и давай уж договоримся, о какой семантике идёт речь. Предлагаю для простоты говорить о structural operational.

fmdw
()
Ответ на: комментарий от lovesan

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

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от fmdw

А какое? Язык - это набор корректных термов. Если в каком-то языке корректных термов меньше - они отличаются синтаксически. Семантика - это смысл корректных термов.

То есть чтобы задать семантику нам надо _перед этим_ определить, какие термы корректные.

anonymous
()
Ответ на: комментарий от qnikst

каким типом будет представлено значение из лиспа

Прекрасно влияют.

Ок, я тебе сейчас взорву мозг. Двумя пунктами:

  • В лиспе типы можно создавать в рантайме. Причем даже примитивные типы, если реализация достаточно навороченная.
  • Строго говоря, тут словосочетание «в рантайме» лишнее. В лиспе всё и всегда - это рантайм.
lovesan ★★
() автор топика
Ответ на: комментарий от qnikst

Ты же сам понимаешь, что динамическая типизация является частным случаем статической, в которой существует единственный тип, являющийся value universe (чёрт знает как по русски это правильно).

Нет, это статическая типизация - частный случай динамической, в которой нет рефлексивного объекта.

anonymous
()
Ответ на: комментарий от lovesan

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

Я не знаю ты или тупишь, или не проследил за веткой дискуссии.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

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

lovesan ★★
() автор топика
Ответ на: комментарий от anonymous

статическая типизация - частный случай динамической, в которой нет рефлексивного объекта

Да пусть будет, чё. Он есть в C, C++, Java, C#, Scala, Haskell как минимум.

motto
()
Ответ на: комментарий от lovesan

В лиспе всё и всегда - это рантайм.

Макросы раскрываются только в компилтайме. Поэтому не все. Если мы говорим о CL, конечно.

Более того, замыкания и функции — это тоже не рантайм-объекты. В рантайме у тебя нет доступа к их исходному коду, в общем случае.

terminator-101
()
Ответ на: комментарий от mix_mix

проектах больше хотя бы десятка тысяч строк

Таких проектов на хаскеле вашем и не существует даже.

loz ★★★★★
()

Закумарили своими лиспами. Пишите на vhdl.

nanoolinux ★★★★
()
Ответ на: комментарий от loz

Таких проектов на хаскеле вашем и не существует даже.

Хаскель не единственный статически типизированный язык, внезапно.

mix_mix ★★★★★
()
Ответ на: комментарий от qnikst

Это сознательная ложь или незнание?

«Не пытайтесь объяснить злым умыслом то, что можно объяснить невежеством» (ц)

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.