Здравствуйте, lomeo, Вы писали:

L>>>Генерацией с языка, который это позволяет.
C>>Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?
L>Зачем дизайнеру трогать результирующий HTML или CSS??
Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.

Здравствуйте, Cyberax, Вы писали:

L>>>>Генерацией с языка, который это позволяет.
C>>>Ага, и когда дизайнер поправит результирующий HTML или CSS, то что будешь делать?
L>>Зачем дизайнеру трогать результирующий HTML или CSS??
C>Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.

Отвечу обоим. В общем, да согласен. Я CSS не генерил ещё, кажется :-) Но и названия классов чтобы менялись — не вспомню.
Но я предупреждал, что пример не очень удачный ;-)

На этом, пожалуй, закругляюсь, спасибо!

Здравствуйте, yumi, Вы писали:
Y>Для себя я определил область применения отладчика. Это когда нужно разбираться в чужом коде. В своем коде, я почти не пользуюсь отладчиком.
Угадываю: в твоём коде отладчиком пользуются другие?

Здравствуйте, lomeo, Вы писали:

C>>Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.
L>Отвечу обоим. В общем, да согласен. Я CSS не генерил ещё, кажется Но и названия классов чтобы менялись — не вспомню.
L>Но я предупреждал, что пример не очень удачный
Генератор CSS на Haskell

vdimas,

L>>Я постепенно прихожу к выводу, что Scala возникла тоже из-за низкого уровня Java А это не та причина, по которой надо создавать новый язык, IMHO. А то получится Scala — монстр типа С++. Язык с набором несвязанных фич вместо языка с фичами, уложенными в некую систему. Хотя, вполне допускаю, что я пока просто эту систему не вижу.

V>Да, как-то пока сложно разглядеть идею Scala и причину его разработки как таковую, кроме причины отсутствия языковых альтернатив для Java — платформы.

Очень легко.

1-я причина — это максимально приближенное к идеалу (а идеал здесь — виртуальные классы, которые не могут быть поддержаны из-за JVM) решение Expression Problem:

"Can your application be structured in such a way that both the data model and the set of virtual operations over it can be extended without the need to modify existing code, without the need for code repetition and without runtime type errors.". We stress "without runtime type errors" as an important statement because the expression problem really becomes interesting (read challenging) when exposed to a type system that ensures safe execution of the code.

Отсюда следуют куски типа selftype-ы, traits, mixin composition-ы и абстрактные типы (не путать с абстрактными классами). А также чтобы реализовать расширяемые компоненты, необходимы функции-как-первоклассные-значения и вообще, всесторонняя поддержка ФП.
(подробности в "Scalable Component Abstractions" и "Independently Extensible Solutions to the Expression Problem")

2-я причина — это расширение паттерн-матчинга с алгебраических типов на объекты. Отсюда следуют куски про паттерн-матчинг в Скале, case classes и apply/unapply.
(подробности в "Translation Correctness for First-Order Object-Oriented Pattern Matching" и "Matching Objects With Patterns").

3-я причина — расширить систему типов так, чтобы джава со своими дженериками стала частным случаем. Отсюда поддержка экзистенциальных типов в Скале.

и 4-я причина — это разработка нетривиальных DSEL, как примеры библиотека актёров и SQL.
(соответствующая статья "Event-Based Programming without Inversion of Control")

Вроде бы всё, то есть я не знаю конструкции, которая бы не была обусловлена одним из вышеназванных 4-х пунктов.

Здравствуйте, thesz, Вы писали:

E>>Твоя фраза, имхо, воспринимается весьма однозначно: деньги платят за решения еще нерешенных никем проблем. Это очень сильное преувеличение, о чем я тебе и сказал. Если же ты пытался сказать о чем-то другом, то лично я этого не понял.

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

T>Значит, получается не решённая никем задача.

Вот хорошая заметка на эту тему: The Book Of JOSH (тебе она может быть еще интересна и враждебным отношением к Java ). Так во в ней описывается, как люди повторяют уже имеющуюся функциональность, но на другой "элементной базе".

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

