CC>Ну, закинул бы все равно — просто для сравнения эффективности алгоритмов. Все равно для практического применения из их списка архиваторов пригодно процентов 20-30%. Остальные такие же спортивные эксперименты...

значит, даю справку по арзиваторам. на данный момент самый лучший практический архиватор — 7zip 4.43, причём именно этой версии — Игорь в прошлом году заметно рванул вперёд и теперь существенно обходит uharc.

далее. написать алгоритм вроде lzma (из 7-zip) самому — это несколько лет работы. я этого делать и не собирался

однако тем не менее сделать архиватор, который будет жать лучше, чем 7-zip, труда не составляет. достаточно взять lzma (доступный в исходниках), прикрутить к нему ppmd для текстовых файлов, добавить несколько препроцессоров — и комплексный обед готов. в моей программе испольщзуется штук 8 алгоритмов сджатия, причём я сам написал только два из них, довольно мелких. поэтому нет ничего удивительного в том, что программа сжимает лучше и быстрее оригинала, на котором она базируется. специалисту для того, чтобы понять, как она будет сжимать, достаточно прочесть список использованных алгоритмов — ну знаете, как в этом анекдоте "- анекдот 885! — все смеются, один не смеётся"

над вопросами практического применения я сейсчас потихоньку и работаю. надёжность, фичи, расширяемость формата архива

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

VD>А я в функциональщики перевербовался.

Что ты наделал?! Знаешь? Ты убил МЕЧТУ! Нет в жизни больше достойной цели... Пойду повешусь.

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

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

BZ>можно считать, что я пошёл ещё дальше и весь прикладной код пишу на хаскеле, а низкоуровневый — на C++ и не требую ни от того, ни от другого языка неестественных для него трюков. что касается арзитектурного подхода, то я тоже когда-то отладивал C с помощью printf'ов. можно чему угодно обезьяну научить но всё же лучше потратить силы на то, чтобы научиться писать более сложные программы с современными языками, нежели учиться делать несложные вещи, которые становятся сложными из-за устаревшего инструментария

Чуть-чуть лишь поправлю. И я так делаю. Я backend пишу только на С++ и не плачу о том что меня никто не защищает от моих ошибок, а лишь считаю за должное знать то, как минимум чем пользуюсь. А frontend вообще пишу без ограничения в выборе а на всем что БОЛЕЕ ВСЕГО подходит для реализации данной части. И здесь никаких моральных заблуждений и ограничений в выборе исходя из допустимых критериев хоть скорости разработки, хоть переносимости, хоть эффективности. Все хорошо в меру и это единственное утверждение.

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

с этим вообще никто не спорит и считаю глупостью опровергать утверждение. Просто из-за собственных предпочтений те или иные люди и выбирает приоритетные области для себя. И на этом все. Все остальное действительно БРОВАДА, не меньше и не больше.

Я бы вообще в обсуждение не вступал бы, если бы не стали ошибочно определять слово "ЗАМЕНА" в контексте "ДОПОЛНЕНИЕ".

А то начали с того, что С++ вообще ущербен и дошли до того что комитет калдет куда то не туда, где ожидалось. Это все бред ..... Все идет по заранее намеченному плану и не пытайтесь опровергнуть то что совершенно очевидно. Чем на более высоком уровне развития мы находимся, тем более разнообразный инструмент мы используем. Не знание инструмента не освобождает от отвественности за его использование. И все. Остановились на этом.


BZ>вы в 80-е программировали? да ещё и отслеживали все события в мире компилтяоров?? я-то просто недавно надыбал dr dobbs за эти годы и с удовольствием отследил борьбу и языков, и компиляторов. кол-во компиляторов C, паскаля и модулы было тогда практически одинаковым — 5 модул, шутк 6-7 Си. ну и ещё интерсено вспомнить, что С++ пошёл только потому, что разработчики были уверены, что на нём можно будет писать программы не медленней, чем на C

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

