+1 Херачить юай на джаве или сишарпе или делать говносайты на похапэ - не программирование. LISP - лучший язык программирования. Мощнее инструмента еще не придумали и не придумают поскольку он натурален. На лиспе можно писать используя фишки пролога или хаскеля

PS: питон тоже говноязык

>Программист отличается от быдлокодера именно тем, что он понимает, как работает программа на уровне железа.

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

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

вот перепиши мой код на лиспе, чтобы он оборачивался за 32 бита, а не 28-29 как у love5an, тогда и сравним. причем сравним при разных BITS. (предупрежают — int там 32битный, да надо было написать assert)

А зачем? Что это докажет?

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

Ты глуп и не образован. Или троллишь. На лисп реализовано до хрена всего.

> Давай конструктивно: рассмотрим dymamic_cast или его аналог в жаве в контексте проблем которые они рещают. Для решения каких проблем нужен динамический даункастинг и как можно обойтись без него? В качестве примера использования динамического даункастинга можно взять например ациклический визитор

я понял о чем ты

в недодуманных плюсах вместо нормальной статически верифицируемой конструкции pattern matching-а в сложных случаях проще плюнуть, и юзать dymamic_cast — но это не значит, что у динамичекой типизации есть какие-то преимущества — это всего лишь доступный костыль.

> А зачем? Что это докажет?

померит скорость исключений

ничего не докажет

> На уровне железа программа работает тривиально: процессор последовательно выфетчивает из памяти инструкции по изменению состояния компьютера или подключенных устройств и выполняет эти инструкции. Для того чтобы осилить этот концепт не нужно даже технического образования.

А теперь расскажи, как на уровне железа работает программа из 10 строк на хаскеле — где юзаются статические вызовы, где диспетчеризация по таблице (а-ля vtbl) а где двойные call-ы.

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

> Давай конструктивно:

Когда я пытаюсь с тобой общаться, у меня постоянное впечатление, что ты говоришь на иностранном языке. Усилия на понимание себя не оправдывают/

рассмотрим dymamic_cast или его аналог в жаве в контексте проблем которые они рещают.

Зачем?

На уровне железа программа работает тривиально: процессор последовательно выфетчивает из памяти инструкции по изменению состояния компьютера или подключенных устройств и выполняет эти инструкции.

Низачот, слишком толсто.

На величие Plain C никто не покушался, он необходим. В мире должно быть два языка: Pure C, Common Lisp

>> Числовой континуум трактуется не как совокупность отдельных точек, а как «среда становления», поток измельчающихся рациональных интервалов.

Мне определённо импонирует такое определение.

ирония что ли?

действительное число от 0 до 1 задается функцией d(n): N -> 0..9, которая есть не что иное, как поток измельчающихся рациональных интервалов

[ d(0)/10, (d(0)+1)/10 ]

[ d(0)/10+d(1)/100, d(0)/10+(d(1)+1)/100 ]

[ d(0)/10+d(1)/100+d(2)/1000, d(0)+d(1)/100+(d(2)+1)/1000 ]

...

d(n) — это n-ая цифра числа.

померить или вычислить сразу число мы не можем, а вот указать конструктивную процедуру измерения или вычисления d(n) — можем.

На величие Plain C никто не покушался, он необходим. В мире должно быть два языка: Pure C, Common Lisp

В моём списке кроме них ещё ассемблер есть ;) До тех пор, пока gcc не научится на sse писать лучше, чем я сам.

>А теперь расскажи, как на уровне железа работает программа из 10 строк на хаскеле — где юзаются статические вызовы, где диспетчеризация по таблице (а-ля vtbl) а где двойные call-ы.

На самом деле в HW на Си объяснить всю цепочку от printf до сисколла сможет не каждый, не говоря уж о том что происходит внутри сисколла. Лично я очень смутно помню архитектуру STREAMS из книжки Робачевского и не уверен насчет того что в линуксе драйвера TTY устроены похожим образом.

