Выход mocl

Покажи хоть один пример статически типизированных лисп-макросов.

Нет, ну если принципиально подойти к сути, то макрос это функция типа s-exp -> s-expr. Ну а тип s-expr описывается элементарно. В чём проблема-то?

В Nemerle - какой-то мрак в сочетании макросов с объектной моделью .NET

А что вообще могут дать статически типизированные макросы? Проверку корректности генерируемого синтаксиса? Че, серьезно что ли? А это как, если мы макросы пишем для расширения синтаксиса, по сути? Гарантию неперекрытия синтаксиса одного макроса другим? А вдруг все так и задумывалось? Один макрос раскрывается в вызове другого? Проверка корректно ли он разложился на плес^W функции и спецопы? От этого, возможно, есть некоторая польза - но это не про статическую типизацию вообще, а про какой-нибудь статический анализ с варнингами. Про доступ в макросе к несуществующим полям структуры тоже в статике ошибку будем клеить? А если за время жизни системы эти поля появляются и исчезают?

Даже какую-то глупую отмазку придумали, что мол, если нужны вам макросы, то вы что-то делаете не так. Право смешно читать их :)

А можно линк?

В чём проблема-то?

Выход mocl (комментарий)

Как не странно - юзерфрендлиевость. По уровню шума и трудноси распознавания высокоуровнвой структуры программы глазами s-выражения в топе.

О каких трудностях речь? На мой взгляд CL вполне себе user friendly. Давайте конкретно, в чём вы видите проблемы?

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

Это да. Правда.

Python - комьюнити проект.

Если ты ван Россума называешь комьюнити...

Руби изначально задумывался как «лисп без скобок» - т.е. дин.типизация и метапрограммирование.

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

Напомню, что именно на нем, а не на каком-то статически типизированном мамонтовом г-не был написан rails фреймворк

И что? Руби динамический язык. Если посмотреть на использование собственно динамики в руби - начинаешь рыдать кровавыми слезами.

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

Куче пионеров которые иначе учили бы php. А так они купили маков и начали ощущать себя хипстерами.

Если программа не умерла, значит она не закончена

Не закончена - значит на момоент сборки отсутствуют все копоненты программы.

В случае шаблонизаторов - динамическую типизацию выбирают потому что от статической оверхед гарантий и падение скорости разработки.

В случае шаблонизаторов это делают потому что никто не разрабатывает их для написания больших проектов. А те кто так делают получают вечную проблему (смотри всякие форумы которые dosятся и индектятся просто потому что существуют), и всякие фейсбуки которые плачут кровавыми слезами изобретая JITы для PHP.

Это именно, что преимущество. Для целого класса систем.

В чем преймущество? Все что я слышу в пользу динамических языков - это почему-то не их действительныё динамические свойства например для RPC, а «я быстрее разрабатываю потому что мне не надо следить чтобы программа собственно работала». Офонареть.

Покажи хоть один пример статически типизированных лисп-макросов.

http://scalamacros.org/

Lisp-style макросы и динамическая типизация - вещи взаимосвязанные.

Так звучит более правдоподобно (хотя всё равно неизвестно, правда ли).

Python - комьюнити проект. Где то сообщество, которое сделало его статически типизированную версию с выводом типов?

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

Давайте конкретно, в чём вы видите проблемы?

В примитивности структурирующих элементов для программы. Все есть s-expression. Высокоуровневіё элементы - тот же CLOS - очень шумный.

(defclass person ()
  ((name :accessor person-name
         :initform 'bill
         :initarg :name)
   (age :accessor person-age
        :initform 10
        :initarg :age)))

vs