BZ>давайте это по-другому выразим. спец C++ , по-вашему — это человек, который в несколько раз дольше учился, в несколько раз больше работает, и в конечном счёте получает ровно то же, что и спец в более современно языке? "товарищ сержант, ну можно я веником подмету?"

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

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

BZ>знаете, что меня к хаскелу привело?

Я знаю.

BZ>высокоуровневого ассеблера? да. но для написания эффективных программ шаблоны особо и не нужны, а для написания прикоадных программ лучше испольщзовать более высокоуровневые средства. у макросов, даже в таком виде, свои недостатки — сообщения об ошибках, отсутствие run-time поддержки, время компиляции

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

BZ>совместимость с BCPL — это ограничитель развития самого C++. ну ни к чему в один язык тащить все aborb? которые когда-либо были изобретены. а когда тащат и начинают всё вместек совмещать, "эмулировать" — тогда и выходит коктейль из switch'a с лямбдой

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

BZ>РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите )

Вот за это я вам ставлю +500, за то что вы абсолютно правы и -500 за то, что вы сделали такой вывод из моего тезиса.
Перевожу для более жесткого head-safe mode.

BulatZiganshin notes:

РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите

Alexmoon notes:

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

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

1. Чем больший набор инструментов вы не используете а можете использовать, тем больший уровень вашего развития, но. Это не значит что основопалагающие понятия в ущерб эффективности вы не должны реализовывать тем, что на чей то взгляд морально устарело. Актуально все и всегда и из пушки в воробьям — касется как и прикладухи с огромным количеством сложных понятий, реализованной на С++, так и обратного направления. Использования С# в механизмах, когда необходимо эффективное манипулирование ресурсами, а не лишь их наличие.

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

BZ>ха! вот тут-то я вас и подловлю. прежде всего — вы представляете, какого уровня знаний требует рекурсвиное порграммирование на фортране IV? для рекурсивного вызова нужно завести по массиву на каждую локальную переменную, и хранить номер текущего используемого индекса в этом массиве. затем нужно обеспечить переход к нужной части порцедуры при вовзрате. но это ещё фигня — предствьте себе взаиморекурсивные вызовы нескольких порцедур!!! нынешние пограммисты и не подозревают, как много им сил сэкономили компиляторы

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

BZ>а теперь скажите, что легче — написать рекурсивную программу на фортране, или многопоточную, с автоматичсекой синхронизацией и разделением ресурсов — на хаскеле? и стоит ли хаскелловскому порграммисту указывать умение писать такие порграммы как отдельный скилл?

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

Вообще концептуальная ошибка сравнивать не сравнимое. Сравнивать можно только спецификации C# от разных производителей. Все остальное, читсый фарс. И если моего уровня развития достаточно, чтобы реализовать архиватор на С++ не с меньшей эффективностью и не менее защищенный во внешней среде — это говорит совершенно не о том, что языки равнозначны, а лишь о том, что алгоритмами написания этих вещей мы владеем одинаково, но на ++ я могу писать не менее производительно чем вы на Хаскеле и НЕ БОЛЕЕ ТОГО. И слава богу, что до сих пор актуально то, что было спроектировано N корличество лет назад и все фарсы поводу выше сказанного будут справедливы лишь тогда, когда что либо превзойдет что либо с той области где он изначально асс. И без привязок к определениям, а то сейчас опять пробежимся по цепи в очередной раз.

BZ>у меня было аналогично. когда я решил присобачить к своему арзиватору read-ahead, опережающее чтение файлов в отдельном от упаковки треде, я потратил неделю. на то, чтобы во всём этом разобраться, и чтобы осознать, КАК это просто будет сделать. у меня просто мозги этого не совпринимали, как и ваши наверно сейчас разобравшись, я сделал за день, там строк 40 кода всего понадобилось. а вот ни в одлном из других арзиваторов этого до сих пор нет. почему? наверно, потому, что они все на C++ написаны

Совершенно не потому. Если бы уровень владения алгоритмами архивации был базовым, то они были бы написаны на всем.

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

respect.

BZ>а мне кажется — можно multi-threading, GC, лямбды и прочие вещи, которые в других языках есть изначально, и умение пользоваться эмуляцией которых в C++ рассматривается как необходимое условие для устройства на работу

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

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

VD>Это понятно. Ты ведь не видел того как может выглядеть метапрограммирование будь оно органично встроено в язык. Потому и сомневашся. А вот IT видел. Как сейчас помню восторженный его восклик в аске — "Оифигеть! Я добавил поле типа Location и забыл сделать его изменяемым, но компилятор мне сказал об этом! И это делает простой макрос!". Так что вы в разных условиях. Он видел и то, и то, а ты только шаблоны С++.

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

Здравствуйте, VladD2, Вы писали:
E>>Сложность AI не означает интересности игры. Во многих 3D-шутерах сложную логику поведения врагов просто никто не оценит. Q3 изначально был нацелен на multiplayer, боты там, по-моему, вообще больше для тестов и начальной тренировки новичков. Ну если ты все же играешь в Q3 один, какого усложненное поведение ты хотел бы у них увидеть?

VD>Поведения неотличимого от человека. Боты в найтмаре очень похожи на человека с отличной реакций, но совсем тупого. А хочется, чтобы они делали подляны... прятались и собирали предметы когда у них мало здоровя/брони, наоборот пресинговали когда захватят ресурсв. И чтобы они мазали не рандомом, а в зваисимости от сложности обстановки. Ну, блин, противно видеть как бот попадает в тебя совершая кульбит в другом конце уровня! И наоборот, мажет в упор.

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

Женя,

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

И да, и нет. У меня есть два аргумента за:

1. Человек ушёл с одного проекта на Java, который он писал где-то года 2. Парень, который пришёл на замену, провёл 10 месяцев, прежде чем написал первую строчку своего кода!!! Меня просто ужас охватывал, когда он мне показывал список классов — он просто нажимает скроллинг и держал. А классы бежали и бежали. От имён уже начинало рябить в глазах, и наконец они сливались в одно непрерывное полотно, и лишь отпечатывался префикс C* или I*... По сравнению со сроком изучения системы, изучение языка это просто "о малое".

2. Потом люди, которых я знаю по жизни и в сети, с радостью бы работали на Хаскеле, дай им такую возможность. Да блин, я хоть сейчас, и даже на меньшие деньги. То есть я думаю, такие люди есть везде. Но! Найти действительно шарящего парня, которому не страшно доверить самые ответственные участки — это проблема. А как только мы его нашли, то изучить для него хоть Хаскель, хоть J, хоть N — не проблема.

Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%

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

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

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

То что вас ограничивает с использованием каких либо средств, не является признаком того, что это логично, а лишь признаком того, что по каким либо причинам вас это просто не устраивает. (А тут хоть что угодно определяйте. Не гибкость, не желание и т.д. и т.п.) Но это уже ваши проблемы а не комитета. Если бы это были проблемы комитета, то на языке уже никто не писал. И по моему это обсуждение уже вышло за рамки ++.

VD>В С# нет встроенного метапрограммирования. По этому и обсуждать не чего. А вот в Nemerle есть. И метапрограммирование на С++ на его фоне выглядит полнейшим извращением и убожеством.
Все верно, но это не значит что нет таких вещей, которые тоже могут являться не естественными в обратном направлении.

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

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

J>В Математике удобнее было :)

Смотри:

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

a b c d x

J>или так:
J>a @ b @ c @ d @ x

a $ b $ c $ d $ x

J>или так:
J>x // d // c // b // a