>> Числовой континуум трактуется не как совокупность отдельных точек, а как «среда становления», поток измельчающихся рациональных интервалов.

Мне определённо импонирует такое определение.

ирония что ли?

действительное число от 0 до 1 задается функцией d(n): N -> 0..9, которая есть не что иное, как поток измельчающихся рациональных интервалов

[ d(0)/10, (d(0)+1)/10 ]

[ d(0)/10+d(1)/100, d(0)/10+(d(1)+1)/100 ]

[ d(0)/10+d(1)/100+d(2)/1000, d(0)/0+d(1)/100+(d(2)+1)/1000 ]

...

d(n) — это n-ая цифра числа.

померить или вычислить сразу число мы не можем, а вот указать конструктивную процедуру измерения или вычисления d(n) — можем.

>> рассмотрим dymamic_cast или его аналог в жаве в контексте проблем которые они рещают.

Зачем?

Ну надо же сначала определить те места в программах где возникает необходимость применить конструкцию наподобие dynamic_cast(*). После этого можно попытаться доказать что все эти места возникли в результате неправильного проектирования. Если докажем, то да - Д.Т не нужна.

(*) dynamic_cast - это твоя любимая рантаймовая проверка типа есличе.

>На уровне железа программа работает тривиально: процессор последовательно выфетчивает из памяти инструкции по изменению состояния компьютера или подключенных устройств и выполняет эти инструкции. Для того чтобы осилить этот концепт не нужно даже технического образования.

На таком общем уровне конечно любой дурак знает. Я имел в виду другое. Глядя на программу на лиспе (и вообще любом ФЯП) ты сможешь сказать, где что будет выполняться, сколько памяти использоваться и т.д.? На том же С/C++ это намного очевиднее, на С#/Java меньше, но и то несравнимо с функциональными языками.

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

я представляю какие жесткие тормоза были бы на интерпретаторе типа лиспа.

А что тут представлять? Люди до сих малообразованы, раз лисп для них - интерпретатор. И даже ассемблерные дампы их на мысли не наводят...

c++ vs lisp

3a mnogo let v hi-tech'e ne videl ni odnogo proekta na lisp. Mojet kto-to podskajet? Uto4nenie: trebuetsya primer kommer4eski uspe6nogo, prikladnogo produkta

> определить те места в программах где возникает необходимость применить конструкцию наподобие dynamic_cast(*). После этого можно попытаться доказать что все эти места возникли в результате неправильного проектирования. Если докажем, то да - Д.Т не нужна.

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

(*) dynamic_cast - это твоя любимая рантаймовая проверка типа есличе.

Вот так зайдешь на ЛОР и узнаешь о себе много нового.

>Глядя на программу на лиспе (и вообще любом ФЯП) ты сможешь сказать, где что будет выполняться, сколько памяти использоваться и т.д.?

CL - это не ФП. Некоторые даже советуют на нем всегда использовать циклы если алгоритм не требует стека. Насчет памяти: в общем всегда очевидно где память аллоцируется - это безопасные функции типа cons, list, append, mapcar, reverse и пр.

Uto4nenie: trebuetsya primer kommer4eski uspe6nogo, prikladnogo produkta

Piano (http://www.lispworks.com/success-stories/piano.html). Пишут, что все крупные вендоры им пользуются. Коммерчески успешный, прикладной продукт.

>dynamic_cast - это средство _статически типизированного языка_.

А зачем он проверяет рантаймовый тип через rtti? Что такое статическая типизация вообще: это когда типы проверяются в compile-time. То что аргументом dynamic_cast-у передается совместимый тип в compile-time проверить нельзя.

>CL - это не ФП.

нет. чего не хватает до статуса «есть ФП»?

это безопасные функции типа cons, list, append, mapcar, reverse и пр.

замыкания, кондишены, массивы с ресайзом?

поздравляем-с.)

> Ну надо же сначала определить те места в программах где возникает необходимость применить конструкцию наподобие dynamic_cast(*). После этого можно попытаться доказать что все эти места возникли в результате неправильного проектирования...

