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

VD>Из ГУИ януса я делал только дерево.
Это то, которое при сворачивании иногда неправильно перерисовывается оставляя хвост?

VD>>В C#, например, это будет выглядить как str.Substring(80).LastIndexOf(' '), не говоря уже о ФЯ.

ПК>Да уж... Rocket science... То, что ты изобразил на C#, на C++ выглядит, мягко говоря, не сложнее: str.rfind(' ', 80)

так это готовые, особенно твоё. дело-то именно в том, что хаскел предоставляет мощные средства КОМПОЗИЦИИ простых операций, в то время как для популярных языков существуют готовые бибилиотеки, где реализована куча алгоритмов. но выйди за пределы этих библиотек. наличие rfind ничем не поможет тебе в работе в lazy списками или деревьями. речь идёт именно о возможностях конструирования алгоритмов, предоставляемых языком

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

FR>Угу хорошая идея начать коммерческую разработку на языке который все еще в бете (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).
Если ты про nikov то это человек с очень редким талантом ломать вобще все. Онже запостил болие 1000 багов по решарперу, нашол кучу багов в C#...
А если он решит занятся D то рейтинг D по версии TIOBE взлетит выше крыши ибо багзила распухнит в разы.

FR>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.
Громно ржу.

FR>Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.

FR>1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет.
Что-то мне подсказывает что он работает лучше чем D на который повесили это ярлык.

FR>2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
А именно?
Есть проблемы (уверен временные) с перемножением кучи векторов на матрицу и тп. Из за того что .НЕТ не использует всякие там SSE.
Но это можно и интеропнуть ибо один вызов обрабатыват сразу кучу всего.

FR>3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
Бардак в игровой индустрии исключительно по тому что недальновидные боссы игродельчиских контор плохо относятся к работникам и по этому в игродельческой индустрии никто кроме фанатиков надолго не задерживается.

FR>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
Даже если DSL будет менятся раз в день что бред... достаточно будет один раз скомпилить сборку с макросами. Да один раз в день. А не каждый раз.

FR>5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой. Так что добавится работа по переписыванию с С++.
Угу... видил я эти поделки... в гробу и белых тапочках...

FR>6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.
Ну десктоп кроме винды рассматривать вобще не имеет смысла.
А на приставочном рынке Xbox360 не маленький сегмент.

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

BZ>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить
Когда можно будет посмотреть его результаты здесь: http://www.maximumcompression.com ?

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

VD>>>>>Второе покоеление уже писалось с использованием скриптов и С++.
DC>>>>Использование скриптов ИМХО еще позже появилось.
VD>>>Погляди Анрэл 1.
CC>>Quake 1 — QuakeC — компилируемый язык с VM.
VD>Кармак все еще и на С пишет. Это не показаоель. Показатель скорее то, что он просрал очередной виток технологий ФарКику.
Без комментариев!!!

DC>>>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
VD>>>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС
CC>>Ой только не надо про %НЮ. Потому как кроме как нецензурно о этой поделке отозваться не могу... Шшупали...
VD>А кто ты такой чтобы твое мнение по этому поводу было интересно?

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

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

Хм, а на этом "убийце скриптов" можно не перезапускать основную программу после изменения отдельного маленького компонента, а просто указать, что если "скриптик" Х изменился после последней его загрузки — загрузить его заново? И что для этого понадобится включить в эту программу — весь framework языка или маленькую dll-ку интерпретатора?

Только не надо говорить про кривость дизайна. Просто скажите — есть такая возможность или нет?

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

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

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

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

IT>Где логика я вас спрашиваю?

Логики здесь нет по нескольким совершенно прозрачным причинам.

С одной стороны адресная арифметика представляется нам как одно из фундаментальных средств, позволяющих использовать плюсы как язык для написания эффективных программ.

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

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

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

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

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

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

Используйте пожалуйста только термины "Я ТАК ДУМАЮ" а не "КОМИТЕТ ДАВНО ПОРА ОТДАТЬ ПОД СУД". Если вам скажу, что он все делает правильно исходя из определяющих условий, то наш спор не закончится до конца жизни и так и умрем не познав истинного удовольствия.

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

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

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

FR>>Угу хорошая идея начать коммерческую разработку на языке который все еще в бете (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).
WH>Если ты про nikov то это человек с очень редким талантом ломать вобще все. Онже запостил болие 1000 багов по решарперу, нашол кучу багов в C#...
WH>А если он решит занятся D то рейтинг D по версии TIOBE взлетит выше крыши ибо багзила распухнит в разы.


Надо его попросить.

FR>>Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.
WH>Громно ржу.

Зря.

FR>>Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.

FR>>1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет.
WH>Что-то мне подсказывает что он работает лучше чем D на который повесили это ярлык.

По устойчивости скорее близки. D тяжелей довести до ICE чем промышленные C++ компиляторы. Nemerle достаточно уcтойчив, но когда я с ним возился я и его (также как и D) доводил до ICE.
D на самом деле рановато присвоили 1.0, хотя с другой стороны сколько уже можно

FR>>2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
WH>А именно?
WH>Есть проблемы (уверен временные) с перемножением кучи векторов на матрицу и тп. Из за того что .НЕТ не использует всякие там SSE.
WH>Но это можно и интеропнуть ибо один вызов обрабатыват сразу кучу всего.

Проблемы может и временные, но работать то нужно здесь и сейчас.

FR>>3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
WH>Бардак в игровой индустрии исключительно по тому что недальновидные боссы игродельчиских контор плохо относятся к работникам и по этому в игродельческой индустрии никто кроме фанатиков надолго не задерживается.

Угу. И платят плохо.

FR>>4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
WH>Даже если DSL будет менятся раз в день что бред... достаточно будет один раз скомпилить сборку с макросами. Да один раз в день. А не каждый раз.

Все равно даже предкомпилированная будет заметно медленее скриптов.

FR>>5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой. Так что добавится работа по переписыванию с С++.
WH>Угу... видил я эти поделки... в гробу и белых тапочках...


Ну конечно мы пишем все сами и всегда наш код лучше чужого

FR>>6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.
WH>Ну десктоп кроме винды рассматривать вобще не имеет смысла.

Мак очень даже имеет смысл, хотя для больших игр как не знаю, для маленьких очень приличный процент.

WH>А на приставочном рынке Xbox360 не маленький сегмент.

Но не доминирующий.

E>Вы меня, конечно, извините, но в ваших словах мне так и слышится бравада: "Я освоил Хаскел! Я проперся от него! Я познал неведомое доселе!". И вспоминается мне один очень талантливый мужик, фанат Пролога, который несколько лет назад написал на Прологе офигенную систему. В которой никто не мог разобраться кроме него. Более того, когда однажды потребовалось выяснить причину ее странного поведения в какой-то ситуации, на вопрос "А как она вообще работает" он ответил -- "А хрен его знает". И закончилось все, как и можно было ожидать, тем, что после его ухода все творение было в довольно короткий срок переписано на C++ парой вчерашних студентов. И работало затем несколько лет без нареканий. Причем те студенты сейчас ведут еще более серьезные проекты и слова Хаскел, я думаю, даже не слышали.

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

в общем, на таких ошибках учатся. я с тех пор никогда больше не перегружал препроцессор. и мой 15-летний опыт коммерческой разработки, вот таких вот удачных и неудачных решений, отлажки, копирования кода, выписания шаблонных конструкций языка, позволил выработать определённые идеи о том, как нужно программировать и что для этого от ЯП нужно. языков я изучал множество — от APL до Явы, так что могу сравнивать

где-то в 60-70-х годах Дейкста написал книжку "взаимодействующие последовательные процессы", в которой ищлагался подход к написания параллельных и распределённых порграмм, не требующий явного описания семафоров, рандеву, мониторов и тому подобных низкоуцровневых вещей. в упрощённом виде его концепция используется в юниксовских пайпах. аналогичным образом устроена и моя программа — она состоит из 4 тредов, передающих информацию друг другу:

create_archive_structure | read_input_files | compress | write_to_archive

в свою очередь, compress разделяется ещё на несколько тредов, последовательно сжимающих данные. разве это не красиво? и позволило мне это реализовать именно наличие higher-order funcs. я думаю о своей программе не в плане отдельных значений которые нужно обработать, а в плане алгоритмов, из которых конструируются более сложные алгоритмы, при этом средства их конструирования также являются алгоритмами. вот это и есть метаподход к программированию на уровне хаскела

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

VD>>К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом.
CC>Сегодня уже гиг...

у меня знакомый весной купил машину с гигом. осенью его спрашивают, он говорит — у меня два гига. думаю, дело в том, что у него осталось смутное впечатление "у меня памяти ого-го сколько!", а по осени гиг за ого-го уже не канал

BZ>>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить
CC>Когда можно будет посмотреть его результаты здесь: http://www.maximumcompression.com ?

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

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

VD>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты?
И за одно тому кто владеет метаизвращениями на шаблонах в совершенстве.

VD>Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле.
А лучше самому попробовать.

Здравствуйте, BulatZiganshin

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

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

Таких историй большинство участников форума могут привести множество. Это нормальный процесс обучения.

BZ>где-то в 60-70-х годах Дейкста написал книжку "взаимодействующие последовательные процессы", в которой ищлагался подход к написания параллельных и распределённых порграмм, не требующий явного описания семафоров, рандеву, мониторов и тому подобных низкоуцровневых вещей. в упрощённом виде его концепция используется в юниксовских пайпах. аналогичным образом устроена и моя программа — она состоит из 4 тредов, передающих информацию друг другу:

BZ>create_archive_structure | read_input_files | compress | write_to_archive

BZ>в свою очередь, compress разделяется ещё на несколько тредов, последовательно сжимающих данные. разве это не красиво? и позволило мне это реализовать именно наличие higher-order funcs. я думаю о своей программе не в плане отдельных значений которые нужно обработать, а в плане алгоритмов, из которых конструируются более сложные алгоритмы, при этом средства их конструирования также являются алгоритмами. вот это и есть метаподход к программированию на уровне хаскела

И это все правильно и замечательно. Но, есть две вещи:

* вы заостряете внимание на Хаскел. Чтож он вам нравится, он соответствуют вашим представлениям о том, как нужно программировать. Хотя на мой взгляд, попытки сравнения Хаскеля с другими языками в данном треде выглядят как "Круче Хаскел только яйца!". Показалось мне так. Обычное, думаю, дело -- один написал с одними мыслями, другой прочитал с другими мыслями;

* мое личное отношение к сложным вещам. Я здесь уже говорил об этом, зарабатывал кучу минусов, наживал обвинения в посредственности, но остался при своем. У людей разные способности, в том числе и по освоению/использованию сложных инструментов. Мне доводилось наблюдать это во время учебы на примерах изучения высшей математики (мат.анализ, в котором мало кто в нашей группе разбирался и еще меньшее количество людей могло применять полученные знания для решения практических задач) и Пролога (большинство вообще, представте, вообще не понимало, в чем дело). При том, есть небольшое количество индивидумов которым природой и воспитанием дадено воспринимать вещи по другому. Кто-то воспринимает математику как само собой разумеющееся, кто-то так же относится к программированию. Вот у меня, например, с программированием вообще никогда не было проблем, в том числе и с Прологом. В отличии от математики. Так вот, в программировании разные способности индивидумов так же проявляются. Кто-то хорошо программирует на Java, но плохо на C++, кто-то замечательно знает Пролог и может на нем сделать все, что угодно, а другой вообще не может понять, по каким правилам Прологовские программы работают. А раз у людей разные способности и пристрастия, то при некоторых условиях с этим приходится считаться. Например, при передаче чужого кода на сопровождение. При попытке заменить выбывшего по объективным причинам или форс-мажорным обстоятельствам человека. И здесь оказывается, что заменить Java программиста возможно. C++ программиста, в принципе, возможно. Найти адекватную замену Хаскел или Пролог программисту... Это мало реально еще и потому, что, по моим наблюдениям, те же Пролог программисты имеют очень высокий уровень, это не обычные кодеры, которым по жизни хватает один раз выученного языка и одной освоенной IDE, и работы над одинаковыми проектами. А значит, Хаскел и Пролог программисты подходят к своей работе более творчески и применяют неординарные идеи. Соответственно, удачно заменить их сможет только такой же продвинутый и неординарный человек. Так что остается всего ничего -- найти его. Ну или переписать все так, чтобы в дальнейшем ротация коллектива не была проблеммой.