Аналогично этому многие производители программ повторяют то, что уже делали когда-то другие, но чуть по своему. Посмотри, например, на реляционные СУБД, компиляторы C++, текстовые процессоры, http-сервера, видео/аудио-проигрыватели и пр. Это все ну никак не попадает под "не решенные никем задачи". И еще хорошо, если в конкретных продуктах есть действительно какие-то серьезные нововедения.

Здравствуйте, thesz, Вы писали:

T>Я практически четыре года подряд пишу программы, алгоритмы которых не знаю. Представляешь, каково это — ловить алгоритмические ошибки в программе, алгоритм которой ты толком не представляешь?

Нет, совершенно не представляю (идиотская ситуация, согласен), но не суть — громкое заявление ты сделал не на этот счёт. Ладно бы ты еще упёрся именно насчёт пошаговой отладки, я бы и не встрял, ибо само существование спора "пошаговая отладка vs отладочная печать" с моей т.з. — пример наличия идиотизма в нашей профессии. Мне этот спор не интересен. Но отказаться от отладки как таковой в любом её проявлении — это для меня открытие.


T>Ну, задача у тебя такая — разработать алгоритм. Это означает, что его изначально нет или он описывается кругами разводимых рук.

А вот это вполне нормально, когда алгоритм изобретаешь ты. Надо вникнуть в предметную область, научиться с потребителями общаться на их жаргоне и по ихнему руками разводить? — без этого в нашей профе никак. Ставить задачи на разработку — это тоже искуство, и сегодня эти люди зарабатывают поболе "чистых" технарей-программистов.


T>"Размеры современных проектов"
T>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.

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


T>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?
T>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.

Спасибо, за лестное звание друга. Очень не люблю количественные вопросы, но на схеме писал прилично, собственно, как и самописный мини-интерпретатор схемы тоже имеется. Бока в другом: тщательно изучил в своё время более 20-ти (!!!) исходников популярных лиспов и схем на предмет реализации замыканий, потому как оно где byvalue, а где-то byref (byname). Самое интересное, что все эти виды замыканий имеют право на существование, но они имеют разную семантику (разную модель), и отсюда несовместимость и косяки отлаженного исходника при смене платформы.

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

V>>P.S. К тому же, все в курсе, что гнутый компилятор Хаскеля до сих пор содержит прорву багов, отчего народ и не собирается пока что им пользоваться в серьёзных продуктах (так же как и Немерле). Так он и ходит на уровне языка для экспериментов и написания тулзин локального использования. Писать на этом "мегаязыке" со встроенными утечками памяти программы для банкоматов — увольте.

T>G не означает GNU.

Да, после того как отослал, увидел на сайте, откуда первая буква.


T>После этого параграфа, пожалуй, я буду настаивать, чтобы ты поверил мне на слово.



T>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.

Знаешь, меня даже не кол-во багов смущает в багтрекере ghc, а их характер. Ведь компилятор написан на Хаскеле! Ладно бы на С, как же так? (10 раз "ай-ай-ай"). Ты ведь не первый здесь Хаскель хвалишь, за последние годы было много рекламы такого плана. И что характерно — по большей части в хамоватом тоне.

То, что ты с чем-то там не столкнулся — это еще ничего не значит. Я, например, несколько лет использовал ADO для Compact SQL от MS, а потом, в одном из сценариев, обнаружил грубейший баг, о чём запостил, получил в ответ "спасибо", но баг был единственный на всю эту либу, а там море interop-a и прочей явной реинтерепретации памяти. Так что, не только в технологиях серебрянная пуля зарыта, она в первую очередь зарыта в организации работ, в ресурсах, в контроле кач-ва и т.д.

Мой поинт такой: за Хаскель было сказано уже слишком много на этом сайте. Кому надо, тот давно понял. Если бы у меня были подходящие задачи, я бы им, наверно, пользовался поактивней. А так у меня то возня с WinAPI, то VoIP. То по размеру программ ограничения идут, то сверхжёсткие по быстродействию... и на фоне этого меня улыбает твоя постоянная мантра о "несвоевременной оптимизации". Знал бы ты, сколько тяп-ляп кода лежит у нас в местах, которые не критичны в плане ресурсов. Как говорится, знаю, как сделать эти места лучше, не знаю — зачем.

