RD>>С другой стороны, не много пользовался потому что мелких недочетов полно. Элементарный пример: поддеркжа unicode в Haskell библиотеках вообще никакая.
BZ>поддержка юникода встроена в компилятор. проблемы возникают только там, где нужно делать интерфейс к С-библиотекам
Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char. Да, я в курсе про w_char, но это ситуацию не меняет. Особенно в свете того, что далеко не всегда 16бит на символ — стандартное представление unicode.
RD>>Ага, и взрывает потребление памяти там, где этого не ждешь. В проекте <1K lines может быть это и не проблема. А если <1M lines? :-) Не согласны? Приведите успешный контр-пример. L>xmonad. И на рабочей и на домашней машине живет без перезагрузки по много-много дней и немного месяцев. Потом выходит новое ядро, я перегружаю машину и оно опять живёт и не ликает.
xmonad.. слышал, слышал. Может даже поставлю, посмотрю.
Так значит, в нем порядка ~1M строк? Немало для оконного менеджера.
Проверим...
Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью.
Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char.
Рабинович напел? в FFI вообще разделены сишные и хаскеловские типы. 16-битные сишные символы — CWchar, они же TCHAR. работа с ними точно такая же, как с 8-битными символами:
T>>Ты требуешь отчёта об успехах, но при этом сразу говоришь, что успехи "в ваших узких областях" меня не интересуют. RD>Я не говорил что успехи в узких областях не интересут.
Это никак иначе понять нельзя.
"Про иммитацию железа я в курсе, жаль это очень узкая область."
Узкая, потому и жаль, что неинтересная.
T>>Я думаю, что даже http://cufp.galois.com/ тебя не удовлетворит. Там тоже какие-то узкие области. RD>Там есть несколько интересных историй успеха. На базе Erlang и Ocaml, например. Что дает основания считать что разработчики не пустозвонят. А мне вот было интересно, чем же еще занимаются хаскелисты, особенно местные. Но молчат. Видимо коммерческая тайна. Ладно, раз тайна, не будем развивать тему.
Именно. Будет что — обязательно расскажу.
T>>У меня могила код на Джаве написать. Сводящий воедино мой код на Джаве и старый код на Джаве. Обработку данных через утилитки на Хаскеле я написал уже давно. T>>Могила, конечно, да только не там, где ты предполагал. RD>"Могила код на Джаве написать" — понятно, очевидно. RD>"Обработка данных через утилитки на Хаскеле" — тоже понятно, в некоторых случаях это рационально. Особенно когда надо просто взять данные из файла, переработать и в другой файл скинуть. RD>"Сводящий воедино мой код на Джаве и старый код на Джаве." -... ндас, всегда думал что русский — мой родной язык. Но это предложение рвет мне мозг в фарш. Возможно, следует понимать так, что ежели Вы что-то напишете на Джава, то оно будет таким экзотичным, что его уже никак и ни с чем другим не соединить? Даже с другим софтом на Джава? А как же модульность?
Просто изучение платформы под названием Eclipse требует времени. Основная часть работы оного Eclipse выполняется не явно, путем передачи значений, а через побочные эффекты.
Вот выявить нужное количество этих эффектов и их проэксплуатировать и есть основная сложность.
Ничего приятного, откровенно говоря.
Код на императивных языках я пишу простой, понятный и элегантный. С хорошо изолированными эффектами, очень модульный.
Я, вообще, очень хороший программист, да. И как всякий хороший специалист, понявший дзен своей профессии (да и не только её), я очень скромен, про это я всегда стараюсь упомянуть.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
Докажиземлюешь.
Я серьёзно. Чего это ты выдвигаешь безосновательные тезисы? Получается игра в одни ворота: сторонники Хаскеля говорят, что он хорош и им надо это доказывать, а противники Хаскеля говорят, что он плох и это считается доказанным априори.
Поэтому сказал А, говори и Б. Сказал, что у Хаскеля будет "другая история", предоставь use case, где это так.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Я думаю, что даже http://cufp.galois.com/ тебя не удовлетворит. Там тоже какие-то узкие области. RD>Там есть несколько интересных историй успеха. На базе Erlang и Ocaml, например. Что дает основания считать что разработчики не пустозвонят. А мне вот было интересно, чем же еще занимаются хаскелисты, особенно местные. Но молчат. Видимо коммерческая тайна. Ладно, раз тайна, не будем развивать тему.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, thesz, Вы писали:
N>>>Где они? Был Darcs, но git и Mercurial, начавшие гораздо позже, просто убивают его функционалом и скоростью. T>>darcs2 и сейчас есть. "Просто убивают" это преувеличение, я думаю. C>Нет.
Убивают скоростью и стабильностью, но не функционалом, нет.
Здравствуйте, BulatZiganshin, Вы писали:
T>>>Ленивость стимулирует модульность (famous 'map f . map g === map (f . g)' example).
E>>А можно развернуть для чайников, о какой модульности здесь идет речь?
BZ>читай "why functional programming matters"
Я читал, чесно. Но, воспитываясь в свое время на Turbo Pascal (Modula-2), о модульности у меня сложилось несколько другое впечатление. И я вообще-то не понимаю, при чем здесь модульность.
E>>Прошу прощения за грубость, но это достойно войти в аналы вместе с вот этой
. Поскольку эта фраза об ненаписанных программах.
BZ>просто ты не понял, о чём речь.
Я-то понял. Но на моей памяти в первый раз в достоинство программы возвели "о которых легко рассуждать".
BZ>работая с отладчиком, ты имеешь дело с одним конкретным прогоном программы. более того, находишься в одной конкретной точке выполнения.
Временами именно в этом ценность и состоит. Когда ты можешь просмотреть содержимое памяти (скажем, буфер, возвращенный от девайса или подготовленный для отправки в девайс), модифицировать его и увидеть, как это сказалось в дальнейшем. Особенно, когда ты только-только знакомишься с какой-то новой предметной областью.
BZ>во-первых, потому, что выглядит глупо, найдя ошибку за одну минуту, затем целый день думать над её исправлением.
Почему это глупо? У меня бывали случаи, когда я находил ошибки и потом по нескольку дней думал, как их лучше исправить. Я, конечно, не самый умный человек и не самый лучший программист, но еще никогда не всречал программиста который бы вообще не ошибался. А раз ошибки все-таки случаются, то почему день на ее исправление -- это много? Особенно, если ошибка была допущена где-то на этапе постановки задачи или проектирования, тогда чем позже она обнаруживается, тем дороже обходится ее исправление.
E>>Вот Дональд Кнут, к примеру, считает отладчик очень важным инструментом программиста.
BZ>но он ведь не говорил, что программисты, снабжённые отладчиком, пишут столь же ясные программы?
Нет, но то, что Дональду Кнуту для работы нужен отладчик является показателем того, что для написания столь же качественных программ отладчик может пригодится
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, BulatZiganshin, Вы писали:
E>>Как человека, который попробовал freearc (0.40, которая была задекларирована как stable), меня совершенно не волнует размер исходников. А вот то, что freearc при какой-то комбинации ключей (по-моему, -mt2 на двухядерном Core2Duo) зависал намертво отжирая процессорное время... В общем, с точки зрения пользователя использования Haskell-я не убеждает.
BZ>не помню именно такой ошибки.
Конкретно вот эту не воспроизвел с ходу (уже не помню, что именно я архивировал), но вот сейчас попробовал заархивировать документацию по JDK:
D:\usr\share\doc\jdk>arc a -r -m9 -mt2 java_docs docs/*
ARC 0.40 creating archive: java_docs.arc
Compressing 9.482 files, 154.037.800 bytes. Processed 36.5%
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
BZ>вообще, есть три уровня отладки программы. первый — когда она у тебя уже компилируется, но не работает так, как ты ожидаешь. вот на этом уровне использование хаскела сильно сокращает работу — если ты смог откомпилировать код, то вероятность его безошибочности гораздо выше. второй — это ошибки работы в различных улсовиях, находимые различного рода тестированием. я этим не пользуюсь, хотя у хаскела здесь есть замечательный козырь пере другими языками — QuickCheck и его последователи (который позволяет написать что-то вроде
BZ>propertySort (\xs -> orderedBy (<) (sort xs))
BZ>и библиотека сама сгенерит энное кол-во списков и проверит, что заданное свойство действительно на всех них выполняется). и наконец третий уровень — это feedback от пользователей, в чём моя программа рахзумеется на порядки уступает популярным архиваторам
Это не правильный разговор. Проблема с программами у программистов состоит в чем? В том, что программы должны работать так, как того хочет пользователь. И если пользователь не видит нормальной работы, то ему абсолютно фиолетово все эти рассуждения программистов об уровнях и условиях.
Здесь постоянно говорят о том, как ФП вообще и Haskell в частности, сокращают время написания программ и увеличивают их качество. Но что можно увидеть на примере того же FreeArc? А нет качества. Заявлена фича в стабильной версии 0.40, но не работает. Ну и спрашивается -- если Haskell так помог сократить время на написание, то почему не было потрачено достаточно усилий на тестирование? Если уж возводят Haskell в ранг языка для написания программ без ошибок, то хочется видеть это на примерах -- берешь программу, используешь ее и с багами не сталкиваешься вообще. Вот это показатель. А так, на первом более-менее серьезном запуске -- облом. Не внушает, в общем
Булат, ничего личного. FreeArc действительно жмет очень сильно, но стабильности не хватает.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности.
Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка.
Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем.
Вторая версия была написана на хаскеле. И она заработала. Сразу.
("Заработала" -- имеется в виду алгебра патчей).
Здравствуйте, Rtveliashvili Denys, Вы писали:
RD>xmonad.. слышал, слышал. Может даже поставлю, посмотрю. RD>Так значит, в нем порядка ~1M строк? Немало для оконного менеджера. RD>Проверим...
Ты забыл прибавить ещё xmonad-contrib, который гораздо больше
RD>Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью. RD>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
Вижу, что если я дам тебе такой пример — ты придумаешь что нибудь ещё.
Ты уже всё решил — зачем мне с тобой спорить?
Здравствуйте, thesz, Вы писали: N>>Замечательно, но Хаскель то здесь причем? Ты считаешь, что "алгебры патчей" не реализуема в Питоне? T>Реализуема. T>Насколько мне известно, в её реализации используется ленивость. T>Те самые ленивые степенные ряды я реализовал-таки, с третьей попытки. T>Поэтому реализация алгебры патчей на Питоне будет... ну, интересной, так скажу.
Ленивость в python-е довольно хорош через итераторы реализуется.
До haskell-я конечно далеко, но таки многое можно.
Здравствуйте, BulatZiganshin, Вы писали: RD>>Наверное это повод считать что проблемы нет? А.. Я понял. Индульгенцию дает то, что в _стандратной_ библиотеке взаимодействия с C-библиотеками просто положили болт на Unicode и тупо счатают что Char это char. BZ>Рабинович напел? в FFI вообще разделены сишные и хаскеловские типы. 16-битные сишные символы — CWchar, они же TCHAR. работа с ними точно такая же, как с 8-битными символами:
А вот другой кусок кода:
#ifdef __GLASGOW_HASKELL__
getCurrentDirectory :: IO FilePath
getCurrentDirectory = do
#ifdef mingw32_HOST_OS
-- XXX: should use something from Win32
p <- mallocBytes long_path_size
go p long_path_size
where go p bytes = do
p' <- c_getcwd p (fromIntegral bytes)
if p' /= nullPtr
then do s <- peekCString p'
free p'
return s
else do errno <- getErrno
if errno == eRANGE
then do let bytes' = bytes * 2
p'' <- reallocBytes p bytes'
go p'' bytes'
else throwErrno "getCurrentDirectory"
#else
System.Posix.getWorkingDirectory
#endif
#ifdef mingw32_HOST_OS
foreign import ccall unsafe "getcwd"
c_getcwd :: Ptr CChar -> CSize -> IO (Ptr CChar)
#endif
Из System.Directory.
Именно из за него ghci (6.10.1) не работает если в имени текущей директории есть русские символы (Ticket #2963).
Не могу не встрять в этот эпичный флейм :-) Заранее извиняюсь за тон; читать следует, как будто после каждого предложения стоит смайлик, или типа того.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, novitk, Вы писали:
N>>Здравствуйте, thesz, Вы писали:
T>>>С функционалом?
N>>http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions N>>и да cherry-picking тоже.
А>Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности. А>Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
Уважаемые защитники ФП! Здоровы ли вы? Работали ли вы когда-нибудь с исходным кодом программ? Известно ли вам, что между патчами существуют и _более_ сложные зависимости, чем то, что два патча один за другим модифицируют одно и то же место кода? (И, более того, эти более сложные, неявные, зависимости — правило, а не исключение?)
До тех пор, пока эта мега-алгебра не сможет разрешать такие зависимости (а этого она не сможет никогда — к слову, она хоть компилируемость программы (хоть на хаскелле) гарантирует при существующем авто-черри-пике?), она будет практически бесполезна. Черри-пик всегда будет операцией, при выполнении которой надо 7 раз подумать. И никакая алгебра тут не спасет.
А>По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка. А>Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем. А>Вторая версия была написана на хаскеле. И она заработала. Сразу. А>("Заработала" -- имеется в виду алгебра патчей).
Алгебра патчей, как мы видим, это киллер фича, да? И то, что другие dvcs ее не имеют, ставит их на ступеньку ниже, так? Очевидно, что любой вменяемый разработчик должен выбрать darcs, получается. А что мы имеем на самом деле?
Проекты, использующие darcs
— darcs
Проекты, использующие git
— git
— Linux kernel
— X.org
— Android
— Qt
— GHC (раньше использовали darcs :-)
— Perl
— Ruby on Rails
— WINE
Не, конечно, darcs еще использует какая-нибудь мега-программа типа xmonad... А что-нибудь покрупнее? Проект AAA-класса? Ход за вами!
И не надо про то, что пока, мол, так и так, но люди поймут, и тогда... На git _сейчас_ активно переходят проекты с cvs, svn, perforce и даже darcs (GHC!). Потому, что он лучше. И всем плевать, что он написан на C, перле и баше. Все настолько просто.
Здравствуйте, Tonal-, Вы писали:
T>Именно из за него ghci (6.10.1) не работает если в имени текущей директории есть русские символы (Ticket #2963).
T>И таких мест там довольно много.
стандартная хаскеловская библиотека не поддерживает юникодные имена файлов вообще. лет 5-10 назад, когда она была написана, это видимо было малосущественно. но это всё же недотаток языка, а не библиотеки — у меня в программе например своя библиотека, которой чужды эти недостатки. у на уровне языка поддержка всё-таки полная вплоть до того, что ты можешь писать идентификаторы арабской вязью
Здравствуйте, pgregory, Вы писали:
P>Не, конечно, darcs еще использует какая-нибудь мега-программа типа xmonad... А что-нибудь покрупнее? Проект AAA-класса? Ход за вами!
freearc, конечно же
P>И не надо про то, что пока, мол, так и так, но люди поймут, и тогда... На git _сейчас_ активно переходят проекты с cvs, svn, perforce и даже darcs (GHC!). Потому, что он лучше. И всем плевать, что он написан на C, перле и баше. Все настолько просто.
и отсюда ты делаешь вывод, что с, перл и баш — это лучшие в мире ЯП, на которые всем немедленно нужно перейти?
(Раз часть поста про алгебру патчей вы не комментируете, следует считать, что вы согласны? Если нет — буду рад, если укажете, где же я не прав)
BZ>Здравствуйте, pgregory, Вы писали:
P>>Не, конечно, darcs еще использует какая-нибудь мега-программа типа xmonad... А что-нибудь покрупнее? Проект AAA-класса? Ход за вами!
BZ>freearc, конечно же
No comments :-)
P>>И не надо про то, что пока, мол, так и так, но люди поймут, и тогда... На git _сейчас_ активно переходят проекты с cvs, svn, perforce и даже darcs (GHC!). Потому, что он лучше. И всем плевать, что он написан на C, перле и баше. Все настолько просто.
BZ>и отсюда ты делаешь вывод, что с, перл и баш — это лучшие в мире ЯП, на которые всем немедленно нужно перейти?
Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана.
И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
Здравствуйте, pgregory, Вы писали:
P>Отсюда я делаю вывод, что хорошесть программы абсолютно ортогональна хорошести яп, на котором она написана.
Вывод не меньшей наивности, чем был предложен.
P>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего. Что мы очень явно видим на примере darcs vs. git. Хороший дизайн + плохой яп всегда победят плохой дизайн + хороший яп.
Т.е. хороший ЧПУ станок не даёт ничего (выделить ещё курсивом). Мастер с инструментами всегда сделает лучше, чем студент на таком станке.
Здравствуйте, pgregory, Вы писали:
P>И хотя хороший яп может помочь в написании хорошего софта (а может и помешать — сколько контрибьюторов имел бы git, будь он написан на хаскелле, а?), само по себе использование хорошего яп не дает ничего.
Ой ой ой, что я вижу!
А это как понимать-то?
И хотя на мотоцикле я доеду быстрее, чем дойду пешком, сам по себе мотоцикл не даёт ничего?
Так может помочь или не даёт ничего?
Кстати, доказывай "не даёт ничего". Интересно послушать объективные обоснования.
Мне тут второе я подсказывает, что ты, как и многие, оспариваешь панацейность, о которой никто и не говорил? Ну, мол, ФП не панацея и если бездарю его дать, то оно ему не поможет? Надеюсь, нет же? Надеюсь, в твоих изложениях заложена мысль.
в FFI вообще разделены сишные и хаскеловские типы. 16-битные сишные символы — CWchar, они же TCHAR. работа с ними точно такая же, как с 8-битными символами:
