Зачем нужны динамические языки?

На сегодня пока все, я ухожу

> Это высказывание того же плана, что и то, которое утверждает что std::vector быстрее [].

Бредишь.

> Нет, почему же, прекрасное понимание.

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

> В плюсах это вообще в 20 строк.

Извини, лениво разбираться, какая часть библиотеки делает именно ЭТО.

> Иди учись. Может быть, тебе объяснят старшие, что подобная техника в ЛИСПе - last resort.

Кто мне что объяснит? Кто в этом треде может, тот не будет (они знают, что я и так знаю :), а ты Лисп не знаешь, поэтому не можешь.

> Че-то мне не понятно, как лениво менять все объекты без жутких тормозов. Ведь это надо вставлять проверку "а не поменялось ли определение класса" на каждый вызов метода этого объекта, или как?

Поэтому есть пачка других реализаций объектнов, а не всемогущий монстр CLOS :) Гибкость даром не даётся.

> Кто мне что объяснит?

Старшие лиспники. Которых в этом треде, в основном, не было.

> а ты Лисп не знаешь

Ошибаешься, у нас существенная асимметрия. Я более-менее знаю Лисп и хорошо знаю Хаскель. Ты более-менее знаешь Лисп (на серьёзное знание, извини, не тянешь) и вообще не знаешь Хаскель.

> Я более-менее знаю Лисп и хорошо знаю Хаскель.

Менее, чем более?

> Ты более-менее знаешь Лисп (на серьёзное знание, извини, не тянешь)

Об этом не тебе судить :)

> и вообще не знаешь Хаскель.

И, заметь, при всём при этом я никого Хаскеллю не учу. В отличие от.

> Об этом не тебе судить :)

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

Принеси песочку, родной.

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

>О да, я вижу. То, что полиморфизм бывает и рантаймовый - ты явно не в курсе.
Прекрасно в курсе, а вам надо было почитать тред, предже чем брызгать слюнями.
Generic fuctions из CLOS, "Object" в Java и .NET, COM из виндовз.

В хаскеле же его нет.

>Старшие лиспники. Которых в этом треде, в основном, не было.
О, вот и маразм попер.
Пациента можно закапывать.

>надеяться на компилятор - последнее дело

Это, как раз, _первое_ дело. Последнее это переписывать на "низком" уровне -- если "первых" не хватило.

На C++ пишете, наверное?

Про низкий уровень я не писал, писал я про дырявые, глупые и бесполезные абстракции.

> Это, как раз, _первое_ дело. Последнее это переписывать на "низком" уровне -- если "первых" не хватило.

Более того, основная моя претензия ко всем существующим языкам -- это именно то, что они плохо поддерживают возможность глубоко оптимизировать интерпретацию написанного мной кода без его переписывания, а точнее "прогибания" под низкоуровневые частности. (Лисп, формально говоря, позволяет такое, но мне кажется это там будет нерационально -- проще переписать).

> На C++ пишете, наверное? Про низкий уровень я не писал, писал я про дырявые, глупые и бесполезные абстракции.

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

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

>бесполезные абстракции
Пожалуйста - карринг
Выше - подробности

>А вот где в нашей теме упоминались или хотя бы косвенно касались дырявых абстракций?
А как же - пример большой дырявой абстракции - т.н. я.п. "хаскель"

>> бесполезные абстракции

> Пожалуйста - карринг

O_o

Я правильно понял, что карринг - это, по вашему мнению, бесполезная абстракция?

Это такой вид неуклюжих костылей.

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

И что? Всё равно же "первое дело" -- быстро написать пользуясь максимально "толстыми" для данной задачи абстракциями, и пусть компилер соптимизирует. Не получится у компилера -- убираем самые неугодные руками. Скорее всего это менее эффективный путь только для какой-нибудь риалтаймовой эмбедовщины.

> Это такой вид неуклюжих костылей.

Как бесполезная абстракция м.б. неуклюжими костылями? (я утверждаюсь в мнении, что гость умеет в основном копипастить)

>> бесполезные абстракции

> Пожалуйста - карринг

Гость, объясни пожалуста, каким образом карринг -- абстракция (и от чего -- абстракция).

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

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

Верно. Не имеет отношения к дискуссии.

> Но это не гарантировано

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

> И к тому же, надеяться на компилятор - последнее дело.

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

>> То, что полиморфизм бывает и рантаймовый - ты явно не в курсе. > Прекрасно в курсе, > Полиморфизм это прикрученные к статике задним числом кривые костыли

Как-то одно противоречит другому.

>>Старшие лиспники. Которых в этом треде, в основном, не было. >О, вот и маразм попер.

Блин, ты серьёзно считаешь, что большинство лиспников были в этом треде?

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

