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

E>>Да ладно вам. Конечно хорошее образование -- это скорее плюс
AVK>Скорее? Что, есть сомнения?
Ну некоторые есть, но в целом, в основном, они из-за некоторой неверной направленности отечественного образования, по крайней мере.
IMHO, для разных работ нужна разная квалификация, и излишняя тоже не хорошо, но я не про это. Я про то, что для нормального разработчика важнее всего быть хорошим инженером. А уж мат. подготовка -- уже опциональна, хотя и крайне желательна. А вот блестящий математик, но плохой инженер совсем не годится


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

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

Да ладно, не живёт
Неужели ты не сможешь описать/разобраться в КА, который, например, идёт по двум соседним RLE-строкам изображения и выдаёт RLE-строку изображения ужатого вдвое по обеим осям?

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

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

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

Понятно, что если ты тупой, упрямый и неотёсанный болван, к тому же ещё и не обременённый "излишними" знаниями, то ты наверное зря таки в программисты двинул.
Но для того, чтобы понимать, что регэкспами описывается далеко не всё, совсем не обязательно что-то знать о КС-грамматиках или ещё о чём. Вполне достаточно попробовать написать регэксп, который проверяет баланс скобок

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

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

BZ>осталось доказать, что неучтённая площадь пренебрежимо мала

А зачем? Тебя же просят вспомнить формулу, а не доказать её...

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

J>Из функционального задания полуокружности получаем интеграл для длины . Так как мы не знаем, что это r arcsin(x/r), да и вообще arcsin явно слишком сложно вспомнить, нужно догадаться, представить это в виде , где r f(x/r) — первообразная. Ну вот и все. И никаких \pi. Чтобы было \pi надо вспомнить определение. , т.е. . Вот вам и формула. Но все равно, надо кучу чего знать и помнить, чтобы её вывести хотя бы так.

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

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

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

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

E>Два вопроса.
E>1) Зачем они всё это хранят в виде текстов?

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

E>2) Зачем везде разный сложноразбираемый формат, а не какой-нибудь унифицированный, например XML?

формат простой — csv.

XML тоже есть но в новых продуктах. старый софт ихний выбросить никак нельзя.

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

СУБД помогат только в случае с многопользовательским доступом, это отдельный прокт, там Оракл пользуется.

А тех, вроде нашего, самая частая операция — вгрузить всю модель в память. Как это побороть за 8 лет ничего так и не придумали, а на этой операции дохнут все СУБД до единой.

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

M>>Вот вспомнился анекдот из советских времен:
M>Я слышал про конус. В случае с циллиндром как раз и надо прощадь круга знать. А в случае конуса нужно еще коэффициент вывести.

Твоя реплика напомнила мне реакцию на анекдот одного чувака, с которым я познакомился при поступлении в один элитный ВУЗ. Чувак был такой, "прямой", скажем, но тоже поступал и мы жили абитурами вместе в общаге.

Так вот, я рассказал анек:

Разговаривают генерал и полковник на полигоне, рядом орёт движок танка. Генерал подзывает прапора:
-- Товарищь прапорщик! Заглушите танк!
-- Есть! А-а-а-а-а!!! (очень громко орёт)

Ну и этот парень и отвечает: "Клёво! Мой папа тоже прапорщик, только он на аэродроме служит"...
Я, кстати, только потом понял, что это он так стебётся тонко. Хотя папа у него действительно на аэродроме служил

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

AVK>Ты это собственным эйчарам скажи
Дык наши эйчары не ставят целей выявить знание элементарной математики Человек же про это спрашивал...
Я нахожу нашу систему отбора несколько причудливой, но поскольку все мы тут отбирались таким образом, и вышло в целом не плохо, то я за консервативный подход к этому вопросу

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

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

Ну, я даже не знаю что и сказать. У тебя, видимо, образование физтеховское?

E>IMHO, для разных работ нужна разная квалификация, и излишняя тоже не хорошо

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

E> Я про то, что для нормального разработчика важнее всего быть хорошим инженером. А уж мат. подготовка -- уже опциональна

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

E>Да ладно, не живёт
E>Неужели ты не сможешь описать/разобраться в КА, который, например, идёт по двум соседним RLE-строкам изображения и выдаёт RLE-строку изображения ужатого вдвое по обеим осям?

При чем тут я?

E>Но я не ополчился. IMHO, если программист знает булеву алгебру, то это хорошо. Плохо, если он без дела её пытается всюду применять.

А что, тут кто то утверждал, что это хорошо?

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

E>Но для того, чтобы понимать, что регэкспами описывается далеко не всё, совсем не обязательно что-то знать о КС-грамматиках или ещё о чём.

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

E> Вполне достаточно попробовать написать регэксп, который проверяет баланс скобок

И каждый раз так пробовать до просветления?

E>Я к тому, что через хороший уровень ДМ -- это только один из путей к тому, чтобы научиться хорошо разбирать логи

