Здравствуйте, minorlogic, Вы писали:
M>Давайте не на личности. ?
Ну, вы же первый начали...
Зы обвинение в запрыгивании внутрь for(), в приличном обществе бьют клавиатурой по лицу
Если, конечно, for() не безусловный...
M>Я уже писал, goto это НЕЯВНАЯ управляющая конструкция ,
Увы, я не читал книгу, где вы это писали. Страуструпа читал, Вирта читал, даже Кнута читал, а вас — нет. Не удосужитесь подкинуть цитатку?
M>чтобы понять чем она занимается надо отслеживать логику переходов.
...в данном куске кода логика лежит на поверхности.
Переход существует ВСЕГДА — безо всяких условий.
Думаю, этого трудно не заметить...
А на вопрос вы опять не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>Стрельба из рогатки, кстати, отнюдь не безобидное занятие и запрещается не безосновательно. DEA>...переход улицы, кстати, тоже. Но иногда надо.
На моих глазах школьный товарищ дорогу перебегал в неположенном месте. Жив остался, но получил пять переломов таза. Так что рекомендовать кому-нибудь переходить дорогу в неположенном месте я не могу.
E>>А если ты используешь goto по принципу "запретный плод сладок". DEA>Ну я вроде бы обосоновал почему я применяю goto в данном случае... DEA>Просто я не испытываю по этому поводу комплексов и применяю его там, где оно подходит
Может быть потому, что не нашел нормального способа от него избавиться?
DEA>А от вас, я тоже хотел бы услышать ответ на вопрос: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
? Здесь есть один тонкий момент. Разбираться в чужом коде не зная алгоритма и предлагать способы "выпрямления" этого кода не просто и может потребовать некоторого времени.
DEA>Кстати, вот еще один пример моего goto-любства: http://www.rsdn.ru/Forum/Message.aspx?mid=1470445
Здравствуйте, Cyberax, Вы писали:
C>reductor wrote:
>> C>Например, если нельзя допускать пауз GC и большого оверхеда >> C>конкурентного GC. Или если существуют гораздо более эффективные методы >> C>управления памятью для данной задачи (preallocated пулы, например). Или >> C>если требуется *детерминированое* уничтожение объекта. >> Вы на чей вопрос здесь отвечаете? >> Я спрашивал для каких задач. Конкретнее.
C>Игры, требовательные десктопные приложения, системный софт.
Ну если требовательные, тогда конечно С++ нельзя, он медленный — куча тормозит из-за фрагментации. Да и на просто аллокацию у него времени уходит раза в три больше, чем у окамла.
Давайте уже договоримся — нечего делать в прикладном софте ручному управлению памятью.
Это очень дорого. Во всех смыслах.
А что касательно системного софта —
Сколько раз увидишь человека, который пишет ядро на С++, столько раз и убей его
И что характерно, на том уровне уже неважно какие синтаксически навороченные аллокации в языке.
Важно другое. Вот например то, что в cyclone
>> Опять же, про паузы интересно.
C>RTFM: http://www.memorymanagement.org/
Ну вот только не нужно этой пошлости.
Конкретно скажите у какого типа GC какие паузы и тп. И что где дороже того, что в С++ получается.
Ну вот пусть в том же окамле. А то там Лерой как-то выкладывал калькуляцию по этим вещам, хочу сравнить вашу и его.
>> C>А в С++ нет проблем с алиасингом. Более того, он тоже успешно >> C>используется для некоторых трюков. >> Переведите
C>В С++ нет проблем с накладывающимися массивами, так как они с помощью C>адресной арифметики могут быть использованы для интересных C>inplace-преобразований.
Абсолютно неинтересной невозможности компактнуть хип правильно сказать.
"интересных преобразований"
>> C>Вот вам прямо с About Haskell >> Что вы хотели сказать цитированием мне этого sales talk десятилетней >> давности?
C>А что, вы один должны гнать sales-talk десятилетней давности про GC?
Чооо? эт где?
>> C>В С++ продумано взаимодействие аллокаторов, стандартных контейнеров, >> C>алгоритмов и т.п. Например, как мне поместить в контейнер OCaml'а >> C>объект, созданый в блоке shared memory? Причем указатели в этом объекте >> C>представлены в виде смещений относительно начала блока, а null pointer >> C>представлен в виде указателя со смещением -1. >> Вы будете продолжать фантазировать или хотя бы прочитаете мануал по >> окамлу?
C>КАК мне разместить, скажем, список OCaml'а в shared memory и передать на C>Хотя я знаю, что вы скажете — дадите мне ссылку на документацию по FFI и C>станете рассказывать, что shared memory устарел и никому не нужен.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>А от вас, я тоже хотел бы услышать ответ на вопрос: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Если я правильно понял, то вот так:
inline bool shift_mask( data::byte_type & mask, data::byte_type const * & ep, data const * en )
{
if( 0 == (mask >>= 1) ) {
if( --ep < en->data_ ) return false;
mask = 1 << (data::bits-1);
}
return true;
}
//rn = (an ** en) mod mn
umodexp(data* rn, data const* an, data const* en, data const* mn)
{
data *n1 = rn; n1->copy(an);
data *n2 = data::alloc(rn->capacity);//пусть этот меморилик вас не смущает
//код немного упрощен для наглядности
data::byte_type const* ep = en->data + en->size - 1;
data::byte_type mask = 1 << (data::bits-1);
while( 0 == (*ep & mask) )
mask >>= 1;//skip to first '1' bit
reduction_algo reduce(mn);
// Все равно один раз reduce(n2, n1) выполнять нужно, поэтому делаем это сразу. Не заходя в цикл.
reduce(n2, n1);
if( shift_mask( mask, ep, en ) )
// Т.к. маска не закончилась, то выполняем основной цикл.do {
umul(n1, n2, n2);
reduce(n2, n1);
if( *ep & mask ) {
umul(n1, n2, an);
reduce(n2, n1);
}
} while( shift_mask( mask, ep, en ) );
rn->copy(n2);
}
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
R>Ну если требовательные, тогда конечно С++ нельзя, он медленный — куча тормозит из-за фрагментации. Да и на просто аллокацию у него времени уходит раза в три больше, чем у окамла.
Моя долго плакаль...
Почему-то упускаются из виду две вещи. В C++ очень много объектов -- автоматические переменные. Размещаются в стеке и автоматически разрушаются. Никакой фрагментации. Никакого оверхеда.
В действительно тебовательных к скорости приложениях (real-time системах) вообще может не применяться выделение памяти во время работы -- вся память выделяется при старте и затем только используется.
R>Давайте уже договоримся — нечего делать в прикладном софте ручному управлению памятью.
Не договоримся.
R>Сколько раз увидишь человека, который пишет ядро на С++, столько раз и убей его R>Важно другое. Вот например то, что в cyclone
Сколько раз увидишь человека, который пишет ядро на cyclone -- сфотографируй его, возьми автограф и разошли фото всем друзям. С подписью: "вот тот, кто пишет ядро на cyclone"!
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Может быть потому, что не нашел нормального способа от него избавиться?
Для меня goto — точно такой же инструмент как и другие выражения языка. Со своими плюсами и минусами. О которых я очень неплохо осведомлен. Буде встретятся еще неизвестные мне — я об этом сразу же узнаю — тк код который пишу, я ВСЕГДА тестирую.
E>Разбираться в чужом коде не зная алгоритма
Ну, я же писал: "реализация бинарного алгоритма возведения в степень больших чисел".
Описание можно найти у Кнута, Седжвика, и еще куче книжек...
ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля любой алгоритм сортировки. Как ни странно, встречаются экземпляры, которые не могут. И их достаточно много.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, 0xDEADBEEF, Вы писали:
E>>Разбираться в чужом коде не зная алгоритма DEA>Ну, я же писал: "реализация бинарного алгоритма возведения в степень больших чисел".
Ну нет у меня под рукой ни Кнута, ни Седжвика, ни других книжек по алгоритмам сейчас DEA>Описание можно найти у Кнута, Седжвика, и еще куче книжек...
ЗЫ. Когда я учу студентов комментировать код, я говорю, что если они используют какой-то алгоритм, взятый откуда-то, то пусть указывают в комментариях точный источник: издание, главу и, желательно, страницу.
DEA>ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля любой алгоритм сортировки. Как ни странно, встречаются экземпляры, которые не могут. И их достаточно много.
А на какую позицию они претендуют?
Я бы, например, с ходу бы задумался, прежде чем вспомнить какую-нибудь сортировку. А потом бы еще покурил, прежде чем написал код. И все равно не был бы уверен в корректности его работы без тестов. Просто потому, что писать реализации алгоритмов сортировки мне приходилось только во время учебы.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Здравствуйте, minorlogic, Вы писали:
M>>Давайте не на личности. ? DEA>Ну, вы же первый начали... DEA>Зы обвинение в запрыгивании внутрь for(), в приличном обществе бьют клавиатурой по лицу DEA>Если, конечно, for() не безусловный...
Я тогда не понял , что это ваш код ...
M>>Я уже писал, goto это НЕЯВНАЯ управляющая конструкция , DEA>Увы, я не читал книгу, где вы это писали. Страуструпа читал, Вирта читал, даже Кнута читал, а вас — нет. Не удосужитесь подкинуть цитатку?
лень искать , гдет в этой ветке про return писал.
M>>чтобы понять чем она занимается надо отслеживать логику переходов. DEA>...в данном куске кода логика лежит на поверхности. DEA>Переход существует ВСЕГДА — безо всяких условий. DEA>Думаю, этого трудно не заметить...
это заметно , но надо опять вверх лезть и смотреть инициализацию переменных цикла
DEA>А на вопрос вы опять не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет".
Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее.
Здравствуйте, minorlogic, Вы писали:
DEA>>А на вопрос вы опять не ответили. А вопрос, напоминаю, был: "должен ли goto в данном куске кода быть изничтожен, если да, то какие преимущества сие действие принесет". M>Чуть выше уже привели пример кода рещшающий вопрос , и выглядит на порядок красивее.
Здравствуйте, eao197, Вы писали:
E>Не удержался...
Евгений, мне понятно Ваше раздражение. Когда что-то рекламируют как панацею, это всегда оказывается Гербалайф. Что поделаешь, как в любом приличном флейме, здесь было сказано много лишнего; не доросла, к сожалению, Философия до конструктивных обсуждений (да, поставьте мне за это 10 минусов) . Но тем не менее, ИМХО, ФП стоит на пороге (о чем говорит появление функциональных элементов в C#, Python и т.д.), и игнорировать его нельзя, ибо программисту надо идти в ногу со временем [пафос офф].
E>
E>Функциональное программирование прекрасно, оно — радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
E>Каким-то религиозным духом попахивает
Да, хороший программист должен быть поэтом и немножко фанатиком. Мне в этом плане нравится эпиграф из SICP (с вашего позволения, приведу целиком):
This book is dedicated, in respect and admiration, to the spirit that lives in the computer.
``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
А с другой стороны, это не религия, а осознанный выбор. Люди вроде Филипа Уодлера знают достаточно языков не понаслышке, чтобы адекватно оценивать их достоинства. E>В свое время и ООП пыталось пробивать себе дорогу.
Вот-вот, и пробивало не один десяток лет. И успело устареть к моменту пика своей популярности (немного сильное утверждение, но доля истины в нем есть).
E>Хочется добавить, что C, C++ и Java успешно работают во всех этих областях
Здесь отвечу сумбурно, т.к. нормально сформулировать не удается да и времени нет, а сказать давно хотелось.
Да, C и C++ успешно применяются в этих областях, но есть ряд но.
Все знают избитую мудрость о том, что преждевременная оптимизация — это корень зла. А что такое выбор С++, как не преждевременная оптимизация? Ручное управление памятью, обратная совместимость с C (кроссплатформенный ассемблер) — зачем это в экспертной системе, например? Далее, все алгоритмически нетривиальные задачи имеют дело с "кудрявыми" (hairy) структурами данных — деревьями и графами, так или иначе. Их грамотная реализация на C++ (вроде boost::graph) — удел немногих избранных, нетривиальной задачей является и проектирование интерфейса (тут на всю катушку включается горячо любимое Вами метапрограммирование, шаблоны выражений и прочая красота, за которую мы так любим С++), и сама реализация (как-никак, ручное управление памятью, мучительная борьба за thread-safety, которой нет в Стандарте, UB на каждом шагу, и т.д.). И при этом выразительности, сравнимой с Хаскелем, все равно не получить. Елки-палки, в ОКамле я могу дерево записать в виде константы, а в С++ — только с помощью злой механики вроде шаблонов выражений и умных указателей, при этом подумывая о порядке инициализации и точках следования. Тем более безумием, с моей точки зрения, заниматься изобретением новых структур данных и алгоритмов на С++. Т.к. сегодня придется отвлекаться на несущественные детали вроде управления памятью больше, чем следует.
Да, у меня немного опыта, чтобы что-то утверждать. Я, можно сказать, просто купился на "маркетинг" функциональных языков. Я просто посмотрел на задачи, которые команды из 2-5 человек решают на ежегодных соревнованиях ICFP Contest и в какие сроки (конечно, моделирование поведения колонии муравьев на поле из шестиугольных клеток имеет мало общего с промышленным программированием, нудным сопровождением, написанием кода в соответствии с стандартами и гайдлайнами, чтобы любой индус мог понять, продолжите сами..., но это же интересно, черт побери, впечатляет! Я тоже хочу быть способным написать компилятор языка, управляющего муравьем, за 2 часа, или ray-tracer за полдня, это вам не XML-сериализация SOAP-envelope'ов, фукакаягадость У меня есть амбиции, хочу решать интересные задачи (как у McSeem2 — поймите меня правильно, я себя ни в коем лучае с Максимом не сравниваю, не дорос еще.) "У меня тоже голос, я тоже хочу петь" ).
Я одно время был очень сильно увлечен возможностями и новыми течениями в С++ (ну Вы знаете, списки типов, CT вычисления и т.д), но потом оказывается, что в реальной работе я их не применяю. А когда применяю, проекту это вредит. Они для элиты, которая пишет библиотеки типа буста. И на что тратит время эта элита? Они знают Стандарт, все 700 страниц, наизусть, знают все глюки и несоответствия стандарту популярных компиляторов, и могут часами обсуждать, имеет ли некоторый фрагмент кода Undefined behaviour — стоит ли тратить на это драгоценное время? (последний абзац не стоит понимать буквально, я уважаю элиту С++-сообщества, честно ).
Я думаю, не стоит объяснять, в чем разница между:
— логическим выводом, встроенным в язык, и реализацией оного на С++
— параллельностью и распределенностью, встроенной в язык — "вот, посчитай мне вот это выражение, а на скольки процессорах и как будет проводиться синхронизация, мне неинтересно" — и того же на С++, с учетом всех граблей ручной синхронизации, видимости памяти, инверсии приоритетов, ... (заметим, здесь тоже нуже человек с умственными способностями академика, но все свои способности он убьет на борьбу с машиной, а не с задачей)
— настоящими ленивыми вычислениями и их имитацией на С++
— продолжите список, посолить по вкусу.
Далее, о сложности и читабельности. Читабельность кода, несомненно, важна, но если не доводить до паранойи. Спорить, что лучше, фигурная скобка или begin, могут, ИМХО, люди с ограниченным мировоззрением. Истина (для меня) состоит в том, что сложность программы должна отражать сложность решаемой задачи, по возможности не добавляя к ней сложности самого языка программирования. Надоедают рассусоливания о том, стоит ли заключать тело однострочного if'а в фигурные скобки или не стоит, не вредит ли это понятности кода (да что там понимать! да, я знаю о стоимости сопровождения кода, в конце концов, с этого я начинал — доделывал и багфиксил монстра с 5-летней историей). Возьмем научную работу с применением современного мат. аппарата, ну, вы знаете, начинается со слов "Очевидно, что" — и пошли формулы на 10 страниц. Вопрос: математики, физики, химики, они нарочно, что ли, усложнить себе жизнь пытаются? Нет, просто для сложной задачи это самая краткая, однозначная и точная запись -> следовательно, самая понятная, адекватная задаче. Вспомним, как в школе заучивали правила дифференцирования/интегрирования, на естественном языке это длинное и непонятное месиво, на языке формул — все ясно, если привыкнуть. Точно так же решение алгоритмически сложной проблемы на С — длинное и непонятное, за деревьями леса не видно. Программы на ФЯ — это те же самые мат. формулы, только исполняемые. Отсюда популярность в академическом мире. Но я думаю, от них и неакадемический мир может получить определенные преимущества. Давайте откроем наши mind'ы новому (а по сути, хорошо забытому старому).
Я отлично понимаю, что ФЯ — это не силвер буллит. Я отдаю себе отчет в том, что для Явы и С++ задач еще на 20 лет хватит. А также о том, что мне еще долго писать на С++ и C# "за еду", оставив ОКамл/Хаскель в качестве хобби и для решения задачи в аспирантуре. Но Яве и особенно, С++ (при всем уважении) нужно подвинуться.
Уфф, о чем это я? Мне же через три дня сдавать редактор конфигурационных файлов в формате XML, с драг-н-дропом и проперти-гридом, а там еще конь не валялся, что я тут делаю? Раскланиваюсь, не судите слишком строго...
reductor wrote:
> C>Игры, требовательные десктопные приложения, системный софт. > Ну если требовательные, тогда конечно С++ нельзя, он медленный — куча > тормозит из-за фрагментации. Да и на просто аллокацию у него времени > уходит раза в три больше, чем у окамла.
Хватит уже бред нести про фрагментацию. Надоело уже, честное слово, — вы
не знаете даже о чем говорите. С++ную кучу можно обвинять в
тормознутости, но уж точно не в фатальной склонности к фрагментации.
Так же, следует знать, что в С++ есть НЕ ТОЛЬКО объекты в куче.
> Давайте уже договоримся — нечего делать в прикладном софте ручному > управлению памятью. > Это очень дорого. Во всех смыслах.
Да? Я вот так не считаю — ручное управление требует некоторой
аккуратности, но вполне окупается за счет более мальениких и быстрых
программ.
> C>RTFM: http://www.memorymanagement.org/ > Ну вот только не нужно этой пошлости. > Конкретно скажите у какого типа GC какие паузы и тп.
У любого современного GC есть паузы при полной сборке — из-за того, что
GC нужно остановить мутатор на время сканирования working set'а. Есть
техники, которые позволяют эту паузу уменьшить, но они требуют
дополнительного затрата времени и памяти.
Паузы GC особенно хорошо заметны при работе с IDEA или ReShaper на
больших проектах.
> И что где дороже того, что в С++ получается. > Ну вот пусть в том же окамле. А то там Лерой как-то выкладывал > калькуляцию по этим вещам, хочу сравнить вашу и его.
ОК. Давайте сравним время создания/удаления автоматических объектов и
ваш GC. Хотите?
> Абсолютно неинтересной невозможности компактнуть хип правильно сказать. > "интересных преобразований"
Еще раз: в С++ можно НЕ ДОПУСКАТЬ фрагментации кучи. Это делается за
счет более медленных алгоритмов распределения памяти, что компенсируется
наличием очень быстрых автоматических объектов.
> C>А что, вы один должны гнать sales-talk десятилетней давности про GC? > Чооо? эт где?
Прочитайте свои слова про всесильность GC...
> Вот этого я кстати не понимаю. Даже если дам ссылку на докуменртацию > по FFI, то что? > Что вы этим хотели сказать?
Вот есть у меня структура:
struct MyStruct
{
int a, b, c;
std::string name;
};
Мне надо поместить ее инстанс в shared-memory. То есть два (или более)
процесса будут видеть один и тот же объект, но из разных адресных
пространств. Причем виртуальный адрес этого объекта в разных процессах
будет разный.
В С++ это делается достаточно просто — объект просто создается внутри
блока разделяемой памяти, а указатели внутри объекта представляются в
виде смещений относительно начала блока. При этом скорость доступа будет
лишь немного медленнее обычной.
> Причем про shared memory непонятно — как это относится к мемори > менеджменту-то?
Здравствуйте, reductor, Вы писали:
R>А что касательно системного софта — R>Сколько раз увидишь человека, который пишет ядро на С++, столько раз и убей его R>И что характерно, на том уровне уже неважно какие синтаксически навороченные аллокации в языке.
Уже несусь на форум C++. Буду убивать. Спасибо за информацию. Один маленький вопрос, я тоже писал ядра на С++. Каким способом покончить самоубийством? R>Важно другое. Вот например то, что в cyclone
Ооо. Последнее желание перед смертью. Увидеть человека который писал ядра на cyclone. Облобызаю по самое нехочу.
E>Функциональное программирование прекрасно, оно — радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
E>Каким-то религиозным духом попахивает
Вообще то, это цитата из раздела "не причины". Я воспринял это как сарказм.
Здравствуйте, Глеб Алексеев, Вы писали:
ГА>Уфф, о чем это я? Мне же через три дня сдавать редактор конфигурационных файлов в формате XML, с драг-н-дропом и проперти-гридом, а там еще конь не валялся, что я тут делаю? Раскланиваюсь, не судите слишком строго...
Да нет, Глеб, все супер. И все так и есть. В принципе.
Нужно только понимать, что для каждой задачи нужен свой язык. Где-то функциональные языки рулят неимоверно. Когда таких задач станет большинство, тогда и эти языки будут мейнстримом. Хотя, скорее, в существующие императивные языки будут добавлены лучшие качества функциональных.
Пока же, к примеру, есть rsync, написанный на C, и unison, на OCaml. Rsync я могу использовать практически везде (даже на HP NonStop-ах). А unison -- только на мейнстримовых платформах. Вот и толку мне сейчас от OCaml-а. Столько же, сколько от Lisp-а. Это если брать текущий момент. А что будет дальше -- поживем, увидим
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Не удержался...
Есть две темы по которым авторы обещают то что они в раю, и вот вам дорога как до него добраться. Это функциональные языки и XP. И эти люди очень обижаются. Они зовут в рай, а мы не идем. И что не идет туда народ, там же рай?
С уважением, Gleb.
ЗЫ сюда еще Oberon неплохо бы приписать.
0xDEADBEEF wrote: > > ЗЫ. Когда приходят к нам наниматься, я прошу кандидата с написать с нуля > любой алгоритм сортировки. Как ни странно, встречаются экземпляры, > которые не могут. И их достаточно много.
Я бы написал сортировку пузырьком, чтобы не рисковать в стрессовых
условиях собеседования.
Интересно, вы бы это расценили как плюс или как минус?
P.S. Мы использовали аналогичный подход на своих собеседованиях, только
давалось штук 10 задач, и "подсудимому" самому предлагалось решить,
какие из них выполнять, а какие нет.
Вместо сортировки у нас был подсчет числа локальных максимумов в массиве
чисел. Впрочем, сортировка тоже была — но quick sort, и мало кто за нее
брался.
Опыт показал, что такой подход позволяет очень хорошо узнать человека
как специалиста, за час-полтора времени собеседования. Например, очень
хорошо видно, с чьим кодом будут постоянные проблемы из-за отсутствия
хоть каких-нибудь проверок во время исполнения.
Почти все правильно. Основной плюс функциональных языков — это математика. Очень большой плюс. Основной минус функц. языков — это математика. Слишком на эту математику все завязано. А это не панацея. Большинство коммерческих продуктов — это большое количество сущностей с простейшими алгоритмами. На императиве можно меньше думать и больше делать. В случае функциональных языков для подобных задач приходится думать поболее, что компенсирует то что, во многих случаях, кода на нем пишется меньше. Кроме того, в коммерческой разработке задача работы и адаптации ресурсов компьютеров встречается значительно чаще чем сложные и интересные мат. алгоритмы с мат. формулами.
Здравствуйте, eao197, Вы писали:
E>Нужно только понимать, что для каждой задачи нужен свой язык.
Да, да, да! Так и есть! И можно а) выбрать его из всего доступного инструментария — (Питоны, ОКамлы, ХАскели, Перлы, и Явы, C и C++, естественно) или б)реализовать на единственном языке, который знаешь от и до. Мне вариант а) больше импонирует. E>Где-то функциональные языки рулят неимоверно. Когда таких задач станет большинство, тогда и эти языки будут мейнстримом. Хотя, скорее, в существующие императивные языки будут добавлены лучшие качества функциональных.
E>Пока же, к примеру, есть rsync, написанный на C, и unison, на OCaml. Rsync я могу использовать практически везде (даже на HP NonStop-ах). А unison -- только на мейнстримовых платформах. Вот и толку мне сейчас от OCaml-а. Столько же, сколько от Lisp-а. Это если брать текущий момент. А что будет дальше -- поживем, увидим
Как раз с точностью наоборот. Unix'ы были созданы в американских университетах, и все новые языки появляются в первую очередь именно под юниксами. С инструментальной поддержкой (отладчики, интегрированные среды и т.д) дела обстоят похуже, а вот с поддержкой ОС — никаких проблем. Мало того, мне для полноценных экспериментов с ОКамлом пришлось установить cygwin, вражеский Emacs (для tuareg mode), "скрипя сердцем" привыкнуть к его горячим клавишам, научиться писать Makefile-ы (всю жизнь работал с чем-то типа IDE — Турбо-Паскаль, Борланд С, Дельфи, Визуальная Студия и Сликедит, когнитивный диссонанс по сравнению с Емаксом — ужасный, но оно того стоит).
reductor wrote: > > Кроме того, что некоторые вещи в С++ будешь делать год, чтобы > заработало, другие там еще и вовсе невозможны по фундаментальным причинам.
Не согласен. На C++ можно написать LISP за неделю, а все остальное
сделать на LISP'е
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Глеб Алексеев, Вы писали:
GZ>Почти все правильно. Основной плюс функциональных языков — это математика. Очень большой плюс. Основной минус функц. языков — это математика.
Отлично сказано ! Афоризм, однозначно. GZ>Слишком на эту математику все завязано. А это не панацея. Большинство коммерческих продуктов — это большое количество сущностей с простейшими алгоритмами. На императиве можно меньше думать и больше делать. В случае функциональных языков для подобных задач приходится думать поболее, что компенсирует то что, во многих случаях, кода на нем пишется меньше. Кроме того, в коммерческой разработке задача работы и адаптации ресурсов компьютеров встречается значительно чаще чем сложные и интересные мат. алгоритмы с мат. формулами.
Возразить нечего. Только есть надежда (несколько наивная), что в определенных пределах я сам могу выбирать задачи, которые мне интересно решать.
Столько же, сколько от Lisp-а. Это если брать текущий момент. А что будет дальше -- поживем, увидим 
! Афоризм, однозначно.