...неправильного проектирования языка с++ — в окамле и хаскеле вместо визиторов имеется паттерн матчинг.

dynamic_cast - это твоя любимая рантаймовая проверка типа есличе.

то, что dynamic_cast *реализует* вариант динамической типизации не означает, что «рантаймовая проверка» в языке с Д.Т. аналогична по безопасности dynamic_cast

«рантаймовая проверка» в языке с Д.Т. проверяет соответствие никак не ограниченных типов, а dynamic_cast обычно уже ограничен корнем иерархии

> В мире должно быть два языка: Pure C, Common Lisp

Не не не ...
Есть еще OCaml/Haskell и РЕФАЛ
Ну может быть еще Prolog
Они тоже реализуют какие-то более-менее общие парадигмы/идеи

>На том же С/C++ это намного очевиднее

Что очевиднее? Что исключения всегда будут тормозить? Что конструкторы/дестукторы будет в каждой функции из трех строк дергать ядро своими new/delete? Что невозможно написать многопоточное приложение за вменяемое время?

>>CL - это не ФП.

нет. чего не хватает до статуса «есть ФП»?

Да вот на схеме вроде бы можно всегда писать в чистом ФП-стиле и быть уверенным что из-за исчерпания стека оно никогда не вылетит. На CL если алгоритм по сути не рекурсивный и для его реализации не подходит конструкция типа map или reduce, то лучше цикл нарисовать.

это безопасные функции типа cons, list, append, mapcar, reverse и пр.

замыкания, кондишены, массивы с ресайзом?

Для таких вещей даже в С++ не отвертеться от привлечения динамической памяти.

>> dynamic_cast - это средство _статически типизированного языка_.

А зачем он проверяет рантаймовый тип через rtti?

ХЗ. Потому что пользователи этого хотели, вероятно. Зачем они этого хотели - вопрос другой (и я не знаю ответа).

Что такое статическая типизация вообще: это когда типы проверяются в compile-time.

Давай лучше так - ты покажешь, как в динамически типизированном языке проверять типы в compile-time. Потому что в статически тпизированном языке есть куча способов сделать динамическую типизацию, а вот наоборот - хрен. Поэтому динамически типизированные языки и должны умереть.

Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

> чтобы он оборачивался за 32 бита, а не 28-29 как у love5an, тогда и сравним.

Не совсем понял о чем там у вас спор с Love5an, но не проще было бы загнать плюсовую программу в те же условия, что и лисповую, если вы действительно хотите что-то сравнить? То есть, переписать плюсовую программу с 32 бит на 28-29, добавить явные преобразования и плюс еще что-то. Или ты все-таки пытаешься что-то доказать всем помимо самого измерения скорости обработки исключений?

> То есть, переписать плюсовую программу с 32 бит на 28-29, добавить явные преобразования и плюс еще что-то. Или ты все-таки пытаешься что-то доказать всем помимо самого измерения скорости обработки исключений?

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

дык бородатым дядькам пишущим на Лиспе ПО для контроля полетов, системы управления аэропортами, военки, разного рода AI и т.д. не нужно кричать на весь интернет о своих успехах и распиленных бюджетах.

>Да вот на схеме вроде бы можно всегда писать в чистом ФП-стиле и быть уверенным что из-за исчерпания стека оно никогда не вылетит. На CL если алгоритм по сути не рекурсивный и для его реализации не подходит конструкция типа map или reduce, то лучше цикл нарисовать.

это не так.

> Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

declaim и declare в CL не прокатят?

> Или ты все-таки пытаешься что-то доказать всем помимо самого измерения скорости обработки исключений?

я не требую допустим доступ к регистрам SSE, я требую доступ к shl, add без проверки переполнения, которые есть в железе уже 40-50 лет.

Давай лучше так - ты покажешь, как в динамически типизированном языке проверять типы в compile-time.