Здравствуйте, thesz, Вы писали:

V>>Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы
V>>интиллисенсом для длинных идентификаторов,

T>Плохая практика. Теорему Шеннона о длине кода никто не отменял.

С точки зрения кода, один идентификатор — один символ. Незначащие идентификаторы требуют дополнительных комментариев, которые составляют неотъемлимую часть кода, и, соответственно, значащей информации.

V>>подсвечивал бы ошибки компиляции прямо в процессе редактирования кода,

T>Отвлекая от написания кода.

Не отвлекает, зато время экономит — я далеко не каждый день свой код компилирую, хотя сотни строк кода в день накидываются. В общем, этот пункт можно бсуждать только после приличной практики. Я в своё время был полным противником Java и .Net, ибо после возможностей С++ как-то убого всё было... Генерики и аналог замыканий в C# 2.0 немного спас положение, а заодно приобрёл практику пользования тулзами поддержки набора кода. В общем, время экономит нехило.

Я понимаю твой аргумент, насчёт того, что время можно нехило сэкономить выбором инструмента. Но, во-первых, инструмент должен соответсвовать задаче (а Хаскель далеко не всегда соответствует), а во-вторых, эффективность разработчика в сложном проекте — величина интегральная от слишком многих факторов, помимо самого выбранного ЯП.


V>>вставлял пропущенные варианты для паттерн-матчинга,

T>С большой вероятностью наиболее идиотским способом.

Ну вставит он тебе нечто вроде: (_, Some x, _) -> ?
и ты сразу будешь видеть, где у тебя получился неполный матч, удали да напиши себе что хочешь. Это был просто пример, вставлять он может много чего. Самым "идиотским" способом Решарпер вставляет NotImplementedExcetion в тело методов, которые я забыл нагенерить согласно реализованным контрактам, но это так удобно, что все именно с этого и начинают реализацию методов контрактов.

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


V>>отмечал бы неиспользуемые переменные в замыканиях,

T>Несмотря на то, что это разрешённая и часто используемая практика.

Для чего используемая? Для соотвествия типу ф-ии?


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

T>Из всех монад только ST и IO имеют побочные эффекты. Прикинь! Только 2 из всего их множества!

T>Ты бы пописал на Хаскеле, вместо фантазирования на эту тему.

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

Здравствуйте, palm mute, Вы писали:

C>>>Ну HTML — ладно. А вот CSS — точно будет редактировать напрямую. Ибо нафиг ему Haskell не сдался.
L>>Отвечу обоим. В общем, да согласен. Я CSS не генерил ещё, кажется Но и названия классов чтобы менялись — не вспомню.
L>>Но я предупреждал, что пример не очень удачный
PM>Генератор CSS на Haskell
Это, как я понимаю, не то. Это просто ещё один язык, "улучшенный css", который преобразуется в обычный css с помощью утилитки на хаскелле. Вот если бы это был eDSL, чтобы css-разметку можно было прозрачно пересекать с haskell-кодом, чтобы всё что можно проверялось на этапе компиляции — вот это другое дело.

V>>>Как это не может быть в принципе? Подобный "Решарпер" для Хаскеля помогал бы
V>>>интиллисенсом для длинных идентификаторов,
T>>Плохая практика. Теорему Шеннона о длине кода никто не отменял.
V>С точки зрения кода, один идентификатор — один символ. Незначащие идентификаторы требуют дополнительных комментариев, которые составляют неотъемлимую часть кода, и, соответственно, значащей информации.

Ай.

(настолько моему мозгу больно)