class Person(val name:Symbol='Bill, val age:Integer=10)

Ну вообще да. От типа, навроде: на входе всё что угодно и на выходе всё что угодно проку никакого. Совершенно.

и всякие фейсбуки которые плачут кровавыми слезами изобретая JITы для PHP.

Facebook плакал не из-за того, что строгая и статическиая типизация отстутствует, а из-за перфоманса. На сколько я знаю.

Покажи хоть один пример статически типизированных лисп-макросов.

Qi?

А что вообще могут дать статически типизированные макросы? Проверку корректности генерируемого синтаксиса?

Дискриминацию по типам. Смотри макросы в скале. Можно для разных типов генерировать различный AST, вызывать разичные оптимизированныё структуры и т.д.

В примитивности структурирующих элементов для программы. Все есть s-expression. Высокоуровневіё элементы - тот же CLOS - очень шумный.

S-expressions и гомоиконность — это скорее минимализм, чем примитивизм, ввиду наличия макросов. А вот сложный синтаксис — это засады для МП на пустом месте. То есть меняем простое МП на синтаксическую вкусовщину.

class Person(val name:Symbol='Bill, val age:Integer=10)

А как получить доступ к name и age? Акцессоры генерятся?

Как не странно - юзерфрендлиевость.

Тогда бы на перле никто не писал бы.

Facebook плакал не из-за того, что строгая и статическиая типизация отстутствует, а из-за перфоманса. На сколько я знаю.

Когда мы увидим динамические языки в топе по перформансу?: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=nbody&lang...

Кстати, мне одному кажется что первый вариант менее шумный, чем второй? В Lisp'овском варианте шумят только keyword'ы. Тогда как во 2-ом варианте шумят: val, :, Symbol и Integer.

S-expressions и гомоиконность — это скорее минимализм

Такой минимализм сейчас хорош для всяких промежуточных языков. А руками уж хватит минимализма - в синтаксисе - хорошо бы минимализм в области сигнал/шум для текста программы.

А как получить доступ к name и age? Акцессоры генерятся?

слово val сказало что они должны быть. Если его поубирать - их не будет. Если сказать что это var - будут и сеттеры.

Тогда бы на перле никто не писал бы.

Уже и не пишет:)

Уже и не пишет:)

Как бы в Топ10 по данным tiobe.

Такой минимализм сейчас хорош для всяких промежуточных языков. А руками уж хватит минимализма - в синтаксисе - хорошо бы минимализм в области сигнал/шум для текста программы.

Да а что шумит-то в таком минималистичном синтаксисе? Я так и не понял. Объективно только скобки шумят. Но это проблема решается тем, что их просто никто не читает, а читают код по отступам. Т.е. это вопрос самой первой элементарной практики.

Как бы в Топ10 по данным tiobe.

Зато тенденция...

http://www.tiobe.com/index.php/paperinfo/tpci/Perl.html

Когда мы увидим динамические языки в топе по перформансу?

Ну начнём с боянов о том, что перфоманс (особенно преждевременный) практически никогда не нужен. Значительно чаще нужен перфоманс в непосредственной разработке. Также, если взять CL, то для перфоманса никто не отменял manifest typing. И у меня, кстати говоря, большие сомнения по поводу того, что Scala со «статической и строгой типизацией» уделает SBCL. Очень большие.

Да а что шумит-то в таком минималистичном синтаксисе?

Вообще шумит именно то что высокоуровневые концепции типа тех же классов декларятся очень низкоуровненым структурным синтаксисом. Как в XML.

Когда мы увидим динамические языки в топе по перформансу?: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=nbody&lang...

Прямой связи между скоростью и типизацией не просматривается. Например, статическая типизация не помогла ghc обогнать sbcl. Линия раздела лежит в другой плоскости: языки с рантаймом близким к железу быстрее языков в абстрактным рантаймом.

Также следует иметь в виду поучительную историю о swizard'e, лиспе и жабе.

Последние три года популярность стоит на месте.

Значительно чаще нужен перфоманс в непосредственной разработке.

Для прототипов. Если в разработке есть две фазы вроде прототип/продакшен с полностью разной реализацией. А на практике - фейсбук изобретает VM, твиттер переписывает на скалу, linked-in на скалу и плюсы и т.д.

И у меня, кстати говоря, большие сомнения по поводу того, что Scala со «статической и строгой типизацией» уделает SBCL.

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

Вообще шумит именно то что высокоуровневые концепции типа тех же классов декларятся очень низкоуровненым структурным синтаксисом. Как в XML.