Type propagation никто не отменял. Другое дело, что жалкий почитач (компьютер по-аборигенски) не может осознать всю глубину человеческой мысли, поэтому имеет право только на ворнинг.

Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

Qi, написанный, как известно, на Коммон Лиспе, имеет опционально отключаемую проверку типов. Хотим, проверяем, хотим, не проверяем.

>> Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

declaim и declare в CL не прокатят?

Если ты еще доставишь ссылку на описание их семантики - может быть.

>> Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

Qi

Это _отдельный язык_, а не CL, так ведь?

я не требую допустим доступ к регистрам SSE, я требую доступ к shl, add без проверки переполнения, которые есть в железе уже 40-50 лет.

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

Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

Qi

Это _отдельный язык_, а не CL, так ведь?

И что? С выключенной проверкой типов Qi - динамически типизируемый язык.

>> А зачем он проверяет рантаймовый тип через rtti?

ХЗ. Потому что пользователи этого хотели, вероятно. Зачем они этого хотели - вопрос другой (и я не знаю ответа).

То есть по твоему он мог быть реализован без рантаймовой проверки? А как бы он тогда работал? static_cast возвращает бинарный мусор если ему передать неправильный аргумент, что конечно еще хуже чем рантаймовая проверка и вероятный экзепшен. Или cast вообще не нужен? Если не нужен, то как реализовать паттерн наподобие ациклического визитора?

Давай лучше так - ты покажешь, как в динамически типизированном языке проверять типы в compile-time

CL как-то проверяет если declare type поставить в начало функции.

> Это _отдельный язык_, а не CL, так ведь?

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

>>>> Если ты, конечно, не продемонстрируешь compile-time проверку типов в динамическом языке.

Qi

Это _отдельный язык_, а не CL, так ведь?

И что?

Да вот интуиция говорит мне, что меня разводят :)

С выключенной проверкой типов Qi - динамически типизируемый язык.

ХЗ. ХЗ... может, ты и прав. Я слишком мало знаю о Qi. Это набор макросов к CL? Подмена readtable или еще чего-то?

> Ты этого не требуешь.

?

Ты наверняка даже до сего момента не знал, что на PPC нельзя в регистр загрузить immediate больше 12 бит.

не знал. но мне это и не надо — достаточно 2-3 бит.

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

не могу. но опять это не нужно

зато я гарантировано могу сказать, что компилятор:

1. молча не оторвет у меня 2-3 бита на тайптег, и еще вдобавок разное количество бит в зависимости от опций компиляции :-)

2. молча не добавит нафиг мне *здесь* не нужную проверку на переполнение (и затем оперирование длинными числами, как питон)

> динамический с опциональной статической проверкой типов.

Это уже близко к тому, что нужно :)

ХЗ. ХЗ... может, ты и прав. Я слишком мало знаю о Qi. Это набор макросов к CL? Подмена readtable или еще чего-то?

Другой парсер (ридтейбл) для того же компилятора и рантайма.

> ирония что ли?

действительное число от 0 до 1 задается функцией d(n): N -> 0..9, которая есть не что иное, как поток измельчающихся рациональных интервалов

[ d(0)/10, (d(0)+1)/10 ]

[ d(0)/10+d(1)/100, d(0)/10+(d(1)+1)/100 ]

Что-либо конструктивное здесь увидят лишь те, кто в детстве в Лего не наигрался. Ладно еще Брауэр, в его времена не было детских конструкторов.

Если серьезно, то я, например, действительно не вижу в таких определениях ничего конструктивного. Спрятать все потенциальные бесконечности в неведомую е***ую х**** под названием «свободно становящая последовательность» — это лишь уход от проблемы, а не ее решение. Не мне конечно судить, но это все похоже на большой-большой самообман.

>>> Числовой континуум трактуется не как совокупность отдельных точек, а как «среда становления», поток измельчающихся рациональных интервалов.

Мне определённо импонирует такое определение.

ирония что ли?

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

> это лишь уход от проблемы

1. От какой проблемы?
2. Чем «бесконечное множество точек» _принципиально_ лучше?