V>>>подсвечивал бы ошибки компиляции прямо в процессе редактирования кода,
T>>Отвлекая от написания кода.
V>Не отвлекает, зато время экономит — я далеко не каждый день свой код компилирую, хотя сотни строк кода в день накидываются. В общем, этот пункт можно бсуждать только после приличной практики. Я в своё время был полным противником Java и .Net, ибо после возможностей С++ как-то убого всё было... Генерики и аналог замыканий в C# 2.0 немного спас положение, а заодно приобрёл практику пользования тулзами поддержки набора кода. В общем, время экономит нехило.

Вот REPL поверх ФЯ попробуй, тогда говори, как часто ты компилируешь код.

V>Я понимаю твой аргумент, насчёт того, что время можно нехило сэкономить выбором инструмента. Но, во-первых, инструмент должен соответсвовать задаче (а Хаскель далеко не всегда соответствует), а во-вторых, эффективность разработчика в сложном проекте — величина интегральная от слишком многих факторов, помимо самого выбранного ЯП.

Лучший ЯП даст лучший дизайн (верхнего уровня).

V>>>вставлял пропущенные варианты для паттерн-матчинга,
T>>С большой вероятностью наиболее идиотским способом.
V>Ну вставит он тебе нечто вроде: (_, Some x, _) -> ?
V>и ты сразу будешь видеть, где у тебя получился неполный матч, удали да напиши себе что хочешь. Это был просто пример, вставлять он может много чего. Самым "идиотским" способом Решарпер вставляет NotImplementedExcetion в тело методов, которые я забыл нагенерить согласно реализованным контрактам, но это так удобно, что все именно с этого и начинают реализацию методов контрактов.

module Events where data Event = Key Char | Mouse Coord2

module MyEventProc where

onEvent (Key c) = ...
onEvent (Mouse c) = ...
onEvent x = ... -- this is default action. may cause "overlapping patterns warning"
                -- for a while. just ignore it.

Или:

unJust (Just x) = x

Смысла в Nothing нет.

V>В хаскеле же тоже есть классы типов (контракты, т.е.), и точно так же под них можно генерить заготовки имплементаций.

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

V>>>отмечал бы неиспользуемые переменные в замыканиях,
T>>Несмотря на то, что это разрешённая и часто используемая практика.
V>Для чего используемая? Для соотвествия типу ф-ии?

Именно.

V>>>подсказывал бы, когда монада не имела побочного результата и можно было бы преобразовать просто в ф-ию (бывают иногда атавизмы в процессе работы над кодом), и т.д. и т.п.
T>>Из всех монад только ST и IO имеют побочные эффекты. Прикинь! Только 2 из всего их множества!
T>>Ты бы пописал на Хаскеле, вместо фантазирования на эту тему.
V>Монады можно и самим делать, вроде, я еще не программировал но видел уже десятки их.

Ай.

(мозгу снова больно)

T>>Я практически четыре года подряд пишу программы, алгоритмы которых не знаю. Представляешь, каково это — ловить алгоритмические ошибки в программе, алгоритм которой ты толком не представляешь?
V>Нет, совершенно не представляю (идиотская ситуация, согласен), но не суть — громкое заявление ты сделал не на этот счёт. Ладно бы ты еще упёрся именно насчёт пошаговой отладки, я бы и не встрял, ибо само существование спора "пошаговая отладка vs отладочная печать" с моей т.з. — пример наличия идиотизма в нашей профессии. Мне этот спор не интересен. Но отказаться от отладки как таковой в любом её проявлении — это для меня открытие.

Этот спор тебе интересен. Ты его продолжаешь.

T>>"Размеры современных проектов"
T>>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.
V>Я ведь понимаю, что наболело, не понимаю только безосновательных обобщений. Ну дык прояви упорство на своём рабочем месте, докажи и обоснуй там свою правоту, там-то у тебя вполне конкретные, надеюсь, доводы будут, в отличие от гаданий тут.

Посмотрим.