А посему получается, что если вы делаете что-нибудь самостоятельно или в очень небольшой группе таких же как вы людей, то что Хаскел, что Пролог, что еще что-нибудь экзотическое -- нет разницы. Совсем другое дело -- дальнейшая судьба написанного вами кода, который вы по каким-то причинам, больше не можете сопровождать. Вот как раз мейнстримовые языки (даже такие ругаемые и проигрывающие конкурентам, как C и C++) имет здесь гораздо больший запас прочности. И большая многословность и даже проигрыше в функциональности у разработанных на мейнстримовых языках систем компенсируются вот этим вот запасом прочности.

Чтобы проилюстрировать эту мысль я и привел пример из собственного опыта.

Вот как-то так. Надеюсь, что врага я себе не нажил.

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

BZ>>>чистый результат в моей работе — я написал архзиватор, по возможностям сравнимый я 7zip, но кодом в три раза меньше. подозреваю, что и время разработки было в три раза меньше, хотя это сложнее сравнить
CC>>Когда можно будет посмотреть его результаты здесь: http://www.maximumcompression.com ?
BZ>боюсь, что нескоро. не потому, что архиватор плохой
Ну, закинул бы все равно — просто для сравнения эффективности алгоритмов. Все равно для практического применения из их списка архиваторов пригодно процентов 20-30%. Остальные такие же спортивные эксперименты...

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

VD>>>К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом.
CC>>Сегодня уже гиг...

BZ>у меня знакомый весной купил машину с гигом. осенью его спрашивают, он говорит — у меня два гига. думаю, дело в том, что у него осталось смутное впечатление "у меня памяти ого-го сколько!", а по осени гиг за ого-го уже не канал

Для PC это конечно так, но для тех же игровых приставок время жизни которых 5 — 7 лет, все гораздо печальнее, есть сейчас 512 Mb (притом общей и для видео и для приложении) памяти (или в другом случае 256 под приложения и 256 под видео) и больше в ближайшие годы точно не будет.

VD>>ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты?
WH>И за одно тому кто владеет метаизвращениями на шаблонах в совершенстве.

VD>>Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле.
WH>А лучше самому попробовать.

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

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

BZ>знаете, у меня из богатого опыта отношение к метапрограммированию умеренное — с однйо стороны, конечно, хорошо, что язык можно расширять, не дожидаясь автором компиляторов и комитетчиков. с другой стороны, поддержка возможностей языка — это не только компиляция.
BZ>а сообщения об ошибках?
Как родные. Болие того многие конструкции языка сделаны именно макросами.
BZ>а отладка?
Также как и обычных программ. Поднимаешь компилятор под отладчиком, ставишь брейкпоинт в макросе и вперед.
BZ>а понимание того, как эта хреновина вообще работает?
В смысле? Скажем интеграция в студию показывает во что разворачивается макрос.
BZ>а взаимодейтсиве с системой типов?
Никаких проблем.
BZ>те же шаблоны в С++ появились как раз как замена макросов препроцессора — очень уж неудобно с ними было
Насчет препроцессора С согласен на 100%.
Но макросы немерла это совсем другая история.

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

LCR>Оператор "euro" из Understanding monads

В Математике удобнее было

там запись a[b[c[d[x]]]] (квадратные скобки там значат то же, что и круглые в С — вызов функции с аргументом в скобках)
можно было выразить так:
a[b[c[d @ x]]]
или так:
a @ b @ c @ d @ x
или так:
x // d // c // b // a
или так:
c @ d[x] // b // a
ну и т.д. (пробелы необязательны)

при этом для бинарных функций был еще такой сахар:
f[b,c]
можно писать как
b ~ f ~ c

You will always get what you always got
  If you always do  what you always did

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

E>Таких историй большинство участников форума могут привести множество. Это нормальный процесс обучения.

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

E>* вы заостряете внимание на Хаскел. Чтож он вам нравится, он соответствуют вашим представлениям о том, как нужно программировать. Хотя на мой взгляд, попытки сравнения Хаскеля с другими языками в данном треде выглядят как "Круче Хаскел только яйца!". Показалось мне так. Обычное, думаю, дело -- один написал с одними мыслями, другой прочитал с другими мыслями;