Ну я, например, не вижу никакого шума и низкоуровневости относительно второго варианта, особенно если ещё убрать аргумент с определением акцессоров. А также, для генерации классов с определённой функциональностью никто не мешает написать макрос, который будет на столько абстрагировать, на сколько это вообще возможно в конкретной задаче. Вот что-что, а Lisp чуть ли не единственный язык в котором можно убрать вообще любую копипасту, любой boilerplate.

Прямой связи между скоростью и типизацией не просматривается

Мы наверное разныё таблицы смотрим.

Линия раздела лежит в другой плоскости: языки с рантаймом близким к железу быстрее языков в абстрактным рантаймом.

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

Последние три года популярность стоит на месте.Последние три года популярность стоит на месте.

Упав из топовых по показателям языков в «лучший из худших».

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

Эти бенчмарки ни разу не показатель. Тут как-то даже Архимаг рассказывал всё по хардкору относительно этих тестов. Если осилишь, то предлагай задачу. Ты напишешь на Scala, а я на SBCL. Померимся.

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

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

Давай начнём, например, с простенького: http://www.spoj.com/problems/HOMO/

Если очень свербит можно определить свой dsl-для описания классов. Благо дизайн языка позволяет.

Но это никому не нужно, бо восприятие синтаксиса --- вопрос привычки.

Эти бенчмарки ни разу не показатель.

Почему не показатель? Потому что числодробилки? Или потому что микробенчмарки?

Чем больше динамики - тем дальше от железа и тем сложнее нужен jit

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

Мы наверное разныё таблицы смотрим.

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

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

Быстрый статический компилятор тоже не так просто сделать.

Как минимум, потому что реализации на SBCL плохие.

Упав из топовых

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

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

Он, в целом, прав. Нынче разработка на perl — чаще весго legacy. Хотя мне, субъективно, по дизайну perl больше нравится, чем python.

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

Быстрый статический компилятор тоже не так просто сделать.

Гораздо проще, чем JIT для динамического языка. Приличные компиляторы статически типизированных языков - начало 70-х, приличный JIT для динамического языка - начало 90-х.

Принципиальная возможность это сделать не важна

Вот честно, ты не знаешь о чём говоришь. Всякие def-что-нибудь, раскрывающиеся в defun или defclass --- это же азбука лиспового макростроения. См. хотя бы тут: http://lisper.ru/pcl/practical-building-a-unit-test-framework

Python - комьюнити проект.

Если ты ван Россума называешь комьюнити...

Почитай что ли Masterminds of Programming для начала, интервью с Гвидо, где он рассказывает о своем участии и роли. О процессе разработке, о том, чем был Python, чем стал - кстати, яркий пример, как открытость разработки делает из овна конфетку.

Это все гон и самооправдания. Статический компилятор напорядки сложнее чем компилятор динамического языка

И напорядок ненужнее.

где достаточно синтаксической корректности, а там будь что будет.

Для статики перестали писать тесты? Или их пишут меньше? Да вы что :) Статика как раз только синтаксические ошибки и отлавливает да необъявленные переменные, на другое не годится. Зато жестко фиксирует структуры так, что в лучшем случае к ним будут обращаться через интерфейсы. Можешь для удобства считать, что динамика - это такие интерфейсы повсюду, чтобы не впадать в многословный статиконевминоз, теряя лес за деревьями.

Авторы банально не осилели статику.

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

Напомню, что именно на нем, а не на каком-то статически типизированном мамонтовом г-не был написан rails фреймворк

И что? Руби динамический язык.

Что что? Язык формирует образ мышления, в случае яп - еще и технологию. На выходе получаем (или не получаем, как в случае со статикоговном) прорыв. Практически *все* современные стартапы не заточенные под специфическую платформу, вроде ведроида с ойфонами, выбирают языки с динамической типизацией - фейсбук, линкедин, инстаграммы всякие, дискусы, *весь* веб (это понятно), но не только веб - куча питона в научке, на js пишут анализаторы движений и эмоций, 99% серверов приложений не вне унылого интерпрайза - на динамике.

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

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

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

Куче пионеров которые иначе учили бы php. А так они купили маков и начали ощущать себя хипстерами.