T>>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?
T>>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.
V>Спасибо, за лестное звание друга. Очень не люблю количественные вопросы, но на схеме писал прилично, собственно, как и самописный мини-интерпретатор схемы тоже имеется. Бока в другом: тщательно изучил в своё время более 20-ти (!!!) исходников популярных лиспов и схем на предмет реализации замыканий, потому как оно где byvalue, а где-то byref (byname). Самое интересное, что все эти виды замыканий имеют право на существование, но они имеют разную семантику (разную модель), и отсюда несовместимость и косяки отлаженного исходника при смене платформы.

Что ты мне в качестве примера приводишь всё самое плохое, что есть в мире ФЯ?

Приводи всё самое хорошее.

Хотя бы ML возьми, если Хаскел не хочешь.

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

Современные ФЯ дают гораздо больше. Я, например, написал DSEL для описания ядер (аппаратуры), там в систему типов Хаскеля вынесены проверки размерности получаемых результатов. Да, это доступно на плюсах, но более громоздко и менее прямо.

T>>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.
V>Знаешь, меня даже не кол-во багов смущает в багтрекере ghc, а их характер. Ведь компилятор написан на Хаскеле! Ладно бы на С, как же так? (10 раз "ай-ай-ай"). Ты ведь не первый здесь Хаскель хвалишь, за последние годы было много рекламы такого плана.

1) Библиотека времени выполнения написана на Си.
2) ghc очень большой. Его поддерживает всего ничего человек, около 10. И при этом я встретил всего две ошибки несмотря на его выбор в качестве основного ЯП.

Для сравнения. Над icc трудится что-то около тысячи человек по всему миру.

Поэтому проводи повторный анализ.

V>И что характерно — по большей части в хамоватом тоне.

Если тебе не нравится мой тон, не общайся. Если тебе не нравится мой тон, не делай Gлупых ошибок.

V>То, что ты с чем-то там не столкнулся — это еще ничего не значит. Я, например, несколько лет использовал ADO для Compact SQL от MS, а потом, в одном из сценариев, обнаружил грубейший баг, о чём запостил, получил в ответ "спасибо", но баг был единственный на всю эту либу, а там море interop-a и прочей явной реинтерепретации памяти. Так что, не только в технологиях серебрянная пуля зарыта, она в первую очередь зарыта в организации работ, в ресурсах, в контроле кач-ва и т.д.

И не допускай non sequitur и смешения понятий.

Серебренная пуля относится только к ЯП. Всё остальное к выбору ЯП ортогонально.

V>Мой поинт такой: за Хаскель было сказано уже слишком много на этом сайте. Кому надо, тот давно понял. Если бы у меня были подходящие задачи, я бы им, наверно, пользовался поактивней. А так у меня то возня с WinAPI, то VoIP. То по размеру программ ограничения идут, то сверхжёсткие по быстродействию... и на фоне этого меня улыбает твоя постоянная мантра о "несвоевременной оптимизации".

Да ты ж оптимизируешь без огонька и без особых рассуждений.

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

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

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

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

Чтобы кода было меньше.

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

Здравствуйте, thesz, Вы писали:

T>>>Плохая практика. Теорему Шеннона о длине кода никто не отменял.
V>>С точки зрения кода, один идентификатор — один символ. Незначащие идентификаторы требуют дополнительных комментариев, которые составляют неотъемлимую часть кода, и, соответственно, значащей информации.

T>Ай.
T>(настолько моему мозгу больно)

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

А теперь еще раз про код и комментарии, а так же про определение понятий "символ/алфавит".


T>Вот REPL поверх ФЯ попробуй, тогда говори, как часто ты компилируешь код.

Вряд ли попробую в "промышленных масштабах" в ближайшее время, а самопридуманные примеры вряд ли что-то мне покажут. Так что делись своими наблюдениями.


V>>Я понимаю твой аргумент, насчёт того, что время можно нехило сэкономить выбором инструмента. Но, во-первых, инструмент должен соответсвовать задаче (а Хаскель далеко не всегда соответствует), а во-вторых, эффективность разработчика в сложном проекте — величина интегральная от слишком многих факторов, помимо самого выбранного ЯП.

T>Лучший ЯП даст лучший дизайн (верхнего уровня).

