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

E>>Неужели ты проводишь формальные доказательства?
Pzz>Прикидываю в голове, как бы я его приводил.
И что, пишешь пред/пост условия и инварианты циклов? Я, например, очень очень редко пишу такой непонятный и ответственный код, что првожу его формальные док-ва. Обычно я и так знаю зациклится прога или нет

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

A>>Зачем этот rocket science при разработке типичных бизнес-приложений?
Pzz>Чтобы на отладку уходило не 80% рабочего времени, а 20.

Прикольно. Я в целом согласен с тем, что квалифицированные люди лучше неквалифицированных, но иногда сотрудники бывают всё-таки слишком умными
Например у нас был один мужчина безусловно очень квалифицированный и хорошо знавший "rocket science" и не только. Одна беда -- он 95% времени занимался не скучным программированием, а выстраиванием каких-то одному ему понятных конструкций, обладавших какими-то мифическими преимуществами.
Так, например, ему надо было провести серию экспериментов по определённому типу обработки неких специфических изображений. В результате экспериментов должно было получиться несколько фильтров, реализованных на С++.
Как бы решал задачу я?
Ну написал бы несколько классов, которые позволяют быстро рожать экспериментальные обработчики (тем более, что там было не на пустом месте, а в рамках довольно развитого фреймворка по работе с изображениями), ну и оболочку какую-нибудь простенькую на приватном аналоге MFC склепал бы. Ну и перешёл бы к экспериментам. Думаю что недели за две справился бы с запасом. Ну стажёр, который не так всё это знает, понимает, и вообще тормозит, действуя под моим руководством, по этой примерно программе действий, справился бы за месяц-два наверное. А обсуждаемый мужчина склепал на дельфи крутую очень оболочку, к которйо склепал крутое средство разработки фильтров, что-то вроде скрипта приладил, позволявшего строить эти фильтры прямо из оболочки. Потом быстро выяснилось, что скрипт нужный тип обработчиков описывает хреново, и он талантливо приделал возможности по использованию из всей этой байды dll, потом эти dll стали от чего-то испытывать трудности с инициализацией crt, ну и так далее. Короче через десять месяцев героической борьбы с трудностями про этот проект вспомнили нормальные менеджеры. Начальника очень основательно поимели, а самого сотрудника выгнали, после чего сотрудник средних способностей с успехом закончил всю эту разработку менее чем за месяц. Тупо просто и эффективно, и даже переиспользовав часть результатов своего предшественника...

Так что бывает и так, что разработчик для данной задачи слишком таки умён Даже для очень сложной задачи...

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

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

Да ладно вам. Конечно хорошее образование -- это скорее плюс, особенно если к нему прилагается ещё и голова, позволяющая не переусложнять без нУжды, но таки те же формальные грамматики, это не что-то такое запредельное, не гомотопическая топология, всё-таки. Можно поботать какую-нибудь толковую книжку, скажем Ахо Ульмана, например, и сразу всё при них узнаешь. И про КС и про какие хочешь ещё.

Я бы, кстати, скорее про конечные автоматы советовал ботать, а не про грамматики. IMHO, концепция автоматов намного более полезна программисту, чем парсеры...

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

ГВ>Плохо, что эти же самые потом полезут в менеджеры (а куда ещё податься бедному кодеру?) и устроят свистопляску.
IMHO именно менеджеру, а не архитектору, скажем, нужны совсем другие знания и навыки, чем знание CS...
И хорошо бы очень
1) Иметь опыт работы на должности, которой этот менеджер будет потом управлять, ну чисто чтобы понимать своих подчинённых, их способы халявить, или, наоборот, что есть большая работа, что круто, что не очень, что нужно, что не очень и т. д.
2) Нужна таки подготовка именно в искусстве менеджера...

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

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

Pzz>А если нет готового? Вот выдал вам заказчик задание — понимать текстовые файлы, которые выплевывает из себя программа, написаная на Коболе. Синтаксис этих файлов более-менее известен, но поменять его нельзя, поскольку Кобола никто уже не знает (да и вообще, кто ж вас пустит ковырать драгоценный доисторический код, написанный на нем?). Синтаксис при этом такой, что регулярными выражениями не обойдешься.