Какая глупость, есть веб (перспективная и возможно самая социально значимая сфера в ИТ), но нет инструментов, кроме пхп, перла и cgi, чтобы разрабатывать можно были без боли (умные люди избегают областей с плохими инструментами) - вот там и были одни глубоко мной уважаемые php-бойцы. Сейчас это совсем не так - веб избавляется от рутины быстрее, чем любой интерпрайз, а веб в виде сервисов на темной стороне луны содержит сервер приложений, с необходимыми для домейна инновациями, технологиями и алгоритмами. Десктоп кончился, как и дрочка на байтики. Сегодня веб - это мордочка gui к высокотехнологичным серверам приложений. Которые тоже все на ерлангах, питонах, лиспах.

Если программа не умерла, значит она не закончена

Не закончена - значит на момоент сборки отсутствуют все копоненты программы.

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

В случае шаблонизаторов - динамическую типизацию выбирают потому что от статической оверхед гарантий и падение скорости разработки.

В случае шаблонизаторов это делают потому что никто не разрабатывает их для написания больших проектов.

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

А те кто так делают получают вечную проблему (смотри всякие форумы которые dosятся и индектятся просто потому что существуют), и всякие фейсбуки которые плачут кровавыми слезами изобретая JITы для PHP.

Ну да, лучше всего было бы не выпустить фейсбук и местный городской форум еще лет 10, главное чтобы не тормозил и не падал. Ты это так жгешь? Всем глубоко похер на скорость, на стибальность, на что-то там еще, какие-то мучения с JIT-ом - людям нужен Прогресс - «right here, right now», это резонное эволюционное требование. 99 из 100 умрут, идея (или организация бизнес-процессов) пройдет проверку на прочность и всем плевать тормозили эти 99 и тем более _насрать_ тормозит ли оставшийся 1 из 100, потому то юзабелен именно он, а вопросы масштабирования и ресурсов нас будут волновать ровно тогда, когда появится конкурент, ни секундой раньше.

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

Какие? Тенденция там очевидна - вверху в основном статика внизу в основном динамика.

Быстрый статический компилятор тоже не так просто сделать.

я про то и говорю - статический компилятор вещь сложная. А наваять простенький интерпретатор для динамики - фигня делов.

Как минимум, потому что реализации на SBCL плохие.

Я так понимаю можно туда залить лучше.

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

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

Это именно, что преимущество. Для целого класса систем.

В чем преймущество? Все что я слышу в пользу динамических языков - это почему-то не их действительныё динамические свойства например для RPC

Очень зря что ты об этом не слышишь. Я вот об этом постоянно говорю. О динамичности системы, это означает, что новая функциональность в рабочую систему может прилететь извне, иногда от обычного пользователя.

а «я быстрее разрабатываю потому что мне не надо следить чтобы программа собственно работала».

Нет, правильно так: я быстрее разрабатываю, потому: 1) Мне не приходится декларировать типы 2) Не приходится собирать и компилировать 3) Не приходится бороться с системой типов 4) Не приходится городить костыли для создания систем с динамичной жизнью времени исполнения 5) Еще мне не приходится отказываться от макросов 6) И хуярить интерфейсы на каждый чих. Динтипизация - это, как я уже сказал, такие соглашения по интерфейсам в документации к проекту.

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

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

Гораздо проще, чем JIT для динамического языка.

Что-то я не вижу толп быстрых компиляторов С++, написанных школотой на каникулах от нечего делать.

Приличные компиляторы статически типизированных языков - начало 70-х, приличный JIT для динамического языка - начало 90-х.

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

Статика как раз только синтаксические ошибки и отлавливает да необъявленные переменные

Тоньше надо.

Можешь для удобства считать, что динамика - это такие интерфейсы повсюду

Да ладно, можно же считать, что динамика - это статика, но у всех объектов один и тот же тип.

людям нужен Прогресс - «right here, right now», это резонное эволюционное требование. 99 из 100 умрут, идея (или организация бизнес-процессов) пройдет проверку на прочность и всем плевать тормозили эти 99 и тем более _насрать_ тормозит ли оставшийся 1 из 100

«Остапа понесло» (ц)