А как же middleware?
Использование максимального кол-ва имеющихся _надёжных_ решений — это тоже важный критерий в большой доле случаев, который оправдывает компромиссы относительно инструментария. Мне, может, глубоко в душе и неприятно соотносить себя с тем саммым миллионом леммингов, которые могут ошибаться (в могут и нет), но тот аргумент, когда всё что нужно есть под рукой и в очень надёжном исполнении, заставил меня примерно лет 5 назад пользоваться языками, которые недолюбливаю до сих пор. Се ля ви.

Я кстати, так и не понял, что насчёт модулей в Хаскеле, я имею ввиду бинарные коммерческие модули библиотечного плана (тот же потенциальный middlware), который не поддавался бы тривиальной декомпиляции. Потому как "предкомпилённые" модули что я пока видел, имеют текстовый формат и довольно легко читаются даже без предварительного форматирования. Да и как иначе, если 99% кода имеет "шаблонный" (в терминах С++) характер?


V>>В хаскеле же тоже есть классы типов (контракты, т.е.), и точно так же под них можно генерить заготовки имплементаций.

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

И что? Тоже самое происходит при отсутствии реализаций контрактов в том же C#. Одно дело по документации вытаскивать все методы контрактов (или по логам компилятора), другое дело сразу поиметь заготовки для их имплементации (одновременно с этим редоктор кода подсвечивает на эту ошибку, т.е. мы знаем о ней до компиляции). Мне тут даже настаивать неохота, ибо это надо просто попробовать в "промышленных масштабах" — все отмечают крайнее удобство подобного рода поддержки. Можно без этого жить? Конечно. Но с этим +1 к эффективности. А "+1" величина относительная.

V>>>>отмечал бы неиспользуемые переменные в замыканиях,
T>>>Несмотря на то, что это разрешённая и часто используемая практика.
V>>Для чего используемая? Для соотвествия типу ф-ии?

T>Именно.

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

Здравствуйте, vdimas, Вы писали:

V>Именно что "именно". Это известный косяк в дизайне, когда для существуют сценарии, для которых в сигнатуре наблюдается избыточность. На более высоком уровне "что-то не так", т.е. здесь есть, что подсвечивать.

Кстати, nponeccop тоже как то высказывал сомнения в практической полезности комбинатора K.

Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?

Здравствуйте, lomeo, Вы писали:


L>Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?

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

Чем больше степеней свободы предоставляет язык, тем больше потенциальных возможностей накосячить, та же самая бритва Оккама.
Именно из-за этого макросы, встроенные в язык, не совсем решают задачу создания своих DSL, т.к. зачастую необходимо не столько предоставить новые синтаксические конструкции в язык, сколько ограничить возможности имеющихся.

В общем, мне нравится идея использования смеси DSL для выражения различных частей программы. Некоторые из них запросто могут быть далеки от Тьюринг-полноты. Жаль, что на сегодня такой подход не оправдывает свои трудозатраты в общем случае, но ведущие разработчики ср-в поддержки разработки идут к "точке практичности" на всех парах.

Здравствуйте, vdimas, Вы писали:

L>>Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?

Речь же шла о косяке в дизайне? Так тут связь вроде как прямая — наличие K-комбинатора — косяк в дизайне. Я может и ошибаюсь, но не вижу где.

V>Если ключевое здесь "общего назначения", то да, наверно. Но мы не это обсуждали, а полезность диагностических возможностей IDE в деле поддержки разработки.

Если речь о IDE, то тут разница в том, что для императивного языка неиспользуемые переменные действительно можно поподчёркивать (изменили алгоритм, переменная не используются, но инициализируется, т.к. мы про неё забыли/не учли). В функциональном же языке неиспользуемая переменная нужна только чтобы закрывать дырку в типе. И везде, где она якобы не используется — верный там дизайн или кривой — надо смотреть далеко наверх в определения комбинаторов, а не при их использовании. Это по-моему очень важное отличие — IDE тут нечего помогать.

V>Чем больше степеней свободы предоставляет язык, тем больше потенциальных возможностей накосячить, та же самая бритва Оккама. ;)
V>Именно из-за этого макросы, встроенные в язык, не совсем решают задачу создания своих DSL, т.к. зачастую необходимо не столько предоставить новые синтаксические конструкции в язык, сколько ограничить возможности имеющихся.

+1. Как насчёт DSL на основе ленивого языка с HOF? (Да, я про Хаскель :))
Статическая типизация будет нам ограничивать, а ленивость + HOF позволят создавать хорошие комбинаторы.

Пример. Ты писал о языке context free art — не помню названия, но там ты очень красивые цветы рисовал буквально несколькими строчками.
Вот этот язык почти в таком же виде можно нарисовать на Haskell.

Это оффтопик, конечно, но тема, наверное интересная. Я тоже считаю макросы крайней мерой.

V>В общем, мне нравится идея использования смеси DSL для выражения различных частей программы. Некоторые из них запросто могут быть далеки от Тьюринг-полноты. Жаль, что на сегодня такой подход не оправдывает свои трудозатраты в общем случае, но ведущие разработчики ср-в поддержки разработки идут к "точке практичности" на всех парах.

Вот тут момент, о котором постоянно говорит thesz. Средства разработки как поддержка DSL против языковой поддержки. Вот ещё хороший язык для рисования DSL без макросов — Scala.

Здравствуйте, lomeo, Вы писали:

L>>>Теоретическая его (или его аналогов — игнорирование связанной переменной) полезность — завершение базиса комбинаторов сомненений не вызывает. Отсюда вопрос — должен ли практический язык общего назначения быть Тьюринг полным?

L>Речь же шла о косяке в дизайне? Так тут связь вроде как прямая — наличие K-комбинатора — косяк в дизайне. Я может и ошибаюсь, но не вижу где.

Сам себе отвечал?

Наверно в том ошибка, что не надо мешать базисы и дизайн.
Например, goto является самой базовой операцией для императивных языков, в которых для Тьюринг полноты достаточно всего пары: if + goto, однако его непосредственное использование в современных императивных языках — неоспоримый косяк.

ИМХО, необходимость использования низкоуровневого костыля в коде прикладного характера и есть косяк дизайна. Для непосредственной логики отсечения должно быть что-то вроде явного if, причём этот if должен так же существовать в моделируемой предметной области, а не "закрывать дырку" в коде.


V>>Чем больше степеней свободы предоставляет язык, тем больше потенциальных возможностей накосячить, та же самая бритва Оккама.
V>>Именно из-за этого макросы, встроенные в язык, не совсем решают задачу создания своих DSL, т.к. зачастую необходимо не столько предоставить новые синтаксические конструкции в язык, сколько ограничить возможности имеющихся.