ну это, я думаю, нет смысла комментировать. хотя нет — я старался писать о преимуществах higher-order funcs, immutable objects, lazy evaluation, type inference и других средств хаскела. когда речь идёт о скорости — я писал о C++. когда о создании скриптов — это будет, скажем, руби. если я чего-то не знаю — я так об этом и говорю. по возможностям, необходжимым для промышленного программирования, хаскел — это лучший язык из тех, что я знаю. но не потому, что это хаскел. а потому, что в нём есть такие-то и такие-то возможности. вот на уровень возмоджностей языка мне и хотелось бы перевести эту дискуссию, а не устраивать здесь свяященные войны. я например вполне поддерживаю Влада в том, что Немерле быстрее хаскела, и в свою очередь языки с нативной компиляцией вероятно быстрее байткодовых


E>* мое личное отношение к сложным вещам. Я здесь уже говорил об этом, зарабатывал кучу минусов, наживал обвинения в посредственности, но остался при своем. У людей разные способности, в том числе и по освоению/использованию сложных инструментов. Мне доводилось наблюдать это во время учебы на примерах изучения высшей математики (мат.анализ, в котором мало кто в нашей группе разбирался и еще меньшее количество людей могло применять полученные знания для решения практических задач) и Пролога (большинство вообще, представте, вообще не понимало, в чем дело). При том, есть небольшое количество индивидумов которым природой и воспитанием дадено воспринимать вещи по другому. Кто-то воспринимает математику как само собой разумеющееся, кто-то так же относится к программированию. Вот у меня, например, с программированием вообще никогда не было проблем, в том числе и с Прологом. В отличии от математики. Так вот, в программировании разные способности индивидумов так же проявляются. Кто-то хорошо программирует на Java, но плохо на C++, кто-то замечательно знает Пролог и может на нем сделать все, что угодно, а другой вообще не может понять, по каким правилам Прологовские программы работают. А раз у людей разные способности и пристрастия, то при некоторых условиях с этим приходится считаться. Например, при передаче чужого кода на сопровождение. При попытке заменить выбывшего по объективным причинам или форс-мажорным обстоятельствам человека. И здесь оказывается, что заменить Java программиста возможно. C++ программиста, в принципе, возможно. Найти адекватную замену Хаскел или Пролог программисту... Это мало реально еще и потому, что, по моим наблюдениям, те же Пролог программисты имеют очень высокий уровень, это не обычные кодеры, которым по жизни хватает один раз выученного языка и одной освоенной IDE, и работы над одинаковыми проектами. А значит, Хаскел и Пролог программисты подходят к своей работе более творчески и применяют неординарные идеи. Соответственно, удачно заменить их сможет только такой же продвинутый и неординарный человек. Так что остается всего ничего -- найти его. Ну или переписать все так, чтобы в дальнейшем ротация коллектива не была проблеммой.

вопрос "если наш язык так крут, почему же его никто не использует?" в сообществах small языков возникают куда чаще, чем здесь есть даже статья об этом профессора Вадлера, одного из авторов Haskell и generic Java. если кратко, то дело (помимо объективных свойств самого языка) в *инфораструктуре*: библиотеках, средствах разработки, книгах, обучении и в конечном счёте подготовленных специалистах

спецы по Прологу или Немерлу — хорошие программисты не потому, что язык хорош. я вот скажем пишу на хаскеле, си и delphi, так что — мои способности каждый день меняются? дело в том, что для изучения скажем ООП+ООД уже есть хорошо накатанная колея, этому учат с института и человек думает о программе в этих терминах на автомате, воспринимает их как нечто соверщшенно ращзумеющееся — точно так же, как умение говорить. как мне Влад говорил, "на самом деле мир — императивен"

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


E>А посему получается, что если вы делаете что-нибудь самостоятельно или в очень небольшой группе таких же как вы людей, то что Хаскел, что Пролог, что еще что-нибудь экзотическое -- нет разницы. Совсем другое дело -- дальнейшая судьба написанного вами кода, который вы по каким-то причинам, больше не можете сопровождать. Вот как раз мейнстримовые языки (даже такие ругаемые и проигрывающие конкурентам, как C и C++) имет здесь гораздо больший запас прочности. И большая многословность и даже проигрыше в функциональности у разработанных на мейнстримовых языках систем компенсируются вот этим вот запасом прочности.

я вас и не призываю на него перейти. вы меня наверно с кем-то перепутали

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

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

A>Таким девелоперам опасно пользоваться и смарт-поинтерами, поскольку по всем известным причинам они не абсолютная панацея и человек не знающий их узких еще с большими проблемами столкнется при поиске причин падений.

Когда нечего сказать, начинают рассказывать про кривость рук