IMHO вывод проги на коболе, да ещё такой, что регулярных выражений мало для разбора -- это немного фантастично звучит. Попробуй придумать пример такого вывода? Я вот могу пока придумать такой, например:

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

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

O>>

12/1/2007  11:55:00 89167734455   OUTGOING  L1C2 05:33

_>No hire, sorry.

А на хрена тут какие-то прасеры, более сложные, чем регулярные выражения?

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

I>файлы(всё множество) хранят состояние объектной модели с рутовым объектом.
I>Подобное в БД решается через хибернейт, только ни один движок БД не дает нужного перформанса да и sql нам ни к чему.

Два вопроса.
1) Зачем они всё это хранят в виде текстов?
2) Зачем везде разный сложноразбираемый формат, а не какой-нибудь унифицированный, например XML?

Ну и ещё один комментарий. IMHO если люди утверждают, что они хранят сложную модель в виде вороха разноформатных текстовых конфигов, разбираемых скриптами на самописном интерпретаторе, и при этом рвут по быстродействию СУБД, то они не умеют таки пользоваться СУБД, или что-то недоговаривают

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

O>В чем смысл собственного языка, можешь пояснить на наглядном примере?

Могу, конечно. Скажем тебе надо выциплять из русского текста согласованные фразы. IMHO написать спец. язык, позволяющий адекватно описывать понятие "согласованная фраза" сильно облегчит тебе работу, по сравнению с "голым C#"

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

E>Так что бывает и так, что разработчик для данной задачи слишком таки умён Даже для очень сложной задачи...

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

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

IID>

IID>const int iLinesInACircle = 100;
//  абсолютно не понятная константа. 


IID>void DrawCircle(int x, int y, int r)
IID>{
IID>    int x1,y1,x2,y2;
IID>    double angle = 0;
IID>    double angle_add = 360.0 * PI / iLinesInACircle;
//   Абсолютно не понятная формула. Во-первых тут есть ошибка с переводом углов, на которую тебе указали
//    Во-вторых тут нет зависимости от r, что как-то странно и неожиданно.
IID>    for(int i=0; i<iLinesInACircle+1; i++, angle+=angle_add)
//    непонятно зачем у цикла два параметра от чего бы по углу не итерировать?
IID>    {
IID>        x2 = x + r*cos( angle );
IID>        y2 = y + r*sin( angle );
IID>        if ( 0 != i )
//              Тоже не понятно зачем так сурово. Неужели sin( 0 ), cos( 0 ) тебе не известны?
IID>            DrawLine(x1,y1,x2,y2);
IID>        x1 = x2;
IID>        y1 = y2;
IID>    }
IID>}
IID>

Ну и как-то не понятно зачем бы не рисовать окружность стразу в восьми направлениях? Сильно реже тригонометрические функции считать бы пришлось...
Или это прога для плоттера?

IID>При этом я знаю про целочисленные алгоритмы (см. пост выше), и вскользь о них упомяну (на собеседованиях, как и в РСДН постах мне напрягаться лниво). Что вы скажете обо мне-кандидате ?

Ну что скажу? Неаккуратный и ленивый кодер, не умеющий ясно думать, даже когда понимает, что это важно для его карьеры/репутации...

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

И>имею глупый вопрос. а что такое CS? контр страйк чтоль?

O>Есть извращенные форматы файлов, в том числе бинарные, их приходится разбирать ручками. Свой собственный язык тут не помогает, т.к. надо писать примерно то же, что и на чистом C#. А если еще прицепить helper assembly с утилитками помогающими разбору файлов, то вообще все замечательно получается.