С логами — это не ко мне. Мне приходится решать задачки посложнее, нередко даже в LL(k) уложиться не получается.

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

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

Всё-таки не первый, а третий. Контрольный вопрос: "Назовите противодействие весу тела"...

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

AVK>>Ты это собственным эйчарам скажи
E>Дык наши эйчары не ставят целей выявить знание элементарной математики

А что они ставят целью, выдавая мутные матформулы?

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

M>Думаю, что по школьной математике ты меня не завалишь. По физике или биологии, возможно. Но мы же говорим об инжинерах.

Кстати, не факт. Надо поспрашать какую-нибудь полную хрень. Скажем попросить перечислить признаки параллелограмма, или там построить треугольник по медиане, высоте и гипотенузе...
IMHO завалить можно любого, тем более не в его области специализации. Только, IMHO, это ничего не значит...

Здравствуйте, Valery A. Boronin, Вы писали:

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

VAB>работать-то с новичком не только коллеге, "мнению которого нужно больше доверять".

VAB>Тут не надо дизъюнкции — тут конъюнкция уместна.

Это очень жОсткий набор.

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

Все люди когда то чего то не знали или не знают.

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

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

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

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

Бывает. Надо уволить начальство в этом случае ибо оно не справлятся с задачами.

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

I>формат простой — csv.
I>XML тоже есть но в новых продуктах. старый софт ихний выбросить никак нельзя.

зачем тогда сложные парсеры? Или речь не о парсерах, а о каких-то скриптах, описывающих саму модель?

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

I>СУБД помогат только в случае с многопользовательским доступом...
IMHO, это не правда. По крайней мере в общем случае.

I>А тех, вроде нашего, самая частая операция — вгрузить всю модель в память. Как это побороть за 8 лет ничего так и не придумали, а на этой операции дохнут все СУБД до единой.

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

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

>> Вполне достаточно попробовать написать регэксп, который проверяет баланс скобок
AVK>И каждый раз так пробовать до просветления?

Ну, в целом, стратегия "попробовать написать регэксп, если это выходит как-то раком, или не выходит вообще, попробовать что-то другое" не так уж и плоха...

E>>Я к тому, что через хороший уровень ДМ -- это только один из путей к тому, чтобы научиться хорошо разбирать логи

AVK>С логами — это не ко мне. Мне приходится решать задачки посложнее, нередко даже в LL(k) уложиться не получается.

Ну тогда тебе знание грамматик -- существенно. Но это же очень специфично для конкретно твоих задач...
А мне вот одно время нужно было обрабатывать тексты на естественных языках, там грамматики в смысле LL(k) практически бесполезны

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

I>>формат простой — csv.
I>>XML тоже есть но в новых продуктах. старый софт ихний выбросить никак нельзя.

E>зачем тогда сложные парсеры? Или речь не о парсерах, а о каких-то скриптах, описывающих саму модель?

Парсер простой как доска, а скрипты запускаются после парсинга.

I>>СУБД помогат только в случае с многопользовательским доступом...
E>IMHO, это не правда. По крайней мере в общем случае.

Про общий случай я отлично осведомлён.

E>Ну значит у вас случай "что-то не договаривают"...
E>Хотя всё равно как-то странно, ну есть у вас какая-то объектная модель, есть способ её представления в памяти, есть части модели, для загрузки которых из старых прог надо написать какие-то фильтры, но старые проги не меняются же? Есть новые проги, откуда, по идее, можно бы получать объекты и как-нибудь поудобнее... Но зачем тут какие-то навороченные парсеры?

Был и варант с фильтром. На питоне писался конвертор. Данный момент эволюционировал до логической смерти

У кастомера разработка тоже не прекращается, они на новые технологии не спешат

А у нас нужна совместимость между версиями например. Модель меняется довольно активно.

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

AVK>А что они ставят целью, выдавая мутные матформулы?
Например?

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

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

AVK>Ну, я даже не знаю что и сказать. У тебя, видимо, образование физтеховское?
Ну и физтеховское. Физтеховское -- вычматы...
А что, так заметно?

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

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

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

E>> Я про то, что для нормального разработчика важнее всего быть хорошим инженером. А уж мат. подготовка -- уже опциональна
AVK>Опять же — я не очень понимаю, как быть хорошим инженером в области софтостроя без знания самых самых основ дискретки.
Ну у некоторых как-то получается...
IMHO, кстати, "быть хорошим инженером" -- это более общий навык, чем разработка ПО. Хороший инженер-механик, если его правильно учить проганью будет и хорошим инженером-программистом, так скажем.


E>>Да ладно, не живёт
E>>Неужели ты не сможешь описать/разобраться в КА, который, например, идёт по двум соседним RLE-строкам изображения и выдаёт RLE-строку изображения ужатого вдвое по обеим осям?
AVK>При чем тут я?
Ну и не ты, тоже. IMHO суть КА на булеву алгебру никак не завязана

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

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

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

Меня именно аналогия приколола