Здравствуйте, novitk, Вы писали:
N>Здравствуйте, Аноним, Вы писали:
А>>Если скрестить cherry-picking и коммутативность патчей, то открываются новые возможности. А>>Поэтому не надо тупо гуглить, почитайте туториал и оцените сами.
N>Меня не настолько интересует "алгебра пэтчей", чтобы читать по ней туториал. Я просто привел, что похожий функционал есть в Hg. Говорить об архиважности этой фичи для пользователя в виду практической невостребованости darcs по причине общей слабости функционала, надежности и скорости по сравнению с hg/git в последнее время смешно. Конь экологичней автомобиля и сложнее, вот только не нужен он больше никому.
Ещё раз призываю не настаивать на "общей слабости функционала" не прочитав хотя бы туториала. Это неконструктивно.
А>>По поводу того, что алгебру патчей можно реализовать на любом языке. С этим глупо спорить, однако небольшая ремарка. А>>Первая версия darcs была написана на c++. К сожалению, она не работала. Совсем. А>>Вторая версия была написана на хаскеле. И она заработала. Сразу. А>>("Заработала" -- имеется в виду алгебра патчей).
N>Это говорит лишь о неумение автора пользоваться C++, что для теор. физика вполне нормально.
Это ни о чём не говорит. Просто замчание в сторону.
P>Чуток не дотянуло до 4K вместе с тестами. Ну да, думаю при таком объеме можно и выловить все возможные проблемы с памятью.
P>Да и большими объемами данных xmonad точно не ворочает. Вот если бы он прогонял через себя хотя бы мегабайт в секунду, да еще и вынужден был держать в себе сложную модель, объемом мегов в 100-100 и нетривиально ее обновлять, то была бы другая история.
T>>Обсуждаемый вопрос: на Хаскеле обязательно получится плохо, много хуже, чем у других. P>>Э! Не передергивай! Обсуждается совсем не это. T>>Поэтому — переписывай свой ответ заново. T>>Дальше я читать не стал, и отвечать тоже. P>No comments. Остынь, что ли.
Будь добр, разверни. Я не понимаю, что ты хотел этим сказать. RD выдвинул совершенно бредовый тезис не потрудившись его обосновать. Ты его повторил.
Ты думаешь, что повторение глупости переведёт её в разряд истины? Это не совсем так.
Для этого надо обладать большими деньгами и, как следствие, трибуной побольше одной темы одного из форумов RSDN.
У Microsoft это получится повторять мантру и сделать её истиной. У SUN получится. У IBM. Масштабы, примерно, такие.
Поэтому, будь добр, перепиши свой ответ. Оба своих ответа.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>>>Но почему? Если ФП действительно повышает производительность и улучшает качество, почему это не выгодно? Даже парное кодирование и unit-тесты широко проникают в коммерческие проекты, поскольку они преследуют те же самые цели.
BZ>>правильный вопрос. а ООП коммерчески выгодно?
E>Выгодно. Достаточно просмотреть на Java Application Server-а и другой middleware софт, построенный на ОО языках.
да, но ведь ООП появилось в 67-м. почему же мы не можем увидеть его выгодность в 68-м, 69-м... а массово коммерческий софт на ООП языках стали писать в конце 80-х. что целых 20 лет мешало людям получать столь очевидную коммерческую выгоду?
BZ>>если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
E>То, что ООП вытеснило PL/1 уже очевидно лет двадцать как. ООП было настолько выгодно, что в 1979-м году некто Страуструп начал создание языка
а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит?
E>, который бы сочетал эффективность C и высокоуровневость Simula. Успешность его попытки ощущается до сих пор.
т.е. сама по себе сиула не была успешным проектом? а смолток, apple object pascal, eiffel? наконец, сам c++ — он с 79-го года стал активно использоваться для коммерческой разработки или может с 80-го?
E>Как в количестве OpenSource-проектов, так и в количестве коммерческих проектов, выполняемых в данный момент
в данный момент. но ведь успешность парадигмы не зависит от времени и языка, так почему бы нам не рассмотреть 80-й год или 68-й?
E>Так вот, если ты говоришь, что ФП коммерчески не выгодно, значит ты знаешь какие-то причины этого.
ты их и сам знаешь. просто думать отказываешься
E>Соображения на счет смены парадигмы они, как бы это сказать... Допустим, что смена парадигмы требует некоторых дополнительных вложений средств. Ну т.е. процедурный программист стоил $5K в месяц, для перевода его в разряд объектно-ориентированных программистов работодатель должен был дополнительно затратить, скажем, единоразово $20K (на обучение, приобритение новых инструментальных средств и пр). И в случае ООП эти дополнительные вложения окупались.
точно? почему же в 68-м году весь мир не перешёл на симулу? в 72-м — на смолток? в 85-м — на apple pascal? в 87-м — на eiffel? почему переход состоялся только в 89/90-м годах на самые слабые ооп языки — turbo pascal и с++? ну же, подумай!
E>PS. Утверждение о том, что самым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
"первым широко распространённым ооп языком". разницу видишь?
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит?
Ладно лисп как и смаллтолк сидит в свой нише и никому не мешает.
Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему
только сейчас есть робкие попытки проникновения ФП в мейнстрим?
Здравствуйте, FR, Вы писали:
FR>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
а мы уже доказали, что коммерческая успешность языка определяется именно его возрастом?
Здравствуйте, BulatZiganshin, Вы писали:
FR>>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
BZ>а мы уже доказали, что коммерческая успешность языка определяется именно его возрастом?
Здравствуйте, FR, Вы писали:
BZ>>а мы уже доказали, что коммерческая успешность языка определяется именно его возрастом?
FR>У тебя это плохо получается
научить тебя думать? ну, я по крайней мере попытался
RD>>Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича. T>Именно. Потому, что после "разворачивания", обычно, выясняется слабость аргументов и позиции вообще.
Ну если Ваш единственный аргумент — "разворачивай", то несомненно под его весом собеседник точно прогнется. Низкий поклон Вашему Гениальному Мозгу.
Кстати, перечитайте свой же пост в своем же блоге на тему культуры общения. Было бы неплохо если бы Вы сами придерживались этих правил. http://thesz.livejournal.com/657874.html
RD>>И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость. T>То, что ты называешь "розовыми очками", я называю прогрессом. T>Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов. T>См. на Doom3 инструменты 2005 года.
Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит.
T>Все аргументы против применения Хаскеля, что ты (да большинство) выкладывают на стол, все они, до единого, звучали в отношении C++ в 1995 году. T>Вот и вся причина моего упрямства. T>Просто у меня хорошая память.
Может память у Вас и хорошая. Но см. выше. Если аналогия с Хаскелем имеет место, то МОЖЕТ БЫТЬ (но не факт) в будущем (а не сразу сейчас) все будет заметно шоколаднее.
RD>>А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел. T>Ещё раз. T>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>Это твой тезис, будь добр, докажи его. T>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров. T>Расскажи мне ещё раз про розовые очки, пожалуйста.
Дорогой товарищ Великий Программист, я не намерен доказывать Вам тезисы, которые я не утверждал.
Я понимаю, что как Боец Ордена Св. Лябмды Вы в любом встречном видите грешника-иноверца и жаждете вспороть ему брюхо. Ничего, это бывало и раньше, и не только с Вами. Через сотню-другую лет обычно попускает даже крестоносцев.
И ваши голубые глаза если кто и трогал, то не я. Я в этом плане вообще гуманист.
Очень прискорбно, но мы с Вами не прийдем к единому мнению. Тут мне уже все ясно как Божий день. И причина этому проста. Вы просто не освоили тернарную логику. Ну, или чтобы Вам было понятнее, разницу между Maybe Bool и Bool.
Последняя попытка с моей стороны.
1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
1.2 Про CUFP я знаю давно. Но деталей там мало. И поэтому те примеры к тревожащему меня вопросу не клеются.
2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек.
2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет.
BZ>>а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит? FR>Ладно лисп как и смаллтолк сидит в свой нише и никому не мешает. FR>Но ML ветка функциональщины и современный мейнстримный ООП по сути ровесники, ты можешь объяснить почему FR>только сейчас есть робкие попытки проникновения ФП в мейнстрим?
Simula-67 и C++ (79-й) — 12 лет разницы. В мейнстрим C++ попал в районе 90-93. MFC, AFAIK. Ещё 12 лет.
ML и Haskell — ~10 лет разницы. 78+24 — 2002. Ну, 2000. Так в 2000 SPJ на работу в Майкрософт и взяли, AFAIR.
Но сейчас количество кода, с которым приходится общаться, значительно выше. Информационная связность повысилась в разы, если не на порядки.
Считается, что для решения задач обязательно, обязательно-обязательно надо использовать сторонние библиотеки. А они, вот засада, на обычных ЯП. А на ФП они странные какие-то, с монадами. А обычные вот они, с привычными классами.
Вот и проникает всё в индустрию медленно и с трудом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
RD>>>Если тебе говорят что-то, что не укладывается в твою картину мира, то ты орешь как недорезанный "разворачивай!" или твердишь что это не недостаток такой а крутейшая фича. T>>Именно. Потому, что после "разворачивания", обычно, выясняется слабость аргументов и позиции вообще. RD>Ну если Ваш единственный аргумент — "разворачивай", то несомненно под его весом собеседник точно прогнется. Низкий поклон Вашему Гениальному Мозгу.
"Разворачивай" — это не аргумент. Это указание на то, что для обсуждения мало информации. Нечего обсуждать-то, поэтому надо изложить тезисы более обстоятельно. Не видно, где ошибка и что можно комментировать.
RD>Кстати, перечитайте свой же пост в своем же блоге на тему культуры общения. Было бы неплохо если бы Вы сами придерживались этих правил. http://thesz.livejournal.com/657874.html
Это правила поведения в моём блоге внешних комментаторов.
Правила RSDN другие. Правил RSDN я, проде, придерживаюсь, нет?
RD>>>И в отличии от тебя, кричащего что "Хаскель крут ваще" я НЕ утверждаю что он не крут. Я просто показываю тебе на то, что пора снять розовые очки. Но видимо они вросли в кость. T>>То, что ты называешь "розовыми очками", я называю прогрессом. T>>Ты не поверишь, но не кто иной, как Джон Кармак по выпуску первого Quake говаривал, что C++ для игр не предназначен, у него нельзя контролировать расход памяти и задержки по времени из-за перегрузки и конструкторов-декструкторов. T>>См. на Doom3 инструменты 2005 года. RD>Вы наверное удивитесь, но мир не стоит на месте. И в то время C++ возможно (ВОЗМОЖНО) действительно не подходил для написания игр. Но если ДАЖЕ он не подходил ТОГДА, то сейчас, после долгой эволюции уже подходит.
За счёт чего это? Те же конструкторы, те же деструкторы, то же непредсказуемое время из-за перегрузки.
Что изменилось-то? Не развернёшь?
(кстати, JC до сих пор пишет в стиле "почти C++" — более строгие проверки, структуры вместо классов и, изредка, перегрузка, если безопасно)
T>>Все аргументы против применения Хаскеля, что ты (да большинство) выкладывают на стол, все они, до единого, звучали в отношении C++ в 1995 году. T>>Вот и вся причина моего упрямства. T>>Просто у меня хорошая память. RD>Может память у Вас и хорошая. Но см. выше. Если аналогия с Хаскелем имеет место, то МОЖЕТ БЫТЬ (но не факт) в будущем (а не сразу сейчас) все будет заметно шоколаднее.
Так готовится к будущему надо сейчас. А то оно наступит, а мы не готовы.
RD>>>А пример с xmonad был предложен как крупный софт, где все стабильно и нет утечек. Пример я не принимаю, т.к. софт небольшой. А меня бы заинтересовал именно БОЛЬШОЙ, перемалывающий кучу данных. И если это сможет так же стабильно работать как и xmonad — слава и хвала разработчикам. Но пока что такого примера не видел. T>>Ещё раз. T>>Ты на голубом глазу высказал утверждение, что если написать систему, которая будет перемалывать хотя бы мегабайт в секунду с нетривиальным обновлением модели, то на Хаскеле всё будет плохо. T>>ЭТО. НАДО. ДОКАЗЫВАТЬ. T>>Это твой тезис, будь добр, докажи его. T>>Мегабайты в секунду с нетривиальным обновлением см. на CUFP. Но ты там в упор не видишь положительных примеров. T>>Расскажи мне ещё раз про розовые очки, пожалуйста. RD>Дорогой товарищ Великий Программист, я не намерен доказывать Вам тезисы, которые я не утверждал.
Спасибо. Очень лестно. Нет, серьёзно, тронут до глубины души.
RD>Я понимаю, что как Боец Ордена Св. Лябмды Вы в любом встречном видите грешника-иноверца и жаждете вспороть ему брюхо. Ничего, это бывало и раньше, и не только с Вами. Через сотню-другую лет обычно попускает даже крестоносцев.
Что-то я поторопился с выражением признательности.
RD>И ваши голубые глаза если кто и трогал, то не я. Я в этом плане вообще гуманист.
Ура! "Я буду жить!"
RD>Очень прискорбно, но мы с Вами не прийдем к единому мнению. Тут мне уже все ясно как Божий день. И причина этому проста. Вы просто не освоили тернарную логику. Ну, или чтобы Вам было понятнее, разницу между Maybe Bool и Bool.
Что это означает?
RD>1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
Что же это было за утверждение тогда?
RD>1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
Прошу прощения, но эти проблемы проявляются в инструментах, специально заточенных под такие задачи. В программах на Эрланге, например. Про утечки памяти в C++ легенды ходят. В C# такие же проблемы.
Про Хаскель мы не уверены, что они не проявятся. А про другие инструменты знаем, что они могут проявится.
Другие инструменты — Эрланг, C++ и C#/Java, — можно использовать, а Хаскель нет.
Эта логика выше моего понимания. Наверное, в ней используют Maybe Bool вместо Bool.
RD>2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек.
Вы глупости на голубом глазу не утверждайте, и я тоже стану спокойным.
Утверждения типа "вы пишите такой код, что он ни с чем не интегрируется" и "вот с хаскелем системы на мегабайт пропускной способности не получится" как-то не добавляют конструктивности в беседу.
RD>2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет.
Для того, чтобы я Слушал, Понимал и Уважал собеседника, необходимо всего ничего: говорить Ясно, говорить Связно и говорить Уважительно. Либо отличиться на почве того, что мне интересно.
Я не могу сказать, что я не стремлюсь быть уважаемым. Но я стремлюсь быть уважаемым теми, кто сам достоин уважения.
Общая популярность меня мало заботит. Иначе я был бы lj user=drugoi, а не lj user=thesz.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Simula-67 и C++ (79-й) — 12 лет разницы. В мейнстрим C++ попал в районе 90-93. MFC, AFAIK. Ещё 12 лет.
T>ML и Haskell — ~10 лет разницы. 78+24 — 2002. Ну, 2000. Так в 2000 SPJ на работу в Майкрософт и взяли, AFAIR.
ML 73 Миранда 85 так что должно быть 97.
T>Но сейчас количество кода, с которым приходится общаться, значительно выше. Информационная связность повысилась в разы, если не на порядки.
Так это не помешало в конце 90-ых начале 2000 динамическим языкам.
T>Считается, что для решения задач обязательно, обязательно-обязательно надо использовать сторонние библиотеки. А они, вот засада, на обычных ЯП. А на ФП они странные какие-то, с монадами. А обычные вот они, с привычными классами.
T>Вот и проникает всё в индустрию медленно и с трудом.
Угу, слишком медленно. Конечно ООП заползло почти во все ниши это тоже надо учитывать, но если бы присутствовала серебрянопулесть это бы не помешало, значит она или отсутствует или слишком дорога.
Здравствуйте, BulatZiganshin, Вы писали:
E>>Выгодно. Достаточно просмотреть на Java Application Server-а и другой middleware софт, построенный на ОО языках.
BZ>да, но ведь ООП появилось в 67-м. почему же мы не можем увидеть его выгодность в 68-м, 69-м... а массово коммерческий софт на ООП языках стали писать в конце 80-х. что целых 20 лет мешало людям получать столь очевидную коммерческую выгоду?
Где доказательство, что мешало? Имхо, как раз люди видели существующую выгоду от использования ООП. Потому и создавали все новые и новые инструменты, которые находили свое применение в реальных проектах. И в конце-концов это вылилось в подавляющее преимущество сейчас. Т.ч. я вижу коммерческую выгоду от конкретной парадигмы. Ты же заявляешь, что от ФП нет коммерческой выгоды. И я пытаюсь выяснить у тебя почему.
BZ>>>если да, почему оно не вытеснило ПЛ/1 с того самого 67-го года, когда было изобретено?
E>>То, что ООП вытеснило PL/1 уже очевидно лет двадцать как. ООП было настолько выгодно, что в 1979-м году некто Страуструп начал создание языка
BZ>а лисп был создан 50 лет назад, где-то между фортраном и алголом. так значит преимущества ФП очевидны уже лет 50 как? или не значит?
Лисп я не стал упоминать, поскольку сталкивался со мнение, что Lisp нельзя считать именно ФП языком.
E>>, который бы сочетал эффективность C и высокоуровневость Simula. Успешность его попытки ощущается до сих пор.
BZ>т.е. сама по себе сиула не была успешным проектом? а смолток, apple object pascal, eiffel?
Я привел только один пример того, как ОО язык стал успешным. Это вовсе не было отрицанием наличия других примеров.
BZ>наконец, сам c++ — он с 79-го года стал активно использоваться для коммерческой разработки или может с 80-го?
Сам Страуструп, AFAIK, говорил, что C++ начал применяться где-то с 1983. А в 1986 вышел его первый коммерческий компилятор. За период с 1986 по 1990 появилось несколько различных C++ компиляторов на различных платформах. Что вполне можно считать доказательством успешности языка.
E>>Как в количестве OpenSource-проектов, так и в количестве коммерческих проектов, выполняемых в данный момент
BZ>в данный момент. но ведь успешность парадигмы не зависит от времени и языка, так почему бы нам не рассмотреть 80-й год или 68-й?
Ну давай рассмотрим 1973-й и ML. Когда великого и ужасного C++ не было в зародыше, а реализации Simula были настолько кривые, что люди подумывали о создании собственных ОО альтернатив. И когда Smalltalk даже не вышел из ясельного возраста (насколько я знаю, Smalltalk-72 никуда за пределы лаборатории не вышел).
И еще: откуда взялся тезис, что успешность парадигмы не зависит от времени и языка?
E>>Так вот, если ты говоришь, что ФП коммерчески не выгодно, значит ты знаешь какие-то причины этого.
BZ>ты их и сам знаешь. просто думать отказываешься
Я продолжаю настаивать, что обосновывать тезис должен человек, который его выдвинул.
BZ>почему переход состоялся только в 89/90-м годах на самые слабые ооп языки — turbo pascal и с++?
Очень мощно утверждать, что C++ "самый слабый ОО язык". Из более-менее мейнстримовых языков множественное наследование для классов поддерживается только в C++ и Eiffel.
E>>PS. Утверждение о том, что самым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
BZ>"первым широко распространённым ооп языком". разницу видишь?
Вижу. Поправка: утверждение о том, что первым широкораспространенным ОО языком был Turbo Pascal нуждается в доказательстве.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, pgregory, Вы писали:
P>Поинт не в том, что ООП это правильно. ООП это просто. Кнопка, говоришь? Хорошо, у нее будет метод «нажать». Почему у нее? А почему бы и нет? Да ни почему. Серьезно. Весь софт именно так пишется, и при этом еще и работает. Зачастую — очень хорошо.
Замечательное описание. Особенно выделенное.
Очень точно соотвествует распространённым представлениям об ООП как о какой-то совершенно аморфной и невнятной хрени.
T>>Simula-67 и C++ (79-й) — 12 лет разницы. В мейнстрим C++ попал в районе 90-93. MFC, AFAIK. Ещё 12 лет. T>>ML и Haskell — ~10 лет разницы. 78+24 — 2002. Ну, 2000. Так в 2000 SPJ на работу в Майкрософт и взяли, AFAIR. FR>ML 73 Миранда 85 так что должно быть 97.
С полиморфизмом — 1978. Алгоритм W.
T>>Но сейчас количество кода, с которым приходится общаться, значительно выше. Информационная связность повысилась в разы, если не на порядки. FR>Так это не помешало в конце 90-ых начале 2000 динамическим языкам.
Они использовались в качестве клея. Основная часть кода была написана на других ЯП.
Кстати, написание библиотек-биндингов провоцирует определённую организацию кода, что улучшает взаимодействие библиотек. Та самая компонентная модель.
T>>Считается, что для решения задач обязательно, обязательно-обязательно надо использовать сторонние библиотеки. А они, вот засада, на обычных ЯП. А на ФП они странные какие-то, с монадами. А обычные вот они, с привычными классами. T>>Вот и проникает всё в индустрию медленно и с трудом. FR>Угу, слишком медленно. Конечно ООП заползло почти во все ниши это тоже надо учитывать, но если бы присутствовала серебрянопулесть это бы не помешало, значит она или отсутствует или слишком дорога.
Здравствуйте, thesz, Вы писали:
T>Будь добр, разверни. Я не понимаю, что ты хотел этим сказать. RD выдвинул совершенно бредовый тезис не потрудившись его обосновать. Ты его повторил.
T>Ты думаешь, что повторение глупости переведёт её в разряд истины? Это не совсем так.
...
T>Поэтому, будь добр, перепиши свой ответ. Оба своих ответа.
Как бы тебя послать помягче?
3 (или уже больше?) человека говорят о том, что ты из поста RD высосал несусветно бредовую мысль, а потом приписал ее своим оппонентам. Ты там как, в порядке?
На всякий случай, процитирую RD:
1. Я НЕ утверждал что крупные программы на Хаскель не могут работать надежно и без проблем с потреблением памяти.
1.1 Я утверждал что я НЕ УВЕРЕН (и не имею достаточно веских с моей точки зрения оснований считать) что в случае разработки действительно большой софтины (порядка миллиона строк) да еще и большим коллективом, да еще и сегодня а не через десять лет... эти проблемы с памятью и общим пониманием всего этого хозяйства не станут проявляться.
1.2 Про CUFP я знаю давно. Но деталей там мало. И поэтому те примеры к тревожащему меня вопросу не клеются.
2 Я НЕ утвержал что Haskell это отстой. Это Вам, уважаемый, везде видятся Враги. Слава Богу, что не все Хаскелисты столь слепо яростны. Скажем, с Булатом общаться, как я вижу, можно и даже интересно. И Simon — очень конструктивный человек.
2.1 Обратно же, пока Вы не научитесь Слушать, Понимать и Уважать собеседника, то и уважать Вас никто не будет.
Герой, ты способен признать, что сказал глупость, а потом ее долго отстаивал?
Здравствуйте, thesz, Вы писали:
P>>Мне интересно, зачем же ты теряешь на меня время? Пойми, если я сказал глупость, другие это заметят и без твоей помощи.
T>Глупость должна быть разъяснена.
T>Я преследую две цели: чтобы никто не купился на глупость впредь, это первое. Тогда она будет меньше меня беспокоить. И вторая цель, не менее важная: активный оппонент, будучи переубежден, начинает работать на тебя.
T>Переубеждать у меня не очень получается, я срываюсь, но иногда мне это удаётся. Этим случаям я рад больше всего.
Рад, что за образом фанатика скрывается что-то человеческое :-). В принципе, я так и думал. Как я уже писал, буду очень рад быть переубежденным. Только вот чтобы переубедить меня, надо на порядок меньше срываться. И перед ответом пытаться найти в сообщениях мысль автора, а не свою мысль об авторе. И не скипать основные аргументы оппонента при ответе. И... ладно, и это навряд ли сбудется.
P>>Не напрягайся так. К чему дурацкие фразы типа T>>>Тут не сказали, падают ли другие системы. Пока я ответа не получил. P>>Он не очевиден? Тебе что, факс прислать, где написано «смирись, джедай, darcs хуже git»?
T>Будь добр, ответить на простой вопрос: почему система на Хаскеле, проакчивающая мегабайт в секунду, с нетривиаьлным обновлением базы в 10-100 МБайт, будет работать значительно хуже, чем на других языках?
«— Вы всегда отвечаете вопросом на вопрос? — Кто вам сказал?»
Собственно, есть простой тезис. Darcs серьезно уступает git, и его не спасает ни больший возраст, ни хаскель, ни алгебра патчей. Этот тезис неоднократно и подробно обосновывался. Для многих, этот тезис бросает серьезную тень на хаскель. И вовсе не потому, что, как ты пытаешься это выставить, оппоненты-идиоты отсюда сразу делают вывод о убогости хаскеля! А потому, что в ответ никто не говорит простое «на любом языке можно написать ерунду, вот и это тому пример». Все, напротив, (и ты в авангарде) стараются доказать, что darcs так же крут, как и хаскель, иначе и быть не может. Это, надеюсь, понятно?
Далее, ты наезжал на каждое подобное обоснование, из чего напрашивается вывод, что ты не согласен, и с твоей точки зрения, darcs лучше git. Ни единого вменяемого аргумента, при этом, приведено не было.
Здравствуйте, EvilChild, Вы в числе прочих меня критиковали.
Пока был в душе, появилась идея, как лучше объяснить свою позици. Итак:
Я считаю, что окружающую реальность довольно легко представить в виде объектов, имеющих состояние, и изменяющих его при выполнении некоторых действий. На лингвистическом уровне — вроде существительных, прилагательных и глаголов.
(Кстати, сама суть действий — изменение состояния. Если состояние постоянно, никаких действий в системе не происходит)
Важными частями, среди прочего, здесь являются
а) строгость действий
б) мутабельность объектов
Теперь: я считаю, что ООП, при всех перечисленных всеми подряд косяках, гораздо ближе к этой модели, чем pure lazy FP. И для pure lazy FP подобную объяснялку у меня выдумать не получается.
Поэтому я считаю, что ООП проще. В этом конкретном смысле простоты.
Если есть люди, заинтересованные в конструктивной дискуссии (может, даже thesz? :-), просьба, отвечая, сначала написать, понятна ли вам моя мысль. Если нет, то критику я игнорирую, так как проще объяснить свою позицию я навряд ли смогу, а терять время на базарные перебранки не хочу.
Да, подобные объяснялки для pure lazy FP приветствуются в любом случае. Пока лучшее, что я знаю — аналогия с Экселем.
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, eao197, Вы писали:
E>>Трудноиспользуемой ООП не была. ООП я начал использовать на втором курсе универа,
K>Думаю, что начни вы использовать ФП на втором курсе универа, трудноиспользуемым ФП вы также не назвали бы.
Я в этом сомневаюсь. Может быть, для людей с хорошим математическим и абстрактным мышлением так и было бы, но не для меня.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