> Фишка в том, что в Хаскеле за счёт иммутабельности переменных можно проводить гораздо более серьёзные оптимизации.

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

НО:

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

Раскрою тему:

При всем этом, функциональных подходов может быть МНОГО, например, не только полный запрет выполнения кода, а выполнение особого, верифицированного кода, и/или автоматическая генерация по этому коду другого кода для поддержки все-таки функциональной парадигмы (ведущей к линейности времени поиска).

> И что, всё-таки, по-твоему мнению старшие лиспники скажу по поводу встроенности компилятора в лисп?

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

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

Жду обоснования этого утверждения. С нетерпением.

> Или что встроен, но использовать его категорически нельзя?

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

> При всем этом, функциональных подходов может быть МНОГО, например, не только полный запрет выполнения кода, а выполнение особого, верифицированного кода, и/или автоматическая генерация по этому коду другого кода для поддержки все-таки функциональной парадигмы (ведущей к линейности времени поиска).

По-моему, ты сейчас сказал вот что: во время обработки регэкспа может выполняться код, завёрнутый в различные монады.

Ставим монаду IO - получаем произвольную императивщину; ставим монаду Identity - получаем отсутствие каких-либо сайд-эффектов; ставим State - получаем код, который дополнительно может писать в переменную (и читать из неё); ставим Writer - получаем код, ведущий логи... и т.п.

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

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

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

Ну да. А ещё в языке не должно быть eval'а, должна быть статическая типизация по Хинди-Милнеру, синтаксис а-ля ML, и вот это уже классный Лисп будет...

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

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

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

> Ну да. А ещё в языке не должно быть eval'а, должна быть статическая типизация по Хинди-Милнеру, синтаксис а-ля ML, и вот это уже классный Лисп будет...

Не путай меня с хаскелистами.

> Процедурщина позволяет сделать поверх себя *разную* фукциональщину

(пожимая плечами) А функциональщина - разную процедурщину, причём проще.

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

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

> (пожимая плечами) А функциональщина - разную процедурщину, причём проще.

1. А по-моему разной процедурщины вообще не бывает. Она одна, в отличие от функциональщины.

2. И в чем это проще? Развей тему.

С ghc/ghci идут либы :]. И до mueval lambdabot таки юзал ghc напрямую, чтобы евалить гадостный юзерский код.

> С ghc/ghci идут либы :]. И до mueval lambdabot таки юзал ghc напрямую, чтобы евалить гадостный юзерский код.

Так где пример на хаскеле, как легко и просто сделать аналог специализации шаблона на плюсах, требующий на плюсах лишнего аргумента?

(желательно как у меня, чтобы откомпилил, и проверил-запустил)

>1. А по-моему разной процедурщины вообще не бывает. Она одна, в отличие от функциональщины.

а что значит "разная процедурщина", "разная функциональщина"? можно примеры разностей в функциональщине, которых не может быть в процедурщине?

>> 1. А по-моему разной процедурщины вообще не бывает. Она одна, в отличие от функциональщины.

> а что значит "разная процедурщина", "разная функциональщина"? можно примеры разностей в функциональщине, которых не может быть в процедурщине?

Кстати да, присоединяюсь к вопросу.

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

http://www.haskell.org/bz/th3.htm (lesson 2)

это что ли? и из-за этого столько шума?

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

А мужики то в ITA Software, Franz и много других и не знают. Ouch.

Засунь свое мнение куда подальше.

>Пример простенького with- макроса напишите:

опять же, что делает этот код?

with-open-file uses open to create a file stream to file named by filespec. When control leaves the body, either normally or abnormally (such as by use of throw), the file is automatically closed. If a new output file is being written, and control leaves abnormally, the file is aborted and the file system is left, so far as possible, as if the file had never been opened. 

>with-open-file uses open to create a file stream to file...

http://notes-on-haskell.blogspot.com/2007/03/design-patterns-in-haskell-brack...

http://www.zvon.org/other/haskell/Outputio/bracket_f.html

и никакого метапрограммирования. можно наконец нормальный пример макроса, который был бы действительно полезен, и который действительно было бы невозможно реализовать средствами Haskell/TH?

> Кстати да, присоединяюсь к вопросу.

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

>реализации процедурщины через функциональщину

слушай, в чём проблема-то? операционная семантика задаётся через State с двумя стеками (операции и результата) и таблицей памяти, синтаксический анализатор - пусть и не такой шустрый как в процедурном варианте,- но пишется без особых усилий (для LR(1) так и вообще генерируется). где сложности?

по сравнению с нутром boost.lambda - сказка. или ты с чем-то другим предлагаешь сравнить? с boost.mpl, например? с felix?