Парсер своего языка как правило писать не надо, потому что есть вагон генераторов парсеров (ANTLR хотя бы, он и под C# генерит). Достаточно описать грамматику и как-то обработать полученное дерево разбора. Описать грамматику как правило проще, чем городить свой парсер. И бинарные форматы тоже не обязательно ручками разбирать — можно также описать грамматику и сгенерить парсер. Это проще, чем разбирать ручками.

Разумеется, я не призываю использовать генератор парсеров для разбора CSV или логов. Но в некоторых случаях split и regexp все же не хватает.

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

E>Ну что скажу? ...

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

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

И>>если мне вдруг понадобится помощь математика для упрощения сложного выражения, то я пойду к математику за консультацией.
AVK>Я так понимаю, что логическое выражение вроде !(!(a && b) || (c && d)) это уже сложное, и нужно идти к математику?

А как и зачем ты собираешься его упрощать?

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

E>Да ладно вам. Конечно хорошее образование -- это скорее плюс

Скорее? Что, есть сомнения?

E> Можно поботать какую-нибудь толковую книжку, скажем Ахо Ульмана, например, и сразу всё при них узнаешь. И про КС и про какие хочешь ещё.

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

E>Я бы, кстати, скорее про конечные автоматы советовал ботать, а не про грамматики. IMHO, концепция автоматов намного более полезна программисту, чем парсеры...

Одно без другого не живет. Автоматы, это самая самая база, без которой о системности знаний в CS говорить не приходится. И, кстати, коль уж ты тут против булевой алгебры ополчился: как можно "ботать" автоматы без знания булевой алгебры?

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

E>А на хрена тут какие-то прасеры, более сложные, чем регулярные выражения?

Даже для регулярных выражений нужно кое какую теорию знать. К примеру, что такое регулярная грамматика. Чтобы потом не пытаться разобрать регексами то, что ими не разбирается регулярно (помнится, в дотнете товарищ пытался регексами sql разобрать, и очень долго упирался, когда ему говорили, что это невозможно). Нужно примерно представлять, как НКА/ДКА парсера регексов работает, чтобы понимать как решать те или иные задачии наиболее эффективным способом.

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

E>Да надо что-то простовыводимое спрашивать. Скажем попросить посчитать сумму чисел от 1 до 1000, или спросить что-нибудь типа "что больше два в пятой или пять во второй?"

Ты это собственным эйчарам скажи

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

E>Интересно, на хрена бы cout в Windows-программе? А ещё интереснее, нахрена в программе под MAC OS...

Это была просто иллюстрация. Не надо пытаться делать выводы на основании аналогий. Если плохо представляешь себе дотнет — просто поверь, без TextWriter там обходится весьма сложно, Windows это или MacOS.

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

I>>как образом ты хочешь пользовать здесь C# что бы все было достаточно наглядно, быстро и гладко ?
O>Пишешь на C# сборку, которая берет в качестве параметра конфиг и по нему разбирает текстовый файл. Подключаешь ее, как плагин к основной программе. Если надо разбирать хитровы..тый формат, пишешь сборку заточенную под него, если есть варианты данного формата, то цепляешь к ней еще и конфиг. Потом ассоциируешь тип файла со сборкой и конфигом. Все.

Я так и думал, что читать ты не умеешь.

>поначалу был вариант такой — в конфиге просто прописывались методы из сборки на C#. Слишком много кода было и этот подход умер сам собой.

Спасибо, до свидания.

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

>В зависимости от формата файла
O>1) Regex — годится для большинства форматов
O>2) String.Split — если поля разбиты разделителями типа запятой
O>3) String.Substring — если поля имеют фиксированную позицию
O>4) XmlReader или как там его — если xml
O>Делаешь эти четыре сборки с элементарным конфигом и их тебе хватит на 90%.

Ты свалял дурака и не удосужлся прочесть текст в сообщении чуть выше.

Все это и ежу ясно.

Язык нужен _потом_, после твоих регэспов и всякого хлама.

O>В чем смысл собственного языка, можешь пояснить на наглядном примере?

Смотри сообщение выше. Ты скипнул весь текст, ткнул пальцем в небо а теперь снова вопрошаешь "В чем смысл собственного языка"