L>+1. Как насчёт DSL на основе ленивого языка с HOF? (Да, я про Хаскель
L>Статическая типизация будет нам ограничивать, а ленивость + HOF позволят создавать хорошие комбинаторы.

L>Пример. Ты писал о языке context free art — не помню названия, но там ты очень красивые цветы рисовал буквально несколькими строчками.
L>Вот этот язык почти в таком же виде можно нарисовать на Haskell.

Да, видел неоднократные подобного рода утверждения относительно Хаскеля... Тогда вопрос: есть ли при этом возможность ограничить набор языковых конструкций? Чтобы потенциальный разработчик, вместо формирования требований к DSL (возникни таковая надобность), не "сорвался" на прямое подключение и использование произвольных библиотечных модулей?

L>Это оффтопик, конечно, но тема, наверное интересная. Я тоже считаю макросы крайней мерой.

Конечно, тема интересная и будоражит умы, т.к. приличный пласт ошибок в проектах — результат соседства высокоуровневого и низкоуровневого кода. Т.е. возможность подобного соседства провоцирует тяп-ляпость сама по себе, а рассуждения о "культуре программирования" — это ведь не более, чем вербальная мантра, в которую реальные люди верят (или хотят верить) с весьма различным уровнем серьёзности.

Называя вещи своими именами, речь идет о разделении труда м/у специалистами разного класса, отсюда и требования к ограничению возможностей, дабы "не давать гранаты в руки обезъян". При чём, "обезъяной" вполне может быть один и тот же человек, т.к. образ мыслей и некий общий "внутренний настрой" может быть сильно различаться, при решении задач различного уровня. Лично я был бы не против ограничивать рамками конкретно решаемой задачи и себя, по крайней мере, в случае экономии на юнит-тестах буду спать спокойнее.


L>Вот тут момент, о котором постоянно говорит thesz. Средства разработки как поддержка DSL против языковой поддержки.

Оно к этому и идёт, дай им по-акуммулировать ресурсы и опыт.
Тут ведь идёт естественное движение от применения наработок по поддержке конкретного языка в сторону поддержки произвольного языка, через некий способ описания того произвольного языка, достаточного не только для компиляции, но и для "разумного" поведения инструментов, уровня Решарпера. Знаешь ли ты или thesz обо всех ньюансах такой поддержки? Я вот уже лет 10 на jIdea смотрю, и на решарпер лет 5 скоро, количество "тонких моментов" просто поражает (и это для "фискированных" и весьма однозначных языков, а не для произвольных ДСЛ), и постоянно растёт. Ребята роют область, которая ранее толком не была пахана.

Здравствуйте, thesz, Вы писали:

T>Этот спор тебе интересен. Ты его продолжаешь.

Похоже, это глюкнул "rsdn@home", или я не то что-то нажал в нём.

Cтранно, вроде отвечал на это сообщение сразу же, "видимо что-то случилось"

Re[16]: Каким отладчиком пользовались разработчики Kx System

Автор: vdimas
Дата: 17.03.09

Здравствуйте, thesz, Вы писали:

T>Мне интересен период, когда они писали самую первую версию kdb.

В недавнем интервью Arthur Whitney признался, что необходимости в отладчике он никогда и не видел:

BC In terms of debugging your code, obviously the power
of a terse language such as K or Q is that, presumably,
it’s easier to find bugs by inspection. How do you debug
them?
AW In C I never learned to use the debugger so I used
to never make mistakes, but now I make mistakes and I
just put in a print statement. K is interpreted, so it’s a lot
easier. If I’m surprised at the value of some local at some
point, I can put in a print, and that’s really all I do.
...
AW It has been 20 years now that I’ve had Wall Street
customers—they’re doing 2 billion transactions a day and
they have trillion-row databases—and in those 20 years,
there was one time where we couldn’t reproduce the bug.
That was nasty. I knew the kinds of operations that they
were doing and I finally found it by just reading my code.
BC Was this a bug in K or Q, or was it in the C base
implementation?
AW It was a bug in C, in my implementation.

Здравствуйте, thesz, Вы писали:

T>А ещё у них отладчика нет до сих пор. То есть, его нет и не было никогда.

T>Как они с поддержкой программ для Wall Street справляются?..

Хм, всегда у них был 'отладчик' и сейчас есть. Пример (K3):

  {(x+y)*2}["a";"b"]
type error
{(x+y)*2}
   ^
>  x
"a"
>  y
"b"
>  :123 / вернуть 123 из текущего выражения
:123
246 / результат
  /

Каждый '>' называется suspension и они могут быть вложены.

Еще можно делать трассировку и брякпоинты:

  {\(x*100)+1}'(1 2 3 4 5)
101 / '\' выводит то что стоит перед ним
201
301
401
501
101 201 301 401 501 / результат 
  \b stop / переключаем в режим брякпоинтов
  {\(x*100)+1}'(1 2 3 4 5)
stop
{\(x*100)+1}
 ^
>  x
1
>  : / продолжение исполнения
:
stop
{\(x*100)+1}
 ^
>  x
2
>  /

Намного удобнее чем всякие маразматические ide.

Здравствуйте, pierre, Вы писали:

P>Хм, всегда у них был 'отладчик' и сейчас есть. Пример (K3):

Правда, это не касается того кода который пишет Arthur Whitney (если это имелось в виду).