(//) = flip ($)

x // d // c // b // a

J>или так:
J>c @ d[x] // b // a

(c $ d x) // b // a

J>ну и т.д. (пробелы необязательны)

Аналогично

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

b `f` c

:-)

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

J>>или так:
J>>x // d // c // b // a

L>

L>(//) = flip ($)

L>x // d // c // b // a
L>

супер!

Я просто смотрел на страничку по ссылке про евро, там было нечто вроде (euro=|>)

d x |> c |> b |> a

Что, очевидно, хуже того, что выше


Тогда не очень понятно, зачем вводить евро, если есть флип бакса

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

Здравствуйте, Last Cjow Rhrr

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

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

LCR>Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%

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

Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает

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

VD>Здравствуйте, dr.Chaos, Вы писали:

DC>>Вот только в чем? В красоте или в эффективности выполнения? BulatZiganshin утверждает что на хаскеле будет медленнее, хотя и более кратко и красиво.

VD>Хаскель медленный язык. Медленный в силу своей специфики.
VD>Для эффективности на уровне маш.команд конечно нужно понижать уровень, а не повышать. Только уверен, что ваши проблемы эффективности лежат не на уровне сочетания процессорных инструкций, а на уровне алгоритмов. Одно только автоматическое управление памятью упрощает применение многих алгоритмов и делает возможным то на что у вас не поднималась рука ранее. А уж в купе с другими возможностями, и говорить не о чем.



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

Автор: Cyberax
Дата: 06.02.07

.


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

VD>Они позволяют сделать возможным мечты.

Ех Влад если бы все было так просто с моими мечтами .

VD>Ты можешь относительно просто превраить интерпретакцию в компиляцию. Макарнонный код в краткий DSL. Сгенерировать код так как тебе надо, а не так как выходит.

Я не намерен дальше продолжать этот спор. В итоге хочу сказать, что не смотря на все преимущества (более мощную поддержку метапрограммирования) С++ все равно остается неплохим инструментом и не фиг его хаять.

"Где та молодая шпана, что сотрет нас с лица земли" © Чайф

Вперед .

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

VD>Прблема в том, что у С++ очень куцие концепции. И рассматривая в них казалось бы простые и логичные решения оправдываются весьма уродливые решения.
Какова постановка вопроса, такова постановка ответа. Получаете ровно то, что просите.
У С++ не настолько куцые концепции, насколько куцые представления у вас о них, либо это просто упрежденное мнение и оно не может учитываться в претендентах на действительность. Если рассматриваются казалось бы простые и логичные определения, то они не оправдывают уродливые решения. Я уже сказал почему. И как бы вам не хотелось подтверждения именно ваших мыслей — это не будет, пока вы не перестанете навязываться. По частоте высказываний вы скоро потеряете связь и продолжите обсуждать сами с собой то, что давно уже будет оставлено другими.

VD>Это не так. В хорошем языке на котором можно описывать лызные гонки, например, есть понятие "снег". И без него дейсвтительно глупо говорить о лыжных гонках. Представь всебе:
VD>

Бегун на плоских палках привязанных к ногам вырывается вперед...

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

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

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

VD>Скорее с неимоверной убогостью. Но ты не поймешь этого пока будешь знать один С++, так как тут работает парадок Блаба

Автор: VladD2
Дата: 23.11.06

.

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

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

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

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

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

L>>x // d // c // b // a
J>Я просто смотрел на страничку по ссылке про евро, там было нечто вроде (euro=|>)

J>d x |> c |> b |> a

J>Что, очевидно, хуже того, что выше


J>Тогда не очень понятно, зачем вводить евро, если есть флип бакса

это одно и то же

a$b = a b
a//b = b a

и вышенаписанное можно точно так же записать как

x |> d |> c |> b |> a

что я собственно в своём примере и делал: bad_crcs .$ ... .$ ...

LCR>2. Потом люди, которых я знаю по жизни и в сети, с радостью бы работали на Хаскеле, дай им такую возможность. Да блин, я хоть сейчас, и даже на меньшие деньги. То есть я думаю, такие люди есть везде. Но! Найти действительно шарящего парня, которому не страшно доверить самые ответственные участки — это проблема. А как только мы его нашли, то изучить для него хоть Хаскель, хоть J, хоть N — не проблема.

LCR>Так что с позиции руководителя — 100% согласен, но с позиции практикующего программиста — только 20%

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

VD>>Скорее с неимоверной убогостью. Но ты не поймешь этого пока будешь знать один С++, так как тут работает парадок Блаба

Автор: VladD2
Дата: 23.11.06

.

A>Это я могу воспринять только как наезд. Где было определение того, что я знаю только С++ или даже еще больше ограничиваюсь только его использованием, и даже если вы соблоговолите это признать, то это совершенно не обозначает что я полностью поддерживаю ваше мнение.

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

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

J>Я просто смотрел на страничку по ссылке про евро, там было нечто вроде (euro=|>)

J>d x |> c |> b |> a

J>Что, очевидно, хуже того, что выше

Для меня неочевидно :-( Имхо, одно и то же.

J>Тогда не очень понятно, зачем вводить евро, если есть флип бакса :)

Да это просто разные названия одного и того же, и определены также. А назвать его евро, а не (//) — это стилистический приём — мол, делает то же, что и бакс только наоборот :-)

А так — это всё простые лямбды:

flip = \f -> \x -> \y -> f y x
($) = \f -> \x -> f x
(//) = flip ($)
     = (\f -> \x -> \y -> f y x) (\f -> \x -> f x)
     = \x -> \y -> (\f -> \x -> f x) y x
     = \x -> \y -> y x

Кстати, вот такая запись (ниже) в Хаскеле всего лишь сахар для лямбд.

flip f x y = f y x
f $ x = f x
x // f = f x

Обрати внимание на определение ($) — это простое применение функции. Смысл его в том, что этот оператор имеет самый маленький возможный приоритет (в Хаскель можно определять не только операторы, но и приоритеты для них). Поэтому его используют для сокращения количества скобок, которое в чистых ФЯ стремится к бесконечности :)

Вместо a (b (c (d (e f)))) пишут a $ b $ c $ d $ e f.

E>Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает

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

  -- Внести в опции вычисленные выше поля
  return$ Just$ Command {
      cmd_command_text         = unwords ("arc":args)
    , cmd_additional_args      = unwords additional_args
    , cmd_arclist              = error "Using uninitialized cmd_arclist"
    , cmd_arcname              = error "Using uninitialized cmd_arcname"
    , cmd_arc_filter           = const True
....

это у меня структура, содержащая все опции, так инициализируется. если где-то что-то забуду, run-time сразу выкинет мне сообщение типа "Using uninitialized cmd_arclist". это одно из преимуществ lazy evaluation

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

E>Так что я сейчас более склонен поменять C++ не на сложный Haskell, а на что-нибудь гораздо более простое. Вроде пятого Турбо Паскаля или Oberon-а Бертран Мейер, редиска, Eiffel за деньги продает


Кстати D если запретить шаблоны тоже хороший вариант как простой язык.

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

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

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

1. Знакомы и очень даже приемлемы. Скажу вам больше и я не собираюсь себя ограничивать даже ими. Одно из качеств любого из нас — это способность быстро подстраиваться под изменение столь быстро уходящей из под ног определенности.
2. Ненавижу просто когда говорят о куцости того, о чем просто не имеют никакого морального права заявлять, как определяющее мнение.
Фразы, а мне не нравится неуместны никогда и нигде. Все что можно сделать — это послать в комитет запрос о том, что все КУЦО и СРОЧНО исправить все в течении дву недель.
3. Коль мы говорим о чем либо, то давайте не лепить в сравнение что либо другое, кроме его клонов. Это касается всех языков без исключения.

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